Is Claude Becoming Less Responsive? Count the Lines in Your Configuration File

After using Claude Code for several months, you may notice that your CLAUDE.md file keeps growing longer while Claude seems to forget rules—adding IMPORTANT doesn’t help, rephrasing still leads to mistakes, and changing formats results in errors. You might start to wonder: has AI regressed? Or are my prompts just not good enough?

The truth is neither. Your configuration file is overloaded.

A number that is rarely mentioned: Claude Code can reliably execute about 150 commands, but its own system prompts already consume around 50 of that capacity. This means your CLAUDE.md effectively has only about 100 usable slots left.

When overloaded, Claude isn’t intentionally ignoring your commands; it simply can’t process any more.

Wishlist vs. Technical Brief: Your Writing Direction Might Be Wrong

Overloading is just a symptom; the deeper issue lies in the direction of your writing.

Most people treat CLAUDE.md as a “wishlist” for AI—“Please think like a senior engineer,” “Code should be simple and elegant,” “Please take every task seriously.” While these sound reasonable, they provide no incremental information. Claude won’t become smarter just because you wrote “please be smarter,” just as an ERP system won’t automatically be accurate just because you wrote “please be accurate” in its configuration.

There’s a core principle in Context Engineering called Minimum Viable Context (MVC): find the smallest high-signal token set necessary for the model to succeed. It’s not about having more; it’s about being more precise. Every line you add to the limited “RAM” consumes attention resources, and low-signal content can drown out high-value rules.

An effective CLAUDE.md should resemble a “technical brief,” containing only three types of content:

1. Information that cannot be inferred from the code (selection reasons, agreed sources, common pitfalls)
2. Rules that, if removed, would cause Claude to make specific errors
3. A clear “do not do” list

The only test is: If you delete this line, will Claude make a mistake? If the answer is “yes,” it’s worth keeping.

Prompt engineering has long proven that the problem is never with AI being dumb; it’s about ambiguous instructions. Phrases like “you are a senior engineer” won’t make Claude smarter; they will only waste your limited quota of 100 commands.

Three Steps to Rebuild Your CLAUDE.md (with Real Cases)

Step 1: Count the Lines to Know Where You Stand

Open your CLAUDE.md in a text editor to check the total line count. Aim to keep it under 80 lines; 200 lines is the functional limit—beyond that, Claude will start to forget rules. If you’ve exceeded 80 lines, today is a good day to start rewriting.

Step 2: Restructure Content into Five Chapters

A tested effective five-chapter structure:

• Key Commands: Commands for building, testing, and type checking (this is the most important context that Claude cannot infer from the code)
• Architecture Diagram: Key directories and responsibilities (2-5 lines are sufficient; a complete README is unnecessary)
• Hard Rules: ≤15 rules, each must withstand the “delete and see if it causes an error” test
• Workflow Preferences: Claude’s working style (“ask before modifying, do not refactor unrelated code”)
• Do Not Do: A clear exclusion list to prevent Claude from taking liberties

Step 3: Review Each Rule and Boldly Delete

Go through your existing rules using the testing standard. Especially delete:

• Personality Instructions (“you are a…")—these won’t make Claude smarter; they just waste your command quota
• Formatting Rules Already Covered by Linters—let tools handle tools; don’t let Claude redundantly enforce formatting
• Global Rules Already Established—move general rules to ~/.claude/CLAUDE.md, keeping only project-specific content in the project file
• Preferences Already Remembered by Memory—check /memory first; don’t repeat what Claude already knows in the file

Real Case: What My Knowledge Base CLAUDE.md Looks Like

When maintaining my AI learning knowledge base, my CLAUDE.md core structure looks something like this:

• Startup Rules: Route based on trigger methods (Skill trigger / status query / daily conversation); this is a behavior path that Claude cannot infer from the code, and if deleted, Claude will perform a global load every time.
• Knowledge Source Limitations: “Only read from wiki/** three domains, prohibit mixing in training knowledge”—if this line is deleted, Claude will immediately start giving random answers using training knowledge, so it must be kept.
• Core Constraints: 4 rules, each corresponding to a specific scenario, each with verifiable completion standards.
• Reference Materials: Only write “on-demand loading paths,” not the entire document stuffed into context.

No personality instructions, no formatting fluff, no “please take seriously.” Every line has a specific reason for being there.

Advanced Tip: Two-Tier Structural Reduction

If you use Claude Code across multiple projects, there are two ways to fundamentally reduce the burden on your CLAUDE.md:

• Three-Tier File Separation: Move cross-project common rules to global ~/.claude/CLAUDE.md, keeping only project-specific content in project files, naturally making each layer more concise.
• Skills Reduction: Detailed steps for specialized workflows can be moved to Skills. Skills load on demand in three tiers, injecting precisely when triggered, and do not consume command budget when idle—effectively shifting some burden from “permanent memory” to “on-demand read disk.”

Note: Some rules in CLAUDE.md can never guarantee 100% execution (execution rate around 70-90%)—these types of rules are better suited for Hooks to enforce. CLAUDE.md writes “suggestions,” while Hooks enforce “must”; the two are not substitutes but rather divisions of labor.

The Compound Effect of CLAUDE.md: The More You Maintain, the Easier It Gets

A perspective that is rarely mentioned: CLAUDE.md is not just a configuration file; it is a living document with a compounding effect.

In the first month, it saves you from repeated explanations; by the third month, when Claude makes a mistake, you add a rule to prevent that mistake; by the sixth month, it has automatically recorded every mistake Claude has made in your project and continues to intercept them. The longer it runs, the less intervention you need.

This is similar to the logic of launching an IT system in a company. In my 16 years of enterprise informatization, configuration systems never include “please execute accurately”—they only state, “trigger replenishment when inventory falls below safety stock” or “allow outbound when document status is approved.” Systems don’t need to be incentivized; they need to be correctly configured.

Claude is the same. CLAUDE.md is not a declaration of your expectations for AI; it is a configuration file for the system.

Now, open your CLAUDE.md and count how many lines it has. If it exceeds 80 lines, today is a great day to rewrite it. What rules in your CLAUDE.md are essential enough that “deleting them would lead to errors?” Let’s discuss in the comments—I’m curious about which rules are truly essential in different scenarios.