[KongchangAI]
· 2 min read· 1,069 words

Splitting Sessions Cuts Costs by Nearly 40%: The Real Lever for Saving Money with Claude Code

Splitting Sessions Cuts Costs by Nearly 40%: The Real Lever for Saving Money with Claude Code

Real data shows 76% of Claude Code bills come from re-reading conversation history — split sessions, not prompts.

A creator analyzed 676 Claude Code conversations over one week and found roughly 76% of costs come from cache reads — the entire conversation history being resent to the model on every turn, with a median request carrying around 338K tokens. By contrast, Anthropic's recommended instruction file optimization (e.g., trimming CLAUDE.md) accounted for just 3.2% of cache writes in his data. A simulation splitting one long session into two with a brief handoff reduced costs by ~37.8%. The key insight: session length, not instruction length, is the primary cost driver.

The Biggest Hidden Cost: Re-Reading Entire Conversations

If you pay for AI coding tools, the official money-saving advice usually points to a relatively small lever — optimizing your instruction files. But one YouTuber ran the numbers on his own real Claude Code usage data and arrived at a counterintuitive conclusion: what's actually eating your budget is the entire conversation history being resent to the model on every single turn.

Over one week, he collected 676 of his own Claude Code conversation records (measured on September 18th, not re-run since) and used them as a sample for analysis. The conclusion is blunt: re-reading conversation history accounts for roughly three-quarters of his AI coding spend, while trimming instruction files saves almost nothing.

Measurement data from 676 Claude Code conversations over one week

Breaking Down the Data: 76% of Spend Comes from Cache Reads

Let's clarify a few terms first. A token is a unit of text — roughly three-quarters of a word as the model reads it. A cache read means the provider reuses previously stored conversation data at a lower price, rather than processing it from scratch.

In his main thread (the actual conversation window where he types):

  • 2,546.9 million tokens were read from cache
  • Only 24.6 million tokens were written
  • A ratio of roughly 103:1

Weighted by list price — the author notes this weighting is his own derivation — the read portion accounts for approximately 76% of total spend. Even more striking is the median request: the median main thread request carried 338,298 tokens. This essentially means that in a typical conversation turn, the entire history gets re-read, no matter how long it's grown.

Weighting by list price is the author's own derivation

Imagine this scenario: you type a single short question at the end of a very long session, and the model still receives the entire conversation a second time — regardless of how long it's become. That's where the cost comes from.

The pricing logic behind caching is worth a brief explanation. With Anthropic's Claude API, for example, prompt cache read prices are typically about one-tenth of standard input token prices (the exact multiplier varies by model version). This means that even though cache reads involve far more tokens than standard inputs, the per-unit discount does reduce the absolute cost — which is exactly what caching is designed to do. However, the author's data reveals a scale effect: when cache read token volume is 103 times that of writes, even at one-tenth the price, it still accounts for 76% of the total bill. In other words, the discount doesn't eliminate the problem — it just pushes the tipping point further out. Once a session runs long enough, the absolute cost of cache reads still dominates the bill.

Instruction Optimization: A Real but Small Lever

Anthropic's official cost-reduction article recommends running a prompt audit command on your instruction files — the files that tell the model how to behave before you type anything (like CLAUDE.md). Their stated figure: removing redundant patterns reduces costs by an additional 9%.

But in the author's own data, this lever is much smaller. His standing prefix (fixed preamble including CLAUDE.md rules, skill descriptions, and connected tool instructions) had a median size of 81,000 tokens, accounting for just 3.2% of main thread cache writes.

Standing prefix median 81K tokens, only 3.2% of cache writes

The author is careful to flag a potential confusion between two different denominators: 3.2% is the share of cache writes, while 76% is the share of total spend — these can't simply be subtracted from each other. As a result, refactoring those instruction files saves almost no money.

This doesn't mean Anthropic's 9% figure is wrong — it reflects a different workload. The author's sessions run unusually long, and that's the source of the divergence: for short sessions, a prompt audit is effective; but for long sessions, it gets completely overshadowed by the cost of session length itself.

The Real Money-Saving Move: Split Sessions Earlier

The author ran a simulation: he took one long session, split it into two, replayed it using his actual growth curve, and added a short handoff re-read at the start of each new session. The result — costs dropped by approximately 37.8%.

Simulation of splitting one long session into two

The logic is simple: every turn re-reads everything that came before, which means the longer a session runs, the more expensive each new message becomes. Costs accumulate with session length, not instruction length.

His core conclusion: session length drives cost, so end sessions earlier. Prompt auditing is a real lever, but in his week of data, it was a small one.

This cost structure is mathematically equivalent to a trapezoid area problem: the cost of each conversation turn equals the current cumulative token count, and the total cost of a session is the sum of all turns — growing quadratically with the number of turns. By contrast, splitting a session and adding a brief handoff is like cutting one large trapezoid into two smaller ones; their combined area is significantly less than the original, even accounting for the small overhead of the handoff itself. The simulated 37.8% reduction is a direct expression of this geometric relationship: the earlier the split and the more evenly the session is divided, the greater the savings. This also explains why "start a new session as soon as a task is done" is a higher-leverage move than any prompt optimization — it directly changes the shape of the cost function, not just adjusts a coefficient.

Actionable Takeaways

The author lays out a two-step path forward:

  1. Start by measuring your own week of usage. Don't just copy someone else's numbers — your workload determines which lever matters most. Users like the author with unusually long sessions will see significant gains from splitting; users with shorter sessions may benefit more from instruction optimization.
  2. Once a task is done, start a new session with a short summary note. A one-time brief handoff replaces an endlessly growing history re-read, and it's the most direct way to flatten the cost curve.

The value of this analysis isn't in any specific number — it's in how real data challenges the default advice, and reminds every paying user: the biggest lever for saving money might be hiding in the session length you've never thought to question.

#Claude Code#AI coding cost optimization#Claude API token cost#cache read tokens#session length cost#Claude Code savings#prompt cache#AI development costs
Share:

Related articles