Watch what a coding agent does across a week and the work is lopsided. A few changes genuinely need a model that can hold several files in its head at once. Then there are the hundreds of renames, import fixes, one more test case, a config value threaded through three files. The same model you're paying for the first group is handling the second.
Databricks shipped smart routing in Unity AI Gateway to deal with this. Their published numbers are more than thirty percent lower cost per task, thirty-five percent on internal benchmarks, and fifty-six percent on public ones while matching Opus 5. Those are their measurements on their benchmarks, and I haven't reproduced them.
What interests me more than the saving is how the routing decision gets made. A cheap fast model reads the task first and labels it. What parts of the code change, what evidence exists, what the failure mode looks like, whether the fix is localised or spread across the repo. The router starts at a medium-sized model and moves up or down from those labels.
Most routing logic I've seen teams write is a length heuristic and a keyword list, which is why most of it gets switched off within a month. Difficulty isn't a single number. A one-line change in an untested file with an unreadable stack trace is harder than a fifteen-file rename, and a scalar score can't represent that. Labels keep the shape.
One limit worth stating, because coverage of this will blur it. Smart routing today is scoped to coding tasks inside Claude Code and Codex. If your bill is a support assistant answering four hundred thousand questions a month, the idea transfers and the feature doesn't.
The traces matter more than the savings
There's a line underneath the cost headline that I'd build on. Traces for coding agents can go into Unity Catalog, with tagging and access policies over them.
So the record of what your engineers asked a model, what came back, and which model handled it sits inside the same governance boundary as your customer tables. Same grants, same lineage, same audit surface.
I've sat in a lot of rooms over the last two years where the AI conversation stalls, and it almost never stalls on capability or price. It stalls when somebody from risk asks where the evidence lives and who can read it, because a vendor dashboard is a bad answer to that question. A governed trace store is answerable with tools the security team already trusts.
It also makes the cost claim checkable in your own environment, which is what I'd actually do with it. Route your own work for a fortnight and read your own traces.
The thing I'd ask in a review
A router is a component that can be wrong, and it's wrong asymmetrically.
Route a hard task down and you get a worse answer that still looks like an answer. Somebody spends twenty minutes with it before deciding to start again, and the inference cost you saved you spent several times over in attention. Route an easy task up and it costs a few cents.
So the router should lean toward escalating, and the number I'd watch isn't average cost per task. It's how often routed-down work gets redone. A team that reports a saving without that second number has measured half of it, and I'd want to know which half before I took the figure to a board.
None of which is an argument against turning it on. If you're running coding agents on Databricks, turn it on and record the traces. Two weeks of your own data will settle it better than anyone else's benchmark, including this one.