You can pin the prompt cache to five minutes or an hour, separately for subagents.
What's wrong with this entry?
Two new settings, promptCacheTtl and subagentPromptCacheTtl, pin the prompt cache to "5m" or "1h". The first covers the main conversation (interactive, -p and SDK turns and the helpers that run inline with it), the second covers subagents, workflows and background requests. CLAUDE_CODE_PROMPT_CACHE_TTL and CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL override the settings. No experiment gate; available to everyone on this build.
- Unset means automatic: 1 hour on a Claude subscription within usage limits, 5 minutes on an API key, Bedrock, Vertex or Foundry for the main conversation; 5 minutes for subagents unless
ENABLE_PROMPT_CACHING_1H=1. - Resolution order is
FORCE_PROMPT_CACHING_5M, then the environment variable, then the setting, then the 1h environment flags. - Both environment names were added to the allowlist, and request telemetry gained
prompt_cache_ttlandprompt_cache_ttl_reason.
# in settings.json
{ "promptCacheTtl": "1h", "subagentPromptCacheTtl": "5m" }
# or per run
CLAUDE_CODE_PROMPT_CACHE_TTL=1h claudeCLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL, Prompt cache TTL for the main conversation (interactive, -p and SDK turns, plus the helpers that run inline with it), Prompt cache TTL for the main conversation (interactive, -p and SDK turns, plus the helpers that run inline with it): "5m" or "1h".
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.227
Less eager module loading at startup
Both mention performance
-
v2.1.227
Event loop stall detector rewritten as a class
Both mention performance
-
v2.1.232
Conversation normalization reuses its previous result
Both mention performance