Model routing and dynamic workflows

What it isCopy Anchor Link

Claude Code supports dynamic workflows: Claude writes a JavaScript script that orchestrates many subagents, a runtime runs it in the background, and your session sees only the final answer. Intermediate results live in script variables, so the main context does not fill with transcripts. The script can also apply quality patterns, such as having independent agents try to refute each finding before it is reported.

The routing ideaCopy Anchor Link

Match model size to the job. A strong model plans and signs off. A small fast model scans every file in parallel. A mid-size model makes edits, each in an isolated copy. A verifier checks each result before it counts. Social media posts describe this as "Opus plans, Haiku scans, Sonnet ships". The posts are marketing, but the underlying pattern is real and documented. Treat any exact recipe as a starting point and measure cost and quality on your own task.

When to use itCopy Anchor Link

Codebase-wide audits, large mechanical migrations, and research that needs cross-checking. Not for a single focused change, where one session is cheaper and simpler.

A worked example: a security auditCopy Anchor Link

Stage 1: a small, cheap model reads every file and flags suspicious ones (fast, read-only). Stage 2: a mid-size model proposes a fix for each flag in its own copy. Stage 3: a different agent tries to refute each finding. Stage 4: the large model reads only the confirmed ones and decides what ships. Cost drops because the expensive model sees little.

A note on the hypeCopy Anchor Link

Posts describing this as a trick that "saves huge amounts" are exaggerated. The saving is real when the work is large and parallel. For small tasks it is overhead. Measure cost and quality on your own task.

How a routed run is builtCopy Anchor Link

Think of it as a small factory with stations. A script, written once by a strong model, lists the stations and passes each station's output to the next. Each station is a call to a model chosen for that job. Because the script is ordinary code, loops and conditions happen exactly as written, not as the model remembers them.

Here is a cost sketch with invented numbers for illustration. Say there are 100 files. A small model reads each at a cost of 1 unit, so scanning costs 100 units. It flags 10. A mid-size model fixes each flagged file at 5 units, so 50 units. A large model reviews the 10 results at 20 units each, so 200 units. Total: 350. If the large model had read all 100 files at 20 units each, it would cost 2000. The saving comes from the large model seeing only 10 percent of the work.

A second example: when routing losesCopy Anchor Link

Take 4 files, all closely linked, where a change in one affects the others. Splitting work among agents means each sees only part of the picture, and you pay to combine the parts. One strong session with all four files in view is cheaper and more accurate. Routing fits work that splits into independent pieces.

Trade-offsCopy Anchor Link

A cheap model scans fast but may miss problems that a stronger one would catch. The pipeline is only as good as the weakest station. Debugging also gets harder, because an error could arise at any step. Add logs, and keep the intermediate outputs so you can see where things went wrong.

What goes wrongCopy Anchor Link

Common symptoms: the final answer ignores a real issue the first station missed, costs end up higher than a single session, or results differ between runs. To confirm a missed issue, plant a known bug in a test repo and see whether the pipeline finds it. To confirm cost, compare the usage of a single-session run with the pipeline on the same task.

Common mistakeCopy Anchor Link

Using the pattern for a focused change. One session is cheaper.