Nobody has figured out how to bill a coding agent

Disclosure before anything else: I work on typed, which sells one of the tools in this market. The production numbers in the middle of this piece are ours.

One fact up front, because it shapes everything below. typed ships two families of tiers. The paid family is hosted: typed++max, typed++xhigh and typed++high -- the two upper rungs on a context window of about 950K, typed++high on about 131K -- and reaching it needs an account and an API key. The free family is not hosted at all. typed (the default, a 35B MoE) and typed-max (a dense 27B) run on your own machine, and they need no account, no key and no signup. The install script takes a key as an optional argument; if you never give it one, the CLI still works. typed local sizes a known-good model preset for your hardware, and the CLI talks to anything that answers POST /v1/messages and GET /props, so a local llama-server or an NPU-backed server both work. We are not in the request path for that family, which is exactly why it is free and why there is nothing for us to bill.

In the past year most of the companies selling AI coding tools have changed how they charge for them, and most of those changes went badly.

Cursor moved off unlimited use to a metered credit pool in the middle of 2025. Pro became twenty dollars of frontier model usage per month, with unlimited use surviving only on the cheaper automatic mode. The rollout was explained poorly and ended in an apology and refunds: "Our recent pricing changes for individual plans were not communicated clearly, and we take full responsibility."

GitHub announced in April 2026 that Copilot was moving to usage-based billing, effective June 1. Sticker prices held: Pro stayed at ten dollars, Pro+ at thirty-nine, Business at nineteen per seat. What changed underneath is that usage now draws down a credit balance priced on input, output, and cached tokens at published per-model rates. Developers worked out the implications on GitHub's own community thread within about three weeks of the switch. One reported a single request costing seven to eight dollars. One watched a single request burn 822 credits. One went through all of Pro+ in two days.

Anthropic sells Claude on rolling five-hour windows plus a weekly cap, and is facing a proposed class action filed in June 2026 alleging that "the actual usage provided by the Max 5x and Max 20x plans is far below the advertised amount of usage." One allegation in the complaint is that a single five-hour coding session consumed 15 percent of a weekly allowance. Anthropic has not responded in court yet and no class has been certified. Separately it has been running a temporary 50 percent lift to Claude Code's weekly limits, which it has now extended twice, most recently on July 18 to run through August 19. That is the status as of publication. The date has already moved twice, so by the time you read this it may have moved again.

Three companies, three billing schemes, one shared pattern. When a single company fumbles its pricing that is a mistake. When all of them do it inside a year, something structural is going on. We have done it too, eight times in ten weeks, and I will get to that.

The tools changed from something with a bounded cost per use into something with an unbounded one, and the billing never caught up.

The unit of work moved

Autocomplete has a predictable cost. You accept a suggestion, the model generated a few hundred tokens, done. Chat is looser but still bounded. You ask a question, you get an answer, maybe a follow-up. In both cases the compute behind one thing you did is roughly knowable ahead of time, and it does not swing by orders of magnitude between two actions that felt the same to you.

An agent breaks that. Tell it to make the failing test pass and it reads files, forms a plan, runs a command, reads the output, edits code, runs the test, reads the failure, and tries again. One instruction from you becomes a loop, and how long the loop runs depends on how well the model happens to do. Three steps if it gets lucky, forty if it does not.

So the cost of a request is a function of the path the agent took through the problem, and that path is not visible in advance. It also correlates only weakly with anything you care about. A trivial task where the model gets confused and thrashes can cost more than a hard task it nails on the first try. What you are paying for is how much the model flailed, which has little to do with the difficulty of the work or the value of the result, and which neither of you controls.

There is a mechanical reason the numbers get large. Every step in the loop resends the conversation so far, and the conversation keeps growing. The files it read, the command output it got back, the stack traces, all of it becomes input on the next turn. The model's own reasoning is output you pay for whether the reasoning helped or not. Context piles up faster than the step count.

How lopsided this gets was our first real surprise. When we sized our original quota we assumed coding traffic would run about five parts input to one part output, which is roughly what chat looks like. Live traffic came back at about forty to one. Customers were hitting their input ceiling at around 80 percent consumed while their output ceiling sat at 9 percent. An agent is overwhelmingly a re-reading machine. The generating is close to a rounding error, and a quota built on chat intuitions mis-sizes the axis that actually binds by most of an order of magnitude.

Every pricing model is a decision about who eats the variance

Once you see cost as a high-variance number stapled to each request, the recent history stops looking like a run of unrelated blunders. It starts looking like a set of answers to one question. Given that one user's monthly compute can be many times another's, and that nobody can predict it beforehand, who carries that risk, and how do they find out they are carrying it?

Per-token billing, which is where Copilot landed and what you get from a raw API key, hands the variance to the user. You pay for exactly what the machine did. That is fair and also useless for planning, because what the machine did is unknowable until it has done it. The old feel for "a request costs about a dollar" is gone and nothing replaced it. That empty space is what people mean when they say the bill was a surprise. It has a nasty side effect too: it makes agents, the workflow the vendor is pushing hardest, the single most expensive way to use the product.

Subscriptions with rolling windows, which is how Anthropic sells Claude, move the variance into a different currency. The price is fixed and knowable, and the availability swings instead. You hit a wall partway through the afternoon because a five-hour counter rolled over. Your budget is fine and you have finished nothing. Windows are a way to shape load. They let a company advertise a generous allowance while capping the users in the tail, and they hold up until the advertised number and the delivered number drift far enough apart that someone sues.

Flat-rate, all you can eat, is the model everyone wants and the one that struggles most with agents. Once a single user can point an unbounded amount of compute at a problem, one price means the heavy few are subsidized by everyone else, and the subsidy grows until something gives. Then the vendor caps, or reprices in the open, or takes the option nobody announces and quietly serves something cheaper. Cursor did the first two in 2025.

There is a fourth answer that gets less attention: the vendor can spend more compute to reduce the variance of the outcome and eat the difference. Run several attempts at a task, keep the best one, charge for one. We built that and it currently ships turned off. Our own design note corrects the tempting version of the math: for a single completion a cached prefix makes the extra attempts nearly free, but for a multi-turn agent that edits files and runs tools the marginal cost is N times the output plus N times the tool executions, and the cache only amortizes input. It is cheapest exactly where it helps least.

There is a fifth answer, and it is the one we ended up shipping next to the paid tiers: take the vendor out of the request path. typed and typed-max run the model on the customer's own hardware, which is why they are free, why they need no account and no key, and why they cannot surprise anyone with a bill. The variance does not vanish. It turns into your electricity and your wait. But nobody meters it, and there is no ceiling to be told about at an awkward moment. It only works if you have a machine that can hold a model, which many developers now do and many still do not.

None of these five is dumb. They are five places to put the same unavoidable variance. Per-token puts it on your bill as a shock, windows put it on your afternoon as a wall, flat-rate puts it on the vendor until they hand it back all at once, best-of-N puts it on the vendor permanently at a price that scales badly, and local puts it back on hardware you already own. The variance is real and it is large. No scheme makes it disappear, and they differ mainly in how the bad news gets delivered.

What this looks like from the inside

The part I did not expect, running one of these, is how much of the difficulty turns out to be measurement.

We launched with a quota denominated in tokens. Over the following ten weeks we revised that envelope eight times. The monthly price never moved; the amount of usage sitting behind it did, in both directions, including twice in a single day in May because the first correction was itself wrong. The forty-to-one discovery drove some of that. Something else broke the unit of account outright.

Prompt caching. When a coding agent resends the conversation every turn, most of that input can be served from cache at a large discount, and that is good for everybody. It also means a token stops being a unit of cost, and a quota that counts tokens stops measuring the thing it exists to measure. Once our cache was warm, roughly nine tenths of the input we served was arriving as cache reads, which a token-denominated quota counted for nothing. It was seeing about a tenth of what was actually being consumed. Usage in that shape runs a long way past a ceiling the meter believes it has not reached.

We rewrote the quota to count money instead of tokens on July 20. Any vendor still selling a token allowance has some version of this hole, and the better their caching gets, the wider it opens.

The most counterintuitive thing we found is worth stating plainly. We sell three hosted reasoning-effort tiers. The effort word you type still picks a tier, it just no longer picks from a single paid ladder: max and xhigh select the free local tiers, and high, medium and low select the paid hosted ones. When we measured real cost per completed task across the hosted ladder, it was upside down: the cheapest tiers cost roughly five to eleven times more per task than the most expensive ones. Less thinking per turn meant more turns to converge, and more turns meant more total input to pay for. The internal note reads: "The 'lower effort = lower cost' mental model the customer-facing pricing implied was wrong."

If the company operating the proxy needs a measurement campaign to discover which of its own options is cheaper, a user reasoning from the pricing page has no chance at all.

Legibility is the fix, and it is harder than it sounds

If the trouble is that nobody can see the number, what helps is showing the number. A meter you can watch while the agent runs, denominated in dollars, converts an unpredictable cost into a decision you get to make: keep going, or stop, I have seen enough. The prediction problem does not get solved, because it cannot be. It gets handed to the party able to judge whether the next step is worth it, which is the person sitting there.

I believe that, and I want to be concrete about why "just show the meter" is harder than it sounds.

A live meter and the figure a request finally accrues are computed in two different places, at two different moments, and keeping them in agreement is real work. Any discrepancy in how one of them treats a cache read, and the two diverge by exactly the size of the cache discount. The only durable fix is structural: both paths read one shared constant, so there is no second copy of the rate to drift. A meter that disagrees with the accounting behind it is worse than no meter, because now you have a number and the number is false.

Stopping the meter is its own problem. When you press Ctrl-C, nothing automatically tells the part of the system that is spending money. The HTTP framework we pin swallows stream write errors, so a write never rejects even once the client is gone, which means the loop sending you chunks cannot learn the socket died. Left alone, the upstream keeps generating into a connection nobody is reading. Making cancellation real meant threading the server's abort signal all the way through into the upstream request. Almost nobody outside a team that operates one of these knows that "the user pressed stop" is a feature somebody has to go build.

The discount you would be watching is not stable either. A cache hit is not something you can count on request to request: we probed ours with a run of spaced requests and watched it hit, then miss, then hit again, with nothing about the requests themselves explaining the difference. In the month after we turned it on, our daily hit rate climbed from 1.3 percent to a sustained 84 to 94 percent. Two identical requests minutes apart can differ several-fold in cost, and you cannot tell in advance which one you are about to send.

None of this removes the variance. It stops hiding it, and hiding it was most of the problem.

The objection I do not have a clean answer to

The strongest reply to all of the above is that legible metered pricing already exists and people ran away from it. You can buy a raw API key today, watch every dollar in real time, and pay exactly what you used. Most developers who could do that picked a subscription instead, deliberately. A meter is a cognitive tax. It turns every "let it keep going" into a small economic decision, and forty of those in a day is worse than a flat bill even when the flat bill is larger in the end. Absorbing variance on the customer's behalf is what a subscription is for. Read that way, the last year is not evidence that subscriptions cannot work, only that several companies mispriced a premium, which is an ordinary actuarial error with an ordinary fix.

I think that objection is largely correct, and it narrows what I am actually arguing for. I am arguing that the vendor should keep absorbing the variance and stop concealing what happens at the edges, which is a smaller claim than telling everyone to sit and watch a number tick. Nearly all of the anger in these episodes clusters at a boundary: the moment you hit a wall nobody told you about, or open a bill you had no way to forecast. Inside the envelope, a subscription that quietly eats the variance is the right product and the meter should be ambient at most. At the boundary, the user needs the number and a choice.

At that ceiling there are two honest moves and two dishonest ones. Asking what you want to do is honest. Cutting you off is honest. Charging more without saying so is not, and quietly substituting a cheaper model is not. I am not accusing anyone of the last one; I have not caught a vendor doing it and would not assert it without evidence. I name it because it is the tempting move at that boundary, tempting precisely because it skips an awkward moment, and because it is the one we wrote tests against to stop ourselves. The products that come out of this with trust intact will be the ones willing to have the awkward moment.

Where this goes

The repricing is not close to finished, because the thing driving it has not been fixed. An industry built its billing around chat, shipped agents, and is working out in public, one refund thread and one lawsuit at a time, that the meter no longer matches the thing being sold. We are eight revisions in, and since then we have restructured the ladder itself: of the five tier ids we ship, two now run on the customer's own machine, where there is nothing for us to meter. I would not bet on that being the last move either.

My guess is that the winners here will be whoever shows you the meter, tells you the truth at the ceiling, and lets you decide, instead of managing how you feel about a number you are never allowed to see.