A multi-file CLAUDE.md token budget is about where each rule lives, not how much each file weighs.

Every other guide on this topic answers the wrong question. They tell you how to add up your layered cost. That is arithmetic. The harder question, the one that actually changes your bill, is where each rule should live given that Claude Code loads from five different kinds of files with five different load frequencies. A rule pays tokens on every turn it sits in context, whether or not the turn needed it. The cheapest spend in a multi-file system is not deleting rules. It is moving them to a file that loads when they fire, and stays out of context the rest of the time.

1. The assumption baked into every analyzer

Open src/lib/analyzer.ts and look at line 264. The ccmd analyzer, the one behind the textarea on ccmd.dev, makes one assumption to turn token count into a cost:

One line: estimatedTokensFireEveryTurn = totalTokens. Every token in the file you pasted, multiplied by every turn that file is in context. That is true for the file you pasted, by definition. It is not true for every file Claude Code loads. Half of the files in a real Claude Code setup fire less than every turn. The analyzer can only score the file in its textarea. The allocation has to happen in your head, and the framework is the rest of this page.

2. Each file has a fire rate. Match it to the rule's scope.

Nine places a CLAUDE.md-shaped rule can live, with the fire rate of each and the kind of rule that should sit there. Read left to right. A mismatch between the right column and the left is your token leak.

Two practical reads from this table. First, the top six rows all have the same fire rate: every turn. Moving a rule from one of those rows to another row above the line does not save you a single token. The decision is binary: above the line is "every turn," below the line is "conditional." Second, the bottom three rows are the only allocation moves that actually shrink your per-turn floor. A rule that only matters when you are working in api/ belongs in api/CLAUDE.md, not in ./CLAUDE.md.

3. A worked example: 4,900 tokens per turn, no rules deleted

A realistic ./CLAUDE.md in a small monorepo, 6,200 tokens, six sections. The audit asks the same question for each section: what is the smallest scope that needs this rule? Move it to the file whose fire rate matches that scope.

The interesting part of the example is what did not change. The user file still loads in every repo on the machine. The 1,300 tokens of house-style rules in ./CLAUDE.md still fire on every turn. The audit moved rules whose scope was narrower than the file they lived in. That is the only allocation move that creates savings; everything else is rearranging the same spend.

4. Three traps that look like budget moves but are not

Trap one: splitting into @import files. Anthropic's memory docs are explicit: imports expand inline at launch, "does not reduce context." A three-line root file that pulls in three 2,000-token files costs 6,000 tokens a turn. The import line is for organization. It is not a budget tool.

Trap two: nesting without on-demand. A guide that says "nest your CLAUDE.md files to save tokens" and does not name the subtree-read trigger has flattened two mechanisms into one. Nested files save tokens only because subtree reads gate their load. A nested file in a subtree you always touch is not free; it is full price after the first turn.

Trap three: deleting rules that should have been moved. The instinct after running an analyzer is to cut the worst-scoring lines. Sometimes that is right. Often the line is fine and the file is wrong: a useful migration warning in your ~/.claude/CLAUDE.md should not be deleted, it should be moved to the one repo where the migration matters. Cutting deletes a rule. Rehoming keeps the rule and removes the unused turns.

5. How to run the audit on your own files

Four steps, no signup, no upload. The analyzer is one-file-at-a-time on purpose; the allocation logic is yours to apply.

1. Paste ~/.claude/CLAUDE.md into the analyzer. For every rule, ask: does this rule belong on every machine you own, in every repo on it? If the answer is no, it does not belong in the user file.
2. Paste your project ./CLAUDE.md. For every rule, ask: does this rule fire in every session in this repo? If the answer is "only when working on X," it belongs in X/CLAUDE.md (if X is a directory) or a path-scoped rules file.
3. For every rule that is procedural (release, ship, set up, audit), check whether it belongs in a skill instead. Skills load only when invoked. A 600-token release runbook in ./CLAUDE.md fires every turn of every session for a workflow you run once a week.
4. Re-run the analyzer on each file after rehoming. The numbers will still feel high. They will be honest about what is in your per-turn floor versus what is conditional, and the gap between the two is the budget you got back.

One closing precision note. The analyzer counts characters, and Claude Code strips block HTML comments before injecting a file, so maintainer notes wrapped in <!-- ... --> score slightly high per file. That is a rounding error compared to the wrong-file problem. A 1,400-token rule that fires on every turn but only matters in one subdirectory is 1,400 tokens × 29 unused turns × 30 sessions a month of waste. Rounding errors do not compound. Allocation mistakes do.