The $200-a-Week Engineer: AI Spend Caps Have Arrived

Tesla reportedly capped per-engineer AI spend at $200 a week. Uber is tightening limits too. Caps ration the work—cutting context waste is how you keep shipping under one.

Six months ago, Tesla reportedly ran internal dashboards that ranked employees by AI token consumption—burn more, climb the leaderboard. As of July 6, the same company caps employee spending on third-party AI tools at $200 a week, with anything above requiring manager sign-off. The trigger, per people familiar with internal usage: some engineers were consuming thousands of dollars in tokens every week, with no natural ceiling in sight. The cap covers models from Anthropic, OpenAI, and Google—though reportedly not xAI’s Grok, the company Elon Musk also runs and Tesla has invested $2 billion in, even as sources say most Tesla engineers prefer Claude on merit.

And Tesla isn’t alone: Uber and other companies are reportedly tightening similar internal limits.

From token leaderboards to spend caps in half a year. That’s the whole story of enterprise AI in 2026, compressed.

Why Caps Are Showing Up Now

Caps are the demand-side response to a supply side that just went metered. Claude Fable 5—the strongest coding model available—leaves included plan access and moves to usage credits at $10/M input, $50/M output (as of publication, included access runs through July 19, its third extension; once your allowance is spent there’s no automatic fallback—you pay credits or switch models). Meanwhile the model race is widening the price spread underneath it: OpenAI’s GPT-5.6 line now includes a budget tier around $1/$6, Grok 4.5 landed at $2/$6, and Gemini 3.5 Pro is expected imminently with a 2M-token context window near $1.25/$10.

Notice what that spread means. The cheap tiers are getting cheaper while the frontier gets more expensive—and engineers, given the choice, reach for the frontier. When individual engineers can each burn thousands a week on the best model and the CFO can’t see a ceiling, a cap is the bluntest available instrument. So companies are reaching for it.

But a cap has a failure mode every engineering leader should see coming: it rations work, not waste. An engineer who hits $200 on Wednesday doesn’t stop wasting tokens—they stop shipping. The leaderboard measured the wrong thing going up; the cap measures the wrong thing coming down. Neither asks where the tokens actually went.

Where the Tokens Actually Go

Here’s the uncomfortable arithmetic underneath both the leaderboard and the cap: a large share of what coding agents spend is context the task never needed.

Agents find code with keyword search or vector similarity—instruments that optimize for recall and return everything tangentially related to a term. In code, the relationship that matters isn’t lexical similarity; it’s the dependency edge. OrderService.place_order() calls a repository, which uses a cache policy. Those files form a chain. Keyword search returns the firehose; the chain is four files. (We’ve written the full primer on why retrieval over-fetches by design.)

Coograph ships a committed benchmark—a single fixed task (“Add caching to OrderService.place_order()”) against a single committed fixture (bench/fixtures/sample-app/), both checked into the repo so anyone can rerun it. On that task:

• Naive grep + read all matches: 20 files, ~4,764 input tokens, 21 tool calls.
• Graph minimal-context query: 4 files, ~969 input tokens, 5 tool calls.

~80% of the input tokens were noise. One representative task, not a universal guarantee—but the mechanism is the same on every task: the agent reads the chain or it reads the firehose, and the firehose is what your engineers’ $200 is buying.

The Same Cap, ~5× the Work

Run the benchmark ratio against a fixed budget and the cap changes meaning. If a task’s input context drops from ~4,764 tokens to ~969, the same spend covers roughly five times as many tasks (4,764 ÷ 969 ≈ 4.9—illustrative, input tokens only; output and reasoning tokens scale with the task, not the retrieval waste). The engineer who hit the cap on Wednesday now hits Friday with room to spare—same model, same cap, same work per task. Nothing was rationed. The waste was cut.

That’s the reframe for anyone about to copy Tesla’s policy—or anyone about to live under one. The cap is a symptom. The disease is that nobody instrumented what the tokens bought. A dashboard that ranked engineers by tokens-per-task-shipped would have told a very different story than one that ranked raw burn—and a context layer that cuts the per-task denominator is worth more than either dashboard.

What This Looks Like in Practice

Coograph is an open-source, MIT-licensed parser and graph engine. It parses your codebase with tree-sitter (Python, TypeScript, JavaScript, Go, Rust, Java, C#, Ruby, and more, with a regex fallback) into one local SQLite file—.code-graph/graph.db—that never leaves your machine. Your agent queries it through MCP tools (get_minimal_context, query_graph) instead of grepping, and gets the dependency chain in one pass. A git hook re-parses only changed files per commit.

Setup is minutes: clone Coograph as a sibling directory, run /coograph-init from Claude Code (or Copilot, Cursor, Windsurf, Codex CLI, OpenCode, Aider, Cline), and build the graph. It’s model-agnostic—which matters precisely because the price spread is widening: whether a task routes to Fable 5, GPT-5.6, or a budget tier, the graph cuts what you feed it. The saving compounds with routing; it doesn’t compete with it.

The leaderboard era rewarded burning tokens. The cap era punishes it. Neither fixes the fact that most of the burn was noise—an agent reading files it never needed, now with a manager sign-off attached. Generate your first graph with the getting-started guide, see what’s inside it on the code-graph page, or talk to us about Coograph Pro if your team is about to live under a cap. The benchmark is committed. Rerun it before you set the budget.