CLAUDE.md Size: Limits, Useful Length, and What to Cut

A useful CLAUDE.md is short enough that every instruction matters to the work it applies to. Its technical file ceiling, recommended instruction length, and the separate loading rules for auto memory are different things; fitting under a ceiling does not make a long file effective.

Keep stable repository guidance in the instruction file, and give changing tasks and project history another home. Tools like fenbs hold the current work record, so yesterday’s debugging log does not become permanent reading for every new coding session.

Which kind of size limit are you checking?

Anthropic’s memory documentation↗ (opens in a new tab) distinguishes a CLAUDE.md file-size ceiling, a recommended line target, and startup cutoffs for the separate MEMORY.md auto-memory index. Follow the current figures there. They describe different mechanisms and should not be copied into one universal “Claude memory limit.”

A file with short bullets can be easier to use than a shorter file containing dense paragraphs. Conversely, adding blank lines changes the line count without adding instruction. Treat length as a reason to review the content, not as the final judgment about its quality.

How do you decide which lines earn their place?

Ask what mistake becomes more likely if you remove the line. An unusual test command, an architecture boundary the code does not explain, or a recurring project trap can justify permanent space. A list of every installed dependency usually has a more current source in the repository itself.

Anthropic’s Claude Code best practices↗ (opens in a new tab) recommend concise, specific guidance rather than a generic coding manual. Use that principle as an editing test: preserve instructions that explain a meaningful difference in this repository, and question text that merely restates common advice.

• Keep the command that runs the relevant checks when it is easy to guess incorrectly.
• Keep a boundary such as “generated client files must be rebuilt from the schema.”
• Keep a warning whose reason is not visible from the code.
• Move task status, lengthy incident history, and superseded implementation plans out of permanent instructions.
• Remove a duplicated rule only after confirming where the current authoritative version lives.

For concrete writing patterns, see CLAUDE.md examples. The question here is how much belongs in the file, rather than choosing a complete file format.

Why does splitting a file not always reduce its cost?

A smaller visible file can still load a large amount of text. Anthropic notes that imported instruction files also consume context; moving paragraphs into imports organizes them without necessarily reducing what loads. Check the documented loading behavior before treating a split as a saving.

Make a distinction between material always supplied and references consulted for a particular task. A database procedure used occasionally should not need to occupy the same permanent space as the rule that generated files must not be edited. The reference still needs a clear name and a reliable way to find it when relevant.

For procedures repeated on demand, Anthropic documents Claude Code skills↗ (opens in a new tab), whose detailed instructions load when used. Choose the location according to when information is needed, rather than breaking up text just to make the root file look smaller.

The guide to CLAUDE.md hierarchy owns the details of where instructions apply. When measuring size, count the instructions the actual session receives, including overlapping files, instead of reviewing only one filename.

What should move out first?

Start with rapidly changing information. “The payment test is failing because the fixture is outdated” belongs with the task until it is resolved. It is poor permanent guidance because a future session could follow it long after the fixture is fixed.

Next, move long explanations that only a narrow kind of work requires. Keep the essential rule and the reason a person needs to notice it, then put the full procedure in a maintained reference. A short pointer should say when to read the reference, not merely announce that more documentation exists.

Do not replace clear instructions with unexplained shorthand. “No direct API calls; use service layer” is concise only if the service layer is easy to identify. A short path and one reason may save more confusion than several lines of compressed internal abbreviations.

Changing tasks, decisions, and session handoffs can live in fenbs through its AI context workflow. The repository file can then explain how to start the work without carrying the entire record of what earlier assistants did.

How can you shorten the file safely?

1. Read the file alongside the guidance it imports or overlaps. Mark contradictions before deleting either side.
2. Label each entry as a stable rule, an occasional procedure, reference information, or current work state.
3. Remove stale statements and move changing work state to its maintained project record.
4. Rewrite vague advice as an observable instruction, keeping any exception that changes its meaning.
5. Review a representative task with the revised file and confirm that the important boundaries and checks remain clear.

Choose tasks that exercise different risks. A documentation change may confirm the basic start-up instructions but tell you little about a release boundary. Ask a teammate to read the result too: a file that makes sense only to its original author still depends on missing context.

If instructions appear to disappear, investigate CLAUDE.md not working before cutting more text. The wrong working directory or an unloaded rule is a different problem from excessive instruction length.

How to do this with fenbs

1. Create a free account and add the project represented by your repository.
2. Move the current task state into tasks, including the next action and any unverified result. Record a person’s lasting project choices in Decisions and rules.
3. Connect Claude Code through the integration guide and ask it to read the project context before working.
4. Keep the repository instructions focused on stable conventions, commands, and how to find relevant references. Save each session’s progress back to the project.

fenbs does not replace repository instruction loading or enforce coding rules inside Claude Code. If you only need a few stable instructions for a single repository, a maintained local file may be enough; an outside work record helps when tasks and handoffs keep expanding it.

What is the right stopping point for editing?

Stop when the remaining content is accurate, consistent, and useful for the sessions that receive it. Do not keep cutting to reach an arbitrary score if that removes a hard-to-discover constraint. A clear exception earns its space when it prevents a real misunderstanding.

Review growth when the workflow changes or a repeated mistake suggests missing guidance. Add the smallest durable rule that solves the problem, rather than appending the whole incident. The context engineering hub covers the broader job of giving an assistant the right information at the right time.