Skip to content

devlog/token-math/a-two-hour-claude-code-session-that-cut-cache-costs-1093.md

A Two-Hour Claude Code Session That Cut Cache Costs

The cache dies the moment your system prompt drifts

Long coding sessions are where prompt caching earns its keep, and they are also where it silently stops working. A provider can reuse a cached prefix only when the first tokens of the request are byte-identical to what it stored before. Change one character near the top and the prefix is recomputed from scratch, at full price.

The most common mistake is a system prompt that generates itself. A timestamp in the instructions, a shuffled tool list, a locale line, or a branch name embedded early all invalidate the cache on every single turn. In practice this turns a cheap two-hour session into dozens of full-price writes, and nothing in your editor warns you.

Keep the first section of every request frozen. Put the date, the branch, the dirty file list, and anything else that moves into the tail of the prompt, where it does not matter that it changes.

  • Freeze the system prompt and tool definitions for the entire session.
  • Move timestamps, branch names, and random seeds to the end of the request.
  • Treat any change above the first cache breakpoint as a full cache miss.

Volatile project files parked at the top of the context

Editor agents love to preload context: project instructions, conventions, dependency manifests, maybe a summary of recent changes. The mistake is ordering those blocks by importance instead of by stability. When the most-changed file sits first, every edit to it throws away the cached copy of everything behind it, so you pay the write tax again.

Sort your context blocks from most stable to least stable. Documentation that never moves goes at the front, the current task state goes last, and anything that changes more than twice an hour does not belong anywhere near the front of the request.

This matters doubly for generated content. A regenerated type map or a fresh build summary can be thousands of tokens that you re-write into cache after every build, which is the most expensive possible way to keep a session current.

  • Order context blocks by how often they change rather than by importance.
  • Keep generated summaries and build output near the end of the request.
  • Split long context into a stable prefix and a small changing suffix.

Replaying the whole transcript after every tool result

The second big leak is history. Each time your agent calls a tool, it usually resends the full conversation plus the tool result. If the transcript already contains a dozen large diffs and test runs, that is thousands of tokens copied on every turn, and the assistant output you already paid for gets sent again as well.

Trim aggressively. Summarize older turns into a short block once they stop being useful, truncate tool output to what the model actually needs, and prefer several small tool calls over one giant dump. Smaller suffixes mean more turns fit under a single cached prefix.

If your client supports explicit cache breakpoints, place one right after the stable prefix and another every few turns, so each new turn extends the cache instead of rebuilding it from zero.

  • Summarize old turns instead of replaying the full transcript on every call.
  • Truncate tool output to the lines the model actually needs.
  • Place cache breakpoints at regular turn boundaries so each turn extends the cache.

Switching models mid-session and paying the write tax twice

Caches live per model and per provider. When you hop from one model to another halfway through a session, the new model knows nothing about the prefix you just paid to write, so it writes it again. Do that three times in a long session and you have funded three copies of exactly the same context.

Pick one model per task and stay there. If a fast pass is enough, run the whole session on a cheaper model rather than mixing; keep Claude Sonnet 5.5 for the long reasoning stretch, and only open a separate short session on DeepSeek V4 Pro when you genuinely want a second opinion.

This is also where a relay earns its place in the setup. Fluxo gives you one key and one base URL, https://api.fluxorelay.com, for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more, and bills per real token including cache reads and writes with no monthly fee. It works with Claude Code, Codex, Gemini CLI and any OpenAI SDK, so changing providers is a configuration line rather than a rewrite, and you can see exactly what each cache read costs.

  • Keep one model per session so every turn extends the same cache.
  • Avoid provider hopping during a task because each provider stores its own prefix.
  • Watch the cache read and write counts in your usage numbers before optimizing anything.

Cache writes that get read exactly once

Caching is not free. A cache write usually costs more than a plain input token, and it only pays off when the prefix is read again. The mistake is enabling caching on one-shot scripts, short prompts, and CI jobs that never repeat, then wondering why the bill did not move.

Only cache a prefix that will be reused at least twice more inside the same session. Skip caching entirely for one-line questions that will never see a second turn, and put every stable block behind a breakpoint when you are settling in for a long run with many tool calls.

Measure before and after. Compare cache reads against cache writes for a typical session and aim for reads to dominate. If writes are the majority, your prefix is drifting, your history is too fat, or your sessions are simply too short to reuse anything.

None of this needs exotic tooling; it is mostly prompt ordering, history hygiene, and a steady model choice. If you want to see the real numbers on your own sessions, create a Fluxo account and point your existing client at https://api.fluxorelay.com. Referrals earn a share when the people you invite pay, and if anything looks odd in your usage, leave a note on the contact page after signing in.

Next in the buffer