What my coding agent would cost on the API: 30 days of transcripts, measured

TL;DR: I priced 30 days of my own coding agent transcripts at public API rates and got about $4,176 for the month. That is an API-equivalent figure, not money I spent: I run on a flat subscription (Claude Max 20x, $200 a month), so the metered price would be about twenty times what I actually pay. More than 90% of that figure is cache reads, because every turn of a long session re-reads the whole context, and 88% of all input tokens were spent in turns where the context was already above 300K tokens. The lesson for context engineering is that long sessions stay expensive even when caching works perfectly, so session length is the lever that matters. The method is simple enough to repeat on your own logs in an afternoon.

The question that started it

I use Claude Code every day, on a subscription, across a few products I run on my own. A question kept coming up: would it be cheaper to pay per token through the API instead? The intuition behind the question is reasonable. Most days I do not feel like I am generating that much text, so metered pricing sounds like it might come out ahead. There was also a side question about whether the API route needs more local CPU or memory.

The second one is quick to answer. It makes no difference. The model runs on the provider's servers in both cases; locally it is the same command line tool, and the only thing that changes is how you authenticate and how you are billed. The first question needed data, and I had the data already, because the agent writes every session to a local transcript file, and every model response in that file carries a usage block with token counts.

How do you measure what a coding agent actually costs?

The method is a script over the transcripts. Each assistant message in the log records four numbers: fresh input tokens, output tokens, tokens written to the prompt cache, and tokens read from the prompt cache. Prompt caching is the API feature that lets a request reuse an already processed prefix of the conversation at a fraction of the normal input price, which is exactly what an agent does on every turn. Multiply each of the four counters by the matching per-million price for the model that produced the response, sum, and you have the API-equivalent cost.

Three details decide whether the number is right:

• Deduplicate. The same response can appear on more than one line of the log, so key each one by its message id plus request id and count it once. Without this the total inflates.
• Price per model family. My month mixed three models, and the most capable one costs twice as much per input token as the next tier down. One blended rate would be meaningless.
• Filter by the response timestamp, not the file date. Long sessions span days, so a file touched yesterday can contain turns from two weeks ago.

# illustrative shape, not the full script
# $ per 1M tokens: input, output, cache write, cache read
PRICE = {"fable": (10, 50, 12.5, 0.25), "opus": (5, 25, 6.25, 0.5)}
FIELDS = ("input_tokens", "output_tokens",
          "cache_creation_input_tokens", "cache_read_input_tokens")

seen, totals = set(), defaultdict(lambda: [0, 0, 0, 0])
for line in transcript_lines(last_days=30):
    msg = line.get("message") or {}
    usage = msg.get("usage")
    key = (msg.get("id"), line.get("requestId"))
    if line.get("type") != "assistant" or not usage or key in seen:
        continue
    seen.add(key)
    t = totals[family(msg.get("model"))]
    for i, field in enumerate(FIELDS):
        t[i] += usage.get(field, 0)

cost = sum(
    sum(n * price for n, price in zip(t, PRICE[f])) / 1e6
    for f, t in totals.items()
)

The prices in that snippet are the published per-million-token rates as of September 2026 for Claude Fable 5.1 and Opus 5 (input, output, cache write, cache read). Sonnet 5 sits well below both. Swap in whatever your provider charges; the structure does not change.

What 30 days of transcripts added up to

The window covered 25 active days and about 15,900 model responses. The numbers below are hypothetical: what the same usage would have been billed if every token were paid for through the API. None of it was actually charged, because all of this ran on a flat subscription.

The surprise was the composition. More than 90% of the figure is cache reads. On the top model alone the month had about 4.15 billion cache-read tokens. Output, the part I intuitively associated with "usage", barely registers. So the question "how much text does the agent write?" has almost nothing to do with the bill. The questions that matter are how big the context is on each turn and how many turns a session runs.

Where do the tokens go in a long agent session?

That led to a second cut of the same data: every turn bucketed by the size of its context, where context means fresh input plus cache writes plus cache reads for that turn.

88% of input tokens went into turns whose context was already above 300K. Out of 45 sessions, 27 crossed 300K, 16 crossed 500K, and five ran all the way to roughly one million tokens, with between 806 and 4,473 turns in a single session. A turn at 800K costs around eight times as much as a turn at 100K, even when the answer it produces is the same length. The model is paying, turn after turn, to re-read everything that happened since the session started, including the three unrelated side quests I picked up along the way.

This is the part that changed how I work. Caching makes each re-read cheap per token, and I had mentally filed long sessions as "fine, it's cached". Cheap per token times hundreds of millions of tokens is still the dominant cost. If those long sessions had ended around 300K, with the next thread starting fresh from a short written note, the same volume of work would have needed a fraction of the tokens.

Subscription or API: the options and the trade-offs

With the numbers in hand, the decision had three real options.

Pay per token through the API. The pros: you pay for exactly what you use, there is no usage window to run into, and it works in places a personal subscription does not, such as scripts, CI jobs and scheduled automations. The cons, for a profile like mine, are decisive: long sessions, a large context and many turns per session are precisely the shape that metered pricing punishes, because cache reads scale with context size times turn count. On my month, the API route would have cost about twenty times the subscription.

A flat subscription. The pros: the marginal cost of a task is effectively zero, so I stop rationing the good model, and heavy long-context use is exactly where the flat price wins. The cons: there is a usage window, and when it runs out you wait; and it is tied to interactive use by a person, so it does not cover unattended automations.

A hybrid. Subscription as the base for all interactive work, an API key only for scripts and as a fallback for the rare day the usage window runs out. This keeps the metered spend small and predictable, at the cost of managing two ways of authenticating.

I stayed on the subscription and treat the hybrid as the escape hatch. The break-even logic is simple: the API makes sense when usage is small and irregular, on the order of a dozen or so dollars a month, or when the work runs without a person at the keyboard. Anyone running an agent for hours a day in long sessions should expect the metered number to be large. That matches what I wrote in my post on agents as co-engineers: the real cash outlay is a flat $200 a month for Claude Max 20x, plus a $20 ChatGPT Plus plan, which includes Codex CLI, while I compare the two agents, and this measurement explains why that price is such a good deal for this kind of use.

What the measurement cannot tell you

The $4,176 is a counterfactual, and it has limits worth stating plainly.

• Behavior would change under metering. If I were paying per token, I would not have let five sessions run to a million tokens. The figure prices my subscription behavior at API rates; a person on the API from day one would work differently and pay less.
• It covers the main agent only as logged. Whatever the transcripts record is what gets counted. I did not try to reconstruct anything outside them.
• Prices move. The rates are as of September 2026. Rerun the script when they change; the shape of the result (cache reads dominate, long context dominates) is what I would expect to hold.

One thing that also did not work, and that the data exposed: I already had a written instruction telling the agent that a new topic means a new session. The model knows the rule. I, in the middle of a productive afternoon, do not follow it. Five sessions at a million tokens are the evidence. A rule that depends on the person remembering it under momentum is a weak control, which is why my next step is enforcing session boundaries in tooling rather than in instructions.

What I would tell someone doing this tomorrow

• Measure before deciding. Your agent already logs token usage per response. A one-page script turns that into a real number in an afternoon, which beats any estimate from how busy the month felt.
• Look at the composition, not only the total. If cache reads dominate, the bill is driven by context size and turn count, and output volume is a rounding error.
• Bucket turns by context size. That single table tells you whether your cost lives in a long tail of oversized sessions. Mine did: 88% of input above 300K.
• Treat session length as a context engineering decision. Context engineering is the practice of deciding what goes into the model's context window and when. Ending a session at a natural boundary and resuming from a short written handoff is the cheapest optimization available, and it tends to improve answer quality too.
• Pick the billing model from your usage shape. Heavy interactive use in long sessions favors a subscription. Light, irregular or unattended use favors the API. Many people need both.

For the other half of the context budget, the part that loads before you type anything, see how I structure what loads into a Claude Code session. Startup cost turned out to be small next to this. Conversation length is where the tokens go.