Interactive explainer · Agents

Agents don't write. They read.

"An agent is just a prompt in a loop" is true, and it is the most expensive word in that sentence. Over 36 real agent sessions on this repository — 5,352 turns of actual work — the models read 1.2 billion tokens of context to produce 6.3 million tokens of output. That is 192 tokens read for every token written.

Lesson progress 0%

"An agent is just a prompt in a loop"

It is the standard explanation and it is accurate. The model answers, something runs a tool, the result goes back, the model answers again. Nothing exotic.

What the sentence hides is the word loop. A language model has no memory between calls, so every turn has to resend the entire conversation — the instructions, every tool result so far, every previous answer — before the model can add one more sentence to it. The loop is not repeating a prompt. It is repeating a prompt that gets longer every time.

That is easy to say and rarely priced. This page prices it, on real work.

What changed while building this. This lesson was planned as "why an agent loop costs 10× a chat", on the assumption that our seven production agents logged their token usage. They do not — they record what they did and nothing about what it cost, so there was nothing to count. The dataset had to come from somewhere else, and the honest answer turned out to be much larger than 10×.

Where the numbers come from

Every Claude Code session leaves a transcript, and each assistant turn in it carries an exact usage record: input tokens, output tokens, and the split between tokens read fresh and tokens served from cache. Those transcripts are the dataset — the agent sessions that built this website, including the four explainers next to this one.

Only counts leave the transcripts. These are private working sessions, so nothing but numbers is published here: no prompts, no file contents, no tool arguments, no session text of any kind. The build script measures the size of each block and throws the block away, and it refuses to write its output if any string in it looks like prose rather than a label.

And nobody was sent this bill. These sessions ran on a subscription, not on metered API billing. Every dollar figure below is a counterfactual — what this exact token usage would cost at published list prices, priced per model and per cache type. It is an honest way to size the loop, and it is not an invoice.

The whole bill, in one picture

Start with the shape of it. Here is every token the models handled across all 36 sessions, drawn to scale — everything read on the left, everything written on the right.

—

tokens read per token written

This is why intuitions about cost are wrong. People picture the model composing, so they price the composing. Output is the small, expensive sliver on the right; the bill is dominated by the enormous cheap slab on the left, and the slab is mostly the same text being re-read.

Turn one already costs a book

Before an agent does anything at all — before you have asked it a question — it has to be told what it is and what tools exist. Those instructions and tool schemas are sent on every single call.

—

tokens, median first turn

That is the floor. Say "hello" to an agent and you have already paid it. Ask a chat model the same thing and the whole request is a few dozen tokens.

And it grows on every turn

From that floor, each turn adds whatever happened — a file read, a command's output, the model's own answer — and all of it is resent next time. The line below is the median context across 6 sessions that all ran to at least 200 turns, so every point is the same sessions measured later, not a shrinking group of survivors.

The cost of a conversation is the area under that line, not the height of it. Turn 200 is expensive on its own, but you also paid for turns 1 to 199 on the way there, each one slightly cheaper. Doubling the number of turns roughly quadruples the tokens read — which is why a long agent session is not twice a short one.

So why doesn't it grow forever?

Because it cannot. There is a hard ceiling on how much a model can be shown at once, and long before the cost becomes absurd the conversation hits it. What happens then is visible in the data as a cliff.

Session	At turn	Context before	After	Dropped	Kind

Compaction is not free, and it is not lossless. Summarising the conversation means reading all of it one more time, at its largest — the single most expensive read in the session. And what comes back is a summary: the agent keeps the gist and loses the detail. Anyone who has watched a long agent session forget a decision it made an hour ago has watched this happen.

Who actually filled the context?

If the model is re-reading an enormous conversation on every turn, it is worth asking what that conversation is made of. Measured across every block in every session, by size:

Share of all content added to the conversation, by character count. Character counts rather than tokens, because the ratio between them is close enough across these kinds of text that the shares hold.

The expensive part of an agent is not the thinking. It is the paperwork. Tool results are the file you asked it to read, the full output of the test suite, the directory listing, the API response — and every one of them stays in the conversation, re-read on every subsequent turn, until something compacts it away.

What caching removes

There is a reason this is affordable at all. Because each turn resends a conversation that is mostly identical to the last one, almost all of it can be served from cache — charged at a tenth of the normal input rate rather than the full one.

Caching is doing more work here than any model choice on the page. It is also the reason the "just a prompt in a loop" design is viable at all: without it, the same work costs several times more, and the growth in Section 4 would bite much sooner.

The cheap-model trap

The obvious response to a big bill is to switch to a cheaper model. —

But that reasoning prices the model and ignores the loop. Here is the same measured growth curve run on both rate cards — a cheap model working through a task turn by turn, against an expensive model answering once:

Turns	Cheap model, in a loop	Expensive model, one answer	Which is dearer

The counter-example, and the useful way to read it. A cheaper model is genuinely cheaper per token, and that advantage is spent by the loop within a few dozen turns. If your agent takes hundreds of turns to do a job, the model's rate card is not where your money is going — the number of turns is.

What to do about it

Count turns, not tokens. Tokens are the unit you are billed in; turns are the unit you control. Every turn you remove takes its own cost and every future re-read of it.

Keep tool output small at the source. — Reading 40 lines instead of a whole file, or grepping instead of dumping, is not a small saving — that text is re-read on every remaining turn of the conversation.

Make sure caching is actually on. — It is the single largest lever measured here, and it is a configuration flag rather than a redesign.

Start a new session when the task changes. A fresh conversation goes back to the floor. Carrying an hour of unrelated history into a new task means paying for that history on every turn of it.

Do not assume a cheaper model fixes a long loop. Section 8. It buys you a few dozen turns, then the loop is back in charge.

The one-line version. An agent's bill is not what it wrote. It is the number of times it had to re-read everything that had already happened — so the way to make it cheaper is to make less happen, not to make the writing shorter.

✓

Check yourself

Ten questions on the method and the findings. The explanations are worth reading even when you get it right.

Five questions across the key ideas.

The lesson at a glance

✔ Measured, not asserted

Where these numbers come from

Token counts were read from this project's own Claude Code session transcripts by website/scripts/build-agentcost-data.py, which emits counts and nothing else; the derived per-turn counts are committed in this repository. Measured —. Prices were read from Anthropic's published table on — and are applied per model and per cache type.

Price your own loop

The arithmetic is not hard: take the context size at the last turn, halve it, multiply by the number of turns. That is roughly what you read to get there — and it is the number that decides your bill, not the length of the answer.

More explainers →