The answer first, the reasoning after
Do not want to read the whole thing? Copy the 5 prompts below into Claude Code. It reads your CLAUDE.md, tells you what to change, and waits for your OK before touching anything. The article then explains why each one saves tokens and how it works.
★One-shot full checkup (start here)
Open Claude Code in your project root and paste the whole block below. It runs every check from all 4 methods, and lists each change before making it, waiting for your OK.
Run a checkup on this project's CLAUDE.md. The goal is to cut context token use. Do it in this order:
1. Run `wc -l CLAUDE.md` and tell me the current line count
2. Scan for comments starting with # that are written for people (history, reasons, context)
(not the rules themselves, the ones explaining why a rule exists)
List them, then rewrite them as <!-- --> block comments
3. Find rules that only apply to one kind of file
(for example only to API code, front-end components, SQL migrations)
Split them into separate .claude/rules/xxx.md files, add a paths field in the YAML frontmatter bound to a glob
Delete the moved parts from the main CLAUDE.md
4. Check for long sections (git workflow, style guides) that belong in an external file pulled in with @path
5. After all the edits, run `wc -l CLAUDE.md` again and tell me the difference
List the plan before each step and wait for my OK. Follow the rules in https://code.claude.com/docs/en/memory.
What you get: A change plan plus a before and after line count. Claude works step by step, no sweeping edits.
How long: Depends on how big your CLAUDE.md is, usually 10 - 30 minutes in one pass.
1Hide the history comments (5 minutes, the fastest win)
Scan my CLAUDE.md and rewrite every human-facing comment that starts with # (history, who decided what, why a rule exists, context written for people, not the rules themselves) as a <!-- --> block comment.
List the sections you found before changing anything and wait for my OK. When you are done, run `git diff CLAUDE.md` so I can check.
2Load rules only when the matching files are touched (saves the most)
Some rules in my CLAUDE.md only apply to certain kinds of files (only to src/api/, only to React components, only to SQL migrations).
Split those rules into separate files under .claude/rules/, each with YAML frontmatter:
---
paths:
- "the matching glob"
---
Delete the moved rules from the main CLAUDE.md. Give me the split plan first (which group becomes which file, what paths says) and wait for my OK.
Rule format: https://code.claude.com/docs/en/memory
3Trim CLAUDE.md once it passes 200 lines
Run `wc -l CLAUDE.md`. If it is over 200 lines, analyse it for me:
1. List the line count of every major section
2. Find the sections best moved out:
- History and context, wrap in HTML comments <!-- -->
- Tied to one kind of file, move to .claude/rules/
- Long examples / full workflows, move to docs/ and pull back with @path
3. Estimate how many lines are left after the cuts
Give me the list of suggestions first, I will pick which ones to do.
4Move long cross-project sections out (@import)
Find the content in my CLAUDE.md that is long and applies across projects (git workflow, personal code style preferences, commit conventions).
Move it to external files and pull it into the main file with @path:
- Cross-project personal preferences: move to ~/.claude/xxx.md, use @~/.claude/xxx.md
- Project-level detail: move to docs/xxx.md, use @docs/xxx.md
List the sections you want to move and the target filenames first, then wait for my OK.
Heads-up: Claude Code follows the rules already in your CLAUDE.md, so if you have a rule like “ask me before editing a file”, it will ask. If you do not, watch the first run and confirm you agree with everything it touches.
How Opus 4.7 handles tokens(Official numbers from the Opus 4.7 period, Apr 2026. The current main model is Opus 5 and effort now has five levels, low / medium / high / xhigh / max, but the CLAUDE.md token-saving methods are unchanged)
Anthropic shipped Opus 4.7 on 2026-04-16, and the announcement says it outright:
The same input costs 1.0–1.35× tokens.
“The tradeoff is that the same input can map to more tokens—roughly 1.0–1.35× depending on the content type.”
Source: Anthropic announcement anthropic.com/news/claude-opus-4-7
The same announcement also says overall token use is net favorable on internal coding evals. 4.7 solves problems more efficiently, so the total comes out lower.
There is only so much you can do at the model layer. But the context layer is where you can act directly, CLAUDE.md. It loads in full the moment a session starts. Write it badly and you burn a chunk of tokens before the conversation even begins.
The 3 token controls Anthropic gives you (model layer)
The announcement spells out how 4.7 users can control token use:
“control token usage in various ways: by using the effort parameter, adjusting their task budgets, or prompting the model to be more concise.”
Source: Anthropic announcement anthropic.com/news/claude-opus-4-7
- The effort parameter in 4.7 adds
xhigh (between high and max), which lets you fine-tune reasoning depth
- Task Budgets (new in 4.7), set how long the model may think
- Prompt the model directly to “answer concisely”
All three are model-layer moves. There is one more layer people miss, the context layer. Every session start loads CLAUDE.md into the context window in full. Write it badly and you burn a chunk of tokens before the conversation even begins.
4 ways to write CLAUDE.md (each with before / after and why it saves)
Every rule here comes from Anthropic's official Claude Code memory docs, code.claude.com/docs/en/memory. The examples are copy-paste ready for your own CLAUDE.md.
1Wrap context written for people in <!-- --> block comments
Why it saves: Block-level HTML comments are stripped before the content is injected into Claude's context. The notes you write for your future self or a teammate, why this rule exists, ask before deleting it, cost nothing in tokens.
“Block-level HTML comments () in CLAUDE.md files are stripped before the content is injected into Claude's context.”
Source: code.claude.com/docs/en/memory
Before (bad), those two history notes load every single time
# Rules
# 2025-08-15: added because Sarah kept getting her PRs rejected
# Do not delete, checked with the Compliance team
- Always include type annotations on exported functions
# Mike thinks we may drop this one later
- Prefer `import type` over `import { type }`
After (good), both notes are stripped and Claude sees only the rules
# Rules
<!--
2025-08-15: added because Sarah kept getting her PRs rejected
Do not delete, checked with the Compliance team
-->
- Always include type annotations on exported functions
<!-- Mike thinks we may drop this one later -->
- Prefer `import type` over `import { type }`
Do it now: Run grep -n "^#" CLAUDE.md to find the human comments that start with # in your file today, and wrap them in <!-- -->.
Note: Comments inside ``` code blocks are kept. Open the file with the /memory command and you still see them. The content written for people is not gone, it just does not enter Claude's context.
2Use .claude/rules/ + paths for conditional loading (this one saves the most)
Why it saves: Put them in .claude/rules/*.md and add the YAML frontmatter paths field. The rules only load into context when Claude touches a file matching the glob. Front-end work does not load the API rules, API work does not load the front-end rules. Session start = 0 tokens.
Before (bad), everything in the main CLAUDE.md, loaded every session
# CLAUDE.md (main file)
## API rules (50 lines)
- All endpoints must validate input with zod
- Use standard error response from src/api/errors.ts
- ... 47 more lines
## React rules (50 lines)
- Functional components only, no class components
- Tailwind only, no CSS modules
- ... 47 more lines
## DB rules (50 lines)
- Migrations must be reversible
- ... 48 more lines
150 lines ≈ 1500 tokens, paid every session. Write front-end code and the back-end rules load anyway.
After (good), three files, loaded conditionally
# .claude/rules/api.md
---
paths:
- "src/api/**/*.ts"
---
- All endpoints must validate input with zod
- Use standard error response from src/api/errors.ts
# .claude/rules/react.md
---
paths:
- "src/components/**/*.tsx"
- "src/pages/**/*.tsx"
---
- Functional components only, no class components
- Tailwind only, no CSS modules
# .claude/rules/db.md
---
paths:
- "migrations/**/*.sql"
- "src/db/**/*.ts"
---
- Migrations must be reversible
How much you save: session start drops from 1500 tokens to 0. Editing the API pulls in only those 50 lines, the other two groups never load.
Do it now: Go through your CLAUDE.md and find the rules tied to one kind of file (API only, React only, SQL only, tests only). Put each group in its own file under .claude/rules/, write the matching glob in paths, then cut them from the main file.
3Keep every CLAUDE.md under 200 lines
Why it saves: CLAUDE.md loads into context in full at every session start. 600 lines ≈ 6,000 tokens, 200 lines ≈ 2,000 tokens, a gap of 4,000 tokens per session. Open 10 sessions a day and the gap is 40,000 tokens.
The docs also say that past 200 lines Claude follows the rules less closely.
Typical reasons a file passes 200 lines (trim these first)
- “Why this project exists / how we did it back in v1” history, wrap it with method 1 in
<!-- -->
- “Onboarding steps for new teammates”, move to
docs/onboarding.md
- “Rules tied to one kind of file”, split out with method 2 into
.claude/rules/
- Long examples / full git workflow / DB schema notes, move to
docs/ then pull them back in with @import from method 4
Do it now:
wc -l CLAUDE.md # how long it is now
grep -c "^#" CLAUDE.md # how many human comments start with #
Over 200 lines, trim along the 4 directions above, then run
wc -l to confirm.
4Use @path to split files (pairs with the structure from methods 2 and 3)
Honestly: @import pulls the content inline into context, so @import on its own does not cut tokens. Its value is a readable main file, sharing across projects, and moving long sections into sub-files (which you can later move into .claude/rules/ for conditional loading, which is where the real saving is).
Typical usage
# Project Rules
- 2-space indent
- Run `npm test` before commit
- API handlers in src/api/handlers/
@~/.claude/my-personal-style.md # shared across projects
@docs/git-workflow.md # detail moved out
The docs say @path recurses at most 5 levels (A imports B, B imports C, up to 5).
When to use it:
- Personal preferences shared across projects (home path
@~/...)
- Modular structure in the main file, easy to move out later to
.claude/rules/
When not to use it: Importing rules only to keep the main file tidy, token use does not change. To actually save tokens, use method 2 and split into
.claude/rules/.
The 4 methods ranked by token saving:
Method 2 (.claude/rules/ + paths) > Method 3 (200 lines) > Method 1 (HTML comments) > Method 4 (@import does not save directly)
Want a result today: do method 1 first (easiest, 5 minutes), then method 2 (biggest saving, 30 minutes).
Going further: Skills save more than Rules
Anthropic has a third layer: Skills. Used in the right place it saves more than rules.
| Mechanism | When it loads into context | Best for |
|---|
| CLAUDE.md |
Every session start (loaded in full) |
Rules Claude needs every day |
.claude/rules/ + paths |
When Claude reads a file matching the glob |
Rules tied to a specific kind of file |
| Skills |
When you invoke it, or Claude decides it is relevant |
Workflows you only need occasionally (complex tasks) |
“Rules load into context every session or when matching files are opened. For task-specific instructions that don't need to be in context all the time, use skills instead, which only load when you invoke them or when Claude determines they're relevant to your prompt.”
Source: Anthropic Claude Code documentation
Rule of thumb: always-on goes in CLAUDE.md, conditional goes in rules, on-demand goes in skills. Putting each at the right level is the saving.