The Claude Code stale-context bug, explained

Anthropic published an engineering postmortem this morning about a bug that made Claude Code quietly worse for weeks. The headline finding: long-running sessions degraded in a way that was hard to see, hard to reproduce, and hard to catch in review. The fix shipped, and Anthropic reset usage limits for everyone affected, which is how most users found out anything had been wrong.

I want to walk through what actually happened, because the postmortem is the kind of document where the interesting part is the shape of the bug, not the patch. This one sits at the intersection of three systems that each behave correctly in isolation: context management, the API, and extended thinking. The bug only existed in the seam between them.

That seam is the bit worth understanding.

What "context" actually is

When you talk to Claude Code, you are not having a conversation in any human sense. The model has no memory between turns. Every time you press enter, the entire prior conversation, your messages, the model's replies, tool calls, file contents it has read, system instructions, gets bundled up and sent to the model as one big input. That bundle is the context.

When you talk to Claude Code, you are not having a conversation in any human sense.

The context has a hard size limit, measured in tokens (roughly: chunks of text, where one token is about three-quarters of an English word). For Claude, we're talking hundreds of thousands of tokens, large, but finite.

Long coding sessions blow through that limit fast. You read a file, that's a few thousand tokens. You run a tool, the output goes in. The model thinks out loud, that goes in. After an hour of work, the raw transcript is much larger than the model can accept.

So Claude Code does what every serious agent system does: it manages the context. It summarises older turns, drops things it judges to be no longer relevant, keeps the recent stuff verbatim, and reconstructs a smaller bundle that represents the session without literally being it. This is context management, and it is one of the hardest unsolved problems in production AI engineering, because every decision about what to drop is a decision about what the model can still know.

What "extended thinking" adds to the picture

Extended thinking, sometimes called reasoning, or thinking tokens, is the feature where the model produces a private chain of reasoning before its visible answer. You ask a hard question, the model writes itself a long internal monologue working through the problem, and then writes the answer you actually see. The monologue is real generated text, it consumes tokens, and crucially: it gets stored as part of the conversation.

Why store it? Because subsequent turns sometimes need to refer back to the model's prior reasoning. If the model decided in turn three that the user's database is Postgres, the thinking that led to that decision is part of why the model behaves consistently in turn four.

So now the context contains three kinds of stuff: user-visible messages, tool calls and their outputs, and the model's internal thinking blocks. Each kind has its own format, its own role in the API request, and its own rules about how it can be modified.

Where the bug lived

Here's the seam.

The context manager's job is to compress old turns. The API's job is to accept a well-formed request and return a response. Extended thinking's job is to produce reasoning blocks that travel with the conversation.

The bug, as Anthropic describes it, was that when the context manager compressed older turns in a session that contained extended thinking blocks, it produced a context that was technically valid, the API accepted it, no error thrown, but semantically wrong. The thinking blocks ended up in a state where they were still present in the request but no longer properly anchored to the assistant turns they belonged to. The model, on receiving this, behaved as if it had thought a bunch of things in a vacuum. Its reasoning in subsequent turns was subtly disconnected from the work it had supposedly already done.

The result wasn't dramatic failure. The model didn't crash. It didn't say obviously wrong things. It just got worse in a long session, slightly more confused about what had been established, slightly more prone to redo work it had already done, slightly less coherent across a multi-hour debugging arc.

This is the worst kind of bug. Loud bugs get caught. Quiet bugs that degrade quality across long sessions look, to most observers, like "the model is having a bad day."

Why it survived review

Anthropic's postmortem notes that the bug passed multiple automated and human review layers. I don't find that surprising, and I think it's the part most worth dwelling on.

Each component, tested in isolation, did its job. The context manager produced valid output. The API accepted it. Extended thinking, in fresh sessions, worked fine. The integration tests presumably checked that requests didn't error and that responses came back. None of those tests would have caught "the model is 8% worse over a four-hour session because reasoning blocks are misaligned."

To catch this, you need an evaluation that:

1. Runs long sessions, not single turns.
2. Uses the full stack, context manager, API, extended thinking, together.
3. Measures quality of output, not just validity.
4. Compares against a baseline sensitive enough to detect a moderate degradation.

That is a hard eval to run, expensive to run continuously, and noisy enough that small regressions hide in the variance. The honest version of this story is that nobody, not Anthropic, not OpenAI, not Google, has nailed this kind of evaluation yet. Long-horizon agent quality is genuinely hard to measure, and the industry knows it.

The metaphor, and where it breaks

The way I find easiest to picture this: imagine you're working with a colleague who occasionally takes private notes in a notebook before answering you. The notebook helps them stay consistent. Now imagine someone shuffles their notebook every hour, same pages, same handwriting, but the pages aren't in the right order any more. Your colleague keeps answering, and the answers aren't wrong exactly, but they're a little off. They've forgotten which thought led to which conclusion.

That's roughly what was happening to Claude in stale sessions.

The metaphor breaks in one important way: a human colleague would notice their notes were jumbled and say something. The model has no equivalent ability to notice. It treats whatever context it receives as the truth of what just happened, because for it, that context is what just happened. There's no internal sense of "wait, this doesn't match what I remember", it doesn't remember anything outside the context window.

This is a recurring theme in agent failures: the model can't tell when its own working memory has been corrupted, because its working memory is the only ground truth it has.

What to take from this

A few things are worth carrying forward as a non-engineer trying to understand what's going on under the hood:

Context management is where the action is. The headline capabilities, long context windows, extended thinking, tool use, get the attention. The systems that knit them together get less. But the integration is where the subtle, expensive bugs live, and where the next year of agent quality improvements will mostly come from.

"It accepted the request" is not "it understood the request." A valid API call can still produce a semantically broken context. The model will do its best with whatever it gets.

Long-session quality is the frontier. Single-turn benchmarks are mostly solved or saturating. The interesting evaluation problem now is: does the agent stay coherent across hours of real work? Anthropic's postmortem is, indirectly, an admission of how hard that problem is.

Resetting usage limits was the right move. Users who burned quota fighting a degraded model were paying for the bug. Refunding them is the minimum, and Anthropic doing it publicly sets a useful norm for the industry.

I'll be watching whether other labs publish postmortems at this level of specificity. They should. The collective understanding of how agent systems fail is still embarrassingly thin, and detailed writeups like this one are how the field actually learns.

---

Footnotes and links

Further reading

• [Anthropic engineering blog]: postmortem on Claude Code stale-session degradation
• [Anthropic docs]: extended thinking and reasoning blocks in the Messages API
• [Anthropic docs]: context management and conversation structure for Claude Code

¶