Your Engineers Have a Burn Rate Now

That is one account. The wider market looks like this. A founder and CTO posting on Hacker News in November: $638 on Cursor in six weeks, on track for over $5,500 a year for a single seat, and he described himself as genuinely shocked. Another developer reporting that a friend was burning $2,000 a month on Cursor. A commenter under an Opus thread noting that an agentic loop on the API can run at roughly $100 an hour if left unattended. Inside portfolio companies, we regularly see individual power users clearing $3,000 to $5,000 a month on their own, and one account last quarter cleared $10,000.

None of these are hypothetical. They are the new ceiling. A year ago a senior engineer cost a company fully loaded salary plus maybe $50 a month in tooling. Today the same engineer, used hard, can book five figures a year in tokens before anyone signs anything off. The decision-rights question this raises is real: in almost no organization we work with has anyone formally authorized that spend, and in almost every one, it is happening anyway.

What the new line item actually looks like

The market has split into three pricing shapes, and most engineering teams are already running all three at once without noticing.

The useful mental shift is that these are not really competing products. They are different cost shapes for different kinds of work. Copilot and Cursor are seats with usage hidden inside. Claude Max is a compensation line item disguised as a subscription. Claude Code and Codex are cloud compute with an editor wrapped around them. Operators who treat them as one budget line end up managing none of them well.

Why the spread is 10x

The first time I saw an engineer burn a four-figure bill in a weekend I assumed something had gone wrong. The second time I assumed the same. By the fifth time I accepted that this is simply what usage-based agentic tooling looks like in the absence of discipline.

The variance is almost entirely a configuration story. A well set up Claude Code or Codex session uses prompt caching, loads only the files it needs, summarizes old conversation turns instead of replaying them, and reserves high-reasoning modes for the problems that actually need them. A poorly set up session does none of that. It re-ingests the monorepo every turn. It fans out to half a dozen MCP servers that each pull thousands of tokens of tool definitions into every single prompt. It leaves reasoning budgets on maximum for tasks that needed a two-line edit. It keeps running background processes whose output quietly drips into context until the window overflows.

The result is a spread that, in our experience inside portfolio companies, runs roughly 10x between the best and worst configured developer on the same team. The worst case is not usually malice or laziness. It is almost always an engineer who installed four MCP servers in the first week because a thread on X told them to, and has never opened the configuration file since.

That gap is the actual management problem. A team where everyone burns $100 is a boring line item. A team where the average is $200 but half the spend comes from two people is a team where you are paying for misconfiguration, not for work.

The conspiracy theories, and what is probably true

If you spend any time reading developer forums about AI coding tools right now, you will notice a second thing going on underneath the cost conversation. A steady drumbeat of engineers claiming that the model they are talking to today is not the model they were talking to a month ago. That Claude got dumber. That the Max plan quietly routes to smaller or quantized variants when demand peaks. That the API gives you the real thing and the subscription gives you something downsampled. That Enterprise is a different tier of service entirely, not just a different SKU.

Almost none of this is officially confirmed. Some of it is probably wrong. A meaningful fraction of it is probably right. It is worth understanding the specific theories in circulation, because they shape how operators should actually route their spend.

The underlying reality most of these theories are groping at is simpler than any individual rumor. Frontier model vendors are severely compute constrained. Data center buildouts are lagging demand. Subsidized subscription plans are a growth and distribution tool, not a high-margin product. Some HN commenters have estimated they can get the equivalent of $1,000 of Opus API usage out of a $200 Max plan, which, if even approximately right, means Anthropic is losing money on its heaviest subscription customers and has every incentive to find quiet ways to throttle them.

For an operator the implication is not outrage. It is routing. If model quality and consistency matter to your product, put your production and your serious coding load on the API or enterprise tier, not on a personal subscription. If you want the cheap subsidized subscription, treat it as exactly that, a subsidy you are welcome to while it lasts, priced more like a promo than a contract. Build your budget on the assumption that subscription behavior will get worse, not better, over the next twelve months.

Brute force and grounding

There are two mental models floating around inside engineering teams right now for how to use an agentic coding tool, and almost the entire 10x cost spread sits on the difference between them.

The first model is brute force. Hand the agent the whole monorepo. Install every MCP server you have heard of. Leave reasoning on max. Let a background agent run while you sleep. Run three parallel sessions in case one of them gets it right. This is the style we see in the engineers clearing four-figure monthly bills on their own, and it is seductive because it genuinely does sometimes work. The model will often, eventually, stumble into the right answer. The cost of getting there is buried in the invoice.

The second model is grounding. Give the agent the specific files it needs, a short and honest description of the task, one or two real examples of the pattern you want it to follow, and a small set of tools it can actually use. Keep the context narrow. Run the cheapest model that can plausibly do the work, and escalate only when the task demands it. Let the agent ask, not scan. This is the style we see in the engineers burning hundreds rather than thousands, and the difference in output quality is, honestly, in favor of grounding. Brute force produces PRs that technically run. Grounded sessions produce PRs that a human reviewer is willing to approve.

The illustration below is the argument in one picture. Same target. Three ways to reach it.

The third row is where this ties back to a point we made in MedGemma and the Local Models Moment. Once you are actually grounded, running the model on an on-prem or on-device stack stops being a research project and becomes a pure cost decision. The hard work of agentic engineering is picking the right context, not paying to re-read it on a hosted API. A grounded harness pointed at a local 4B or 27B model is, for a meaningful slice of coding work, both cheaper and more private than the same harness pointed at a frontier API, and the gap is widening every quarter.

None of this means local replaces hosted. It means the teams that have done the grounding work earn the right to route more of their traffic local, and pocket the difference. The teams still in brute force mode cannot, because a brute force agent pointed at a small local model just fails louder and cheaper. Grounding is the prerequisite. Local is the dividend.

The harness is the new build system

Every decade or so, engineering organizations acquire a new discipline that used to be optional and is now non-negotiable. Source control in the nineties. CI/CD in the 2010s. Observability in the late 2010s. What we are watching now is the same arc for what the Anthropic and OpenAI teams call the harness: the configuration around the model that decides how much of your codebase gets loaded, which tools are available, which model answers which kind of question, and how context is managed across a long session.

The harness is a first-class engineering artifact now. It lives in a repo, carries versions, gets reviewed like any other code, and has measurable quality. The specific levers that matter most in our experience:

None of this is exotic. It is roughly as complicated as writing a good Dockerfile. But it has to be written down, shared, and enforced, and almost no engineering organization we work with has put that discipline in place yet.

The Pro plan arbitrage hiding on your team

Here is the quiet story almost nobody in finance has noticed. A meaningful fraction of your best engineers are paying for AI coding tools out of their own pockets, and using them for work. Claude Pro at $20. Claude Max at $100 or $200. ChatGPT Pro at $200. They are not doing it to cheat. They are doing it because procurement is slow, the enterprise tier they were given is underpowered, and the productivity gap between a disciplined power user and an average seat license is genuinely career-defining.

From an individual engineer’s perspective this is rational. From an operator’s perspective it is a compliance and security failure in slow motion.

The answer is not to ban personal plans. That just pushes the behavior further underground. The answer is a reimbursed AI stipend that routes through a corporate-managed account: same model access, same power-user limits, but on your BAA, your SSO, your audit log, your retention policy. The stipend costs roughly what the engineer was already paying. The operational risk drops to something a CISO will actually sign off on.

Put a meter in the path

You cannot manage what you cannot see, and until recently the default visibility into AI coding spend was a monthly invoice and a vague sense of dread. The observability layer for this has matured fast in the last twelve months.

The pattern we are putting into portfolio companies looks roughly the same every time. Route every agent and IDE through an LLM gateway. LiteLLM, Helicone, and Portkey are the three most common choices. The gateway gives you per engineer token visibility, per project cost attribution, hard dollar caps, and a single place to enforce zero-data-retention flags. It turns the bill from an end-of-month surprise into something the team can see while the work is happening.

On the individual engineer side, ccusage and similar small CLIs give developers a local readout of their own Claude Code usage in real time. This matters more than it sounds. Most overspend comes from the moment an agent quietly enters a loop and nobody notices for two hours. A meter ticking on the engineer’s own screen catches this in minutes rather than days.

The more interesting metric, once the basic plumbing is in place, is not dollars. It is tokens per merged pull request. An engineer spending $400 a month and shipping 30 reviewed PRs is well configured. An engineer spending the same amount and shipping 2 is burning money on a thrashing harness. You cannot tell these apart without the gateway. Once you have it, the gap between teams is usually the single most useful signal a VP of engineering gets all quarter.

What I would put in place

We are writing this from inside portfolio companies where we are either running engineering or advising the people who do. The checklist is not complicated. The hard part is getting someone to own it.

The model I use now

A year ago, AI coding tools were a productivity experiment you ran on the side of your engineering budget. Today they are a variable cost line with a range that runs from a rounding error to a real number, and the spread depends on choices your operators have almost certainly not been asked to make yet.

The companies we see doing this well have stopped treating AI coding as a tools problem. They treat it like cloud compute: metered, useful, dangerous when nobody watches it, and boring when the defaults are good. The ones doing it badly are still pretending it is a SaaS seat, and quietly absorbing 10x variance inside a line item they do not look at.

If you are running engineering, or sitting on a board asking what the AI line on the P&L actually represents, get in touch. This is the kind of operating work we do inside portfolio companies. The gap between disciplined and undisciplined teams on this line item is already large enough to show up in the budget.