You are not training Claude Code with CLAUDE.md. You are renting prompt space from yourself, by the turn.

No. CLAUDE.md never enters model weights and is not part of any training pipeline. It is a Markdown file the Claude Code harness reads at session start and pastes into the system prompt of every API call to the Messages API. The model has no persistent memory of your file between turns; it only sees the copy that arrives inside the current prompt. That copy is re-sent on every turn, which is why our analyzer at src/lib/analyzer.ts line 264 sets estimatedTokensFireEveryTurn = totalTokens. The word 'training' is a useful shorthand for 'I am teaching Claude how to behave on my repo', but billing-wise it is the exact opposite of training: training is one charge then free, CLAUDE.md is no charge up front then billed forever.

Multiply your file's token count by the number of turns you will run, then by the input rate, divided by one million. Take a 6,400-token file (about 25,600 characters), a developer running roughly 30 turns per day, and Opus 4.7 input at $5 per million tokens. That is 6,400 x 30 x $5 / 1,000,000 = $0.96 per day in just CLAUDE.md prefix tokens, before any of your actual work. Run that 365 days and you have spent about $350 per year purely re-sending the same file. Prompt caching reduces the cached portion to 10% of the base rate, dropping the same scenario to roughly $35 per year, but caching only works if the prefix stays byte-identical between requests within the cache window.

Because the user experience feels like training. You write rules, the agent's behavior changes, you keep adding rules. The pattern looks like fine-tuning. But the mechanism is prompt engineering, not parameter updates. The practical consequence: rules in CLAUDE.md do not get cheaper over time the way fine-tuned weights do. If a rule is dead weight (Claude ignores it on most turns), training would have learned to ignore it during the gradient update; prompt context bills you for it on every single turn whether the model uses it or not. That is why analyzing the file matters more than analyzing your token usage after the fact: ccusage tells you what you spent, but only an analyzer tells you which specific lines spent it for no behavioral return.

Fine-tuning Claude (when offered) is a one-time training charge on the training dataset, then per-token inference at a different rate against the resulting custom model. The training cost is amortized over every future call. CLAUDE.md has no training charge; the cost is loaded entirely onto inference, charged on every turn forever. The two also fail differently. A bad fine-tune behaves badly on every output until you re-train. A bad CLAUDE.md silently bills you for tokens that produce no behavior change, because Claude is allowed to ignore prompt instructions when they conflict with newer ones or with the current task. You cannot 'retrain' your way out of bloat. You can only delete or move the lines.

Closer, but no. Anthropic's prompt cache bills cache reads at 10% of the base input rate, so a 6,400-token CLAUDE.md drops from $0.032 per turn to $0.0032 per turn when the cache hits. That makes the prefix feel almost free, which is why a lot of teams stop worrying about CLAUDE.md size. The catch: the cached prefix has to be byte-identical between requests within the cache window (5 minutes). One ISO date in the first 20 lines (today's date, last-modified, current-sprint string) mutates the prefix every session and forces the full uncached rate. The analyzer flags that pattern as a cache_bust finding. Even with perfect caching, you still pay the cache-write turn at full rate, and you still pay every turn for lines the model ignores.

Heuristic from the analyzer: lines that name a specific file path, a specific command, or a specific failure mode tend to fire. Lines that say 'always X', 'be careful with Y', or 'write clean code' tend to be ignored 80%+ of the time and still bill on every turn. The Karpathy-12 rubric (rule 5: avoid silent assumptions, rule 6: no orthogonal damage, rule 7: tests as truth) is a strong filter; rules outside that rubric usually fail the 'would Claude behave differently if I deleted this' test. Paste your file into the textarea at ccmd.dev and the analyzer returns a per-line findings array with severity and token savings, so you can see exactly which lines are paying rent and which are not.

Because every turn it reads CLAUDE.md again, plus whatever files it has open, plus the conversation so far. The 'learning' is a reading exercise, not a parameter update. Two consequences worth knowing. First, a fresh session starts from zero understanding of your project until it reads CLAUDE.md (so the file's value is highest right after /clear). Second, the model is not getting smarter about your repo over time, it is just re-reading the same instructions; if you want compounding behavior, move durable rules into installable skills that load on demand rather than into CLAUDE.md that fires on every turn.

Three patterns work. (1) Delete aspirational lines ('write clean code', 'follow best practices') that fire every turn but produce no measurable behavior change. (2) Move stack-specific runbooks ('how we run migrations', 'how we deploy') into skills that load when the user types the matching command, so they cost zero tokens on every turn that does not need them. (3) Replace prose with hooks and MCP allowlists in settings.json where you can; a deterministic hook costs zero tokens and cannot be ignored. The ccmd analyzer recommends installable skills from skillhu.bz for each prose block you cut, so the behavior survives the diet.