Claude Code performance degrades when context quality drops — not just when the context window fills up. Most developers experiencing inconsistent results from Claude Code have the same problem: too much in the context, too little of it useful. A bloated CLAUDE.md, an auto-capture memory tool running in the background, five MCP servers connected "just in case" — each one adds noise that Claude Code has to process before answering your actual question. The fix is not better tools. The fix is fewer, better-chosen inputs.
Not more context. Better context.
This article draws from two real projects: florianstangl.com, a personal site rebuild using Astro and a custom SCSS design system, and a significantly more complex client platform. The same degradation pattern appeared in both. It was more visible in the complex project, where the signal-to-noise ratio mattered more.
What "Claude Getting Worse" Actually Means
Claude Code does not randomly degrade. The degradation has a pattern: responses become generic where they were once specific, earlier project decisions get ignored, and Claude Code starts re-asking questions it already answered in prior sessions. Developers report this as Claude Code "forgetting things" or "getting dumber over time." The cause is almost never the model. It is almost always the context.
Claude Code evaluates every session against whatever is in its context at the time. When the context contains high-quality, specific, stable information — project architecture, naming conventions, hard constraints — responses reflect that specificity. When the context contains noise — stale instructions, auto-captured tool history, redundant MCP server descriptions — Claude Code spends processing capacity on material that does not improve the answer.
On the more complex client project, the degradation became traceable. Sessions that started with a clean, minimal context produced consistently specific responses. Sessions that inherited a noisy context from prior tool integrations produced responses that were technically correct but architecturally uninformed — the kind of answer that solves the immediate question and breaks something adjacent. In a simpler project like florianstangl.com, the same noise created friction. In a complex project, it created regressions.
The distinction matters: context window exhaustion — context window full, performance drops — is the problem most guides address. Context quality degradation — context window has space, but it is full of low-signal content — is the problem most developers are actually experiencing.
Why Context Quality Beats Context Size
Claude Code generates responses by processing every token in the current context. A 50,000-token context full of relevant, curated information produces better responses than a 20,000-token context containing instructions Claude Code could derive from reading the codebase, session history from three weeks ago, and tool descriptions for servers that have not been used in this session.
Context quality is the ratio of useful signal to total tokens. Low-quality context is not an abstract concern — it is directly observable as responses that address the surface of a question rather than its actual constraints. Claude Code with high-quality context knows the project uses BEM naming with a c- prefix and never asks. Claude Code with low-quality context asks, guesses, or defaults to a generic pattern.
The practical implication: before adding anything to a Claude Code setup — a new CLAUDE.md rule, a memory tool, an MCP server — the useful question is not "could this be helpful?" but "does this provide information Claude Code cannot derive from the code itself?" Derivable information is noise — with one exception: constraints Claude Code consistently gets wrong without being told, even when technically visible in the code. Non-derivable, stable, project-specific information is signal.
Three categories of content consistently degrade context quality:
- Derivable instructions — naming conventions readable from any existing file, architecture patterns visible in the directory structure, technology choices obvious from package.json
- Temporal context — in-progress task state, session history, notes about what you were working on last Thursday
- Speculative rules — instructions for scenarios that have not occurred and may not: "if we ever add authentication, remember to..."
All three feel useful when written. All three add noise in practice.
What Belongs in Your CLAUDE.md — and What Does Not
CLAUDE.md is a persistent instructions file that Claude Code reads at the start of every session. The file has one purpose: to provide project-specific, non-derivable information that Claude Code needs but cannot get by reading the codebase. Everything else is overhead.
The most common mistake is treating CLAUDE.md as a comprehensive onboarding document. It is not. It is a constraint list. The question for every line in CLAUDE.md is: would Claude Code get this right without being told? If yes, remove it.
Include in CLAUDE.md | Leave out of CLAUDE.md |
|---|---|
Non-standard build commands | Technology stack (readable from package.json) |
Hard constraints Claude Code regularly violates | Naming conventions visible in every file |
Workflow steps not obvious from the codebase | Architecture patterns clear from directory structure |
Non-negotiable output requirements | General best practices Claude Code already knows |
Domain-specific rules that deviate from standard patterns | Instructions for hypothetical future scenarios |
External system URLs not visible in the code | Anything that changes session to session |
A CLAUDE.md that fits on one screen and contains only the left column will outperform a 400-line CLAUDE.md mixing both. Longer is not more thorough — it is more noise.
On florianstangl.com, CLAUDE.md contains build commands, the SCSS import order, the BEM prefix convention (because c- is non-standard and Claude Code defaults to no prefix without being told), deployment instructions, and external service references that are not visible in any tracked file. Everything else is derivable. During a phase when CLAUDE.md was expanded with architecture notes, content guidelines, and general principles, sessions produced noticeably less precise responses. The file was trimmed back. Precision returned.
The signal-to-noise test applies to every line on every review: if removing the line would not change Claude Code's responses on a well-structured project, the line does not belong.
How Memory Systems and Auto-Capture Tools Work Against You
The concept behind AI memory tools is sound: preserve context across sessions so Claude Code remembers past decisions, current project state, and constraints that have been established over time. Most implementations trade context quality for context volume.
Auto-capture memory systems record tool usage, file reads, and session activity into a searchable store that gets injected into future sessions. The problem is that captured history is almost entirely low-signal: what files were read, what commands ran, what Claude Code said three sessions ago about a file that has since changed. Volume is high. Relevance per token is low. The net effect on response quality is negative.
Manual, curated memory — specific facts about the project that are not in the code, architectural decisions made with explicit reasoning, constraints that matter long-term — produces the opposite outcome. Signal density is high. Every injected fact improves the response.
The tool marketed as giving your AI a memory was the thing making it forget how to think.
This is not an argument against persistence across sessions. It is an argument for discipline about what gets persisted. Two questions decide whether something belongs in a memory system: is this fact stable enough to still be true next session? And is this fact non-derivable from the current state of the code? Both answers must be yes. If either is no, the fact is noise waiting to be injected.
The developers who benefit most from auto-capture tools are those starting from zero with no memory discipline. Auto-capture is a floor, not a ceiling. If a curated, high-signal memory system is already in place, auto-capture adds noise to something that was working.
The MCP Server Problem Nobody Mentions
Model Context Protocol servers extend Claude Code capabilities by providing tools: search, database access, external APIs, analytics platforms. Each connected MCP server registers its tool names in Claude Code's context at the start of every session. Claude Code uses a deferred loading pattern — full parameter schemas load on demand rather than upfront — but the tool names themselves are always present and always require reasoning through.
The cost is not primarily token volume. The cost is tool selection noise. When the active tool list is short, the correct tool for a task is obvious. When the active tool list contains 150 names across seven connected servers — which is a realistic count for a developer with research, analytics, database, and deployment servers all connected — Claude Code has to reason through more options to identify the right one. Adjacent, plausible-looking alternatives increase. Routing precision decreases.
A concrete example: one search server means "search" maps to one tool. Three connected servers that each offer some form of search or lookup means every search decision requires Claude Code to evaluate which server's tool is most appropriate for this specific query. The overhead is small per decision. Across a full session of dozens of tool calls, it accumulates.
The right number of connected MCP servers is the minimum required for the current project phase. A server added for a one-time research task and never disconnected is a tax on every subsequent session. A server connected because it might be useful is context noise with an ongoing subscription.
The useful audit question is not "what does this server do?" — it is "when did I last actively use a tool from this server, and would I have noticed if it had not been there?"
How to Audit Your Claude Code Setup
This audit takes fifteen minutes and consistently surfaces the highest-impact changes. Run it at the start of a new project phase, or whenever Claude Code responses feel less precise than they used to.
Step 1: Audit CLAUDE.md
Read every line and apply the derivability test: can Claude Code get this right by reading the codebase, without being told? If yes, delete the line. What should remain after this step: non-standard build commands, hard constraints Claude Code regularly breaks without them, and external system references not visible in any file. Target length after the audit: under 80 lines. Every line past 80 is a candidate for deletion.
Step 2: Audit Connected MCP Servers
List every connected MCP server. For each one, identify the last task where a tool from that server was directly used. If the answer is "I cannot remember" or "not in the last two weeks," disconnect it. Reconnecting takes thirty seconds. The session-by-session cost of leaving it connected accumulates faster than it appears.
Step 3: Audit Your Memory System
If using a memory system, scan the last ten entries. For each entry: is this fact still true? Could Claude Code derive it from the current code? If stale or derivable, remove it. A memory system with fifty stale entries is worse than no memory system — it actively misleads on every session it runs.
Step 4: Check Session Hygiene
Identify when /clear or /compact was last used in Claude Code. For tasks spanning multiple sessions, context from earlier sessions carries forward unless cleared. If the current task is substantially different from the prior session's task, clearing before starting prevents earlier context from interfering with the current one.
Step 5: The Single-Screen Test
Everything Claude Code needs to know about the project that is not in the code should fit on one screen. If it does not, the setup has accumulated overhead. The question is not what to add — it is what to cut.
After completing this audit on the complex client project, three MCP servers were disconnected, CLAUDE.md was reduced from 340 lines to 78, and the memory system was trimmed from 200 entries to 31. Session response quality improved within two sessions — responses became specific to the project's actual architecture rather than technically correct but contextually generic answers.
Frequently Asked Questions
Why does Claude Code get worse over time?
Claude Code performance degrades when context quality drops across a session or between sessions. The most common causes: a CLAUDE.md that has grown beyond non-derivable instructions, an auto-capture memory tool injecting stale session history, too many MCP servers adding tool names that increase routing noise, and infrequent use of /clear between unrelated tasks. The degradation is not the model — it is the context the model receives.
What should I put in CLAUDE.md?
CLAUDE.md should contain only information Claude Code cannot derive from reading the codebase: non-standard build commands, hard constraints Claude Code regularly violates without being told, external system references not visible in any file, and project-specific deviations from standard patterns. Everything derivable from package.json, directory structure, or existing file contents belongs outside CLAUDE.md.
How many MCP servers should I use with Claude Code?
The minimum needed for the current phase of work. Each connected MCP server adds tool names to Claude Code's active tool list, increasing routing noise before the first prompt. Disconnect servers that have not been actively used in the last two weeks. Reconnecting takes under thirty seconds.
How do I make Claude Code perform better on complex projects?
Complex projects amplify context quality problems — the more moving parts in a codebase, the more Claude Code depends on its context being accurate and specific. The highest-impact actions: trim CLAUDE.md to only hard constraints and non-derivable instructions, maintain a manually curated memory system rather than relying on auto-capture, and use /clear between distinct task types within a session.
Does the CLAUDE.md file affect Claude Code performance directly?
Yes. Claude Code reads CLAUDE.md at the start of every session and applies it as a constraint layer over its responses. A CLAUDE.md with high-signal, specific instructions produces precise responses. A CLAUDE.md with derivable, generic, or outdated instructions adds noise to the context. Signal density matters more than file length — 20 lines of hard constraints outperforms 300 lines mixing constraints with derivable observations.