You asked about #5 and #6, here is my reply!

A week ago I posted the usual reasons usage stays high after you set up ICM. Most of the replies zeroed in on #5 (model choice) and #6 (loops and retries). I promised a deeper post. Here it is, and a lot of it is your ideas.

I wrote #5 the day it burned me. Polished new process, felt careful, and Opus and Fable crushed my account usage before I noticed. Lesson: a polished process is not a cheap process.

#5: the model leak

*The shop.* Haiku is the parts runner, Sonnet is the mechanic, Opus is the foreman. You do not pay the foreman to fetch a filter, and you do not ask the runner to decide if the engine is worth saving.

*What I changed.* My setup now picks the model by the job: Haiku for mechanical work (search, extract, rename, format), Sonnet for routine building and writing, Opus only for judgment (planning, review, hard debugging, anything a client sees). Max four Opus agents in any one run, so an overnight job can not shred the account. Fable only when I name it for that job.

*Subagents are not a discount.*

@Eddie Barry

nailed this one. Handing a stage to a subagent protects your main conversation's context, but it is the same meter. The saving only shows up when the subagent runs on a lighter model. So my rule now: a subagent never inherits the parent's heavy model.

@Mofedul Alam Joy

Joy hands big reads to a subagent that sends back only a summary. Great move, and pair it with Eddie's point: put that reader on the light model.

*Cost is not value.*

@Pascal Pollack

asked the real question: what are we getting for the tokens? Twice the tokens for a clearly better result can be the cheap choice. Half the tokens for worse work is not a win. Before you move a stage down a model, decide what good looks like for that stage, then check the lighter one still hits it.

#6: the loop leak

*Run it small first.*

@Gabriel Azoulay

's rule, now mine: run any new process once on a small input and look at the usage before you let it loop or leave it overnight. This is the one that would have saved me.

*Every loop gets a stop.* "Review and revise" with no ceiling is a meter running with nobody at the wheel. Mine: if something fails 2-3 times, stop and ask a human. No fourth try on its own.

*Watch what gets printed.*

@Aurel Babiš

caught one I missed: command output. Tests, builds and searches dump everything into context, and every later turn pays for it again. Have the command write the full log to a file and print only the summary.

Add to the 10-minute audit

- Run /context at the start of a fresh session (Mofedul's tip). It shows what is loaded before you type anything.

- For each stage, write which model it runs on. Then check what actually ran.

- Anything mechanical on the heavy model?

- Does every loop have a cap and a stop-and-ask?

- Did you run the new process once, small, before letting it loop?

I still get the heavy-model call wrong sometimes. If your numbers disagree with mine, post them.

Thank you @Eddie Barry, @Gabriel Azoulay, @Aurel Babis, @Pascal Pollack, @Mofedul Alam Joy,

@Mark Pipkin

and everyone who dropped a setup. This is the dominoes of help I keep talking about.

Your turn: which stage in your setup is heaviest, and what model is it running on?

5 comments