Who picks the model?
Coding agents let you choose a model and an effort level. Why both easy answers cost something, and the idea of a model that picks for you.
You open a coding agent to rename a variable. The agent lets you pick a model and how much effort it spends. Do you change that setting for a small task like this, or keep what you used for the last one? And who should make that choice?
A small choice you can make per task
I use coding agents like Claude Code and Codex. In both tools I can choose the model per task, and I can choose an effort level.
You can keep your current choice or reconsider it for the next task. If you do reconsider, it's worth asking whether there's a better way than gut feeling.
Two easy answers, two costs
There are two easy rules. Both work, and both have a price.
| Always the strongest | Always the cheapest | |
|---|---|---|
| What you pay | The highest price, also on tasks that didn't need it | A lower price per task |
| What you risk | Paying for more than the task needed | Another attempt when the result isn't good enough |
I could run every task on the strongest model at high effort. I don't want to. There's a German saying for that: "nicht mit Kanonen auf Spatzen schießen", don't shoot sparrows with a cannon. Renaming a variable is a sparrow.
The cheapest rule fails the other way. When the model gets the task wrong, you pay again: you read the bad result, explain the problem, and run a second round. When I wrote down the goals for my project, I put quality before cost. Better the right model once than a failed try plus a correction round.
Say you have twenty small tasks a day. With the first rule, every one of them gets the cannon. With the second, the few hard ones among them get a model that may not be up to the job, and you only find out after the first try.
So the real answer is in the middle: a strong model for the hard tasks, a cheaper one for the easy tasks. The hard part is telling them apart, every time, quickly.
A model that decides
Here is the idea this series follows. What if a second model made the choice for you?
Not a chat model that writes a long answer, but a decision model: a model that answers fixed questions by picking from fixed options. Think of a clerk in a mail room who reads each letter and puts it into one pigeonhole, but never writes a reply. For a task, the questions could be: what kind of task is it, how hard is it, and which of your models fits best? Part 2 explains what a decision model is and how it works.
The model I tried is called Jev, from a company called TypeSafe. The vendor says it answers in 70 to 500 milliseconds at a very low price, and that it can't make up text because its answers are typed (always one of the given options). Those are the vendor's claims, not my measurements. Later parts show what I measured.
The tool: spatz
From that idea I built a small tool. Its name comes from the saying: spatz is German for sparrow.
spatz (opens in a new tab) is a proof of concept. It's a command line tool. You give it a task and the models available to you, and it recommends one pair of model and effort from that list. It only ranks the models you gave it, and nothing else.
spatz also learns which pairs succeed. When a task is done, it notes whether the result worked, and it uses that the next time a similar task comes in. That way the recommendation doesn't rest on the decision model alone. Part 3 shows how.
What spatz doesn't do
This matters as much as what it does. spatz never runs the task, and its command line tool never switches the model. You read the recommendation, and you or your agent picks the model.
That isn't only a design choice. Claude Code has hooks (small scripts that the agent runs at fixed moments, for example before a tool runs). A short experiment, meant to be thrown away, checked whether a hook can change the model or the effort. It can't. A hook can watch what happens and add a hint, nothing more. So with hooks, a recommendation is as far as a tool like spatz can go. Part 6 shows a mod (a plugin that runs inside Claude Code) that can make the switch.
Where this series goes
This is part 1 of 6. The plan for the next parts:
- Part 2 will explain what a decision model is, and how it differs from the chat models you know.
- Part 3 will show how the recommender is built and what data it learns from.
- Part 4 will be about measuring fairly whether a cheaper model is good enough.
- Part 5 will weigh the pros and cons, and the alternatives to letting a model pick your model.
- Part 6 will look at a Claude Code mod that can apply the choice, and at when it should decide.
One thing up front: the learning phase hasn't started yet. There's no data on savings or success rates so far. Every result about that is pending, and the series will say so where it comes up.
Next in this series: What is a decision model?
Update (2026-10-07)
Part 6 still looks at the mod, but spatz doesn't use it for now. It records outcomes through hooks instead, in Claude Code and in Codex (spatz pull request #101 (opens in a new tab), merged on 2026-10-07). Part 6 explains why.