Claude Code Got Worse Over Time? Diagnose It by Symptom

It works beautifully for two weeks. Then it starts forgetting things. Then it starts confidently doing the wrong thing. Nothing changed on your side, and that is the part that makes it feel like the model got worse.

The model did not get worse. Your setup accumulated.

I wrote up six failure modes and the mechanism that fixes each one. That post is organised by mechanism: here is the failure, here is the hook. This one runs the other way round, because when your setup breaks you do not know which of the six you have. You have a symptom.

So: find your symptom, run one command to confirm it, then fix the right thing instead of the first thing.

Start Here: What Does It Actually Do Wrong?

Work down that list in order, and resist skipping to the interesting one. The order is not arbitrary: it runs cheapest-confirmation-first, so you spend a minute ruling things out rather than an afternoon rebuilding a memory layer that was never the problem. The first three cover most cases.

One warning before you start. These six overlap, and treating a symptom as proof of a single cause is how people end up fixing the wrong thing confidently. Rule saturation and prompt bloat are the same underlying growth measured two different ways. Stale memory and context poisoning both look like "it believes something untrue". Confirm before you fix, every time, because the confirmation steps below take about a minute each and a wrong fix costs an evening.

It Forgets Decisions From Last Week

This is the easiest one to misdiagnose, because it looks like a model problem and is almost always a storage problem.

Claude Code starts every session cold. Whatever it knew last Tuesday exists only if something wrote it down and something reads it back. If you have no memory layer, the answer is simply that there is nothing to forget.

If you do have one, the failure is usually the opposite of what people expect. It is not that memory is missing. It is that memory never expires, so a decision you reversed three weeks ago is still sitting there being read as current.

Confirm it: open your memory file and look at the oldest entry. If you find things you no longer do, that is your answer. Memory that never expires does not go quiet, it starts lying.

Fix: archive on an age-and-use rule rather than deleting, and re-read the active project at the start of every session. Details in the stale project memory section, and the full architecture in the memory system deep dive.

It Forgets Things From Twenty Minutes Ago

Different symptom, completely different cause, and the distinction matters: this one happens inside a single session.

When a session runs long, Claude Code compacts. Anthropic's cost documentation describes it plainly: auto-compaction "summarizes conversation history when approaching context limits". Summaries are lossy by definition. The specific constraint you gave at minute 5 becomes "the user described some requirements" at minute 90, and the agent proceeds without it.

Confirm it: scroll back and find the point where compaction happened. If the thing it forgot was said before that point and not after, you have found it.

Fix: get load-bearing decisions out of the conversation and into a file before the session gets long. Anything that exists only in chat is something compaction is allowed to drop. See compaction drift, and context management for the wider picture.

It Got Slower and More Expensive

This is the one people feel first and diagnose last.

Every turn re-sends your context: the system prompt, your claude(.)md, your rules, whatever memory got injected, the tool definitions of every MCP server you have connected. That is not a one-off setup cost, it is a per-turn cost, and it grows every time you add a rule or connect a server. Anthropic states the relationship directly: "Token costs scale with context size: the more context Claude processes, the more tokens you use."

I measured my own usage over 60 days and 326 sessions, ending July 2026. The shape surprised me:

Almost none of the cost was the thing I was actually asking for.

Confirm it: run /context in a fresh session, before you ask for anything. That number is your floor. You pay it on every single turn of every session, whether or not any of it is relevant.

Fix: load knowledge when a turn needs it instead of always. That is the prompt bloat fix, and Anthropic makes the same argument in its context engineering guidance: just in time, not just in case.

It Ignores Rules That Are Right There

Usually the same disease as the last one, wearing a more annoying costume.

Rules do not fail because the agent cannot see them. They fail because there are now ninety of them, half contradict each other, and the important three are structurally indistinguishable from the trivial eighty-seven. Adding emphasis to a rule that is being ignored is the intuitive move and it does not work, because the previous forty rules were also marked important.

A concrete version from my own setup: my always-loaded memory file grew until it was about to cross the size limit that governs whether it gets read at all. It had not stopped being useful. It had stopped fitting.

Confirm it: check the byte size of the file, then run /context and look at how much of the window is spent before you have typed anything. Then read your own rules end to end and count how many you have actually followed this week.

Fix: delete rules rather than emphasising them. A rule nobody can act on is noise that makes the actionable ones harder to find.

It Spawns Agents for Everything

Subagents got much better in 2026, and the new failure is using them for work that never needed the overhead. Per Anthropic's subagent docs, each one runs in its own context window and takes maxTurns, hooks, mcpServers and isolation as configuration, so the old reasons to avoid them are gone. Those specific option names are the ones documented as of 31 July 2026, and this is the part of Claude Code that changes fastest, so check the page rather than trusting this sentence in six months.

Every spawn pays a setup cost before it does anything useful. In the same 60-day sample that prefix ran to roughly 31,000 tokens per spawn, so three small parallel agents can cost more than doing the work inline while producing three reports you then have to read.

Confirm it: pick one real session and count the spawns. Then ask, per spawn, whether the answer needed an isolated context or whether you just liked the idea of parallelism.

Fix: delegate on genuine independence, not on enthusiasm. Bundle related lookups into one agent rather than fanning out three. See over-delegation and the score-based routing approach.

It Is Confidently Wrong the Same Way

A repeating, specific wrongness is the useful kind, because randomness points at the model and a pattern points at your inputs.

Something false is being loaded on every turn. A stale rule, an outdated memory, a hook injecting a claim that was true in April. The agent is behaving correctly given inputs you cannot see.

The tell is consistency. If it reaches for the wrong library, names a file that moved months ago, or keeps applying a convention you abandoned, that is not the model guessing. Something is telling it. Models are stochastic; your injected context is not, and the reliable wrongness is coming from the deterministic half.

Confirm it: find the exact wrong belief, state it in one sentence, then grep your rules, memory and hook output for it. It is in there. If you cannot find it in text, check what your hooks emit at runtime rather than what their source says they emit, because those two drift apart quietly.

If the belief is about Claude Code's own behaviour rather than your project, check whether it is a known issue before assuming your setup is at fault. The claude-code issue tracker is public, and searching it takes less time than the rebuild you were about to start. Also worth knowing what memory Claude Code loads on its own, which the memory docs set out.

Fix: treat everything that gets injected as content with an expiry date, the same way you treat a cache. See context poisoning.

The Pattern Underneath All Six

Every one of these is something that grows while nothing prunes it.

None of it announces itself, because each addition is individually reasonable and the system degrades smoothly rather than breaking. Which is why it feels like the model got worse: smooth degradation with no error message is indistinguishable, from the inside, from a tool that is quietly getting dumber.

The habit worth building is small. Run /context in a fresh session once a week and write the number down. When it climbs, something got added. That single number catches three of the six failure modes above before you feel them.

If you want the mechanism for each fix rather than the diagnosis, that is the six failure modes post.