Cheap sweep, strong synthesis: routing models across multi-agent work

TL;DR: When I split work across several agents, the expensive mistake is running every subtask on the strongest model with the whole conversation attached. What works for me is a model ladder, routed by what a wrong answer costs and by who reads the output: the strongest model for plans, incidents, hard debugging and anything a customer reads; a mid model for sessions that mostly ingest tool output; a fast model for mechanical, fully specified edits; the smallest model only as a search subagent. I lower effort before I lower the model, I pick the model when the session starts, I pilot on 3-5 records before fanning out, and every subagent gets a minimal, self-contained spec. Subagents keep the main context clean, but they do not make the total bill smaller.

The run that spent its budget before producing a single table

The problem that forced me to write any of this down was a wide research task: collect a set of facts about 58 content channels and turn them into comparison tables. It looked like a textbook case for parallel agents, so I split it into three subtasks and ran them at the same time. All three got the strongest model available in that tool, and all three inherited the full conversation that preceded the split.

The usage limit ran out before any table existed. The checkpoint the agents left behind contained zero numbers and the names of two channels. The full report was eventually delivered by a single session on the strongest model, working sequentially. The lesson was uncomfortable but simple: a broad scope does not justify the strongest model at every stage. Collecting 58 rows of dates and counts is not the part of the task that needs judgement, and paying top price for it three times over, with a large inherited context on every call, is how you burn a budget and end up with nothing to show for it.

What does multi-agent orchestration actually buy you?

AI agent orchestration is one coordinating session splitting a task across several agents, each with its own context window, and collecting their results. The part people over-sell is cost. The part they under-sell is isolation.

A subagent does its searching and reading in its own window, and only its final report comes back to the main session, typically a summary in the range of one to two thousand tokens. That is real value: the main session stays focused and does not fill up with file dumps. But each subagent also loads its own system prompt and its own copy of the project instructions, so in total tokens it is not free. What it buys is isolation, which is a different benefit.

I measured what the agent setup costs at session start in one of my projects. Eleven project agents added less than two thousand tokens, because only their one-line descriptions load up front; the bodies load inside the subagent when it runs. The fixed floor of a session, before a single word about the task, was around 28 thousand tokens of system prompt, instructions and memory index. And the thing that dominated the actual bill was neither: over 90% of cost was re-reading cached context on every turn of a long conversation. That changes the math. A subagent for one grep is a loss. A subagent that sweeps forty files and returns a list is a win, because it keeps forty files out of a context that gets re-read on every later turn. I wrote more about what loads when in how I structure context per project.

The options I weighed

• Strongest model for everything. Simplest, and the quality ceiling is as high as it gets. The cost is limit burn and slow turns on work that never needed that model. The incident above is what this looks like at scale.
• Cheapest model for everything. Fast and light on the limit, and it falls over exactly where it matters: inclusion criteria, ambiguous records, the final recommendation.
• Switching models mid-session as the work changes. Tempting, and quietly expensive. The prompt cache is per model, so a switch in the middle of a long session means the whole context is read again at full price on the new model. On a short session it does not matter; on a long one it erases the saving you were after.
• A ladder chosen at session start, plus explicit routing of subtasks. More deliberate, needs a small launcher and a habit of writing down the model next to each subtask. This is what I run.

The ladder I run

At the time of writing the rungs look like this. The prices are ratios of the list API price per million tokens, which is the relative number that matters when you decide what to route where.

On the OpenAI side, in Codex CLI, the same shape maps onto three GPT-5.6 tiers: Sol for demanding work with a complete spec, Terra as the middle when Sol is eating the limit, Luna for mechanics. My own read is that Sol is slightly weaker than Fable on open-ended problems, so it gets tasks where the discovery is already done and written down. One gotcha: Sol defaults to low reasoning effort, which gave me shallow answers, so every profile that uses it sets effort to high explicitly.

The routing rule I use most is model by who reads the output. If a customer reads it, the strongest model. If I read it and will check it, the mid model. If a machine consumes it, the fast one. The second rule is lower effort before lowering the model: on well-specified work the reasoning dial is mostly a latency lever, so I turn it down first and only move down a rung when the cheaper effort still costs more than the task is worth. I covered that reasoning in how I pick effort and model per task. A related trap: a "fast mode" toggle is faster, not cheaper. It is the same model served quicker.

How do you split a wide research task across cheap and strong models?

After the incident I stopped thinking of a research task as one job and started splitting it into three layers before any agent starts:

The execution rules that make that split pay off:

1. The strong model does not collect records. It designs the schema, resolves exceptions and writes the synthesis from finished material.
2. Minimal forked context. A sweep agent gets a self-contained spec and nothing else. When the tool offers to fork the conversation into the subagent, I fork zero turns or the smallest number that works, never the full history by default. Inherited context was a large part of what sank the original run.
3. Pilot on 3-5 records per bucket. Check the columns, the sources and the format on a handful, then run the full sweep on the cheap model. Fixing a schema after 58 rows is a rerun; fixing it after three is a sentence.
4. A numeric exit criterion per subtask. For example: 20 rows, every listed field filled, a source URL next to every number. A description of progress is not a result.
5. Write in batches to a canonical file or to disjoint working files, so the first useful checkpoint exists long before the whole sweep ends.
6. The main session checks, it does not redo. It reviews every ambiguous case and a sample of the mechanical output. It does not repeat the sweep on the strong model.
7. Write the model next to each subtask before delegating. If there is no reason for the top rung, the default is the fast or mid one.

// illustrative shape of a sweep subtask
subtask: collect-release-dates
model: fast            // written down before delegation
effort: medium
fork_context: none     // self-contained spec only
pilot: 3 records, stop and report
exit: 20 rows, all fields, source URL per number
output: batch-02.json

The success criterion for a wide research task became a usable, verifiable dataset before the limit runs out. An elegant synthesis comes from that dataset, not instead of it.

Should a subagent ever edit code?

In my setup, no. A subagent earns its place when its output comes back as a report, a list or a draft: a search across the repo, a sweep of sources, an audit, a first version of a text that someone reviews. Code changes happen in the main session, with the right project instructions loaded, helped by built-in search and planning subagents and a review pass. When I want a second implementation or a second opinion, it runs as a separate CLI session in its own git worktree, which I described in running coding agents in parallel with worktrees. The reasoning is about ownership: a subagent returns a summary, and a summary is a poor thing to review a diff against. The session that will be asked to defend the change should be the one that made it.

The other half of routing is pinning a model per agent. In Claude Code the model sits in the agent definition's frontmatter, not in its prompt. Without that entry the agent inherits the session model, and that bit me: under a mid-model session, the agents that write customer-facing text would silently run on the mid rung. So those are pinned to the strongest model, sweep and list agents are pinned to the fast one, and analysis agents whose output I read myself run on the mid one.

# illustrative shape of an agent definition header
---
name: source-sweeper
description: Collects rows into a fixed schema. Returns a table, never edits code.
model: sonnet
---

Two details that are easy to miss. Agents also inherit the MCP servers of the session they run in, so an agent that needs an analytics server has to run inside a session started with that server. And changing a pinned model means editing the definition and restarting the session.

One data point on the fast rung doing real work: a spec for a small set of unit tests went to the fast Codex tier in its own worktree. It finished in 70 seconds on about 30 thousand tokens, and all six tests were green on the first run. The spec carried the quality; the model only had to transcribe it.

Where this falls short

The ladder is a judgement call. My placement of each model comes from my own tasks, and a model update can move a rung. The launcher that picks a profile from keywords in the task description routes most tasks well, but a task phrased without any of its keywords falls to the default profile, which is the right fallback and still occasionally the wrong choice. And the cache penalty for switching models mid-session means a session that changes character halfway through is simply stuck on its starting rung, and the fix is a new session.

What I would tell someone starting tomorrow

• Route by the cost of a wrong answer. Strongest model for plans, incidents and customer-facing text; mid for tool-heavy sessions; fast for spec execution; smallest only for search.
• Turn effort down before stepping down a model.
• Choose the model at session start. The prompt cache is per model, so a mid-session switch re-reads everything.
• Pilot on 3-5 records, then fan out cheaply with a numeric exit criterion per subtask.
• Fork as little context as possible into every subagent.
• Use subagents for isolation, not for savings, and only for output that comes back as a report, a list or a draft.
• Pin the model in each agent definition, or it will quietly inherit whatever the session runs on.