Statelessness: Why "Memory" in a Chat Is an Illusion

The concept in one sentence: Claude does not remember your conversation — every time you send a message, the entire conversation so far is silently resent, and Claude generates a reply having "read" it all again, from scratch, with no memory of having done so before.

This is the mechanism behind the context window (A.concept.under-the-hood, A4.conceptual-vocabulary). Those documents describe what the context window is. This one explains why a chat feels continuous even though the model underneath has no continuity at all.

1. The model is a stateless function

Strip away the chat interface and what remains is a function: give it text, it gives back text. Call it again with different text, it has no idea the first call ever happened. There is no session, no memory, no internal state carried from one call to the next. Each call to the model is independent — mathematically and literally.

This is true even mid-conversation, message 47 of the same chat. The model is not "still there" from message 1, quietly remembering. It is invoked fresh, every single time.

2. What "generating a reply" actually means

The model is generative and autoregressive: given some input text, it predicts the single most probable next token (roughly a word-fragment), appends it, then predicts the next token after that, and so on, one at a time, until it decides to stop. That is the entire mechanism. There is no separate "thinking" step that persists — the only thing that exists is the input text and the token being predicted right now.

This means the model's entire "knowledge" of the conversation, at the moment it generates each word of its reply, is whatever text is in front of it at that instant. Nothing more.

3. So how does it seem to remember?

The chat interface (or Claude Code, or the API client) does something you never see: on every single message you send, it resends the entire conversation transcript so far, plus your new message, as one combined block of text. The model then generates a reply to that whole block.

Turn 1:
  You send:        [your message 1]
  Model receives:  [your message 1]
  Model replies:   [reply 1]

Turn 2:
  You send:        [your message 2]
  Model receives:  [your message 1] [reply 1] [your message 2]
  Model replies:   [reply 2]

Turn 3:
  You send:        [your message 3]
  Model receives:  [your message 1] [reply 1] [your message 2] [reply 2] [your message 3]
  Model replies:   [reply 3]

Every turn, the whole history rides along, invisibly, packaged by the harness or interface — not by the model. What feels like Claude "remembering" what you said three messages ago is Claude re-reading what you said three messages ago, because it was pasted back in front of it, along with everything else, a moment before it started generating.

This is exactly the same mechanism as the context window described elsewhere in this book — this document just makes explicit the resending step that produces the feeling of memory.

4. Why this matters practically

Cost and length compound. Because the full transcript is resent every turn, a long conversation does not cost like a long conversation feels — it costs like re-sending the entire conversation every single time, because that is literally what happens. Turn 50 sends everything from turns 1–49 again, plus the new message. This is why very long chats get slow and expensive, and why /compact or starting fresh sessions exist as tools (see A.token.management).

Editing or deleting earlier messages changes what Claude "knows." Since the whole transcript is reassembled and resent each turn, if an interface lets you edit or delete an earlier message, the model's next reply is generated from the edited history — as if the original had never been said. There is no separate memory of the original to fall back on; the resent text is the only reality the model has access to.

Nothing survives outside the resent block. If something is not in the transcript that gets resent — because the context window overflowed and old messages were dropped, or because you started a new chat — it is not merely "hard to recall." It does not exist for the model at all. This is different from human forgetting, which is partial and probabilistic. Model "forgetting" via context loss is total and immediate: the text is either in the resent block, or it is gone.

This is also why Claude cannot tell you what happened in a different conversation, or "remember" you from yesterday, unless a separate persistence mechanism (Claude Code's Memory file, a Project's saved instructions, a CLAUDE.md) writes something down and that something gets loaded into a future resent block. See A.concept.memory for that mechanism specifically — it is a workaround built on top of statelessness, not a contradiction of it.

5. The harness does the resending, not the model

This is the same model/harness split covered in A4.conceptual-vocabulary. The model itself has no capacity to reach back and fetch prior turns — it only ever sees what it is given in a single call. It is the harness (Claude.ai's web app, the Claude Code CLI, the API client you or someone else wrote) that keeps a running transcript, reassembles it, and resends it on your behalf, every time, so the model can produce a reply that looks continuous.

Two consequences follow:

Two different harnesses running the same model can implement this differently — one might resend the full transcript verbatim, another might summarise older turns before resending (this is what "compacting" does), another might selectively drop irrelevant earlier turns. The model has no say in this; it only ever sees whatever text arrives.
"Continuity" is a property of the interface, not of the model. When you experience Claude as a coherent conversational partner across fifty turns, that coherence is manufactured by careful, invisible resending — not by an underlying persistent mind holding the thread.