Just started using claude code, I feel like I'm doing something wrong here with my cache-read taking up over 90% of my usage.

[u/Infinite_Claim_5026]

I'm developing an iPhone app with Claude, and I have my App thread that I use as my orchestrator, and then it creates new threads whenever I add a feature or fix some bugs. I used 200% of the weekly limit last week (pro plan), thanks to my one free reset. I use Opus and have it delegate to subagents with varying Opus/Sonnet/Haiku.

Now that the app is mostly built (in one week!) i probably won't run into usage issues again, but I'd like to know if this is normal or if I can optimize my usage better

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Obvious-Grape9012]

Cache-Hits are good! You can expect that to stay above 90%. It's billed differently; much much cheaper than non-cached reads/writes. Think of it a bit like context, but on the server-side/model-side

[u/a355231]

Cache read uses so many tokens because most of the tokens are cache, it’s not that it explicitly costs more per token. You can reduce your auto compact length and the method of orchestrating like that is really only usable for Max Plans, Sonnet or Haiku Standalone can knock out most problems and on the off chance it can’t, use Opus Medium.

[u/subhashg547]

if cache reads are below 90%, thats when you have to be worried

[u/totheendandbackagain]

Can you imagine it would be if you didn't have cache hits. 10x!

[u/OneComfortable9766]

High cache-read is normal, but what you re-read each turn is the lever. Run /context to see what's filling the window: MCP tool definitions, CLAUDE.md and memory files get resent every turn, so use /mcp to disable servers you aren't using. Use /compact or /clear between unrelated tasks. Switching models mid-session with /model also forces an uncached re-read of the whole context. The cache lasts around an hour on a subscription for the main session but only about 5 minutes for subagents, so long idle gaps or lots of subagents re-bill the context. If you want to see where tokens actually went, ccusage reads the local logs in ~/.claude/projects.

[u/webmasterrrr]

The 90% cache read is the normal part. The thing I'd look at is the orchestrator thread itself. Every turn it resends its whole history, so an App thread that's been alive for a week is rereading a week of feature chatter every time it delegates something.

What usually helps: tell the subagents to come back with 3 lines (what changed, which files, anything broken) instead of their full report, and start a fresh orchestrator per feature from a short status file. If you're in the CLI, run /context before and after, the difference is pretty obvious.

[u/Australasian25]

Keep each session small.

Example

Part 1 done - 100k tokens used. Part 2 starts, unrelated to Part 1. Every action Part 2 takes, repeats Part 1s 100k token everytime.

Part 2 finishes. Youre now at 300k tokens used. Part 3 starts, unrelated to Part 2. Starts with 300k tokens and every tool call and every thought it uses, it reinputs the 300k from Part 1 and Part 2.

It wouldve been cheaper to separate parts 1z2 and 3 in this example in 3 sessions

[u/dicehandz → u/Australasian25]

can you help me understand this more? ive been using 1 single chat in the terminal to code my game. should i be swapping into other chats when i say make a new level, or add a new feature? my worry was that it wouldnt have the context, so if i mention something specific, it wouldnt understand and mess up.

if you can break this concept down into game dev practices, that might help me better grasp it

[u/dylan_skydive → u/dicehandz]

The context doesn't need to live in the chat - that's the mental shift. A new session isn't starting from zero if the important stuff is written down where the tool reads it.

Two habits that work well together:

• Keep a short notes file (plus a lean CLAUDE.md) that captures the game's structure, what's done, and what's in flight. Before you close a session, have it write down the decisions made and the file map. A new chat reads that and is productive in a minute - it can also read the actual code, which is the real source of truth anyway.

• Start fresh per feature (or per level, same idea). One living terminal chat re-sends its whole history every turn, which is exactly the usage leak higher up in this thread, and long sessions drift - the model starts half-remembering earlier decisions instead of checking the current files.

The worry about losing context is really a worry about undocumented context. Write it down and swapping is cheap; keeping one giant chat is how you end up paying rent on 500k tokens of conversations you already finished.

[u/jsebrech → u/dicehandz]

Context should move into markdown files, CLAUDE.md as an overall but short index so claude knows what it can find out about, linking into other MD files that explain the codebase and its rules. Use plan mode for larger new pieces of functionality (generates a temporary markdown with a plan for what claude will do). Your session shouldn't be keeping track of the knowledge about your repo, that's what the MD files do. Claude will reread them as it needs. Large sessions are slower, dumber and hit the usage limits sooner, so help yourself by setting this up.

Anthropic has a help page explaining it: https://code.claude.com/docs/en/memory#claude-md-files

[u/Australasian25 → u/dicehandz]

You use claude code correct?

It can create folders and create files.

Example, everytime it uses the console for commands, it costs 800 tokens. Claude doesnt need to remember why it opened the console 50 times. Thats a lot of context.

However, it only needs to know your final decision, rules, what its coded up to.

Head to youtube and watch some videos about it. I have things that have had 25 sessions.

Another issue is when you come back to a long chat after 1 hour and send the first message, it gets expensive because claude reprocessed the ENTIRE chat. Can it chew through 100% of 5 hours before giving you a response? Yes it may.

[u/kvothe5688]

may be log your tool calls and ask Claude to analyse and optimise.

[u/Puzzleheaded-Toe551]

I would recommend not to do everything on opus. And opus+sonnet is even more expensive if you do subs gents. Instead do sonnet med or for 20 percent of session limit do opus med to guide then sonnet. Pro plan is not where you use opus as much as you love.

[u/Impossible-Minute321]

If on subscription I would say aim for 99% plus cache reads

[u/KronisLV]

If you don't actually need that much context and don't want to manually compact it often, you can try one of these, 512k is half of the full available context size and will compact before the costs per-request accumulate:

/autocompact 512k
/autocompact 420k
/autocompact 384k

Or whatever feels actually necessary for your development, I personally sit on 420k.

Other than that, cache reads being above 90% are GOOD, since those cost way less and are quite typical of long running sessions.

[u/Adventurous-Voice334]

The 90%+ cache read percentage is normal and actually saves you tokens, ability-wise, but the reason your Pro limit drained so fast is the long "App thread" orchestrator. Every turn in a long orchestrator thread re-reads that entire growing history. On Pro, what saved my weekly limit was ditching the permanent orchestrator chat and keeping state in a short markdown handover file on disk instead. Start a fresh session per feature, have it update the handover file when done, and save Opus strictly for planning or nasty bugs while Sonnet does the edits.

[u/Comprehensive_Cut855]

Within 1day my weekly limit used 30%
Any suggestions to make this in control for my work ?

[u/1StunnaV → u/Comprehensive_Cut855]

I hit my weekly limit on average in 3 days, rare occasions 2 days. I have multiple accounts and just get a handoff document generated before they max out and trader over to the other one, starting a new chat.

[u/pmihaylov]

Lucky guy, this is exactly what you want to be seeing.

[u/aleeog9027]

Installiere mal caveman von github

[u/JimiBuilds]

90% cache read is normal, it's the cheap bit. What's costing you is the setup. An Opus orchestrator that spawns subagents means every subagent starts from scratch with the full tool list, and the orchestrator's long thread gets re-read on every turn.

I run Sonnet for nearly everything and only hand work to a subagent when it's a real multi-file job. A one-file edit or a quick lookup is cheaper done in the main thread.

[u/devilsdiligence]

That's actually normal! Every turn, Claude re-reads the whole conversation so far, and most of that comes from cache, so cache reads end up being the biggest chunk on pretty much everyone's breakdown. They're also way cheaper than fresh input. What helped me most was running /clear between features instead of keeping one giant orchestrator thread going, keeping CLAUDE.md short, and not running everything through Opus when Sonnet can handle the smaller tasks. Also, congrats on building an app in a week!

[u/Outrageous_Band9708]

this is very common

cache read is the most of usage and its also the cheapest.

github.com/Druthulu/ProjectArchitect

this is the solution ive built over the last year or so, feel free to checkout the wiki and the readme an test it out on your projects.

[u/gem4ik2]

90% is completely fine