Where we waste AI tokens, and how to stop: the six levers that decide what one agent session burns

For anyone who runs an AI agent and keeps hitting the limit: the engineer whose Max plan runs dry by mid-afternoon, the team lead who sees the API bill double after adding one MCP server, and whoever has to explain either of those upstairs. Every number comes from one of two places: a published source listed at the end, or a worked example with five stated assumptions laid out in full in Level 0. The thresholds in the decision guide and the checklist are rules of thumb and are marked as such. The example is not a recording of a real session. It is an arithmetic model, so you can redo every sum yourself and swap in the numbers from your sessions. Prices are the public Claude API list prices as of 6 October 2026; on a subscription the same token counts draw on your plan limits instead of a card; the direction of every lever carries over, the exact size does not, because the plan weighting of cached tokens is not published. After reading you can look at a session's usage line and say which of six levers is eating the budget, and pick from 30 concrete suggestions, each with its saving on the example and its limit, what to change on Monday to fit more work into the same bill or the same plan limit.

The quick grasp (read this if you read nothing else)

Most of the tokens an agent burns are not spent on your task. They are spent re-reading what it already read. An agent session is a loop: you type something, the model reads the whole conversation so far, calls a tool, reads the whole conversation again plus the tool's result, and so on until it answers. The model has no memory between calls. Every call re-sends everything that came before it.

That one fact explains where the tokens go. The input cost of a session is roughly the startup context, times the number of turns, plus everything the turns added, re-read by every later turn. The second part grows with the square of the number of turns. Caching makes that re-reading cheap, but not free: in the worked example a session twice as long costs two and a half times as much with caching and three and a half times without. Output tokens, the model's thinking and its replies, cost five times more per token than input on current models and come on top.

Which gives six levers, and only six:

Caching changes the arithmetic without changing the shape. If a request starts with the same bytes as the previous one, the repeated part is billed at a few percent of the normal price. So a session where turns come quickly keeps its history cached and pays full price only for what is new. A long pause, a model switch, or a toggled tool breaks that, and the next turn re-pays the whole history. In Claude Code caching is on by default; on the raw API you turn it on with a marker, and a harness you build yourself has it only if you added it.

Important: the cheapest token is the one you never put in the context; the second cheapest is the one the cache has already seen.
What it means for us: caching is on by default in Claude Code, so every lever in this article is measured on a cached session. The levers that keep tokens out of the context (what each turn adds, how many turns there are) are worth as much as a model switch, and they stack with it.
Why it matters: in the worked example below, shrinking what each turn adds saves 34 percent of a cached session, a cheaper model saves 34 percent, and the two together save more than half. Starting with the model switch skips the lever that also keeps the context small, which is where quality goes first.

How to use this article: Level 0 runs one session through the arithmetic. Level 1 names the formula. Level 2 tells you how to measure the sessions you run, because you cannot pick a lever before you know which term is big. Levels 3 to 8 take one lever each and carry 30 concrete suggestions between them, each with its saving on the example and its limit. Level 9 covers the trade-offs where two levers pull against each other. Then a decision guide, takeaways, and a 26-question checklist you can run against your own setup on Monday.

The levels

Level 0: one session, turn by turn

This level answers: where does the money go inside one ordinary session?

The session: an agent answers a question by reading a folder of documents and drafting a short memo. It searches the folder, reads the files that match, follows a few references, checks a figure, drafts, and reports. Nothing unusual, and a coding session that reads a test, edits and re-runs has exactly the same shape. To make it computable, five assumptions:

Cached figures use real API billing: tokens already in the cache are billed as reads, tokens new to the turn as writes, and nothing is billed twice.

Now watch the context grow. At turn 1 the model reads the startup context and your one-line request. At turn 10 it reads the startup context plus nine turns of history. At turn 40 it reads the startup context plus 39 turns of history.

The request at turn 40 is seven times the request at turn 1, and nothing in the task got harder. The history is simply longer. What each of those turns costs, without caching, at list price:

The per-turn cost grows in a straight line with the turn number, and the sum of a straight line is a square. Add all forty turns:

Three quarters of the input is accumulation, not startup, by turn 40. That is the first thing the example teaches: the big term is the one that grows.

Now the same session with caching, using the 5-minute cache that is the API default (Claude Code on a subscription uses a 1-hour cache for the main conversation; Level 7 has the rules) and assuming every turn comes before the cache expires:

Look at the per-turn figures again: 0.145 at turn 1, 0.051 at turn 10, 0.075 at turn 40. Uncached, turn 40 cost six times turn 10. Cached, it costs half as much again. Caching flattens the per-turn line, because most of each turn is now a fixed write plus output, and only the re-read of the history still grows with the turn number, at a twentieth of the price.

Against the uncached sum, caching removed about 86 percent. That is not a saving you can go and collect: caching is on by default in Claude Code, so 2.49 USD is the real baseline, and the uncached sum is here only to show what caching did to the shape of the bill. Without caching, output was 5 percent of the total. With caching, output is a third of it. The same session, the same tokens, and a different lever at the top of the list.

Each of the next levels changes one assumption and leaves the other four fixed. The resulting six numbers are the spine of the article; every claim about which lever is bigger points back to one of them. Cached cost unless stated:

Two of the six are a tie: cutting per-turn growth and switching model each save a third, half a cent apart, and together they save 59 percent. Which of the two wins depends on the output assumption. With 500 output tokens per turn the growth cut saves 41 percent and the model switch 31. With 3,000, which a high effort setting easily produces, the growth cut saves 21 percent and the model switch 40, and halving the output saves 29. The levers that shrink the context matter most when thinking is modest; the price levers take over as thinking grows. Level 6 picks this up.

Carry forward from Level 0:

Level 1: the cost formula

This level answers: what are the terms, and which one does each lever touch?

Write the input side of the session as two terms. Without caching, the input tokens of a session are the startup context times the number of turns, plus the per-turn growth times the number of turn pairs (for 40 turns that is 780 pairs, 40 times 39 divided by 2). In words: the startup context is read once per turn, and everything a turn adds is read once by every later turn. The second term is the quadratic one, because the number of pairs grows with the square of the turn count.

Each lever is one symbol in that line, plus the price it is multiplied by:

Three of the six levers (startup context, per-turn growth, number of turns) live inside the input formula, and they interact. Halving the per-turn growth halves the quadratic term. Halving the number of turns quarters it. Halving the startup context only reduces the linear term, which is the small one in a long session. That is why, in the example, cutting growth saves a third while cutting startup saves under a tenth, and why a real cut in the turn count (not a split) would beat both. Output, cache and price are separate multipliers, and once caching bills the re-reads at a twentieth of the price, the multipliers are the same size as the context levers.

Now caching, in two paragraphs.

The API caches the prefix of a request. If the next request starts with the same bytes, that part is billed as a cache read instead of at full price. The read price is a tenth of the input price on most models, a twentieth on Opus 5.5, and a fortieth on Fable 5.1 (the pricing page lists 0.20 USD per million on Opus 5.5 and 0.25 on Fable 5.1). Writing to cache costs 1.25 times the input price for a 5-minute entry or twice the input price for a 1-hour entry. A read refreshes the timer for free. So a session where turns come faster than the cache lifetime keeps its whole history cached, and each turn pays full price only for what is new. In the example, that turned 17.28 USD into 2.49.

This is why session duration matters for the first time. A 20-minute coffee break expires a 5-minute cache; the next turn re-writes the whole history at 1.25 times the input price. Anything that changes the prefix does the same: a model switch, a toggled tool, a timestamp in the system prompt. That is lever 5, the cache hit ratio, and Level 7 has the full list of what breaks it and the lifetime rules, including the 1-hour cache that Claude Code uses on a subscription.

Important: the part of the bill that re-reads history grows with the square of the number of turns; caching makes that part cheap, not flat.
What it means for us: the levers that shrink the per-turn growth and the turn count are worth more than the lever that shrinks the startup context, and as much as a model switch.
Why it matters: a team that reads "40 turns cost 2.49 USD" and plans for "80 turns cost 5 USD" is short by a quarter: 80 turns cost 6.16 USD cached. Without caching the same plan would be short by nearly half: 60 USD against the expected 35.

Carry forward from Level 1:

Level 2: measure first

This level answers: which of the five terms is big in my sessions, and how do I know?

Everything so far was a model. Before pulling a lever you need the same four numbers for the sessions you run: input tokens, cache reads, cache writes, and output tokens. Four places give them.

From those four numbers, three ratios tell you which lever to pull:

Then one number above the ratios: tokens per completed task, with each kind of token weighted by its price, which on the API is simply dollars per completed task. Raw counts do not work across models or across cached and fresh tokens: in the example 96 percent of the input tokens are cache reads at a twentieth of the price. "Completed" means accepted by whoever judges the task, a passing test or a reviewer, and it travels with a success rate: a cheaper model that needs three retries is not cheaper, and a model that finishes in fewer tokens but fails more often is not cheaper either. A hook that truncates test output and hides the failing line costs a re-read turn. The ratios tell you where the tokens go; tokens per completed task tells you whether a change helped.

Important: context size hurts quality long before it hurts the budget, so trimming context pays twice.
What it means for us: treat the last third of the window as a zone to avoid, not as free capacity, and plan tasks to finish well before it.
Why it matters: the Context Rot study by Chroma (2025) measured 18 models and found accuracy degrading well before the window fills; one focused prompt of about 300 tokens beat the same question asked over roughly 113,000 tokens of history. Practitioners who run agents all day describe the same thing as a "dumb zone" in roughly the last 30 to 40 percent of the advertised window (Huntley, 2026, a working claim, not a measurement).

Carry forward from Level 2:

Level 3: Lever 1, startup context

This level answers: what is in the context before I type anything, and what can leave?

Startup context is the fixed rent of a session. It is paid once per turn (so forty times in the example), and written to the cache once per session that starts cold; a session that starts while a sibling's identical prefix is still cached reads it for a twentieth of the price instead (Level 7). Cutting it from 25,000 to 8,000 tokens saved 0.21 USD cached in one session and 2.72 USD uncached. Small per session, but it is the one lever that multiplies across every session, every subagent, and every automated loop you run.

Audit what loads: CLAUDE.md and AGENTS.md, rules, skills, plugins, MCP servers, memories, hooks. Print the turn-1 token count before and after each removal. In Claude Code the context command does this; in a harness you build, log the first request's input count. You are looking for two things: items that are large, and items that are present in every session but rarely used.

MCP servers: two decisions, in this order. An MCP server that loads eagerly puts its tool schemas into every session whether or not the session uses them; a CLI costs nothing until called and returns only what you asked for. The size of the problem, measured before deferral existed: Anthropic's own write-up of its Tool Search Tool counted five common MCP servers at 58 tools and roughly 55,000 tokens of definitions before the first user message, and some setups past 134,000. Those figures still apply to any harness that loads schemas up front.

First decision, whether the servers you keep are deferred. Claude Code now defers MCP tool definitions by default: only tool names and server instructions enter the context until the model uses a specific tool. Run the context command and check what your setup still loads eagerly, because a deferred server costs a few hundred tokens of names, not tens of thousands of schemas.

Second decision, which servers to keep at all. A deferred server is cheap but not free: its names are in every session, its schemas are written to the cache the first time it is used, and every extra tool is a distractor. If a server is used rarely (one session in five is a rule of thumb, not a measurement), drop it and make the tool a CLI described in one line in the instructions file. The schemas leave the startup set for good, and the agent still has the tool when it needs it.

For the servers you keep, defer the definitions instead of loading them all up front. If you build a harness on the API, the Tool Search Tool and the code-execution approach to MCP (where the model writes a small script that calls tools, and only the script's result returns) are the two documented ways to get the same effect. The measured numbers: loading definitions on demand cut one 77,000-token tool load to about 8,700, an 85 percent reduction by the vendor's count, and accuracy on an MCP evaluation went up, not down, because the model was choosing among fewer distractors; the code-execution post reports one workflow dropping from 150,000 tokens to 2,000. Checkly measured a real monitoring setup after Claude Code began deferring and found a deferred MCP server and a CLI within a few thousand tokens of each other. So the CLI rule is about servers you rarely use, and about harnesses that do not defer; a server you use every day is fine once it is deferred.

Progressive disclosure. Short description first, long description only when needed. Skills already work this way: a name plus one line at startup, the body loaded on demand when the skill is invoked. Apply the same to the docs you write and to the codebase: small files, grouped hierarchically into folders, imports flowing only bottom-up, so the agent reads one leaf and not the whole tree. A 2026 study of progressive disclosure for agent instructions found a flat index of one-line pointers works well and deep nesting hurts, because every extra hop is a turn.

One CLAUDE.md, short. Move everything task-specific into skills or recipes the agent calls when needed. The vendor's guidance is under 200 lines, and the auto-memory file is only read for its first 200 lines or 25 kilobytes. A 2026 evaluation of AGENTS.md files on real repositories is the cautionary tale: files generated by a model lowered task success and raised cost by about 20 percent, while short human-written files gave a modest gain of about 4 percent. Length is not help. The agent reads every line of that file on every turn.

Important: every item in the startup context is read on every turn of every session, so a 10,000-token convenience costs forty times 10,000 tokens per forty-turn session.
What it means for us: confirm that tool schemas are deferred, then move anything rarely used out of the startup set and into something called on demand: a CLI, a skill, a deferred tool.
Why it matters: eagerly loaded MCP servers alone can put 50,000 to 130,000 tokens in front of the first message, a quarter to two thirds of a 200,000-token window, before the model has read a single line of the task.

Carry forward from Level 3:

Level 4: Lever 2, accumulated context

This level answers: what does each turn add, and how do I keep it small?

Accumulated context is the term that compounds. Everything a turn adds is re-read by every later turn, so a 10,000-token tool result at turn 5 of a 40-turn session is read 35 times. Cutting the per-turn growth from 4,000 to 1,500 tokens took the cached bill from 2.49 to 1.63 USD and the uncached total from 17.28 to 9.48. It ties with the model switch as the biggest single lever in the example, and unlike the model switch it also keeps the context small, which is where quality goes first.

Limit the outputs of the tools and MCP servers you build. Cap lines, return summaries, paginate. Anthropic's guide to writing tools for agents makes the same point from the model's side: a tool that returns 50 rows with ids and a next-page token is more useful than one that returns 5,000 rows, because the model can ask for more but cannot un-read what it was sent. Claude Code caps an MCP tool result at 25,000 tokens by default; that cap is a safety net, not a target.

Limit the outputs of built-in tools with hooks. Truncate, filter, or summarise long tool results before they enter the context. Claude Code hooks can rewrite a command before it runs (a PreToolUse hook that pipes a test run through a filter for failures) or replace a tool's output after it runs (a PostToolUse hook that returns an updated tool output). The cost documentation's own example turns a 10,000-line log into the handful of lines that contain errors. Tens of thousands of tokens become hundreds, on every turn that follows.

Avoid screenshots where text will do. An image costs far more than the text on it and cannot be grepped later. A single 1092 by 1092 pixel image is about 1,600 tokens by the vendor's formula, and a screenshot of a terminal carries less information than the 200 tokens of text it shows. An image, once in the history, is re-read on every later turn like any other token, and changing or removing it later invalidates the cache from that point.

Isolate context-heavy steps into a subagent or a separate session that returns only the final result: searching a retrieval index or a wiki, reading a large file, running a long test suite. The subagent's context fills with the mess; the parent receives a one or two thousand token summary. The vendor's long-running-agent harness post and its context-engineering post both describe this as the default pattern for research-style steps. The trade-off is in Level 9.

Context editing. The API can clear old tool results automatically, keeping the most recent few and dropping the rest once the context passes a threshold. Anthropic's own evaluation of this on a 100-turn web-search task reports an 84 percent reduction in token use and a quality gain, a vendor claim on a vendor benchmark but a large one. Claude Code does something similar at compaction, and since version 2.1.251 counts those rebuilds separately in the cache line. Know which one your harness uses, because both rebuild the cache once when they fire.

Compaction threshold. Auto-compact at a set size (for example 125,000 tokens) rather than at the hard limit. A compact summary of 40 turns costs a few thousand tokens per later turn instead of a hundred thousand. In Claude Code this is the auto-compact window setting, also available as an environment variable. One measured caution: a 2026 study of context compression in coding agents found that compressed agents re-query for information they already had in six of six settings, so some of the saving comes back as turns. Trade-off in Level 9.

Do not let the agent re-read what it already has. Repeated reads of the same file are a smell. It usually means the earlier read was truncated or the agent lost track. Fix the truncation or the instructions, not the model.

Important: a token added at turn t is paid for on every turn after t, so the cost of a tool result is its size times the number of turns remaining.
What it means for us: cap tool outputs at the source, prefer text to images, and send noisy steps to a subagent that returns a summary.
Why it matters: one unfiltered test run of 20,000 tokens at turn 5 of a 40-turn session adds 700,000 input tokens to the bill, more than two thirds of the whole startup term.

Carry forward from Level 4:

Level 5: Lever 3, number of turns

This level answers: why are turns the square, and what makes a session shorter?

The turn count sits in both terms of the formula and squares in the second. Doing the same task in 20 turns instead of 40 costs 1.14 USD cached instead of 2.49, more than half off; nothing else in the example comes close. Even splitting the same 40 turns into two sessions of 20 saves 9 percent cached when the second session starts cold, 14 percent when it starts warm, and 37 percent uncached, although the startup context is paid twice. Doubling to 80 turns costs two and a half times as much cached and three and a half times uncached, not twice.

One task per session. A new session is a fresh prefix. Clear between unrelated tasks; in Claude Code the clear command is free, and the vendor's cost guide names "long sessions never cleared" as the most common cause of surprising bills. Rename the session before clearing so you can resume it later if you need the trail.

Few simple tasks instead of one composite task. History accumulates across every step of a composite task, so step 8 pays for steps 1 to 7. This is the quadratic term made visible. A 2026 benchmark study of agent spending across 23 models found that turn-by-turn interaction consumed up to 3,500 times the tokens of a single-round answer to the same problem, and that more tokens did not buy more accuracy. The comparison is interaction against one shot, not composite against simple, but the mechanism is the same: every extra turn re-reads everything before it.

Isolate turn-accumulating work (complex multi-step search, trial-and-error debugging) into its own session; bring back the answer, not the trail. The multi-turn study "LLMs Get Lost in the Multi-Turn Conversation" (2025) measured a 39 percent average performance drop across 15 models when the same task was delivered in pieces over turns instead of all at once. That study is about instructions arriving piecemeal, which is the next point; what it shows is that a long back-and-forth costs quality as well as tokens.

Provide context and instructions up front. Every fact the agent has to discover is a turn. File paths, expected behaviour, which tests to run, how to run them, what "done" looks like. A specific prompt ("add input validation to the login function in auth.ts") lets the agent work with minimal file reads; a vague one ("improve this codebase") triggers broad scanning.

One task per loop. The Ralph pattern: a loop that starts a fresh agent process for each iteration, hands it one bounded task from a list, and exits. Each iteration pays startup once but never carries the previous iteration's trail; and because the iterations run back to back with the same prefix, the second and later ones read the startup context from the cache instead of writing it (Level 7). Its author's argument is exactly the arithmetic above: a long-lived session drifts into the zone where the context is both expensive and dumb, and a fresh process per task stays in the cheap, sharp zone. The vendor's own harness for long-running agents does the same thing with "one feature per fresh session" and a progress file on disk. Huntley's claimed numbers (a 50,000 USD contract delivered for about 300 USD of tokens) are a practitioner's anecdote, not a measurement, but the shape is sound.

Plan first, then execute. A short planning turn with the task spec written down reduces exploratory turns later. In Claude Code, plan mode makes the agent explore and propose before it edits, so a wrong direction costs one plan rather than ten edits and a revert.

Cap the retries. The most expensive turns in a session are the ones spent trying the same fix again. They come at the end, when the history is longest, and each one re-reads everything the failed attempts added. In the example, ten turns of retrying at the end of a 40-turn session (turns 31 to 40) cost 0.73 USD cached, 29 percent of the session, and 6.72 USD uncached, 39 percent, for nothing that the first attempt did not already show. The multi-turn study above found that models rarely recover once they have gone wrong in a conversation, so the cheaper move after a second failed attempt is to stop, write down what was learned, and start a fresh session with that note. Put the rule in CLAUDE.md ("after two failed attempts at the same fix, stop and report"); in headless runs use the spend cap flag (in Claude Code, a maximum budget in dollars for a print-mode run) so a stuck loop ends itself.

Parallel tool calls. Independent tool calls in one turn cost one turn, not three. The model can read three files in a single response; the API documents this, and a prompt line asking for it raises the rate. Three reads in one turn add three results to the history once, instead of three results plus two extra re-reads of everything.

A measured bound on all of this: a 2025 study of turn control in agents found that capping turns at the 75th percentile of a task's usual length cut cost by 24 to 68 percent with little loss of success. The reading I take from it: the tail of long sessions is mostly retries that would not have worked anyway.

Important: the turn count appears in both terms of the formula and squares in the one that dominates.
What it means for us: split work into bounded tasks, write the spec up front, and start fresh for each task rather than continuing a long session.
Why it matters: the last twenty turns of a forty-turn session re-read three times as much history as the first twenty; caching turns that into 20 percent more money, but the context is twice as long, and the Context Rot measurements in Level 2 say that is where quality drops.

Carry forward from Level 5:

Level 6: Lever 4, output tokens

This level answers: how much does the model say and think, and who decides?

Output is billed at five times the input price, and thinking counts as output. On Opus 5.5 that is 20 USD per million against 4; on Fable 5.1 it is 50 against 10. In the uncached example, output was 5 percent of the bill and easy to ignore. In the cached example, where the input side had shrunk by 90 percent, output was a third. Halving it took the bill from 2.49 to 2.09 USD. Once you have caching working, output is the next line on the invoice.

Where output comes from: the visible reply, the thinking before it, and on current models the thinking before every tool call too. The Claude Code cost guide says the default thinking budget "can be tens of thousands of tokens per request depending on the model". That is per request, and a forty-turn session is forty requests. The example assumes 1,000 output tokens per turn; at 3,000 per turn output is 59 percent of the cached bill and halving it saves 29 percent, more than cutting the per-turn growth. At 10,000 per turn output is 83 percent of the bill and nothing else matters until it is down.

Effort level. Effort is a single parameter (low, medium, high, xhigh, max on current models) that tells the model how much to think, how many tool calls to make, and how terse to be. Lower effort means fewer and more consolidated tool calls, less preamble, terser confirmations. The vendor's steering guide is explicit that effort controls thinking depth and tool use, and that reply length should be asked for in the prompt. Measure quality at medium before defaulting to high or xhigh. On Opus 5.5, Sonnet 5.5 and Fable 5.1 changing the effort mid-session keeps the cache; on earlier models it breaks it, so set it at the start.

Ask for terse replies in CLAUDE.md for routine work; ask for full explanations only when you will read them. The reply is paid for whether or not anyone reads it. A 2024 study of concise chain-of-thought prompting found a 49 percent reduction in response length at nearly unchanged accuracy from a single instruction. On current models the prompt controls the visible reply; the thinking is controlled by effort.

Fast mode costs twice as much per token. Opus 5.5 in fast mode is 8 USD per million input and 40 output, against 4 and 20. Use it for latency, never to save money. Turning it on mid-conversation is also a cache invalidator, so the next turn re-pays the whole history at full price.

Important: on a well-cached session, output is the largest remaining line, and the thinking budget is the part of it you did not ask for.
What it means for us: set effort to the lowest level that passes your task evaluation, request terse replies for routine work, and treat fast mode as a latency purchase.
Why it matters: with effort left at the top, forty turns of "tens of thousands of thinking tokens" at 20 USD per million can exceed the entire cached input bill.

Carry forward from Level 6:

Level 7: Lever 5, cache hit ratio

This level answers: how much of my input is served from cache, and what is breaking it?

Everything so far cut tokens. This lever and the next change what each token costs. Caching comes first because it is the bigger of the two and because it is already on: the question is not whether to use it but what stops it from working. In the example a fully cached session costs 2.49 USD against 17.28 uncached, and a single miss at turn 20 re-writes a 101,000-token prefix for 0.50 USD instead of reading it for 0.02, a fifth of the session. The number to watch is the cache hit ratio from Level 2: cache reads divided by all input, above 90 percent on a long session, checked per request.

What breaks the cache. The cache holds the prefix of the previous request. Anything that changes that prefix, anywhere, invalidates everything after the change, and the next turn writes it again at 1.25 times the input price. The list: switching model, toggling an MCP server or tool mid-session, a timestamp or session id in the system prompt, changing or removing an image earlier in the conversation, changing the effort level on models that do not preserve the cache across effort changes, turning on fast mode, and compaction or context editing, which rebuild the history once when they fire. The Claude Code cache line in the usage command names the likely cause of each miss (tool definitions changed, model switched); in a harness you build, log cache_read_input_tokens per request and look at the turn where it drops to zero.

Lifetime and gaps. The API default cache lives five minutes, and every read refreshes it for free, so a session whose turns come faster than that stays cached indefinitely. Claude Code on a subscription plan uses a 1-hour cache for the main conversation, which drops to five minutes once you are drawing on usage credits; on an API key or a cloud provider the default is five minutes. So the coffee-break loss in Level 0 is an API-key fact; on a plan the same loss needs a break of more than an hour, a lunch rather than a coffee. Subagents use the 5-minute cache either way. On the API, set the 1-hour cache on workloads with gaps between five and sixty minutes: it costs twice the input price to write instead of 1.25 times, and that extra 3 USD per million is earned back the first time it prevents one expiry and rewrite (in the example the extra premium is about 0.54 USD over the whole session, and one avoided rewrite at turn 20 is worth 0.5 USD, more later on).

The cache is shared across sessions. The cache is not tied to a conversation. It is keyed on the exact bytes of the prefix, per organisation and per model, and any request from any session that sends the same bytes within the lifetime reads it. Two consequences follow. First, "a new session pays startup again" is only true when the new session starts cold: a second session started within the lifetime, with an identical prefix, reads the 25,000-token startup context for 0.005 USD instead of writing it for 0.125. That is where the warm split figure above comes from. The condition is strict, though: byte-identical. A git status line, today's date, an auto-loaded memory file that changed, a different set of tools, a different model, any of these makes the second session's prefix a different key, and it starts cold. A fork of the current conversation inherits the parent's full prefix and therefore its cache; a fresh subagent sends its own prefix and starts its own. Second, when you run many tasks at once from the same startup context (a fleet of agents, a batch of Ralph iterations, a queue of subagents), startup stops being the lever it looks like. The prefix is written once, for 0.125 USD, and then read: 0.20 USD per 40-turn session in the example, which is the same 0.20 whether one session runs or fifty, because reads are already the cheap rate. What does not shrink is the per-session part: the growth term and the turn count are paid in full by every session, and they are the quadratic part. So a fleet of identical starts shifts the weight of the bill from lever 1 to levers 2 and 3. Trim startup for the quality reasons in Level 2 and for sessions that start cold; for a fleet, cut what each session accumulates and how many turns it takes.

Prefix order. Stable content first, volatile content last: system prompt, then tools, then instructions, then the conversation, with anything that changes per request (the date, the current file, the latest tool result) at the very end. The Harness Effect paper's two-zone prompt is this rule applied strictly, and it reached 99.9 percent of input served as cache reads. A harness that rewrites the system prompt per turn, or re-sorts tools, pays a full write on every request and never notices, because the dollar total still looks like one session.

Breakpoints, and the last turn. On the API you say what to cache with cache_control markers, up to four per request. The usual shape is one after the system prompt and tool definitions and one on the latest message, moved forward each turn. The API matches the longest cached prefix it has and writes only the part after it, so moving the marker writes the new turn, not the history, and anything shorter than the minimum cacheable length (a few thousand tokens, depending on the model) is not cached at all. Claude Code and most harnesses place these markers for you. Is it worth writing the latest turn, given that the write costs 1.25 times a plain read? Yes, whenever one more turn follows: a 5-minute write plus one read costs 1.30 against 2.00 for two plain reads of the same tokens, so the write pays back on the very next turn. The only wasted write is the last turn's, and that is the new tokens of one turn, about 4,000 in the example, at the write premium: 0.004 USD. Not worth managing. The 1-hour cache writes at twice the input price and needs two later reads to pay back, so it belongs on a prefix that is long-lived, not on the newest turn of a conversation that is about to end. The one case where the rule flips is single-shot work: a batch of independent requests that share a long prompt and never continue. There, put the marker after the shared prompt and nowhere else, because the per-request part is never read again.

Caching rules in one list. Stable prefix first, volatile content last. No timestamps in system prompts. Do not toggle tools or models mid-session. Keep turns closer together than the cache lifetime, or set the longer one. Start sibling sessions from a byte-identical prefix so they read what the first one wrote. Check that cache reads are not zero, per request, not per day. Fix the hit ratio before pulling lever 6, because a model switch on a session that misses the cache is a discount on the wrong bill.

Important: a cache miss re-pays the whole history at 1.25 times the input price; a hit pays a twentieth.
What it means for us: read the cache hit ratio per request before touching the model, remove every invalidator you control, and match the cache lifetime to the gaps in your work.
Why it matters: in the example one 20-minute gap on the API costs a fifth of the session, and a session that misses on every turn costs seven times one that hits.

Carry forward from Level 7:

Level 8: Lever 6, price per token

This level answers: once the cache is working, what sets the price of a token, and which choices change it?

This lever changes the price of the tokens the cache did not absorb: the writes and the output. There are more ways to do that than "pick a cheaper model", and several of them stack.

Separate brain from hands. Analysis and planning with the strongest model, execution with a simpler one. Claude Code's "opusplan" setting does exactly this: Opus for plan mode, Sonnet for execution. The price of it is one cache rebuild at the switch, because the cheaper model cannot read the prefix the expensive one wrote, so it pays when the execution phase is long enough to earn the rebuild back (in the example, a rebuild at turn 20 costs about 0.5 USD and the cheaper model saves about 0.02 USD per turn after it, so the switch needs more than 25 execution turns to pay). One caveat from the vendor's cost guide: measure the strongest model at lower effort first. It often beats a cheaper model at high effort, and one model means one cache.

The cheaper model saves less than its list price. In the example, switching to Sonnet 5.5 saved 34 percent, not 50. Cache reads cost the same 0.20 USD per million on both models, and in a well-cached session reads are most of the input. The saving comes from writes and output only. Measure the saving on cached sessions, not on the price list.

Local model for text processing: summarising, extracting, reformatting, classifying. Practitioners running 27 to 35-billion-parameter open models on a workstation report them handling bounded, well-specified chores (telemetry analysis, code review) for the price of electricity, and looping or hallucinating on open-ended tasks. Not for the hard reasoning, but for the parts of a pipeline that do not need it.

Judge models for classification. For route-this-ticket or rate-this-output jobs, a typed judge model that returns a probability over labels instead of generating text is far cheaper than a generative call. TypeSafe's Jev is one such product; its documentation claims about a hundred times lower cost per judgment and a response in well under a second, a vendor claim, and I use it in my own pipelines. Two limits: a judge only picks among labels you supply, and it needs the same evaluation as any classifier before you trust its probabilities. The principle holds for any classifier: when the answer is a label, do not pay for prose.

Subscription against API. This is the question the previous levels skipped, so here it is in full. On the API you pay per token at the prices above. On a Claude subscription (Pro, Max, Team, Enterprise) you pay a flat fee and every request draws on a per-seat allowance that resets on a rolling 5-hour window and a weekly window, shared across Claude chat and Claude Code. The allowance is drawn down by the tokens you send and receive. Anthropic does not publish how cached reads are weighted against it, so treat the dollar deltas in this article as a proxy for window use: the direction of each lever carries over, the sizes are unconfirmed, and a lever whose saving comes mostly from cheap cache reads (the model switch) may look different on a plan. Three practical differences: the main conversation gets a 1-hour cache instead of five minutes; the usage command's dollar figure is an estimate that does not bill you; and utilisation means spreading work across windows, not bursting, because a window hit stops everything until it resets. Other vendors sell the same shape: OpenCode Go, for example, is a flat-fee plan at 10 USD a month (and a larger tier at 40) with a 5-hour window, a weekly window and a monthly cap, documented as percentages of the plan rather than token counts. Check its current limits page before planning around specific rates.

Important: a cheaper model does not make cached tokens cheaper, and switching models throws the cache away.
What it means for us: try the strongest model at lower effort before a model swap, switch models only at a point where the execution phase is long enough to earn the cache rebuild back, and reserve the cheap model for whole tasks that do not need the strong one.
Why it matters: the model switch is the lever everyone reaches for first, and in the well-cached example it is worth a third of the bill, less if the cheaper model needs more turns, and no more than cutting what each turn adds.

Carry forward from Level 8:

Level 9: trade-offs

This level answers: which way does each one go, and when?

Every lever above has a case where pulling it costs you somewhere else. Five of them come up constantly.

Caching against splitting. Splitting into sessions drops the accumulated history and re-pays startup context, in full if the second session starts cold, at the read price if it starts warm with the same prefix. In the example, two 20-turn sessions beat one 40-turn session (2.27 cold or 2.15 warm against 2.49 USD cached, 10.88 against 17.28 uncached) even though startup is paid twice. The break-even depends on that one condition: with a 25,000-token startup context and 4,000 tokens of growth per turn, a cold split starts to pay at about 24 turns in total, by 1 percent there and 9 percent at 40 turns; a warm split pays at any length, because the second startup costs a twentieth. Uncached it pays at any length too. Shorter startup contexts move the cold break-even earlier, and the second session has to be re-briefed on what the first found, which the arithmetic does not count. Split for the quality reasons in Level 5 before you split for the tokens.

Subagents against one context. A subagent isolates its mess but cannot see the parent's history, and a fresh subagent pays its own startup, written cold unless a sibling just wrote the same prefix; a fork inherits the parent's prefix and reads it. Good for read-heavy work (search the index, read the long file, run the suite and report failures), bad for work that needs the parent's state (apply the fix we just discussed). Two measured warnings: Claude Code's documentation puts agent teams, where several full agents run at once, at roughly seven times the tokens of a plain session, and Anthropic's multi-agent research write-up puts its research system at about fifteen times the tokens of a chat. Cognition's "Don't build multi-agents" argues the quality side of the same point: parallel agents lose each other's decisions. Use one subagent for one bounded, read-heavy step; do not use a team to parallelise a task that shares state.

Compaction against clear. Compaction keeps a summary and may keep stale facts; it is also a large request (it reads the whole conversation to summarise it) and it rebuilds the cache. Clear starts fresh, costs nothing, and loses the plan. Rule: compact when the plan is still valid and the next steps depend on what was decided; clear when the task changed. The 2026 context-compression study found compressed agents re-query for information they had, so a compaction that drops the file you are editing costs a re-read turn.

Strong model against cheap model. Tokens per completed task decide, priced at each model's rate. In the example the cheaper model saves 34 percent on a well-cached session, not 50; if it needs 15 more turns to finish, the saving is gone, because fifteen more turns at the end of a forty-turn session are the expensive ones. The Harness Effect paper (2026) is the counterweight: the same model under a leaner harness delivered the same task quality at about 40 percent lower cost (0.21 to 0.12 USD per task) and 38 percent fewer tokens, with 99.9 percent of input served as cache reads thanks to a two-zone prompt that keeps everything volatile at the end. The paper compares harnesses, not models, so the lesson is that a harness change can be worth as much as a model change, measured the same way. Harness before model.

Hooks that truncate against tools that paginate. Truncation is cheap but can hide the line the agent needed, which costs a re-read turn and sometimes a wrong fix. Pagination costs a design change in the tool and returns the right lines. Truncate output that the agent should never need in full (progress bars, passing tests, install logs); paginate output where the needed line could be anywhere (search results, log files, large data).

Important: every lever has a region where it costs more than it saves, and the region is set by the formula, not by taste.
What it means for us: decide splits, subagents and compaction by comparing the quadratic saving against the extra startup read, and decide model swaps by tokens per completed task at each model's price.
Why it matters: in the example, a cold split below 24 turns, a subagent for a step that needs the parent's state, or a model swap at turn 30 each cost more than the plain session they replaced.

Carry forward from Level 9:

The tools and approaches, observed

What I have seen used, with the one fact about each that decides whether it fits.

A decision guide

Read your usage line, find the row, pull the lever. The thresholds are rules of thumb; the example sits just under the first two of them and exactly on the third, and the levers still paid there. Dollar deltas are from the example; on a subscription expect each lever to free some of your rolling window, in the same direction and in an unpublished proportion.

Fifteen things to carry away

One-page checklist

At startup

Per turn

Per session

Per model

Per bill

References

Vendor documentation (Anthropic), fetched 6 October 2026:

Engineering write-ups:

Papers: