docs/
Outline
---
title: Running small models under a big one
slug: small-models-brief
lang: en
published: 2026-11-02
words: 529
lines: 71
size: 2.9 KB
read: 3 min read
reel: Your smartest model should not write a single line of code
---
My usage limits ran out mid task, and as the context filled up the model got worse. The fix was not a better model. It was management: the expensive model stops typing. It plans, splits the work, briefs small models, and checks what comes back.
This site was built that way. Here is the method, with what went wrong along the way.
The setup
- Main model: plans, decides, reviews, commits. It reads only what it needs.
- Small models: one job each, several at once when the jobs do not touch the same files. Each one sends back a short report.
The main model's context stays clean, because the file reading and the trial and error happen in the small models' sessions.
Rule 1: small pieces
A big job confuses a small model. Split by files, so that two agents never edit the same one:
agent 1 src/features/posts/**
agent 2 src/features/documents/**
agent 3 src/features/hero/** src/styles/sky/**
When one job depends on another, run them in order. On this site the frontend data layer ran first, alone, and the pages started only after it passed.
Rule 2: a brief that leaves nothing to decide
If you leave a choice open, a small model plays its own tune. Every decision goes in the brief before it starts. This is the shape I use:
Job: one sentence.
If anything is impossible or unforeseen, stop and report. Do not choose.
Rules: branch, no commit, what not to touch.
Write only: exact file paths.
Do:
1. Exact names, values and text, in order.
2. ...
Checks, all must pass:
- exact commands
Report: files changed, the real last line of each check, what you stopped on.
"Stop and report" matters most. Without it, the agent quietly picks something and you find out later.
Rule 3: the main model checks everything
This is the one people skip, and then the small model's mistakes go straight into your code. Do not trust "all checks pass". Rerun them, read the diff, and look at the real result. Real catches from this site:
- A pages agent passed every check, but all public pages answered
no-store, so a CDN could not cache them. Only acurlof the real headers showed it. - Document rows overflowed phones by 11 px. Lint and types cannot see that, but a scroll width check in a browser can.
- A browser test failed on home, and an agent suspected the environment. The real cause was the sitemap fetching during
next buildand caching an empty list.
curl -sI https://example.com/en | grep -i cache-control
In Claude Code
Subagents can run on a cheaper model. Put the rule in CLAUDE.md so that every session follows it:
The main model plans, writes the briefs, reviews and commits.
Hands-on work goes to small model subagents, one job per agent.
The main model makes every decision before it writes the brief.
The main model reviews every result before it commits.
The cost is your time up front, writing an exact brief. That is the same work a good lead does for a team.
| My usage limits ran out mid task, and as the context filled up the model got worse. The fix was not a better model. It was management: the expensive model stops typing. It plans, splits the work, briefs small models, and checks what comes back. |
| This site was built that way. Here is the method, with what went wrong along the way. |
| ## The setup |
| - **Main model:** plans, decides, reviews, commits. It reads only what it needs. |
| - **Small models:** one job each, several at once when the jobs do not touch the same files. Each one sends back a short report. |
| The main model's context stays clean, because the file reading and the trial and error happen in the small models' sessions. |
| ## Rule 1: small pieces |
| A big job confuses a small model. Split by files, so that two agents never edit the same one: |
| ```text |
| agent 1 src/features/posts/** |
| agent 2 src/features/documents/** |
| agent 3 src/features/hero/** src/styles/sky/** |
| ``` |
| When one job depends on another, run them in order. On this site the frontend data layer ran first, alone, and the pages started only after it passed. |
| ## Rule 2: a brief that leaves nothing to decide |
| If you leave a choice open, a small model plays its own tune. Every decision goes in the brief before it starts. This is the shape I use: |
| ```markdown |
| Job: one sentence. |
| If anything is impossible or unforeseen, stop and report. Do not choose. |
| Rules: branch, no commit, what not to touch. |
| Write only: exact file paths. |
| Do: |
| 1. Exact names, values and text, in order. |
| 2. ... |
| Checks, all must pass: |
| - exact commands |
| Report: files changed, the real last line of each check, what you stopped on. |
| ``` |
| "Stop and report" matters most. Without it, the agent quietly picks something and you find out later. |
| ## Rule 3: the main model checks everything |
| This is the one people skip, and then the small model's mistakes go straight into your code. Do not trust "all checks pass". Rerun them, read the diff, and look at the real result. Real catches from this site: |
| - A pages agent passed every check, but all public pages answered `no-store`, so a CDN could not cache them. Only a `curl` of the real headers showed it. |
| - Document rows overflowed phones by 11 px. Lint and types cannot see that, but a scroll width check in a browser can. |
| - A browser test failed on home, and an agent suspected the environment. The real cause was the sitemap fetching during `next build` and caching an empty list. |
| ```bash |
| curl -sI https://example.com/en | grep -i cache-control |
| ``` |
| ## In Claude Code |
| Subagents can run on a cheaper model. Put the rule in `CLAUDE.md` so that every session follows it: |
| ```markdown |
| The main model plans, writes the briefs, reviews and commits. |
| Hands-on work goes to small model subagents, one job per agent. |
| The main model makes every decision before it writes the brief. |
| The main model reviews every result before it commits. |
| ``` |
| The cost is your time up front, writing an exact brief. That is the same work a good lead does for a team. |





