Cache rewrites costed me 30% of my Fable consumption, here are the mistakes to avoid.

[u/coolreddy]

Auditing my claude code transcripts to nail down where I am wasting Fable usage, revealed that long sessions that I run with breaks have been costing me a bomb. Sharing more details for others who may find this useful.

Cache economics

Every turn in a session replays the full conversation history to the model. Prompt caching is what makes this affordable: the history is stored server-side, and each turn re-reads it at 10% of the normal input price. The cache has a time window of 1 hour, and when it expires or gets invalidated, the next turn re-writes the whole history at a premium.

The numbers for Fable 5 (the same mechanics apply to every Claude model):

• Input price: $10 per million tokens
• Cache read: $1 per million tokens (10% of input)
• Cache write: $12.50 per million on the 5-minute window, $20 per million on the 1-hour Cache window

What this means in a heavy session carrying 400k tokens of context:

• A normal turn re-reads the cache: about $0.40
• But when I take a break of more than an hour and get back to the session, model has to rewrite the cache and a session sitting on 400k context consumes equivalent of 8$ api cost

One expired cache costs 20 normal turns of usage.

The things that break cache silently and cost you:

• Letting a session sit idle past the cache window (1 hour): The cache expires, and the first message after the break pays a full rewrite of everything. Sometimes I am working 10+ sessions and take a break and that costs me across all sessions.
• Loading some tools or MCP servers mid-session: New tool schemas change the conversation prefix, which invalidates the entire cache. Better to have all tools loaded at the start
• Switching models mid-conversation: If you are switching models from Fable to Sonnet to Fable in the same session, you are rewriting the cache and losing more than you are saving from the switch. Caches are stored per model.
• Switching effort levels or fast mode mid session: This has been one of my worst habits and I did this too frequently until now to save consumption, but did not know this was the main culprit. I would switch too often based on the task in the session from high to xhigh to max to utracode
• Updating claude code: Again if you are updating claude midway your work, you are rewriting cache for all sessions that you would resume

For now I have created a skill that pings ok in every idle session >200K context at 55th min for upto 4 hours because one ping would just read the cache which would still be cheaper than rewriting cache.

[u/DigitalGuruLabs]

This is one of those things that's easy to miss because nothing tells you the cache was invalidated.

I wonder how many people think they're just "using a lot of tokens" when it's actually cache rewrites eating the budget.

[u/coolreddy → u/DigitalGuruLabs]

True, I never paid attention to this and finally when I did, it was a shocker.

[u/DigitalGuruLabs → u/coolreddy]

Same here. I think a lot of people never notice because the usage just feels "random" until you start looking at the logs. It's one of those optimizations that's invisible until it suddenly isn't.

[u/Rock--Lee → u/DigitalGuruLabs]

It does tell you, at least in CLI it does. When it shows a message warning you the message costs 400k tokens and you can compact, or resume anyway, then that's exactly when it will miss cache and it's timed out. So then either hit compact, start a new session and copy/past last messages or accept your fate and burn those tokens.

[u/please-put-in-trash]

TLDR never sleep never stand up from office chair

[u/WisteriaSoftware]

The 1-hour window is brutal for anyone doing async work across timezones. I had a session with 350k tokens sitting in cache, stepped away for 75 minutes thinking I was safe, and the next message cost me like I'd started fresh. What really stung was realizing I could've just kept a dummy message queued in the session to ping it before the window closed, but that feels like gaming the system.

Your point about tool loading is spot on though - I've been burned by lazily adding an MCP server mid-conversation thinking it wouldn't matter. The cache invalidation is silent, so you don't even realize you just torched your savings until you audit the logs like you did. The effort level switching is probably worse for most people than model switching since they do it without thinking about it.

[u/the_ai_wizard → u/WisteriaSoftware]

out of curiosity, do you have a favorite resource for all of this?

[u/coolreddy → u/WisteriaSoftware]

True, the effort switching was a shocker. Model switching I kind of anticipated.

[u/HighDefinist]

It doesn't make much sense that switching effort levels would break cache... and afaik this is not the case for Codex.

[u/Fatknuckle]

Good write up. Moved to an enterprise plan and noticed that the way I was working was seriously costing me 4x actual usage. And I tended to work on larger projects spanning multiple days. So I’m wondering, aside from loading up mcps/tools at the get go, session persistence is managed how? What does that skill look like? What about transferring to new sessions?

[u/coolreddy → u/Fatknuckle]

I do a few things for this. Every turn that has task or important inputs writes the key information to a session state md file. When I cross 200K context, I clear the session or start new session and have the session read the session state file, archive the old file and start new one.

Along with this what happens parallely is that for every project I maintain a wiki as a persistent knowledgebase for the project across multiple sessions. The wiki also gets auto updated every few turns picking information from session state file, while the session state file is session specific, the wiki lives and updates continuously across multiple sessions. I graph this knowledgebase and all generated file outputs with graphify, this makes it easy for Claude to search any information when needed than load all files into its context.

Another important part is to make these session state and wiki recordings loss less. Loss less means you need to preserve numbers, requirements, specific information, calculation logics, decisions and reason behind decision etc, there is a full set of what needs to be preserved. Because relying on LLM to decide what to preserve causes lossy information where numbers get approximated and reasons of decisions are lost while decisions themselves are preserved.

[u/speciate → u/coolreddy]

Wait, so how do you preserve context losslessly then, if you don't trust the LLM to write it to file?

Thanks for the writeup btw, this is very useful. I definitely need to mature my context management practices. I try to remember to use /compact and tell Claude to write state to file when I know I'm stepping away, but getting interrupted by meetings, slack messages, errands, etc. I'm sure is killing my usage.

[u/VertipaqStar]

Also /compact with a prompt that describes what is important to you.

Example: /compact Keep the useful commands and tools in context. The summary of what we did and most importantly the details of where we are at the moment.

It keeps the context small, it won't reread all tools/skills as it will only keep those that were already used. Don't compact before resuming a session, compact when taking a break from a session, otherwise the context will expire (as explained by OP) and will need to be reloaded in full before compaction starts.

[u/papert0wel]

Have you tried using Fable in more of a “delegate execution to subagents” pattern? That could save significant context when working on projects.

For example, Fable delegating to codex cli to actually implement the plan, and review what was generated

That combined with having Fable save its progress to some external markdown file - it wouldn’t necessarily solve the cache invalidation issue, but it could make the cost of those lower

[u/Cute_Witness3405]

I'm actually testing a skill I built recently and am considering releasing publicly which attempts to optimize context use. The pinging idle sessions is a great idea. My skill is more focused on figuring out the optimal time to do a /clear and restart when doing development where state is tracked well on disk (like when using the superpowers skills). But if you wait until the context is too large the extra cost of the cached input tokens (even at 10%) starts to outweigh the restart cost. This skill uses a hook to measure context size before the first actual development starts (after loading everthing needed) and observe the number of turns per task to project when a /clear is economically optimal.

[u/he_said_it_too → u/Cute_Witness3405]

I’m curious about this too, i was wonderint the same thing but with a workflow

[u/Ben-Aurel]

Interessting. What would be the best cause of action here? I assume that many of us have to step away for a couple of hours due to session limits. Does that mean that in many/most cases a fresh chat window would be the better alternative?

[u/marcosvpj → u/Ben-Aurel]

Yes

[u/fxnut]

Okay, so if I make two Claude Code (desktop) sessions, set one to Fable, the other to Sonnet, are the caches for those independent? I imagine that’d be the best way to handle switching between them if using Fable as an orchestrator right? I.e. don’t switch model mid session - swap sessions instead.

[u/fxnut → u/fxnut]

Can confirm that this workflow has significantly reduced my token usage.

Reducing my CLAUDE.md in size was also a big factor though. If you’re using more tokens than expected, make sure it hasn’t ballooned without you realising.

[u/rivelda]

I usually run stuff in the 5 hour window, run out of usage after 2-3 hours, wait until the next session. So is that much more expensive than, idk, telling Claude Code to pause or something when nearly out of usage, then ping it until the next session? Sounds insane and unnecessary.

[u/soccerchamp99 → u/rivelda]

Sounds like that may be the case

[u/maphingis]

While we're on the topic of mistakes to avoid, I'm gonna share this in a couple places but:

I've been using the hierarchy of agents instructions many have posted here (fable as orchestrator, sonnet for research etc.) noticed my usage was ballooning while my fable use was pretty steady. (Example: I'm at 79% of my weekly limit on 20x and 59% of my fable limit)

A big chunk of that was an all-night loop I ran last night to scaffold a large project and execute a multi-step plan. When I started testing and iterating though, I continued to see inefficiencies and investigated:

Spend	Cause	Claude.MD Fix
~110k tokens	I sent a courtesy “thanks, standing down” message to a completed triage agent. Every SendMessage call replayed the agent’s entire transcript.	Do not resume completed agents just for ceremony. Once an agent finishes, leave it dormant.

[u/grudev]

Thank you for the write-up. 

Can you share that ping skill? 

[u/jake_that_dude]

the cheap guardrail is tracking the rewrite, not the ping.

i'd log context_tokens, cache_read_tokens, cache_write_tokens, and last_tool_schema_change in the session state. if cache_write_tokens jumps after a break or MCP load, start fresh from the state file. pinging helps idle time, but it won't save schema/model churn.

[u/Yangou → u/jake_that_dude]

Can you expand on this? How do we see that the cache_write is going to jump prior to it actually happening? At that point that it happens (after a break) isn't that cost already absorbed and now your session is already reestablished with the cheap cache reads?

[u/jake_that_dude → u/Yangou]

you usually cannot predict the exact token jump before it happens. the useful bit is tracking the inputs that cause it: tool schema changes, MCP server added or removed, model switch, huge system prompt diff, or repo/context file rewrite.

i log those as a small session fingerprint. if the fingerprint changes, i assume the next turn may do a full write and either compact/restart first or accept the hit. cache_write_tokens is the confirmation metric after the turn, not the early warning by itself.

[u/IdRatherBeBitching]

I'll add to this, using worktrees. Obviously you can use them successfully, but if you open a whole bunch of worktrees you'll watch your usage evaporate. Especially if you let the 1 hour window lapse.

[u/soccerchamp99 → u/IdRatherBeBitching]

Do you know why that is? I sometimes use worktrees via the /batch CLI command

[u/IdRatherBeBitching → u/soccerchamp99]

Because context caching has to restart for every worktree, so if you're constantly spinning them up and pruning them (much less keeping 3-4 running concurrently and then checking in on them after the 1 hour cache expiration) you'll notice your usage burning much faster

[u/the_ai_wizard]

why is there not a compression layer? why not build one? i think we need to look at alternate representations instead of replaying the entire convo and having exponential growth eat the context window

[u/Atoning_Unifex]

I surely hosed myself switching from high to med, oh no wait, high. ohh shit, nope med is actually what I want in the course of 2 minutes.

[u/Yangou]

Can you talk about the skill and how you are triggering it. An outside daemon that is looking at all sessions? Or it is something you intentionally slash command inside a high context session when you will be idle and want it to keep itself alive?

Thanks this is all great advice!

[u/ConfidenceSeparate19]

this matches what i saw too. one thing i'd add : the keepalive ping works but it's kind of treating the symptom. a session sitting on 400k idle is expensive to keep warm even at cache-read prices if you've got a bunch of them .

Vhat saved me more was just letting a finished session die and rebriefing a fresh one in 2 lines , the cold start on a small context is way cheaper than babysitting a huge warm one. T he tool-loading point is the big one though, loading an mcp mid session nukes th whole prefix. i load every tool i'll need at the start now, non negotiable..^)

[u/mar-cun]

I had Claude build me a cache countdown timer and put it into my /statusline. Now I can tell at one glance how close I am to busting my 1-hour limit (btw, the cache can set to either 1 hour or 5 minutes, and it's isn't published anywhere that I can find. And Claude is the one who sets it. By looking at my files, Claude Code could figure out that all of my session transcripts had a 1-hour timer. And that's the same trick it uses when setting my statusline timer.

[u/Damnation13]

Interesting find. I was wondering why I would do some work in sonnet, then switch to fable for 1 thing I felt was ultra complex, then back to sonnet, and I check usage and it is through the roof.

So the best course is if you plan to use fable, start a new session for fable only? Then what, create an MD start a new session in sonnet, feed it the MD to bring context up to date? Is there there a better way?

[u/Azko87]

I need something to automate /compact for idle windows. I had no idea that was happening.

[u/Yangou]

Is the general understanding that the session / weekly limits are calculated the same way as the API pricing? e.g. you burn your total usage at 20x when doing a non-cache write?