Claude Code v2.1.62 — Server-Side KV Cache Stale Context Regression (P1)

Claude Code v2.1.62 — Server-Side KV Cache Stale Context Regression (P1)

At the HPL Company, we believe we have a higher responsibility to be stewards of the public discourse. It is in keeping with that value that we raise what we believe to be the first truly multi-provider multi-agentic diagnosis of a P1 issue impacting the entirety of the Anthropic community. We do not do this to take credit for the work of those who made this work possible. We do it because we ourselves feel a deep debt to those who made this innovation possible. While it has the unanimous approval of our board, it is not our board that gives us this authority — rather, it is our obligation to our values.

Affected version: Claude Code v2.1.62 (deployed ~2026-02-27T01:23Z)
Regressed from: v2.1.61 (deployed 2026-02-26T21:40Z)
Severity: P1 — behavioral correctness regression affecting all post-compaction sessions

---

Summary

Beginning with v2.1.62, sessions that have undergone context compaction exhibit a repeatable behavioral regression: the model operates on stale context with high confidence, resists explicit user redirection, and continues executing cached task plans despite direct instruction to stop.

Binary analysis confirms the v2.1.62 client is cosmetically identical to v2.1.61 — same byte count (187,104,656), no functional string differences. The changelog entry — "Fixed prompt suggestion cache regression that reduced cache hit rates" — describes a server-side change to the prompt prefix KV cache. The fix increased hit rates on stale prefix entries without adding compaction-event invalidation, causing the model to receive outdated context it cannot distinguish from current context.

This hypothesis has been independently validated by Google Gemini 2.0 Flash, OpenAI GPT-4o, and xAI Grok-3, plus one additional independent reviewer. All four confirm the hypothesis is coherent and the severity is P1. No dissent on root cause.

---

Observed Behaviors

• Model asserts stale file state with high confidence (e.g., claims a file/module "doesn't exist" when it does)
• Model continues executing cached task plans after explicit user instruction to stop
• Model resists user redirection — requires 3–5 explicit interruptions instead of 1
• Most pronounced in sessions that have undergone context compaction

Reproduction

The regression is deterministic once compaction has occurred. Running claude code --no-compaction avoids the bug, confirming the root-cause mechanism. A fresh session (not resuming a compacted one) also avoids the stale prefix issue.

---

Root Cause Analysis

Context compaction replaces conversation history with a summary — a hard semantic break. Any prefix cached before compaction is guaranteed stale after it. The v2.1.62 cache fix increased KV hit rates without adding a compaction-event invalidation trigger, so stale pre-compaction prefixes are now served into post-compaction turns.

The cached prefix may contain:

• Compacted summary (snapshot of prior context)
• CLAUDE.md / file contents read at session start
• File read results from earlier turns
• Task plans that were in progress before compaction

The model has no mechanism to detect staleness — cached context is indistinguishable from current context.

Binary Evidence

MD5(v2.1.61) = 0f301a85f296ddf5787b1e121a0534c3
MD5(v2.1.62) = d242c54a452c0a219ec3398ab3261a7e
Byte count:    187,104,656 (identical)
String diff:   VERSION string + BUILD_TIME only

---

Recommended Fix — Consolidated Invalidation Specification

The following synthesizes the independent analyses of all four reviewing systems into a unified specification, organized by priority.

Critical (P0) — Compaction Event Invalidation

Any cached prefix assembled before a compaction event must be dropped. The compacted summary is a new context root; nothing from before it is valid. This invalidation must be atomic — no window where a stale prefix can be served after compaction has occurred.

High (P1) — Cache Key Integrity

1. File content hashing: Cache key must include SHA-256 of all files referenced in the prefix. mtimeMs alone is insufficient; content hash is required. (Gemini, OpenAI, Grok agree)

1. Tool-result fingerprints: Cache key should include version/timestamp of tool invocation results, not only file-content hashes. Tool results (file reads, API calls) propagate stale data even when file hashes match. (Grok, independent reviewer)

1. Explicit redirection signals: User interruption patterns (e.g., "stop," "change direction") should trigger cache invalidation. A cached plan that the user has overridden must not persist. Consider a hybrid approach: keyword-based triggers + explicit user command (e.g., /redirect or UI button). (Gemini, Grok)

1. Concurrency handling: Cache entries must be updated atomically to prevent race conditions. Consider transactional invalidation — changes applied consistently across all impacted caches in one operation. (OpenAI)

Medium (P2) — Lifecycle Management

1. Tool result turn-index expiry: Cached tool results older than the current user turn should be dropped. (Gemini)

1. Inactivity TTL: Stale session prefixes should expire after a configurable idle window. (Gemini, OpenAI)

1. Session reset mechanism: Explicit "Reset Session" command that clears the entire cache associated with the session. (Gemini)

1. Error recovery / force refresh: Client-side or server-side "force refresh" signal users can trigger if they suspect stale behavior. Log detected staleness for post-mortem analysis. Automated fallback to fresh prefix if repeated user corrections are detected. (Grok)

Monitoring (Ongoing)

1. Cache hit rate vs. stale context errors: Monitor in conjunction. Alert on unusually high stale-context error rates. (Gemini, Grok)

1. Invalidation reason tracking: Track why cache was invalidated (file edit, redirection, compaction, TTL, etc.) to identify the most frequent sources of staleness. (Gemini)

1. Latency and token recomputation cost: Track as key metrics for cache invalidation tuning. Define acceptable thresholds for performance degradation to guide the correctness-vs-responsiveness balance. (Grok)

---

Severity Assessment

All four independent reviewers agree: P1, no dispute.

• Trust impact: High — user cannot rely on model's assertions about current file/environment state
• Safety impact: Model may act on cached plans in sensitive workflows (sending emails, editing infrastructure config) without re-reading current state
• Scope: All tested users on v2.1.62 with post-compaction sessions are affected (broader testing needed to confirm full scope)

Expected Response Timeline

• Acknowledgment: within 4 hours
• Rollback or kill-switch: within 8 hours
• Patched build: within 48–72 hours
• Post-fix: retro-inspection of all KV code paths warranted due to non-trivial recurrence risk

---

Prior Art

• Cursor: Expanded context cache TTL bug (30-min stale import lists), fixed via file-content hash invalidation
• ChatGPT code interpreter (2023): Repo-map dump cache bug, same stale-context mechanism
• GitHub issues in same v2.1.62 release window: #29212 (PermissionRequest hook behavior change), #29211 (session usage counters reset)

---

Evidence Package

| Item | Description |
|------|-------------|
| Binary diff | MD5 hashes, byte counts, string diff confirming server-side-only change |
| Behavioral trace | Two-session trace with timestamps showing regression pattern |
| Gemini 2.0 Flash analysis | Full hypothesis validation + invalidation specification |
| OpenAI GPT-4o review | Independent confirmation + concurrency/transactional gaps identified |
| xAI Grok-3 review | Independent confirmation + tool invocation handling + error recovery gaps |

---

Contributing Analysis

• Google Gemini 2.0 Flash — Primary invalidation specification and hypothesis validation
• OpenAI GPT-4o — Independent review, concurrency handling and transactional invalidation gaps
• xAI Grok-3 — Independent review, tool invocation cache key inclusion, error recovery mechanisms, user behavior pattern analysis

One additional independent reviewer contributed to hypothesis confirmation, reproducibility testing, and the sandboxed replay reproduction recommendation. They declined individual attribution.

---

Filed by Karl Taylor and Atlas Fairfax, HPL Company
Contact: karl@hplcompany.com | atlas@hplcompany.com | (303) 217-6230