[BUG] /effort change confirmation dialog warns about cache miss, but cache is preserved

Status Open

Maintainer reply None cached

Activity 3 comments · opened May 30, 2026

Bug description

When changing effort level mid-session via /effort, Claude Code shows a confirmation dialog:

"This conversation is cached for the current effort level. Switching to xhigh means the full history gets re-read on your next message." Subtitle: "Your next response will be slower and use more tokens"

This warning is incorrect. Empirical testing shows the prompt cache is fully preserved across effort level changes.

Reproduction

Three sequential claude --print calls with identical system/messages, varying only --effort:

Request 1 — effort high:
  cache_creation: 84,300    cache_read: 0

Request 2 — effort high (control):
  cache_creation: 61,695    cache_read: 22,653   ← partial hit (expected)

Request 3 — effort xhigh (CHANGED):
  cache_creation: 0         cache_read: 84,348   ← FULL cache hit

Request 3 shows cache_read: 84,348 and cache_creation: 0 — the entire messages prefix was served from cache despite the effort level change.

This is consistent with the Anthropic prompt caching docs, which state that the effort parameter (sent via the effort-2025-11-24 beta header) is a server-side output control, analogous to max_tokens or temperature, and should not affect the input cache key.

Impact

Users avoid switching effort mid-session because the dialog warns of cost/latency penalties that don't exist
This defeats the intended workflow of dynamically adjusting effort per-task (e.g., high for simple questions, xhigh for complex reasoning)
The same F8_ confirmation component is shared between /model and /effort — the warning is correct for model switches but incorrect for effort changes

Expected behavior

/effort changes should apply immediately without a cache-miss confirmation dialog, since the prompt cache is preserved.

Source code reference

The confirmation is triggered by fM_() in the binary, which checks PVH(model) (supports prompt caching) and shows F8_ dialog with identical text for both model and effort changes. The fix would be to skip fM_() when kind === "effort".

Environment

Claude Code: v2.1.143+
Model: claude-sonnet-4-6 (tested), applies to all models
OS: macOS 15.4

View original on GitHub ↗

3 Comments

arivero · 2 months ago

Good to know it is a bug, I saw it first time today in Fable and I thought terrible things.

uguremrah · 1 month ago

Still present in v2.1.200 (Windows native build, 2026-07-03). Strings in the shipped binary point at the root cause: the effort-change confirmation reuses the model-switch dialog component, including its cache warning —

"Switch model?" / "Change effort level?"   <- same component, ternary on the dialog type
"... means the full history gets re-read on your next message."   <- shared warning suffix

The warning is accurate for a model switch (different model → cold cache) but not for an effort change, which per the measurements above preserves the cache. Branching the warning copy per dialog type would resolve the confusion.

NubeBuster · 1 month ago

I got a warning that switching from fable to opus would invalidate the context, but the context had long expired by then. I know this because the jsonl transcripts contain the real TTL epoch, so this is known client side. Additionally, since 26th January, early 4ACE, the server stopped lying to the client and they consequently started agreeing when the cache expires.[^evidence] So this warning is misleading and unnecessary. Just like the aforementioned effort switch warning.

Handwritten human slop

Statistically, I expect there to be at least one peculiar user that would misinterpret those warnings as new information and spend unnecessary time consulting the documentation, being left with the recurring task of triaging if the documentation is accurate, or if the github issue reports provide more value by providing empirical findings, as opposed to literature that is based on other literature written at a branching point, diverged from the development team. Never collaborated with nor corroborated by the apostils who were present at the meeting many agile sprints ago.

I know him, he is me! 💀

An Unexpected Journey

This sent me on a whole journey to investigate if /compact might operate differently now, or if the cache is somehow bumped (this would be a nice feature).

Documentation states regression

Then in the docs I found the statement that effort affects the cache key. It used to work like that like back in late 3ACE (After ChatGPT Era). I was shocked for a sec.
<img width="224" height="224" alt="Image" src="https://github.com/user-attachments/assets/2e912bd7-1aba-4c0b-ba82-e33089652bc4" />

But time has passed. We've long forgotten that era. It's almost 4ACE already... I was happy to be reminded that Anthropic isn't great at communication - why do you think they make chatbots....

[^evidence]: https://github.com/anthropics/claude-code/issues/22435#issuecomment-4071453103