# Reduce Claude Code token usage: shorten the session
> To reduce Claude Code token usage, shorten sessions. Re-reading the conversation was about 76% of my consumption, and instruction size was ruled out.
Canonical: https://brandonlazovic.dev/articles/ai-coding-spend-is-rereading/
Author: Brandon Lazovic
Published: 2026-10-05
## The short version
- Across a week of my own Claude Code sessions, re-reading the conversation on every turn was about 76% of token consumption, so session length is the lever.
- The standing instruction block (CLAUDE.md, rules, skill descriptions) was 3.2% of what my main conversations stored for later reuse, so trimming it was ruled out as the main saving.
- Anthropic's own post credits an instruction audit with an additional 9% and, in its own cost tool, ranks prompt caching first. That agrees with this measurement, since the discounted re-read is what the provider calls a cache read.
- A simulation against real growth curves puts two shorter sessions in place of one at about a 37.8% cut. The measurement is from 2026-09-18 and was not re-run for this piece.
Claude Code gets expensive because every turn re-sends the whole conversation to the model. Across a week of my own sessions, that re-reading was about 76% of all token consumption, and the standing instruction block was 3.2% of the main-thread tokens the provider stored for reuse. [2] The usual advice is to trim your instructions. Measured, the lever is how long a session runs before you start a fresh one, so a long session you never split is where the money goes.
> Re-reading the conversation was about 76% of my token consumption, and the instruction block behind the standard advice was 3.2% of the tokens stored for reuse.
## Why does a long Claude Code session cost so much?
A long session costs a lot because the model has no memory between turns. Each turn, Claude Code sends the full conversation so far, and the provider charges for that input again. A token is the unit of text a model reads or writes, roughly three quarters of a word. So turn 400 pays for turns 1 through 399 all over again, and a session's cost grows faster than its length.
Providers soften this by storing the conversation on their side, so later turns can reuse it at a lower price instead of processing it from scratch. Storing it the first time is called a cache write, and reusing it on a later turn is called a cache read.
Anthropic describes the mechanism this way: "Before Claude generates a response, it first processes your prompt into an internal working state. This step, called prefill, is the expensive part of handling input. Prompt caching saves that state (the key–value, or KV, cache): when a request starts with the same prefix, Claude reads it back instead of recomputing it." [1] It adds that "Cache reads are billed at a fraction of the full input price." [1]
A cheaper re-read is still a re-read. When the conversation is large enough, the discounted charge repeated on every turn adds up to the largest line on the bill.
## What did a week of real sessions show?
A week of my own sessions showed that cache reads, the discounted re-reads, dwarfed everything else. I counted 676 transcripts over seven days ending 2026-09-18. The logs repeat some calls, so I counted each call once, using its two ID fields, the request id and the message id.
The read and write figures below are for the main thread, the conversation I drive directly, as opposed to the sub-agents it launches. Main-thread cache reads came to 2,546.9M tokens. [2] Cache writes came to 24.6M tokens, a ratio of 103.5 to one. [2]
The 76% share is derived, so read it as about 76% and treat it as suspected. I weighted each token type by its list price. A cache read counted at 0.1 times the base input price, a cache write at 1.25 times and output at about five times. The raw token counts are confirmed. The weights are the assumption. [2]
Two numbers show why the reads pile up. The median main-thread request carried 338,298 tokens of context, and the 90th percentile carried 692,151. [2] The context is everything the model is sent on a turn, the whole conversation so far plus the standing instructions. Requests over 200k tokens were 77.6% of all requests. [2] They were also 91.8% of the context processed, so the expensive work was almost all in large contexts. [2]
Two bars, two denominators. Both come from one measurement, made 2026-09-18 over 676 transcripts and not re-run since.
## Does trimming your instruction file reduce Claude Code token usage?
Trimming your instruction file helps a little and does not touch the main cost. The standing instructions, meaning the files Claude Code loads at the start of every session (CLAUDE.md, the rules files, skill descriptions and tool instructions), had a median size of 81k tokens in my setup. They were only 3.2% of main-thread cache writes, which is why I ruled them out. [2]
Anthropic's post reaches a compatible result on a different workload. Its instruction audit removed anti-patterns such as verification rituals, emphasis boosters and stale examples, and the post says: "Running `/claude-api prompt-audit` removed the anti-patterns, decreasing costs by an additional 9%." [1]
The word "additional" refers to a saving of about 18% the same benchmark got from moving from Opus 4.8 to Opus 5.5 before the audit ran. [1] Prompt caching is a separate lever, and the post's own cost tool ranks it first. [1]
Anthropic's 9% comes from its own benchmark runs, which I did not repeat. A benchmark task says nothing about a habit like letting one session run for a thousand turns, so the two results measure different things.
## Does the Claude Code token cost contradict my finding that instruction files never shrink?
This measurement of Claude Code token cost does not contradict my earlier finding on instruction-file growth. My piece [Catastrophic remembering](/articles/instruction-files-never-shrink/) measured how instruction files grow and why nobody prunes them. That is a regression risk, since a rule whose reason is lost cannot be deleted safely, and it stays true.
This piece asks a different question, which is what a file of that size costs per token. At 3.2% of writes, the answer is small next to what a long conversation costs. [2] Both findings can hold together. A file can be worth pruning for maintenance and still not be where the bill comes from.
## What does starting a fresh session save?
Splitting one long session into two shorter ones cut about 37.8% in my simulation, and each further split saved less. I ran it against the real per-turn growth curves from the same week, with an assumed 81k-token block of standing instructions and 25k tokens to re-read a handoff note at each restart. [2] It is a simulation with two stated assumptions, so it is an estimate and not a result I observed.
The saving lands on a few sessions. Every turn re-reads everything before it, so the longest sessions pay the most, and the top 8 of 83 sessions made 69.6% of main-thread cache reads, so a small number of very long sessions carried most of the bill. [2] Splitting those few sessions is where the simulated cut comes from, and shaving the other 75 sessions would buy little.
## Does re-reading also dominate a real build session?
Yes, re-reading dominates a build session too. In the five sessions since 2026-09-01 that built video kits and drafted articles for this site, the main thread, where the re-reading happens, took between 61% and 100% of each session's weighted spend, and the sub-agents took the rest. [3]
In one of them, the main thread's per-call context grew from about 205k tokens in the first quarter of the session to about 723k in the last. [3] Sub-agents were cheap by comparison, and my reading is that their context ends with them. The reasons that makes delegation useful are in [What sub-agent delegation actually costs you](/articles/sub-agent-delegation-context-cost/), and I will not re-derive them here.
In my experience SEO work runs long, though I did not measure that. A site audit, a log-analysis pass or a pipeline build keeps one session open across many files and many rounds of checking, which lets a single conversation grow very large. Those are the sessions most worth splitting.
## What evidence would show session length is not the main cost driver?
A statement from Anthropic that conversation length is the main cost driver would change the piece, and I found none in the post as I read it on 2026-09-29. The page carries both its publication date, 2026-09-08, and an update date, 2026-09-22, so the check is worth repeating whenever it changes again. If the vendor did say that, this article would become agreement with a measurement, and the title would change with it.
Three limits stay open. This is one operator's workload over one week, with unusually long sessions. The 76% share depends on list-price weights that a provider can change. I also did not re-run the measurement for this piece, because the script from 2026-09-18 was never kept, so every figure here is dated and none is fresh. My read: the direction is likely to hold on other setups, but the sizes will differ.
## How do you shorten a Claude Code session?
To shorten a Claude Code session, end it at a task boundary and start a new one from a short written handoff. That converts the growing re-read into a one-time read of a small note, which is the 25k assumption in the simulation above.
1. Watch how large the context has grown, and treat a session that has passed several hundred thousand tokens as a candidate to split.
2. Finish the task in hand first, so the split falls between pieces of work and not in the middle of one.
3. Write a short handoff naming what is done, what is open and which files matter.
4. Start a fresh session that reads only that note and the files it names.
5. Keep sub-agent work for tasks whose intermediate output you will not need again, since that context is discarded when the agent finishes.
Do this before you rewrite your instruction file. Measure your own week first, using a deduplicated count of requests, because the shape of a bill differs from one setup to the next.
## Sources
1. Anthropic: Reducing cost and improving performance with Claude Platform (published 2026-09-08, updated 2026-09-22) — https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform
2. First-hand: 676 Claude Code transcripts over seven days to 2026-09-18, deduplicated on request id plus message id. Measured that date and not re-run.
3. First-hand: token totals for five kit-building sessions since 2026-09-01, measured 2026-09-22 with the same deduplication