model-gear-router

Most people pick a model once, at the start of a session, and then run everything through it — research, bulk edits, code, review. That is one setting doing five jobs. This skill replaces it with an orchestrator layer that picks a model per task, the way you would assign work to different people.

You are not choosing a favourite model. You are choosing a gear.

1. A gear is two dials, not one

Two gears can share a tier and still behave completely differently, because the mission is injected as orders, not as a setting. Same engine, different instructions is a real difference in output, and it is the dial most people never touch.

Name your gears. A named gear is a job class you can say out loud — "send that one to the red-team gear" — instead of a model string you have to remember and retype.

2. Pick the mission first, then the tier follows

Write down your verbs before you write down your models. A workable starting set:

Pick the cheapest gear whose mission fits. Escalate a tier only with a reason you can state. Most work is build or grind; almost none of it is deepest.

3. Then the job class picks the provider

Once you know the verb, the provider follows from the shape of the work — not from brand preference.

The one rule that is not a preference

Never review code with the same family that wrote it. A same-family reviewer shares the author's blind spots, which defeats the entire purpose of a second opinion. If your build gear is family A, your review gear must be family B. This is the single highest-value line in the whole table.

Fill in your own providers in gears.template.md and keep it next to your agent instructions.

4. In-session vs. headless — what you give up

Two ways to run a worker, and they are not interchangeable.

A headless one-shot is bare by construction. That is what makes it cheap and what makes it wrong for judgment work. Route by what the task needs, not by what is cheapest to run:

• Needs your rules and memory to be correct → in-session.
• Fully specified, mechanical, and self-contained → headless, on whichever provider fits.

5. The inline threshold

Not everything deserves a worker. Dispatching has real overhead — a spawn, a context handoff, a merge on the way back.

Under ~15 minutes, and read-only? Do it inline. Everything else gets dispatched.

Pick your own number and write it down. The point is that the threshold exists and is explicit, so the orchestrator stops spawning an agent to answer a question it could have answered itself.

6. Fan out in parallel — and keep the merge

The orchestrator's real leverage is not picking one good model. It is running four at once.

                 ┌── cheap provider  · bulk pass
orchestrator ────┼── long-context    · read the big inputs
   splits        ├── other family    · red-team the result
                 └── in-session      · the build itself
                          │
                 orchestrator merges

Two conditions before anything goes out in parallel:

1. Independent. No branch needs another branch's output.
2. Specified tightly enough to survive without a follow-up question. A headless worker cannot ask you what you meant; it will guess, and you will not see it guess.

Anything that fails either test stays in-session. Sequencing and the merge never leave the orchestrator — that is the part you cannot delegate.

7. Precedence — who wins a disagreement

Write this down, in this order, and never invert it:

1. The gear or model you typed. Always wins.
2. The orchestrator's own choice. It picks by job class, says which in a clause, and does not stop to ask.
3. Whatever an automatic router would pick. Last. Nothing defaults here.

Automatic routers optimise for their own objective — usually cost. That is a fine objective and it is not always yours. Opt into one deliberately, per task, or not at all.

8. Setting this up

1. Name your verbs. Section 2's list, trimmed to the ones you actually do.
2. Fill in gears.template.md with the providers you have access to. One row per gear.
3. Put the table in your agent instructions, so the orchestrator reads it every session.
4. Add the routing heuristic — section 3's table, plus your inline threshold.
5. Make the orchestrator say which gear it chose, in a clause, on every dispatch. If it cannot say why, the routing is not working and you will not find out any other way.
6. Check the precedence order holds by typing an explicit model and confirming it wins.

Anti-patterns

• One model for the whole session. The default, and the thing this skill replaces.
• Routing by price alone. Cheap on a judgment task costs more in rework than it saved.
• Same-family review. Covered above. It reads as covered and is not.
• Fanning out under-specified work. Four workers guessing in parallel is worse than one worker asking a question.
• A router you cannot override. If your explicit choice does not win, you do not have a router, you have a policy.

Related

• cli-llm-routing — when to ask a second model at all.
• agent-runbook — which execution mode a task needs; this skill decides which model runs it once the mode is chosen.
• multi-model-council — the high-stakes case, where several models judge the same work against a rubric instead of one being picked.
• ../../tools/agent-memory-kit/ — pushed recall, so the orchestrator starts each turn already knowing what you decided last time.
• ../../handouts/model-gear-router-pattern.html — the same routing shown as diagrams.