Today I was working between Opus and Fable when I noticed our CLAUDE.md had crept to 75 lines, over the recommended 50 outlined in Lesson 3.3 (Mistake 1: making the CLAUDE.md too long). So I asked Claude to review it. The useful discovery wasn't the trim. It was that line count is only a smoke alarm and the real test is whether each line actually changes Claude's behavior. We got from 75 to 55 with zero instruction loss, and this is what Claude shared with me afterwards: Trim done — 75 → 55 lines, zero instruction loss. Backstory is now a pointer to CONTEXT.md, Status delegates to HANDOFF (which I verified holds everything the deleted lines said — due date, schema, locked status set), and the archive note is compressed to its one live fact. Now your real question — what to look for going forward so you're helping, not just counting. Your line-count instinct was a good smoke alarm: it got us to look. Here's the sharper toolkit, in order of usefulness: 1. Ask the function question, not the length question. Scan any always-loaded file and ask of each line: "does this change what Claude does?" Instructions and routing earn their place. History, narrative, and state don't — they belong in CONTEXT, HANDOFF, or git. That one question did all the work in today's trim. 2. Hunt duplication — one home per fact. The Status section was the genuine hazard today, not the length. Anytime you see the same fact in two files, ask "which is canonical?" and make the other a pointer. Drift between copies is the failure that actually burns us. 3. Watch for time-bombs in always-loaded files. Dates, "due", "currently", "Status:" — anything time-bound in CLAUDE.md will go stale, because nothing forces an update there. State belongs in HANDOFF, which gets overwritten by design. 4. The best prompt you can give me, occasionally: "Which CLAUDE.md lines did you actually use this session?" That's ground truth no heuristic matches — lines I never act on across several sessions are candidates to demote. 5. Trust the tripwires we've now written (folder >10 docs → room map; state never in CLAUDE.md). You don't need to re-derive these — they're in the file, so I'm bound by them even when neither of us is thinking about it.

I sort every task by leverage — what changes the shape of the whole build if it's right or wrong. On an expensive model, that sort is the whole game. The top of the list gets the frontier. Everything under the line gets offloaded to cheaper and local models through Pushing Dispatch from @Ari Evergreen credit where it's due. So Fable was never running my stack. It sat at the top doing the one slice worth frontier money: deep diagnosis, strategic synthesis, finding the gaps and the false "fixed" claims. The 90% underneath — building, refactors, the delegated volume — ran on MiniMax M3, GLM, Kimi, Codex and local models. When you see Fable delegating or spinning out subagents, that's the offload. Fable decides; the cheaper lanes do the work. Concrete from yesterday: I had Fable audit CheckYourself, my open production-readiness checker. Deep review plus hands-on testing, three real bugs found, fixes shipped. (It also kept bouncing me to Opus 4.8 on anything it decided was "sensitive." Annoying then. Funny now.) So when access got pulled, what broke was that top slice. That's it. The 90% never ran on Fable in the first place. I swapped which model sits at the top, and the machine kept moving. That's the part I keep coming back to. Sort by leverage, and the expensive model becomes a specialist you can fire and replace — not the foundation everything sits on. If losing one model stops your work, the model was never the problem. The wiring was. I don't know if Fable comes back the same, dumbed down, or at all. Doesn't change what I ship Monday. When it got pulled — did your work stop, or did you swap one model and keep going?