A lot of the current limit discussions here are probably caused by several things at once, including the weekly-promotion change. But one specific workflow shape silently burns a 5-hour window, it’s documented, and there’s a one-line fix: sub-agents running blocking commands longer than their default 5-minute prompt cache. TL;DR: sub-agents default to a 5-minute prompt cache while the main session gets 1 hour. If a sub-agent blocks in a command longer than five minutes, its next request can re-write most of its accumulated context instead of reading it from cache. Set “subagentPromptCacheTtl”: “1h” in ~/.claude/settings.json if your agents regularly run long commands; in my comparable test-heavy workflow, it cut cache writes by about 75%. The mechanism. Claude Code caches a conversation on Anthropic’s side so it doesn’t re-send the whole thing every request. Your main session’s cache lives an hour on a subscription; every sub-agent’s lives five minutes. A sub-agent’s context is everything it has read and done, easily 300K to 600K tokens on a real task. If it sits inside a tool call longer than five minutes (a test sweep, a build, a git hook, a long-polling call), the cache is gone when the call returns and the next request writes the entire context again. Six long test runs, six full re-writes, window gone. Cache reads barely move the window, writes are what counts. In my MAX 5x measurements, the weekly meter moved at roughly a tenth of the 5-hour rate for the same activity, so burning a full 5-hour window was roughly a tenth of my week as well. The fix. json { “subagentPromptCacheTtl”: “1h” } in ~/.claude/settings.json , or CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL=1h . Needs v2.1.242 or later. One hour is the longest the API offers; there are exactly two lifetimes, so there is no 15-minute option. One trap: that setting outranks a per-agent experimental: cacheTtl: 5m frontmatter pin. If you want a few read-only agents at five minutes, leave it unset and put ENABLE_PROMPT_CACHING_1H=1 in the env block instead, which sits below the pin. The trade-off. The API price list says a 1-hour write costs 2x normal input against 1.25x for a 5-minute one. The subscription meter doesn’t charge that: measured against the 5-hour and weekly windows, a 5-minute write costs about 0.9 of a 1-hour one, and cache reads count almost nothing. That does not mean 1h is always the cheaper choice. A short agent that never sits idle past five minutes may gain little and just pay the modestly higher write cost. But if an agent builds meaningful context and regularly blocks longer than five minutes, preventing repeated large cache rewrites is usually the important part. Before and after. Test-heavy multi-agent workflow on MAX 5x: one orchestrator session, a few sub-agents in their own git worktrees running test sweeps of 30 seconds to 40 minutes. Before: one sub-agent re-wrote its ~590K context eight times in a day, 5.4M tokens of cache writes on its own; 26 full re-writes and 12.2M tokens of writes across five agents; the 5-hour window went from 2% to 100% on four of them. After: five comparable sub-agents ran about 530 turns for 3.0M tokens of writes, only the first write of each was large, and the window went 0% to 22% on four agents. About 75% fewer cache writes for the same kind of work. How to check yours. Sub-agent transcripts: ~/.claude/projects/<project>/<session id>/subagents/agent-<id>.jsonl . If usage.cache_creation_input_tokens on assistant lines repeats the same huge number after long tool calls, that’s the re-write; cache_creation.ephemeral_5m_input_tokens versus ephemeral_1h_input_tokens shows which lifetime each write went to. The second half, which the setting doesn’t cover. Even an hour runs out under a long sweep. Don’t let a sub-agent block inside a call for more than a few minutes: run the long thing in the background with output to a file and have the agent check it every few minutes, or wake it once at about the run’s usual length. Each check is a cheap read that keeps the cache warm. One thing the lifetime doesn’t fix. The first message you send a background sub-agent after it has finished re-writes almost its whole context even inside the hour (243K and 399K tokens in my two measured cases, 49 and 54 minutes idle); the API labels the miss messages_changed , so it’s the harness rebuilding the request, not expiry. There’s an upstream issue with the repro, the link is in the first comment. If you can confirm it, add your Claude Code version, model, and relevant findings there so the evidence stays in one place. Docs, the measurements and the linked posts are in the first comment. submitted by /u/Schadz
Originally posted by u/Schadz on r/ClaudeCode