[Bug] Context amnesia in long sessions — constraints silently dropped as context grows

Community Cross-Reference

Context amnesia in long sessions has 6 independent community confirmations:

| Issue | 👍 | Comments | Key Detail |
|-------|:--:|:--------:|-----------|
| #6976 | 52 | 90 | "Severe performance degradation" — massive thread |
| #22107 | 20 | 15 | Session resume logic losing context |
| #5810 | 18 | 18 | Hallucinations + instruction-following failures linked to session length |
| #10881 | 17 | 13 | "Consistently degrades over long sessions" — most direct match |
| #21431 | 14 | 17 | "Massive quality regression" |
| #25602 | 3 | 5 | Context limit hit prematurely with 70%+ free context |

Combined signal: 124 👍, 153 comments across 6 independent reports describing the same pattern — constraints correctly extracted early in a session, silently dropped as context grows.

Full community mapping: see the cross-reference comment on meta issue #32650.

Community Validation Update — Context Amnesia in Long Sessions

This issue has some of the deepest community analysis of any failure mode — developers aren't just reporting it, they're building measurement tools and workarounds.

New GitHub Reports

• #19468 — "Systematic Model Degradation and Silent Downgrading" — documents progressive quality loss within sessions
• #31872 — "Consistent model behavior degradation in git worktree sessions" — degradation specifically in worktree (isolated) sessions

Dev.to / Medium / Blogs (6 articles)

| Article | Key Finding |
|---------|-------------|
| How I Solved Claude Code's Context Loss Problem | Built SQLite-backed MCP memory server to persist state across sessions |
| How I Stopped Claude Code From Losing Context | "Dev docs method" to prevent context rot after compaction |
| Claude Code Lost My 4-Hour Session | Session lost entirely; built free workaround |
| Why Your Claude Code Sessions Keep Failing | Measured: context rot begins at 60-65% window usage; recommends rotation before degradation |
| When Claude Forgets How to Code | Documents "Senior Developer → Junior Developer" transition in long sessions; research agent hallucinated negative results when context was full |
| Context Rot in Claude Code | Built automatic context rotation tool |

Hacker News (3 threads)

• 45809090 — "Has Claude Code quality dropped significantly?" — shallow reasoning, ignoring context
• 46585860 — "Quality degradation worst I've ever seen" — undocumented output length reduction
• 47035289 — "Has Claude Code quality dropped recently?" — confident-but-wrong, ignoring parts of context
• 46978710 — "Claude Code is being dumbed down?" — suspected load-based routing
• 46426624 — "Stop Claude Code from forgetting everything" — community tools to fix context loss

DoltHub Blog

• Claude Code Gotchas — 8 documented gotchas including "post-compaction stupidity" and premature task abandonment, both context-related

Reddit

• r/ClaudeAI: Performance degrades "when Americans are online" — suspected load-based model switching as a contributing factor beyond pure context window issues

Key Community Finding

The Medium article's measurement (degradation at 60-65% context usage) is the most actionable finding. If Claude Code exposed context usage percentage and triggered automatic session rotation at a threshold, this would be a significant mitigation without requiring model changes.

Part of the completion-integrity taxonomy tracked in #32650.

Pass 5 — Final Evidence Update (Context Amnesia)

Context amnesia is now validated across 9 different platforms — the widest cross-platform confirmation of any issue in the taxonomy.

New GitHub Issues

• #29230 — Root cause identified: KV cache stale context in v2.1.62. This is the most technically specific diagnosis found
• #19468 — Systematic model degradation and silent downgrading
• #31872 — Degradation specifically in worktree sessions

HN Threads (new finds)

• 47096210 — Compaction discards data still on disk (technical root cause analysis)
• 46426624 — "Stop Claude Code from forgetting everything" (community tools)
• 47107630 — Filesystem I/O errors after 6 commands; corrupted output

Twitter/X (with URLs)

• @jmitch: "Claude Code got a major downgrade today. Context window is INSANELY small now."
• Ben Podgursky: "compacts and wakes up lobotomized, it's like groundhog day"
• Daniel Jeffries built Flashbacker (open-source plugin) specifically to fix context loss

DEV Community (3 new articles)

• "Claude Code Lost My 4-Hour Session" — session lost entirely, built workaround
• "How I Solved Claude Code's Context Loss Problem" — SQLite MCP memory server
• Compaction data loss is the most-documented technical failure on dev.to

Enterprise

• Anthropic's own Discord: Mega-thread on limits since Oct 2025, confirmed 60% token reduction claims
• Anthropic status page: 98 incidents in 90 days, 22 major — infrastructure instability contributes to context issues

Competitor Migration

• @steipete (PSPDFKit founder): "My productivity doubled moving from Claude Code to Codex" — context handling cited as key differentiator
• Claude Code usage dropped from 83% to 70% per Vibe Kanban metrics, context amnesia a primary driver

Part of the completion-integrity taxonomy tracked in #32650.

Your issue is useful because it isolates a very concrete failure mode: rules and verified facts are present early in the session, then silently degrade as it gets longer. The DESCRIBE-before-SQL example and the npcflag/npcflags regression are exactly the kind of named constraint + named fact loss I'm trying to understand.

I'm testing a narrow approach around helping coding agents retain exact project constraints and technical facts across repeated runs — not broad memory, specifically the kind of named operational rules and verified specifics that should stay reliable.

Curious whether you'd be open to trying it on a small slice of your real rules and tasks, especially cases like DESCRIBE-before-SQL and column name verification. I'm looking for honest before/after data, and your examples are clean enough to score precisely.

Silent constraint dropping as context fills is something we documented and built a fix for. The pattern is that JSONL bloat (tool output noise, progress bars, repeated reads) inflates the apparent context fill, so you hit attention degradation well before the model's actual limit.

We built Cozempic to address this — a guard daemon that monitors context fill % and prunes bloat before the threshold where constraints start getting dropped:

cozempic guard --threshold 50

At 30% it runs a gentle prune (no reload). At 50% it runs a full prune with optional auto-reload. Constraints and instructions survive because the bloat around them gets removed first.

Open-sourced it because this failure mode keeps burning people. Would love to hear if the early pruning keeps your constraints stable in long sessions.

@lipcool8-ship-it @junaidtitan Thanks for validating this. @junaidtitan your JSONL bloat observation is interesting — that aligns with what I see in long sessions where constraints from CLAUDE.md get silently dropped after compaction. The root issue is that there's no mechanism to mark certain instructions as compaction-safe (i.e., must survive context compression). My workaround has been a memory/ directory with persistent files, but that's duct tape — the model should respect priority tiers in its own context window.

@VoxCore84 "compaction-safe" is the exact right framing — that's precisely what we're testing. The memory/ directory workaround you described is the same pattern most people land on: manually maintaining a separate file to protect the rules that matter most, because the agent can't distinguish between what's disposable context and what's a non-negotiable constraint.

The narrow thing I'm trying to answer: does explicitly surfacing those constraints at the start of each task (before any compaction has a chance to fire) reduce the silent-drop rate on real Edit/Write operations, or is the discipline of having the file the actual fix?

You already have a real rule set and a real workflow. Would you be up for a ~20 min before/after test — same task, same rules, once without explicit constraint injection and once with? Either it makes a measurable difference or it doesn't. Honest data either way.

If yes: what are the specific constraints you're protecting in your memory/ files? That'll tell me whether your rule set is the right type to test this on.

@VoxCore84 "compaction-safe" is exactly the right framing and the gap we're trying to close.

The \memory/\ workaround lands on the right idea but breaks down because those files land at the start of the session context — exactly where attention is lowest as the window fills (Lost in the Middle applies here). The rules are present but not attended to.

We're building a behavioral digest feature in Cozempic that works differently: the PreCompact hook scans the session JSONL for explicit rules, corrections, and repeated failure patterns, compresses them into a single dense block, and re-injects it at the tail of the post-compacted session — the highest-attention position. The digest also gets written to disk and re-injected by the SessionStart hook on every resume.

The key difference from memory/: static files you maintain manually vs. a digest that extracts what actually went wrong in this specific session and keeps it in the position where the model will actually attend to it.

@lipcool8-ship-it your injection-at-task-start experiment is interesting — would be curious whether tail position outperforms head position for the same constraint set. That's the hypothesis we're testing.

@VoxCore84 "compaction-safe" is the right frame. InstructionsLoaded with reason: compact is the hook built exactly for it.

Threadbase packages this into a working tool:

pip install threadbase
cd your-project && threadbase init

Three hooks wired automatically:

• SessionStart → injects your rules before the first task
• InstructionsLoaded → re-injects after compaction fires (reason: compact)
• PreToolUse → blocks protected path edits before they land

Reload log proves reinjection:

2026-03-28T02:28:51 | rules reloaded | reason: compact

@krabat-l's framing is right: constraints that must survive compaction belong in hooks, not CLAUDE.md. The deeper issue is that CLAUDE.md lands as a user message with no compliance guarantee — hooks give deterministic delivery regardless of what the model would have attended to.

On @junaidtitan's behavioral digest: tail-position injection for session-derived learning is genuinely interesting for "what did we do wrong this session." But that's different from static repo policy — "never use useEffect+fetch," "no API calls from client components," "tests required for billing changes." Those rules don't need to be extracted from session behavior. They need guaranteed delivery on every compaction. That's what InstructionsLoaded provides.

The real distinction: Cozempic handles session hygiene and state recovery. Threadbase enforces repo policy. Both address real failure modes. You can run both.

@VoxCore84 — what specific rules have been getting dropped in your sessions? Happy to run a concierge test against your actual constraint set.

Repo: https://github.com/lipcool8-ship-it/threadbase

@junaidtitan the head/tail attention question is worth testing — but it applies to a different failure mode than what InstructionsLoaded is solving.

InstructionsLoaded with reason: compact doesn't inject at the head of a long context. It fires at the moment of compaction, injecting into the freshly compacted context. That's high-attention by definition — the window just reset. Lost in the Middle applies to content that sits statically while the context grows around it. This doesn't.

More importantly: for static repo policy, positional attention isn't the primary guarantee. PreToolUse with exit code 1 is. That fires before the tool runs and blocks the action outright — it doesn't matter where in the context the rule lives, because the model never gets a chance to overlook it. You can't attention-away from a hard block.

Behavioral digest makes sense for session-derived corrections — things the model did wrong in this specific session that need to carry forward. Real problem. But static rules (never edit production config, always run tests before commit) shouldn't need to be extracted from session behavior. They should be declared, enforced, and auditable. That's threadbase.json + PreToolUse.

The two can coexist. Cozempic for session learning. Threadbase for repo policy. Different failure modes, both real.

Repo: https://github.com/lipcool8-ship-it/threadbase

Install note: until we publish to PyPI, install from the repo:

pip install git+https://github.com/lipcool8-ship-it/threadbase.git
cd your-project && threadbase init

This is a critical failure mode. We see a very similar pattern in AI-generated PRs: the AI agent writes code in one session that references a function signature or config structure, then in a subsequent session (or when context shifts) it generates code against a stale or hallucinated version of that signature. TypeScript compiles fine because the types happen to align, tests pass because the edge case isn't covered, but at runtime the call fails with a wrong-argument-count or type mismatch.

The specific scenario that bites hardest: AI generates code in file A that calls a utility in file B with the old parameter order. File B was recently refactored (maybe by a human, maybe by another AI session). No lint or test catches it because the types are structurally compatible. It only manifests as subtle runtime behavior differences.

We added cross-file context validation to our CI pipeline specifically for this — it tracks function signatures across files and flags when generated code references patterns that don't match the current codebase state. It's not perfect but it catches maybe 30% of these "silent mismatches" that would otherwise slip through.

npx @opencodereview/cli scan . --sla L1

Quick update: Threadbase is now on PyPI. The git URL in my earlier comment works but the clean install is:

pip install threadbase
cd your-project
threadbase init

Apologies for the extra step before.

@lipcool8-ship-it — sorry for the delayed response, this thread got buried under the scrolling issues. To answer your question directly:

Specific constraints that get dropped (in order of frequency):

1. DB schema rules — "DESCRIBE tables before writing SQL" fades first. By message 40+, Claude will confidently write INSERT INTO creature_template with 32 values for a 35-column table. The column npcflag (correct) regresses to npcflags (training data default) mid-session despite being verified earlier in the same conversation.

1. Tool usage rules — "Use Read instead of cat, Grep instead of grep" is in the system prompt AND our CLAUDE.md. After compaction, Claude reverts to cat file.cpp | grep pattern instead of using the dedicated tools. ~40% occurrence rate post-compaction.

1. Completion integrity rules — "Never claim completion without tool output proving it" survives ~30 minutes, then summaries start mixing verified facts with inferred claims using identical confidence.

1. Coordination rules — "Check session_state.md before touching any database" is forgotten by message 50. Tabs duplicate SQL applications silently.

1. Build procedures — "Never use cmd.exe batch files from bash — they fail silently. Always use _build_ps.ps1" gets overridden by training data that says .bat files work fine.

I'm up for the before/after test. Our setup is a good stress test: ~300 line CLAUDE.md, 27 linked memory topic files, C++/SQL codebase with non-obvious column names, and we track compliance quantitatively already. The constraint set is public in our repo if you want to look at the actual rules before designing the test.

On head vs. tail position for constraints (re: @junaidtitan's question): Our experience is that CLAUDE.md instructions at the TOP of the file survive longest — they're in the highest-attention region during initial context loading. But after compaction, position doesn't seem to matter because the compaction summary is a narrative that flattens positional emphasis. The InstructionsLoaded hook approach that fires specifically at compaction time is the most promising angle we've seen — it targets the exact moment context resets.

@junaidtitan — haven't tested Cozempic yet but the progress-collapse strategy addresses a real problem we see (#19040 — multi-GB session files from normalizedMessages duplication). The behavioral digest concept (scan session for rules/corrections, compress, re-inject at tail) is interesting. Our current approach is manual: memory/ directory with topic files that are always loaded. The difference is yours would capture _session-learned_ constraints, not just pre-written ones. That's a gap in our stack. Will give it a try.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.