Rate limits are a product decision, not an infrastructure one

Several AI tool vendors have adjusted usage limits this month, in most cases tightening them for the heaviest users. The reactions have been loud and the underlying dynamic is worth separating from any particular company's decision.

the structural problem#

A subscription product with unbounded variable cost per user is a bet that usage distribution stays roughly log-normal. Most users are light, some are heavy, the average works out.

Agentic AI tools break that assumption in a specific way: the heaviest users are not 10x the median, they are 1000x. An engineer running parallel agents continuously during work hours consumes a genuinely different order of magnitude than someone asking a few questions a day.

At that spread, flat-rate pricing does not work. There is no price that is both attractive to the median user and non-catastrophic for the top percentile. You either subsidize the heavy users from the light ones — which works until the heavy users are a larger share — or you introduce limits.

Everyone in this category is going to hit this. Most already have.

the part that is avoidable#

The economics are not the failure. The communication is.

Here is the pattern that generates anger, which I have now watched play out at four companies:

1. Launch with generous or unstated limits.
2. Users build workflows around the observed capacity.
3. Limits tighten, often announced after users notice.
4. Users discover the limit by hitting it mid-task.
5. The error message does not say when it resets or how much was used.

Every step after the first is a choice.

what good looks like#

Publish the meter. If there is a limit, show consumption against it, continuously, before it is hit. Every cloud provider learned this a decade ago. An unmetered limit is a trap regardless of how generous it is.

Give the number in the units the user thinks in. "You have used 60% of your weekly allowance" is useful. "Rate limit exceeded" is not. Neither is a token count, because nobody has intuition for tokens.

Announce changes before they take effect, with a date. People will be annoyed. They will be much less annoyed than if they find out at 4 p.m. on a deadline.

Degrade, do not cut off. Falling back to a cheaper model with a notice is almost always better than a hard stop. The user's task completes; they learn about the limit; nobody loses work.

Make the expensive thing visible while it is happening. If a request is going to consume a large share of the budget, say so before running it. Users make reasonable decisions when they can see the cost.

the pricing shape that actually fits#

My read is that this category converges on hybrid: a subscription that covers a defined baseline, plus metered usage above it, with a spend cap the user controls.

That is how cloud infrastructure priced itself, after a decade of the same argument, and for the same reason — the underlying cost is genuinely variable and pretending otherwise breaks in both directions. Flat pricing means either the vendor eats unbounded cost or the user hits a wall.

The version I want as a user: a dial that says "spend up to $X this month," a meter that shows where I am, and no surprises. That is not complicated, and it is strange that a category built by extremely sophisticated companies has mostly not shipped it.

the vendor's side, fairly#

Serving these workloads is genuinely expensive and the costs are not well-predictable even to the vendor. Nobody had usage data for agentic coding tools two years ago because they did not exist.

Getting the pricing wrong initially is forgivable. Adjusting it is necessary. Doing it without a meter, without notice, and with an error message that tells the user nothing — that is the part that is just bad product work.