Where the money actually goes

"I hit the weekly limit on Wednesday and I don't know what did it"

People spend their allowance during the week without knowing what on. Same thing is usually visible on the bill, but as a monthly figure.

The reason it's hard to say is because of a common misconception that doesn't work in one particular scenario: we expect our spend to be proportional to what we type. It's not, it's proportional to what is being re-transmitted and how many times it's being re-transmitted. Let's say you ask "what is the weather today?" — a question that size is a handful of tokens (Anthropic's rough conversion is 0.75 words to the token), but the entire context of the conversation is being sent with every request. On one of our machines this is what the usage panel tells us: "65% of your usage was at >150k context" over the last 24 hours.

So the thing you actually type is negligible compared to what rides along with it.

So the useful part is not what you write but rather what's in every request and how many requests you're making.

Four line items, and only one of them is what you think

Let's have a look at the four building blocks of the bill, priced very differently:

• Input — everything that gets transmitted; the base rate

• Cache write — the input being saved so future requests can skip processing it; more expensive than plain input

• Cache read — the input served from this store; a fraction of the base

• Output — the model's generated tokens; by a big margin the most expensive per token, the reasonings are being billed in this column

Anthropic publishes multipliers relative to the base input price:

• 5 minutes cache write: 1.25x

• 1 hour cache write: 2x

• Cache read: 0.1x

But not every provider discloses all four columns. For example on OpenAI's Codex credit card there are three columns, no cache write row; Antigravity's CLI shows quota as requests and tokens but not in currency; where they're published it works the same — on the Codex card cached input is exactly 1/10 of the input in every row, output six times the input. Cursor prices all four columns separately per model.

These two things follow, both of them reversing the common assumptions:

• That big numbers don't mean big bills — look at Anthropic's own worked example, where they split 1.2k of fresh input against 940k of cache read for the same conversation being read back ten times cheaper; a screenshot of a huge token total is mostly that, and gets read as a fortune spent

• That output is low-volume and expensive, input high-volume and cheap — for instance on Opus 5 it's $5 per million input vs $25 per million output (5x per token), while the volumes differ by two orders of magnitude, in the same worked example above input side tokens are over 180 times more than the output ones. But what column dominates depends on your own output-to-context ratio which is a figure you can't know before but only observe in the usage panel

A turn is not a message

The second multiplier is the number of requests and it's not under your direct control. Every instruction you give the agent is multiple requests:

• Reading a file — one request

• Running tests — another, carrying the test output

• Editing three files and grepping, then re-running — four more

Anthropic says that Claude Code sends the entire conversation with every request, so every tool usage is another request sending the result of it back; so whenever you say "fix this failing test" it's actually as many requests as needed for the loop to run, each carrying everything before it plus whatever the last tool returned.

Therefore the actual unit of account is a turn — everything that happens on the agent's side following one sentence you say.

Contrast this with a prompt that sends the agent looking for something versus one that points to a specific file. Anthropic says that they recommend being as specific as possible, and a good example of what we mean by "vague" is "improve this codebase", it will make the model search a lot.

The shape of a long session

So what long sessions look like when these two things combine: if every request carries the entire context and every turn adds roughly the same number of tokens, request number k costs around k units and the total cost of N-request session is 1+2+…+N, which is N²/2 rather than N. So if you double the session length it's not a twofold but a fourfold input increase. Just a thought experiment, we're not saying this is actually what happens, just saying that this is the right mental model, "session became long" is a different class of problem than "prompt became long".

The cache changes the constant by ten — substantial — but a tenth of N²/2 still grows like N².

For example on Claude Sonnet 5 the list prices through August 31st 2026 are:

• $2 per million input

• $0.20 per million cache read

• $10 per million output

And increase to $3 and $15 the next day. If you had a session with 40 requests of 50k context each:

You did the same work, the only difference between the first two lines is the cache warmth, which is the entire reason to keep it warm. The last line is how much the model writes and can't be really guessed from the outside, in this scenario it dominates (1.5k per request) but if it was at Anthropic's worked example ratio (output much lower compared to context) it wouldn't.

So basically there are two equally valid scenarios leading to two different numbers which is why the resolution is the usage panel.

The five things that actually top the bill

Five main reasons behind high spend:

1. Long context — Anthropic's article about unexpectedly high spend (accounted for the API and cloud-provider plans, not the subscriptions) usually points to sessions being left uncleared or Opus being set as default model; just think that if you were to ask "what's the weather today" during a one-day session it would still include the entire conversation; on our own panel, for the previous 24 hours: "65% of your usage was at >150k context" — the panel itself is careful to say these are independent characteristics rather than a breakdown, which is the right caveat and still points one way

2. Cache misses — the cache is short-lived, five minutes by default on Anthropic's API, an hour on a subscription; if you return after a break the next message will reprocess the entire context. On a 150k-token session this request is a tenfold increase compared to the read alone, and then there's also the cache write behind it. Nothing changes on your screen. Invalidation is stricter than we think — to be read from it the prompt needs to start with the exact same prefix, and altering any of the tool definitions invalidates the entire thing

3. Unread tool output — running tests that print thousands of lines, dumping a generated file, fetching an entire documentation page. Anthropic's own article says:

   • 10KB web page ≈ 2,500 tokens

   • 100KB documentation page ≈ 25,000

   • 500KB PDF ≈ 125,000

   Treat these as a lower bound; the same article says that newer models' tokenizer generates around 30% more tokens for the same text. Again, you don't get charged just once, the content is now part of the conversation and goes along with every request. The right thing to do is filtering at the source instead of inside the model — a hook selecting only failure lines will drop a test output from tens of thousands of tokens to hundreds

4. Thinking — extended reasoning is being billed in the output column, and the default budget can be tens of thousands of tokens per request depending on the model; enabled by default in places like Claude Code because it's really useful on hard problems, but also because it's the simplest thing to reduce if you don't need it for the task

5. Fan-out — every subagent has its own context window so a fan-out is actually N sessions instead of one. Anthropic says that agent teams consume around 7 times as much as a standard session on tokens when team members work in plan mode, and their usage is proportional to the team size; but on the other hand every subagent is also a saving — the bulky output stays in the sub-context and only a summary gets back to the parent, lowering its per-request cost. So it's like trading a cheaper parent for a higher total, which makes sense if you needed the parallelisation

As a sidenote, the compaction has a cost — /compact reads the conversation it summarises, so compacting a big context is a big request; clearing is free so clearing between unrelated tasks is better than compacting more often.

As another sidenote, sessions in the background are still being transmitted — for example it's summarising for resuming and doing status checks; Anthropic says that they cost typically under four cents per session, so this isn't the problem — but a scheduled task you've set up fires on its interval even while the session is idle, and sends the entire context each time.

Dollars or limits — two different currencies

The last thing is that whether tokens are money or quota depends solely on authentication, and that's where people usually get it wrong:

• API key — tokens are money, per token, per model, on an invoice

• Subscription — tokens are quota, a flat fee with an allowance spent against moving windows (five hours and a week for Claude, five hours for Codex, a weekly quota plus a five-hour window for Kimi Code), within the allowance you don't get charged more, you just run out sooner

Even though these sound like different problems — a figure at month end versus hitting a wall in the middle of the week — they're the same behaviour. And every subscription here has some form of paid overflow past the allowance, so you end up back on the first bullet without changing anything about how you work.

But if you use Claude Code it shows a dollar figure calculated locally from token counts based on list prices, and discloses this; don't treat this as an invoice — it doesn't consider promotions or contract discounts and may not reflect what's in the bill. Always treat any in-app price as relative, useful for comparing sessions, never as a bill.

What it actually comes to

Finally, here are Anthropic's published deployment numbers: enterprise average $13 per dev per active day, $150–250 per dev per month, with 90% of users under $30 per active day.

So a big span, same tool, same work, tenfold difference in cost that speaks for looking at your own figures rather than benchmarks. And it's a small figure compared to the salary of a person using the tool anyway, so we want to say it out loud before anyone decides to sacrifice output for token savings.

The habits, ranked

At the end of the day it all comes down to four things, not equally valuable:

1. Clearing between unrelated tasks — the most important one, the only thing that affects N²/2 instead of just the constant, and it's free

2. Keeping bulk output outside the window — filtering at the source with a hook, a tail or a subagent summarising in a paragraph; reading a file is cheap once but expensive across forty requests

3. Choosing the right model — adjacent tiers differ by 2–2.5 times on the output column (more if you skip a tier), which is real money on the expensive side

4. Fan-out with purpose — three agents on a question that wanted one agent is three times the cost of one answer

And then there's the one nothing measures: the heaviest session is the one that went in the wrong direction for an hour and needed to be redone; you don't see it on the bill, only as a high figure on your weekly total. Plan mode, an acceptance criterion and an early interrupt are cost controls even though no usage panel will ever credit them with savings.

Last but not least, reducing tokens and maximising output are two separate goals and it's only the latter that matters; check the usage panel, see which of the five things above applies to you, address it and get back to work.