Routing models saves tokens. Routing work saves the operation.
NVIDIA's open-source router sends each agent step to the cheapest capable model. Useful, but the bigger savings sit one layer up, in who owns each step of the work.
Model routing is becoming standard: send each step of an agent's work to the cheapest model that can handle it. It is good engineering and it will cut your bill. But a company does not run on a model bill. It runs on work that has an owner, a rule and a record, and routing models does nothing for any of those.
What the routers promise
In an NVIDIA blog post from 11 August 2026, NeMo Switchyard is described as an open-source routing library that sends each step of an agent workflow to a model suited to that step, tunable for quality, latency or cost. NVIDIA says it keeps frontier-level accuracy while cutting task completion cost to nearly one-third of using Opus 4.8 alone, in its own internal benchmarks. The same post passes along savings reported by three partners.
Source: NVIDIA blog, 'Nemotron 3.5 Lightning and NeMo Switchyard' (11 August 2026). Vendor and partner reported, on their own task sets; not independently verified.
Read these as what they are: vendor and partner numbers on their own tasks. They show the direction, not what your operation will save. And they all measure the same thing: the price of a step, not whether the step should exist.
The expensive part is not the model
Think about where a company's cost really sits. A model call costs fractions of a cent. A wrong handoff, a request nobody owns, a report rebuilt by hand every month: that is where the money goes. A router makes the call cheaper. It cannot tell you that the call was the wrong step, or that a person is about to redo its output.
Routing models answers "which brain should do this?" Routing work answers harder questions:
- Who owns this step? A named person or role, not "the agent".
- What is the rule? What counts as done, and when it must stop and ask.
- Where does it land? The record the next step reads, so nobody retypes it.
- What happens when it fails? An escalation path with a person at the end.
None of that is in a router's configuration. It is operational design, and it has to exist before the router is worth anything.
A cheaper step in a broken flow is still a broken flow
If two teams each keep their own version of an order, a routed agent will update either one faster and for less money. Cost per call goes down while rework stays the same. This is the same failure we have written about before: speed applied to a system nobody redesigned.
The reverse also holds. Sentynel's OCESA case rebuilt the reporting operation around the question each person was asking, connecting ticket sales, sponsorship results, ratings and media evidence. The case record reports −70% reported operating cost, with the note that these are reported project outcomes and the cost comparison is normalized. That result came from changing how the work flows, not from picking a cheaper model for the same steps.
- 01Map the workEvery step, with an owner
- 02Write the ruleDone, stop, ask
- 03Fix the recordOne place the next step reads
- 04Place the agentInside the step it owns
- 05Route modelsCheapest capable, per step
Review monthly: which steps can be removed, not just cheapened.
Do routing last
None of this is an argument against routers. Once the operation is designed, they are exactly the right tool: each agent runs inside a step it owns, and the cheapest capable model does the thinking. The order is what matters. Redesign the operation first, put autonomous agents inside it, and only then optimize what each step costs.
A first test for this week: pick your most expensive agent workflow and list its steps. For each one, write the name of the person who owns it and the rule that says it is done. If you cannot fill a row, you do not have a routing problem. You have a design problem, and no model, cheap or frontier, will fix it.