Matt Savich / WritingZero Nine

Matt Savich ·

The right model for the job

Model routing balances cost, speed and intelligence by matching each request to the capability it needs.

A calendar update and a difficult software problem need different levels of reasoning. Sending both to the largest model can mean paying for capability the simpler task doesn’t need.

A model router chooses which model handles each request. The goal is to spend enough to get a useful result, while keeping routine work cheap.

Match the model to the work

A router can use a small model to assess a request, then apply rules to choose the model that executes it. Difficulty matters, but so do context, urgency and the consequences of a mistake.

For example, rewriting a short email is bounded work. Diagnosing a fault across several systems requires more reasoning. A short follow-up can also depend on a long conversation, so message length alone is a poor guide.

Illustrative routing: assess a request's difficulty, context and urgency, then select a small model for routine work, a mid-sized model for harder tasks, or a large model for complex reasoning.

Model choice is only one control. Reasoning effort determines how much thinking the selected model is asked to do. A smaller model with more effort can be worth testing on a clearly scoped task that can wait. Extra thinking doesn’t guarantee the capability of a larger model.

Count the trade-offs

Routing adds a decision before the work begins. That decision takes time and, when it uses another model call, adds cost. On a long task, the overhead may be worthwhile. On a quick answer, it can be a noticeable delay.

Evaluate cost, speed and quality across the whole task. Include routing, execution, retries and the correction needed to reach a useful result.

A cheap first answer isn’t necessarily a cheap completed task. Retries and manual corrections can outweigh the initial saving. Compare routes using work you can verify, and measure time to a usable result as well as spend.

Tune against results

A router can underestimate difficulty or miss essential context. A successful model call only proves that a response arrived. It doesn’t prove that the answer was good.

Keep examples of poor results and inspect the cause. Was the wrong model selected, was information missing, or did a tool fail? Adjust the routing rules against those examples, then test on fresh tasks. Preserve a manual model choice for requests that need it.

Try it with OpenClaw

Zero Nine’s open-source OpenClaw model router includes the routing policy, tests and installation notes under an MIT licence. It selects both a model and reasoning effort, with fallbacks when classification fails.

The integration includes a patch for a specific OpenClaw build. Check compatibility and adapt the model names before installing it. Start with a small set of routine tasks and compare the results with your usual model. Keep the cheaper route where it does the job well.