Expose extended (1h) prompt-cache TTL for interactive sessions
Problem
The Anthropic API's prompt cache defaults to a 5-minute TTL. In interactive Claude Code sessions, the human reply gap routinely exceeds that: measured across 1,967 reply times in one power user's session telemetry, 27% of replies landed after the 5-minute window and 10% after 15 minutes. Each late reply forces a cold re-read of the entire conversation context (often hundreds of KB in long sessions), paying full input cost and latency for content that was cached moments earlier.
Users can't reasonably be expected to watch a cache clock while thinking, reviewing diffs, or juggling parallel sessions — and the UI surfaces no signal about when the window lapses.
Ask
The API already supports cache_control: {type: "ephemeral", ttl: "1h"} (2x write cost, ~0.1x reads, break-even at ~3 requests). Expose it in Claude Code, any of:
- A setting (
cacheTtl: "1h"in settings.json) or env var, or - Automatic: use the 1h TTL for interactive sessions (or adaptively, when the user's recent reply gaps exceed the 5-minute window), keeping 5m for headless/scripted runs.
For long interactive sessions the economics clearly favor 1h: one 2x write amortizes across every turn of an afternoon session, versus repeated full-price cold re-reads.
Workaround today
None exposed. Users can only restructure their workflow (fewer, longer autonomous runs; checkpoint files + fresh short sessions instead of resuming stale transcripts), which helps but shouldn't be required to avoid a silent 10x cost cliff on a reply that took six minutes instead of four.