In two weeks, three major providers have restructured their usage limits: weekly quotas for a coding tool starting 14 September, caps indexed to compute consumed for a Google service, and various tier adjustments. The price per million tokens — the one compared in tables — has become the least informative part of a pricing grid.
We have documented all week that the advertised price does not reflect what you pay: the tokenizer, the cache, the effort level. Here is the next layer, and it is becoming widespread.
The three mechanisms
The weekly quota. Instead of a daily or per-session limit, a cap over a rolling seven-day window. The effect is subtle: heavy usage early in the week consumes what would have been available later in the week. This penalises spikes and favours steady usage.
The compute-indexed cap. Rather than counting requests or tokens, the power consumed is counted. A complex request with high effort weighs more than a simple one. This is fairer economically and far less legible for the user.
Context tiers. We described these regarding Grok 4.6: beyond a context threshold, the price per token changes. An agent accumulating history crosses that threshold without noticing.
Why these restructurings are multiplying
Three reasons converge, and they are consistent with everything we are observing.
Agents have changed the nature of consumption. A conversational user sends a few dozen requests a day. An agent runs thousands of them, in loops, without pause. Limits designed for the former blow up with the latter.
The real cost varies enormously from one request to another. With effort levels and long contexts, two requests billed at the same rate can cost the provider very different amounts. Indexing to compute restores the correspondence.
Unlimited offers were not unlimited. We wrote this about ChatGPT's free unlimited tier: a promise of unlimited always eventually meets a usage pattern that makes it untenable.
Comparing two providers on their advertised price has become about as useful as comparing two phone plans on the price per minute. What matters is a package: the rate, the billing unit, the cache, the effort level, the tiers, the quota and its window. And that package cannot be read in an announcement: it has to be measured against your own usage, over a representative period.
How to measure what you pay
The method is simple and rarely applied.
Choose a representative period, a week or a month, with your usual volume and mix of tasks.
Record the total cost, not the cost per token: what you actually paid, quotas and tiers included.
Divide by the number of tasks completed, in the sense of useful results obtained. This is the only metric that incorporates all layers: the cost per completed task.
Repeat quarterly. Pricing grids change at that pace, as this fortnight has just shown.
What to take away
There is a positive reading of this complexity, and it is a fair one: pricing that reflects real cost is more honest than a single price that makes light usage subsidise heavy usage.
There is also a less favourable reading: complexity protects those who design it. As in telecoms, those who do not read the terms pay more than those who do, and most people do not read them.
The only defence is to stop looking at the advertised price. It is not that it is wrong; it is that it no longer describes very much.