Plan on the Big Model, Type on the Small One

The question that made me write this

A junior developer came to me this week with a simple complaint. Their sessions kept hitting the limit before lunch, and they wanted to know what I was doing differently.

I watched how they worked for a few minutes. Everything ran on the biggest model at the highest effort setting: the planning, the file reads, the one-line fixes, the renames. Every turn was paying top rate, including the turns that were just typing.

I told them two things. Plan and orchestrate on Opus, and let Sonnet subagents do the implementing. And put Opus on low effort for a while and see whether you miss anything.

They had not heard either one. I was honestly surprised, and then I realised why. I have been knee deep in this for months. Somewhere along the way these stopped being decisions and became habits, and a habit is the easiest thing in the world to forget you ever had to learn. That is the reason this note exists.

Thinking and typing are different jobs

Most of a build task is not hard. Deciding what to change, in which files, in what order, and what done looks like is hard. Writing the function once all of that is decided is mostly typing. Paying the most capable model to do the typing is like paying a senior engineer to retype a spec.

Treat the big model as the senior engineer and the subagents as subroutines. You would not ask your best engineer to retype a spec. You would ask them to write it, hand the pieces out, and read what comes back. A subroutine takes a clear input, does one job, and returns a result without dragging its working notes into the caller. That is exactly what a good subagent is.

So the work splits in two. The main session runs on Opus. It reads the code, asks the questions, writes the plan, and cuts the work into pieces small enough that each one has a settled answer. Each piece goes to a Sonnet subagent with a short brief: the files, the contract, the finish line. The subagent works in its own context and hands back a result. Opus reads it, checks it against the plan, and either accepts it or sends it back.

The split: the expensive model thinks at both ends, the cheap one types in between, and the files it reads never reach the top lane.

There is a second saving hiding in that picture. Every file a subagent reads lives in the subagent's context, not the main one. The orchestrating session stays small, so every later turn in it is cheaper, and the plan does not get buried under a pile of file dumps.

The split has one rule that matters more than the rest. Only hand off work that is already decided. A subagent given a piece that is still being designed will design it for you, quietly, and you will find out in review. If you cannot write the brief in a few lines, the piece is not ready to leave.

The biggest model is not the default

I almost never reach for the very top tier, Fable on the Claude side or Astra on the Codex side. I have played with both, and they are impressive. For what I do day to day, the tokenomics just do not work. Opus and Sol have built nearly everything I have shipped this year, and the gap between them and the top tier rarely shows up in a pull request.

Where Fable has earned its place is research and audits: reading a whole project and telling me what I got wrong, or working through a question where breadth and depth matter more than speed. It has been a godsend for that. But notice that even then it does not replace the pattern. It adds a layer on top of it. Plan on Fable, orchestrate on Opus, implement with Sonnet subagents. The expensive model does the one job only it does well, and then hands off.

The wider the box, the more of the work it does. The narrowest box costs the most per token.

Try low effort before you assume high

The second piece of advice surprised them more. I run Opus on low effort almost all of the time.

That works for me, and I want to be honest about why. Over the past months I built a loop around the model: instruction files that say how each repo works, standards installed as skills, hooks that check the work at session start and before it is called done, a plan file for every piece of work. On low effort the model does not have to work out from nothing how I like things done, because the repo tells it. The thinking that high effort would spend rediscovering the context is already written down.

The thinking high effort would spend on context is already sitting in four files.

A fresh setup does not have that, so low effort may cost you something there. Do not take my word for it either way. Run a trial:

1. Pick twenty ordinary tasks from your backlog, the kind you do every week.
2. Do ten on medium effort and ten on low.
3. Have your agent log each one as it finishes: the task, the effort setting, the tokens used, whether it needed a second attempt, and what you had to correct.
4. Compare the two halves at the end.

When low effort gets something wrong, ask one question about it. Would more thinking have fixed this, or would one line in my instruction file have fixed it? Usually it is the line. Write it, and every session after that gets it for free, at any effort level. Raise the effort for the turns that earn it, a hard design call, a bug that has already beaten one attempt, a plan for a large change, and then drop it again.

A miss fixed with thinking is paid for again tomorrow. A miss fixed with a rule is paid for once.

Where the split is actually wired

Advice is cheap, so here is where mine lives. I went looking this week to check that the split was doing what I tell people it does, and it mostly was. Mostly.

The model is pinned in the agent file, not chosen per task. Each kind of subagent is a short file that names its job, its tools and its model. A locator, which only answers "where is this defined" with file and line, runs on Haiku. An implementer, which types a change that is already decided, runs on Sonnet. An auditor and a writer, the two whose mistakes are expensive, stay on Opus. The main session never decides any of this mid-flight. It picks the kind of subagent, and the file picks the model.

A brief that cannot be written does not get sent. A hook runs before every spawn and refuses one that is missing four things: the lane, the scope cap, the hard stops and what should make the subagent stop and ask. That is the "only hand off decided work" rule from earlier, turned from advice into a gate. A session that tries to delegate a half-designed piece gets bounced back to finish the design.

The nudge to delegate counts reads, not models. A second hook watches the main session. After fifteen file reads and searches with no subagent spawned, it says so once. I measured why it nudges toward delegating instead of toward a cheaper model: across twelve of my sessions, cache reads were 94 percent of all input tokens (a snapshot, from August). Nothing leaves a conversation once it enters, so a file read early is paid for again on every turn after it. A subagent keeps that file out of the main thread for good, and that saving is bigger than any discount on the model.

The model switch happens once, at the start, or not at all. A third hook reads the first prompt and suggests a stronger model only when the task looks like one that earns it, a refactor across many files or a hard design call. It never suggests a switch later, because changing the model halfway through throws the whole cached conversation away and you pay to rebuild it.

And now there is a receipt. When a subagent finishes, a hook reads its transcript and logs which model it actually ran on and how many tokens it spent. My project dashboard, PANTRY, shows that beside every subagent: locator, haiku, 68k in, 1k out. A pin in a file is a request. This is the proof it was honored.

Here is the "mostly." The delegation nudge was written, tested and documented in August, and then never switched on. For three months it sat there explaining at length why it mattered, to nobody. The receipt did not exist at all until this week, so before it I was taking my own setup on faith, which is the one thing this note tells you not to do. Both are fixed now. The lesson is the same as the trial above: check what actually ran, not what the config says should have.

The same pattern in Codex

None of this is specific to Claude. I run Claude, Codex and DeepSeek side by side, and I wrote about why the loop matters more than any one of them in The Loop Outlives the Model. In Codex my setup is Sol 6.1 on light for the main session and Luna on medium for the subagents. Same shape: the stronger model plans and reviews, the cheaper one types. Codex reads an AGENTS.md the way Claude Code reads a CLAUDE.md, and in my setup they are the same file, so the rules that make low effort safe in one tool make it safe in the other.

The lesson

What I was really telling that junior developer is where the intelligence in a session should live. If it lives only in the model, you pay for it on every turn, at the highest rate, and you pay again tomorrow. If it lives in your files, the plan, the instructions, the rules you wrote down after something went wrong, then a cheaper model on a lower setting can carry it, and the expensive one is free for the few calls that need it.

• Plan and review on the big model. Implement on the small one.
• Only delegate work that is already decided, with a brief of a few lines.
• Save the top tier for research and audits, and put it above the pattern, not in place of it.
• Measure low against medium on your own work before you decide.
• Fix a miss with a written rule before you reach for more thinking.

Where this goes next

Here is what I told that junior developer at the end, and what I would tell anyone starting out. The model split and the effort setting are the easy part. They save you tokens this week. What saves you tokens, time and frustration for the rest of your career is the thing underneath them.

None of what I run today existed on day one. It started as one instruction file with three rules in it. Then a rule I kept repeating to the model became a line in that file. A mistake I kept catching in review became a check. A check I kept forgetting to run became a hook. Months of small additions later, I have a loop that orients every session, holds the work to a standard, and refuses to call something done before it is. That is why low effort works for me. The model is the same one everyone else gets. The floor it stands on took me months.

Every step is something I got tired of saying twice, and each one stands on the last.

You can build yours the same way, one rule at a time. Start with the word itself: I wrote about what a harness is, and why the machinery around the model matters more than the model, in Everybody Wants the Agent. Somebody Has to Build the Floor. The story of how my own loop came together, and why I needed it, is in I Was Shipping Faster Than I Could Understand It. When you are ready to set one up, Set Up the Loop With One Prompt gets you started in an afternoon. And once it runs, The Loop Outlives the Model shows why it keeps paying off long after the model you built it for has been replaced.

Every model you use today will be retired. The loop you build around them stays, and it gets better every time you teach it something. That is the real skill in working with AI, and you can start on it today, with one file and the first rule you are tired of repeating.

What feels obvious to me after months of doing this was news to someone last week. A year from now, your loop will be the obvious thing you forget you ever had to learn. Write it down, and pass it on.

The judgment is human. The typing, by design, is not.