Detailed Analysis
A Reddit user's complaint about "Forgetful Claude" surfaces one of the most persistent and well-documented friction points in working with large language models on extended technical projects: the failure to retain and consistently apply established rules, constraints, or algorithms across a multi-session workflow. The user describes a specific pattern — Claude correctly implements a selection criterion for choosing "bases" to build "targets" upon, but on subsequent runs reverts to an earlier, incorrect approach, requiring the user to re-explain and re-correct the same logic repeatedly. This is not a hallucination in the classic sense (inventing false facts) but rather a regression failure, where previously-corrected behavior silently degrades without any signal that it has done so.
The root cause is architectural rather than a simple bug. Claude, like other transformer-based LLMs, does not possess persistent memory across sessions unless explicitly given tools for it (such as memory features, project knowledge, or system prompts that get reloaded each time). Each conversation — or even each new code-generation request within a long session — is reconstructed from the context window available at that moment. If the corrected logic isn't explicitly re-stated, embedded in a system prompt, saved to a project file, or reinforced through techniques like retrieval-augmented context, the model has no guaranteed mechanism for "remembering" that a fix was applied three turns ago. Long technical sessions compound this risk: as context grows, earlier corrections can get diluted, truncated, or deprioritized relative to more recent or more frequently repeated instructions in training data, causing the model to default back to more "generic" or statistically common patterns rather than the user's specific bespoke rule.
This matters because it exposes a gap between how LLMs are marketed — as capable coding collaborators for sustained, complex projects — and how they actually function under the hood without deliberate scaffolding from the user. For technical users running iterative build/test cycles over weeks, this forgetfulness isn't a minor annoyance; it undermines trust in automation and forces manual verification of previously "solved" logic, which erodes the productivity gains AI coding assistants are supposed to provide. It also highlights the difference between conversational memory (recalling facts about the user) and procedural consistency (reliably executing a codified rule across many invocations) — the latter being a much harder and less-solved problem, since it requires the model to treat certain instructions as immutable constraints rather than soft preferences.
Practically, the kinds of fixes the community typically recommends — and that Anthropic has been building toward — involve moving critical logic out of conversational memory and into persistent, machine-checkable artifacts: codifying the "basis selection" rule directly in the codebase or a CLAUDE.md/project-instructions file that gets reloaded every session, using Claude's Projects feature or system prompts to pin the rule, writing automated tests that fail loudly when the rule is violated, or breaking the workflow into smaller, rule-verified steps rather than trusting the model to hold the entire algorithm in working memory over a long session. This complaint fits into a broader industry trend where AI labs — Anthropic included — are racing to solve the "long-horizon coherence" problem through longer context windows, persistent memory products, and agentic tool-use patterns that let the model consult external ground truth rather than relying purely on its own recall. Until those solutions mature, users doing sustained technical work are effectively required to build their own external memory and verification layers around the model, treating Claude less as an infallible engineer and more as a fast but occasionally amnesiac collaborator that needs guardrails.
Read original article →