What a coding-agent session actually costs, request by request

A developer types one sentence and the bill records fourteen API calls. That is not a defect, and it is the single most useful thing to understand about agentic coding costs: the unit a developer experiences is a turn, the unit you are billed for is a request, and one turn contains as many requests as the agent needs tool calls. Every one of those requests carries the entire conversation so far.

This post is the anatomy of that bill. It is written for the person who has to explain a $40,000 month to a finance team, not for the developer trying to shave tokens off a prompt — the levers at those two scales are different, and most published advice is about the second one.

Everything cited here is from Anthropic’s public documentation, and the arithmetic is stated so you can redo it with your own numbers.

Why does one prompt produce so many billed requests?

An agent works by calling tools, and every tool result becomes a new request. The loop is: the model reads the conversation, decides to run a command or read a file, the harness executes it, appends the result, and sends the whole conversation back for the next decision. Ten tool calls in service of one instruction is ten billed requests, not one.

This is why “cost per session” and “cost per 1,000 requests” tell you different things and you need both. A session that got expensive because the agent took forty steps to do a five-step job is a different problem from a session where each step carried too much context — the first is an agent-behaviour problem, the second is a context problem, and the aggregate spend number cannot distinguish them.

Anthropic states the consequence directly: Claude Code sends your full conversation with every request, and each time it uses a tool it sends another request carrying that batch of tool results (Manage costs effectively). A one-line question in a session that has been open all day still draws usage for the whole conversation.

What are the four token classes, and what does each cost?

Every request is billed across four classes, and their prices differ by an order of magnitude. Written as multiples of the model’s input rate, which keeps the arithmetic model-agnostic:

Class	What it is	Price
Input	Tokens sent that were not served from cache	1×
Output	Tokens generated, including reasoning tokens	typically 4–5× input
Cache read	Tokens served from a cached prefix	0.1×
Cache write (5 min)	Tokens written into a five-minute cache entry	1.25×
Cache write (1 hour)	Tokens written into a one-hour cache entry	2×

Three consequences follow, and they are the whole economics of agentic coding.

Cache reads dominate the volume and almost nothing of the cost. In a warm coding session the great majority of input tokens are cache reads at a tenth of the rate. A session showing 90% of input served from cache is not saving 90% of its bill; it is paying a tenth for that 90%.

Output is the expensive class per token, and thinking tokens are billed as output. Anthropic notes that the default thinking budget can be tens of thousands of tokens per request on some models, which is why reasoning effort is a cost lever and not just a quality one.

Cache writes are the tax on discontinuity. Nothing is cheaper than a prefix you never had to rebuild. Every event that invalidates the cache — an idle gap past the lifetime, a compaction that rewrites history, an edit to the top of the context — converts a 0.1× read into a 1× re-read plus a 1.25× or 2× write.

Where does the money actually go in a real session?

Take a modelled session — the numbers below are illustrative, chosen to be round rather than measured, and the point is the shape rather than the total. A developer works for two hours, the agent makes 120 requests, the conversation settles at a 150,000-token prefix, and each turn generates 800 output tokens.

If the prefix stays cached throughout:

• 120 requests × 150,000 cache-read tokens × 0.1 = 1.8M token-equivalents of input
• 120 requests × 800 output tokens × ~4.5 = 432K token-equivalents
• one initial cache write of 150,000 × 1.25 = 188K token-equivalents

Now break the cache six times — six coffee breaks longer than the cache lifetime, or six compactions:

• six rebuilds × 150,000 × 1 (full-price re-read) = 900K token-equivalents
• six re-writes × 150,000 × 1.25 = 1.125M token-equivalents

Those six interruptions add roughly as much again as the entire cached session cost. This is the single most under-appreciated fact in agentic cost management: the expensive thing is not the work, it is the discontinuity. It is also why advice aimed at individuals — write shorter prompts, be more specific — moves a small term while the large one is set by cache lifetime and session hygiene.

What makes one session cost ten times another?

Six mechanisms, in rough order of how much they move a fleet’s bill. Each is documented behaviour rather than folklore.

1. Cache lifetime versus how people actually work. The prompt-cache lifetime is one hour on a subscription, five minutes once you are drawing on usage credits, and five minutes by default on an API key or a cloud provider. Interactive development is full of gaps longer than five minutes — a meeting, a code review, lunch — and each one that crosses the lifetime turns the next request into a full-price rebuild.

2. Context that only grows. The conversation is re-sent every request. A session that has accumulated a large context pays for it on every subsequent turn, at the cached rate if it is warm and the full rate if it is not. Anthropic’s guidance to clear between unrelated tasks is a cost instruction, not a tidiness one.

3. Compaction. When the harness summarises history to free space, it reads the conversation it is summarising — so compacting a large context is itself a large request, and it rewrites the prefix, which invalidates the cache below it. Compaction is worth its cost, but it is not free and it is not silent.

4. Tool schemas in the prefix. Tool definitions sit in the context, and if they are preloaded they are re-sent on every turn of every session. Uber’s public account put the fix — deferring tool definitions until a tool is actually used — at roughly 50–70K tokens saved per session before any work happens. Modern Claude Code defers MCP tool definitions by default, which makes this a question of what your fleet has configured rather than what is possible.

5. Subagents and agent teams. A subagent runs its own context. Agent teams use approximately 7× the tokens of a standard session when teammates run in plan mode, because each teammate maintains its own context window. This is the lever with the widest range: the same feature is either the best or the worst thing in your bill, depending on which model the subagent traffic runs on.

6. Model and reasoning effort. The frontier model is several times the price of the mid-tier, and thinking tokens bill as output. A fleet where every subagent file-search runs on the frontier model at high effort is paying top rate for work that has no reasoning content.

Which numbers should an organisation actually track?

Total spend is the number you cannot act on. It moves when headcount moves, when adoption moves, and when a single team starts a migration — none of which tells you whether your agents got more or less efficient. Five unit metrics answer questions that total spend cannot:

Metric	The question it answers
Cost per session	Is a unit of developer work getting cheaper?
Cost per 1,000 requests	Is each step getting cheaper, independent of how many steps?
Tokens per request	Is context growing?
Cache hit rate	Is the prefix surviving between requests?
Cost per active hour	What does an engineer-hour of agent assistance cost?

The pair that matters most is the first two. Cost per session falling while cost per 1,000 requests holds steady means sessions got shorter — possibly because the work got easier, possibly because developers gave up. The reverse — cost per request falling while sessions hold — is the one that means your policies worked.

Uber’s published result is the cleanest example of this discipline in public: cost per session down 52% and cost per 1,000 requests down 34%, measured with the model held constant, while agentic requests grew 9.4×. We wrote up which of their levers are configuration rather than engineering.

Why doesn’t the number in the client match the invoice?

Because it was never meant to. The figure in /usage is computed locally from token counts at list price, from one machine’s history, and it resets when a session is cleared. If your organisation has negotiated rates, the client keeps using list price until an administrator configures otherwise.

That gap is worth understanding in detail before anyone builds a budget on client-side figures — we wrote a whole post on it, including the four documented ways the two numbers diverge and the four properties a savings claim needs before a finance team should accept it.

Where to start if the bill just doubled

In order, because the order is what saves time:

1. Get one week of per-request records with model, token classes and a session identifier. Without per-request data you can only observe that spend rose.
2. Split the change into volume and unit cost. More sessions is adoption; more expensive sessions is a problem. These have opposite responses and the aggregate number hides which one happened.
3. Look at cache hit rate before anything else. It is the cheapest thing to fix and the most common cause of a step change.
4. Check what subagent traffic runs on. It is usually the largest single misallocation and usually one default.
5. Only then look at prompts and workflow. The advice is real, but it moves the term you can least control and the one that scales worst across a fleet.

If you would rather see those five answers for your own traffic than compute them, our spend audit reads your provider’s billing data read-only and reports what each lever is worth per year, before you install anything.

Frequently asked

Is a cache read really a tenth of the input price? Yes — 0.1× the model’s input rate, for both the five-minute and one-hour tiers. The difference between the tiers is on the write side: 1.25× for five minutes, 2× for an hour.

Does a longer session cost more even if I am not typing? It can. Background work in the harness (summarisation for resume, scheduled tasks, idle check-ins) sends the conversation again, and each request carries the full context. Anthropic documents these as small — typically under $0.04 per session — but they are not zero, and the dominant cost of an old session is that every new message re-reads a large history.

Do thinking tokens bill differently from normal output? No. Reasoning tokens are billed as output tokens, which is the most expensive class, so reasoning effort is a direct cost lever.

Why does the same task cost different amounts on different days? Most often cache state: the same work with a warm prefix and with a cold one differs by roughly the ratio of a cache read to a full-price re-read, which is 10× on the input portion. Model choice and the number of tool calls the agent needed explain most of the rest.

Is per-seat pricing cheaper than API billing for coding agents? It depends entirely on the shape of your usage, and the honest answer requires your own per-request data. What can be said generally: seat pricing converts a variable cost into a fixed one and removes your ability to optimise it, while API billing keeps both the risk and the levers.