Deep Dive: Claude Code's Effort Levels and Caching Mechanisms

Claude Code offers a variety of effort levels and model selection options, but a fair amount of confusion surrounds these concepts. A Reddit user in the /r/ClaudeAI community shared an in-depth investigation into effort levels, prompt caching, and subagent behavior — surfacing details that official documentation doesn't always make clear. These insights are especially useful for developers looking to control costs and optimize their workflows.

The Hidden Cost of Effort Levels and Caching

One of the most easily overlooked pitfalls: changing the effort level mid-session invalidates the prompt cache. This forces the model to reprocess the entire conversation context, directly adding to your credit or API costs. For long conversations spanning tens of thousands of tokens, that's a non-trivial expense.

The author notes one exception — on the Fable 5.1 model, switching effort on a per-message basis does not break the cache. According to them, Opus is also testing similar behavior (currently in API beta), with the expectation it will eventually roll out to Claude Code. This discrepancy is a reminder that different models handle caching differently, and you should understand your specific model's behavior before switching.

Prompt Caching is an optimization mechanism in LLM APIs: when consecutive requests share the same prefix context, the server can reuse already-computed KV (key-value) caches, skipping redundant token computation and significantly reducing latency and cost. Anthropic's cache hit pricing is typically around one-tenth the standard input price. However, the cache is tied to a specific model configuration — including the effort level. Once a parameter changes, the server can no longer confirm that the current request is compatible with the cached prefix, and must recompute from scratch. In long sessions with system prompts and conversation history spanning tens of thousands of tokens, a single effort-level switch is essentially "paying again" for the entire context — which is precisely why the author urges caution.

The Truth About Ultracode and Ultrathink

There's been plenty of community chatter about "Ultracode," but the author is blunt: it's essentially a "fake" effort level. It's nothing more than xHigh plus an additional instruction — telling the model to use workflows, meaning it spawns a batch of subagents to collaborate on the task.

So if you're already at xHigh, switching to Ultracode is free. On Fable, switching to it is free regardless of your current effort level. Even more interestingly, you can simply write "Ultracode" directly in your prompt — the effect is equivalent to telling the model to "use workflows" to launch subagents, without actually changing the effort level. To avoid any confusion, the author recommends just writing "use workflows" directly.

Another misleading keyword is Ultrathink (note: THINK, not code). It's a prompt keyword asking the model to "think harder," but it also does not change the effort level. The author admits these kinds of "think more" instructions are largely ineffective today — they're a legacy feature — and suggests ignoring them entirely.

Effort Level in Claude Code is the core parameter controlling the depth of model reasoning and token consumption, typically ranging from low to high across several tiers (e.g., low, medium, high, xHigh). Higher effort means the model invests more "thinking tokens" (i.e., internal reasoning steps in extended thinking), leading to better performance on complex tasks — but also linearly increasing costs. Users often mistakenly assume that keywords like Ultracode and Ultrathink push the effort level even higher. In reality, they're natural-language behavioral instructions that don't touch the underlying effort configuration. Understanding this helps avoid pointless adjustments when you're already at xHigh.

Using Effort Levels to Combat Rabbit-Holing

Effort levels aren't just about computational investment — they also shape the model's behavioral patterns. The author points out that lower effort can help mitigate rabbit-holing — the tendency to over-verify, over-explore, get stuck in loops, and refuse to give up.

But it's a double-edged sword: too low an effort level can also cause the model to abandon a problem it should have solved. The author adds that rabbit-holing is often a prompting issue — describing your requirements precisely enough usually prevents it. This is a useful reminder for developers: before tuning effort levels, check whether your prompt is clear enough.

Subagent Cache Lifetimes

Subagent behavior is the most information-dense part of this writeup. Key takeaways include:

• Subagents inherit the effort level of the main session, which is especially important to keep in mind when using workflows.
• The main session's cache is retained for 1 hour, while subagent caches are only retained for 5 minutes.

That 5-minute window creates a real practical problem: if a subagent appears stuck and you ask the orchestrator to "wake it up," moving too slowly will trigger a full re-caching of that subagent's entire conversation, spiking costs. The author's rule of thumb: rather than waking a stalled subagent, just spin up a new one to continue the work. That said, this requires judgment — creating a new subagent has its own overhead, and if the old one has completed significant work, reconstruction may not be worth it.

For users who want to adjust this behavior, the subagentPromptCacheTtl parameter in settings.json lets you extend the cache window. But the author cautions that extending it to 1 hour isn't free — it makes the cache itself more expensive to write. Since subagents typically handle a single task and don't wait around for instructions for long, the default setting is actually quite sensible.

Subagents and Orchestrators are core concepts in multi-agent workflows. The orchestrator is responsible for decomposing tasks, scheduling, and monitoring multiple subagents running in parallel; subagents each hold their own isolated session context and focus on a single subtask. This architecture can dramatically improve parallelism, but it also introduces complexity around context isolation. Each subagent is essentially an independent chain of API calls, with its own token count and cache lifetime. Because subagents typically execute short, one-off tasks, Anthropic defaults their cache window to 5 minutes rather than the main session's 1 hour — which is sufficient for most normal execution scenarios, but prone to expiring during human-in-the-loop pauses or network waits. The subagentPromptCacheTtl parameter lets users extend this window, at the cost of higher cache write fees.

Platform Differences and Practical Advice

The author also touches on differences between the TUI (terminal interface) and the Desktop client: the TUI is more "chatty" when you attempt risky operations — like resuming a stale session or switching effort mid-session — prompting "are you sure?" confirmations. The desktop client offers no such warnings.

It's worth emphasizing that the cache durations described above apply to Claude Code usage under subscription plans. Behavior may differ for API access, prepaid credits, cloud provider integrations, and similar scenarios — buyer beware, and verify for your own setup.

Overall, the core value of this writeup lies in clarifying the real relationship between effort levels, Ultracode, and Ultrathink, and in exposing caching as a key variable that directly affects cost. For Claude Code users chasing the right balance between efficiency and expense, understanding these underlying mechanics is far more valuable than blindly toggling configuration settings.