On a subscription, the main session’s prompt cache lasts 1 hour; subagents’, teammates’ and forks’ last 5 minutes. When a subagent with a big context waits on something slow (a test suite, an e2e harness, a poll loop), its next turn writes the whole context to the cache again. Over four months, avoidable cache rebuilds were about a quarter of my usage at API prices, and subagents waiting like this were the biggest part. What I changed: Agent teams off. Teammates were 72% of my subagent usage: each kept its whole history across tasks and re-read it every turn. One task per agent , then a fresh one with a written brief. I only message an agent again if it finished under 5 minutes ago and is still small. Nobody waits inside a big context. Long commands run from the main session (which has the 1-hour cache) in the background, through a small wrapper that writes the full log to a file and prints only the exit code and the failure lines. A fresh agent gets the failures. Compaction on purpose: a 400K auto-compact backstop ( autoCompactWindow ), a status line with context size and a cache countdown, and /compact <focus> at the end of each phase. Less noise: Bash output compacted with RTK. The week after, against the week before, on about the same number of requests: avoidable rebuilds 27% → 5% of usage, usage on contexts over 400K 68% → 3%, cost per request at API prices $0.11 → $0.06. Not from cheaper models: the mix got more expensive. One week is a small sample. Generic versions of the agent files, the rules and the wrapper: https://github.com/27medkamal/claude-cache-audit/tree/main/examples To check your own transcripts: uvx claude-cache-audit (local only, no prompt text printed). Write-up: https://27medkamal.com/blog/claude-code-usage/ submitted by /u/27medkamal
Originally posted by u/27medkamal on r/ClaudeCode