Token efficiency in Claude Code: why the week runs out early, and why the fix is mostly free

A Claude Code subscription that empties before the week is out is rarely a wrong setting. The limit hands out an opaque rate against two clocks and one shared pool; what drains it is structural — every turn resends the whole conversation, so a task's cost grows with about the square of its turn count, and prompt caching quietly saves more than any dial the user touches. This report ranks the real cost drivers, explains the turns-squared mechanism, gives the honest verdict on whether a heavy CLAUDE.md is the culprit, and orders the levers cheapest-first — the free ones at the top.

Published · By Dan Walter

Executive summary

A Claude Code subscription that empties before the week is out is almost never the symptom of a wrong setting. The weekly limit is opaque by design: it hands out a rate, metered against two clocks and drawn from one pool shared with Claude chat and Cowork, and it never names a token budget to manage. What actually drains it is structural. An agentic task is a loop, and every turn of that loop resends the entire conversation so far, so the cost of finishing a task climbs with roughly the square of the number of turns it takes. A session that wanders, or lingers open across unrelated work, spends its allowance on invisible overhead rather than on output — which is why the meter so often feels broken when the activity looks light.

The most powerful economy in the whole system is one nobody configures. Prompt caching serves an unchanged context prefix at a fraction of the fresh rate, and it is the single largest lever on cost — which means the cheapest wins are defensive: keep the cache warm, read in less, and end a session before it sprawls. Only beneath those does the choice of model and reasoning effort — the subject of a sibling report on the other dial — come into play, and only then does trimming a heavy stack of standing instructions. The order is the point: the free levers sit at the top, and they resolve most "ran out early" weeks without surrendering an ounce of capability.

This matters well beyond a progress bar. As more of an operator's real work moves onto agents — the defining move of an AI-native way of working — the weekly cap stops being a nuisance and becomes the binding constraint on how much an AI workforce can actually get through in seven days. Understanding where the tokens go is therefore understanding the economics of running on AI at all. It is not a rationing exercise. It is the difference between spending a week on the work and spending it on overhead nobody named.

The weekly limit is a rate, not a number

Every unit of work an operator hands to an agent is metered, and the meter is the weekly limit — which is precisely the part of the system that resists being reasoned about. The reason it is so hard to ration is that Anthropic never states the quota in the unit a user would want it in. There is no published token budget for a subscription. What a plan buys is a relative position — Pro is the baseline, Max multiplies it five- or twenty-fold — metered against two overlapping windows and drawn from a single pool that also feeds Claude chat and Cowork.

Exhibit — The subscription meters a rate against two clocks — never an absolute token budget.. There is no number to manage, only a rate set by the work — which is exactly why the levers, not the settings, decide the week. Source: Anthropic Claude Code cost docs (code.claude.com/docs/en/costs) and the Max-plan help centre, as of Sept 2026.

Read those four facts together and the mystery dissolves. There is no number to see because none exists to see: burn rate, in Anthropic's own framing, depends on conversation length, complexity, model choice and features. The two clocks run independently — a five-hour window that rolls forward continuously, and a weekly window that resets at a fixed time assigned to the account, not on any universal Monday. There is a second layer of subtlety in the model-family sub-limits: hitting an Opus limit is not the same as hitting the seat limit, and a user who has exhausted one model family can often keep working by switching to another with `/model`, whereas the seat-wide window cannot be escaped that way.

Hitting the cap is not a dead stop, either. The message names the exact moment the window resets; usage credits, where an organisation or subscriber has turned them on, let work continue past the allowance at metered rates; and recent versions of Claude Code can simply wait for the reset and resume the interrupted task on their own. All of that is worth knowing, and none of it changes the underlying arithmetic. The allowance is finite, the reset is fixed, and the only durable lever is reaching the same result for fewer tokens — which is a question about where the tokens go, not about which button stops the bleeding.

Because the pool is shared, an afternoon of heavy coding quietly borrows from the allowance a user was saving for something else entirely. Anthropic states the quiet part plainly in its own budgeting guidance: budget more for a coding seat than a chat seat, because each Claude Code turn carries file contents, tool calls and multi-step reasoning, so one debugging session can consume more than a day of chat. That sentence is the whole report in miniature. The thing draining the week is not a setting; it is what a turn costs — so the honest way to find the savings is to follow the tokens.

Most of the week goes to context, not the model badge

There is no token number to watch, but there is a window onto the rate. The `/usage` breakdown attributes recent usage to skills, subagents, plugins and individual MCP servers, each as a percentage of the total; it raises a behaviour flag when one pattern — long context, cache misses — accounts for a tenth or more of recent usage; and it lists the heaviest scheduled loops by total tokens. A toggle swaps the last twenty-four hours for the last seven days, and `/insights` goes further, analysing recent sessions to report not how many tokens were spent but where the friction was. So the driver list below is not folklore. It is what that breakdown surfaces, session after session, and the same short set appears every time — roughly in the order they tend to bite for typical agentic work, with the honest caveat that this is a shape, not an official leaderboard, and any given mix depends entirely on the work being done.

Exhibit — Six things drain a week — and only the first two are about the model at all.. Most usage is context and turns, not the model badge — so most of the saving lives in how a session is run, not which model it picked. Source: Anthropic Claude Code cost docs (code.claude.com/docs/en/costs), Sept 2026. Order is directional, not an official ranking.

The card that surprises people is the second, not the first. Context is the master dial, and the documentation puts it without ornament: token costs scale with context size; the more context Claude processes, the more tokens are used. Model choice matters because it sets the rate on all that context, and the whole of the sibling report is devoted to that dial. But the volume being priced is almost always context — the files read in, and the conversation carried forward on every single turn. Two of the lesser drivers are worth pre-empting before the mechanism chapter, because they are easy to fix once named. Extended thinking is billed as output, and the default budget can run to tens of thousands of tokens per request on a hard task, which is why lowering effort on work that does not need deep reasoning is nearly free money. And MCP tool definitions, once a quiet tax, are now deferred by default: only tool names and server instructions enter context until a specific tool is actually used, so a wall of unused integrations no longer sits in every prompt.

Two other drivers compound while nobody is watching, and they deserve the next two chapters. The agent-team figure is the eye-catching one: a team of teammates uses roughly seven times the tokens of a single session, because each teammate spins up its own context window as a separate Claude instance and keeps consuming until it exits. That is not an argument against ever delegating. Handing one verbose job — running a test suite, grinding through a log file — to one sub-agent actually protects the main context, because the noise stays in the teammate's window and only the summary comes back. It is an argument against reaching for a crowd when one worker would do. The quieter and far more common drain is the long session, and it runs on a mechanism worth understanding, because it is the one that makes the meter feel broken.

Double the turns and the cost roughly quadruples

An agentic task is not one request; it is a loop. Claude reads something, acts, reads the result, acts again — and every turn resends the whole conversation so far, because that history is how the model knows what it is doing. A task that takes forty turns therefore sends its early context something like forty times over. Cost does not rise in step with the work. It rises with roughly the square of the turn count.

Exhibit — Double the turns and the cost roughly quadruples, not doubles.. The cheapest task is the one that finishes in the fewest turns — which is why a capable model and a clear prompt pay for themselves. Source: Illustrative of the mechanism Anthropic documents: each turn resends the full conversation, so cost grows with about the square of the turn count. Not exact figures.

The gap between those two lines is the tax a wandering task pays. It is why a weaker model that flails on an ambiguous job is not a little more expensive but a lot more: it takes more turns, and every extra turn is priced against a longer history — the same reason the sibling report on model choice argues that a more capable model often finishes cheaper, not dearer. Retries make the same shape worse, because a failed attempt bills its tokens, then the retry bills again on top. The cheapest task, in other words, is the one that finishes in the fewest turns, which reframes two ordinary habits as cost controls: writing a specific prompt instead of a vague one ("add input validation to the login function in auth.ts," not "improve this codebase"), and using plan mode to settle the approach before implementation so an expensive wrong direction is caught before it runs.

The same mechanism is why a session left open all day is such a silent drain. Anthropic's documentation is blunt about it: Claude Code sends the full conversation with every request, and with caching it re-reads that history at the cached rate — so a one-line question in a session that has been open since morning still draws usage for the whole day's conversation. This is the exact failure the auto-compact window exists to soften, summarising older history as the context fills; but auto-compaction is a mitigation, not a licence to let a session sprawl. Worse, an idle session is not necessarily a quiet one. A scheduled task fires on its interval and sends the full context each time, whether or not anyone is watching; a message handed over from another session arrives as a fresh turn carrying the whole context; and while background work keeps a goal waiting, Claude Code checks on it of its own accord, each check-in another full-context turn. The turns mechanism does not pause just because the human did. The fix is not to work less. It is to stop dragging a morning's context into an unrelated afternoon question — which points straight at the single most powerful economy in the system, and the one almost nobody thinks about.

Caching is the quiet giant, and the easiest lever to break

Prompt caching is a discount quietly applied that no user configured and few notice. When the start of a context is unchanged from the previous request — the system prompt, the standing instructions, the tool definitions, the early conversation — Claude reads that prefix from cache instead of reprocessing it, and cached reads bill at about a tenth of the rate of fresh input. Across a long agent loop, where the same growing prefix is re-sent on every turn, that is the difference between a cold and a warm path, and it is not a rounding error.

Exhibit — Kept warm, the same agent loop runs at roughly a third of the cold-cache cost.. Almost nothing else moves the needle this much — which is why thrashing the cache is the most expensive small habit there is. Source: Directional. Anthropic prompt-caching docs: cached reads bill at ~0.1× fresh input; the loop-level multiple is illustrative. As of Sept 2026.

Because caching is doing this much automatically, the practical advice is almost entirely about not breaking it. A cache helps only while the prefix it holds stays byte-for-byte identical and stays warm, and a handful of ordinary habits throw it away. Switching model mid-task starts a new cache from scratch, because caches are model-scoped. Changing effort level mid-session invalidates the message cache. Editing a CLAUDE.md while working rewrites the very prefix everything downstream was matching against — the documented invalidation order is tools, then system, then messages, so a change high in the stack invalidates everything beneath it. And walking away for longer than the cache lifetime — an hour on a subscription, dropping to five minutes once usage credits are in play — means the next message misses the cache and reprocesses the entire context at full price.

That last one is what the usage screen flags when cache misses cross ten percent of recent usage: not a bug, a cold start that was paid for. The definition is precise — Claude Code counts a request as a miss when it reprocesses more than five percent and at least two thousand tokens it could have read from cache — and the same `/usage` breakdown flags "long context" the moment it, too, crosses the ten-percent line. On the larger sessions, resuming from a summary after a long break sidesteps the worst of it, so later requests do not carry the full history back into a cold cache. Even the cleanup has a price worth knowing: `/compact` has to read the conversation it summarises, so compacting a very large context is itself a large request, while `/clear` — a clean break with no summary to build — costs nothing. And a user drawing on usage credits, whose cache lifetime otherwise drops to five minutes, can keep the one-hour window by choosing the TTL deliberately. The rule underneath all of it is simple: keep the cache warm and steady and the discount arrives for free; thrash it and it is handed straight back.

The instruction stack is a standing tax caching discounts but never zeroes

The lever most often blamed is the one users set up themselves: the CLAUDE.md file, the standing instructions Claude reads at the start of every session. The honest accounting has two halves, and both are worth stating plainly. The first half: yes, it is a real, recurring cost, and it is easy to underestimate precisely because it is invisible. Instruction files load into context at session start and sit there for the whole session, whether or not the work in front of them needs a single line of it. Editing them mid-session does not even help until the next `/clear`, `/compact` or restart, because the loaded copy is what is in play.

Exhibit — Instruction files reload every session — roughly two thousand tokens before the first word.. A recurring tax, not a one-off — and a heavy stack of skills and protocols multiplies it, which is why lean instructions matter most for power users. Source: Directional. Anthropic advises keeping CLAUDE.md under 200 lines and moving reference content to on-demand skills; the ~320 / ~1,800-token split is a reported figure, not a live measurement.

The second half is the one that keeps the accounting honest: for most users that ~2,000-token load is real but small beside a single big file read, a deep exploratory loop, or a seven-times agent-team fan-out. The official cost-driver ranking puts context size, extended thinking and subagents at or above a standing instruction file, so a typical user worried a CLAUDE.md is the reason for running out early is almost certainly wrong — model, effort and context hygiene will pay back faster. The exception is the power user running an unusually heavy stack. The heaviest setups — a global file, a project file, a large roster of skills, session hooks, whole protocol machineries — are real; I run one, and the per-session tax sits well above the baseline. Multiply a couple of thousand tokens by every session, all week, and it stops being a rounding error and becomes a genuine top-tier lever for that setup specifically. The way to settle it for any given stack is to stop guessing and measure: a token count of the assembled global-plus-project-plus-skills payload turns the argument into a number, and the number usually decides the question.

The fix is the same whoever is paying it, and Anthropic states it directly: keep CLAUDE.md under about 200 lines, and move anything reference-shaped — the detailed how-tos needed only occasionally — into skills that load on demand when invoked, or into path-scoped rules that load only when Claude touches matching files. The essentials stay present; the encyclopaedia stays on the shelf until it is reached for. (The `/doctor` checkup will even propose trims, cutting what Claude can derive from the codebase and keeping the conventions and pitfalls that differ from tool defaults.)

One caveat is worth stating clearly, because it is tempting to wave the cost away with "it's cached, it's fine." Caching does not make standing instructions free. The documentation is explicit that a cached prefix is re-read on every turn — cheaply, at the cached rate, but re-read, and re-drawn against the plan; a one-line question still draws usage for the whole cached context. What Anthropic documents precisely is the dollar discount on the API, cached reads at about a tenth of fresh input; exactly how that discount maps onto the subscription weekly cap is not spelled out anywhere public. So "it's cached, therefore free" is wrong on its face — the cost is reduced, never removed — and it is not a safe reason to let the file sprawl.

Spend the free levers first

Put the whole picture together and the advice sorts itself into a clear order, and the good news is that the levers that cost nothing sit at the top. Most "ran out early" weeks are fixed in the first three rows without giving up a single ounce of capability.

Exhibit — Spend the free levers first — cache, context and session length — before trading effort or model.. The top three cost nothing and fix most of the problem; only the bottom two ask for a real trade. Source: Synthesis of Anthropic's cost-reduction guidance (code.claude.com/docs/en/costs) and a sibling report on model choice. As of Sept 2026.

A few rows deserve a sentence of colour. Reading in less is the highest-frequency habit worth building: name the file, ask for the answer rather than an open-ended "explore the codebase," and let a language server or a preprocessing hook hand Claude the ten lines that matter instead of the ten-thousand-line log. Anthropic's own guidance points at exactly these moves — a `grep`-style hook that filters test output to failures, code-intelligence plugins that resolve a symbol instead of reading five candidate files, a skill that hands over the project's shape instead of making Claude rediscover it. Ending or compacting a long session is `/clear` when switching to unrelated work — it costs nothing and starts a clean, cheap context — and `/compact` when the thread is worth keeping but the dead weight is not. Either one stops a morning's context bleeding into an afternoon's unrelated question.

The bottom two rows are deliberately last. Turning effort down is genuinely free on flat-curve work like research and chat, where deep reasoning buys almost nothing, and a real trade on the steep-curve building work where it earns its cost. Dropping to a smaller model is right for well-specified, checkable jobs and wrong for ambiguous ones — the entire subject of the report on the other dial. Both are powerful, but they are the only levers here that ask the operator to give something up, so they come after the ones that do not. Even Claude Code's small idle costs — background summarisation for resumable sessions, a status check here and there — sit below all of this; they are real but typically pennies, and chasing them is a distraction from the three free rows at the top.

Bottom line

Running out early is not a verdict on a user's settings. It is what happens when context and turns compound quietly across long agentic sessions — and almost all of the fix is free. The short version worth keeping by the desk:

  • The limit is a rate, not a number — two clocks, a relative multiplier, one pool shared with chat and Cowork. There is nothing to "manage" except the habits that set the rate.
  • Context is the master dial; turns are the multiplier — cost climbs with roughly the square of the turn count, so a session that wanders or lingers is the real drain, not the model badge.
  • Caching is the quiet giant — it is saving more than any dial the user touches, and the whole job is not to break it by switching model, changing effort, editing instructions mid-flow, or leaving it cold past its lifetime.
  • Fan out sparingly — one sub-agent for a verbose job protects the main context; a team of them costs about seven times a single session.
  • Keep the instruction stack lean — a genuine top-tier lever for a heavy setup, a rounding error for a light one; either way, under 200 lines with reference content in on-demand skills, and never assumed free just because it is cached.
  • Pick the model-and-effort dial last — it matters, but it is the only lever that trades capability, so it comes after the free ones, not before.

None of this is about rationing. It is about spending the week on the work instead of on overhead nobody named — so the limit stops reading as a mystery and starts reading as what it is: a rate that can be managed by anyone who knows where the tokens go.

Sources