[BUG] cache_control TTL ordering 400 recurs on v2.1.220, now at message index 6 (regression from fix in 2.1.116)
Preflight Checklist
- [x] I have searched existing issues and found related closed reports (#37188, #37842, #38542, #39599, #38320) — this is filed as a regression, not a fresh duplicate
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
Hit the well-documented cache_control TTL ordering 400 error, which was previously reported fixed in 2.1.116 (per maintainer comment on #38542, closed as duplicate of #37188):
API Error: 400 messages.6.content.0.cache_control.ttl: a ttl='1h' cache_control block must not come after a ttl='5m' cache_control block. Note that blocks are processed in the following order: tools, system, messages.
Version
Claude Code 2.1.220 (claude --version) — well past the 2.1.116 fix version, so this looks like a regression rather than the original unfixed bug.
Why this looks like a distinct trigger, not just the old bug resurfacing
Prior reports (#37842, #38542, #37188) describe this occurring deep into long conversations (message index 60, 126, 156+), attributed to hook/MCP additionalContext injection reshuffling cache breakpoints over many turns.
This occurrence was at messages.6 — very early in a short session, before significant history accumulation. That suggests either the original fix only covered the long-session case and missed an early-session trigger path, or a regression reintroduced the bug more broadly between 2.1.116 and 2.1.220.
Impact
The request fails outright (hard 400), aborting the turn — a correctness bug, not just a caching/cost inefficiency (distinct from #81967, a related but separate cost-only TTL downgrade issue that remains open).
Workaround
Starting a new conversation avoids the immediate error, consistent with prior reports, but does not address the regression.