Which AI Model Should I Use for Coding? Stop Answering That Every Turn
Most routers treat a prompt as a standalone request.
A coding conversation is not one, and that single difference changes what a good routing policy looks like.
Short answer
Stop answering it every turn. Pick a router once, and prefer one that routes over the subscriptions you already pay for rather than a per-token catalogue. Keep it sticky inside a thread: switching engine mid-conversation is a real context handoff, so it should leave an engine only when quota, sign-in or install forces it to.
What this covers
- It routes over the local, subscription-limited engines you already have installed and signed into, rather than a hosted API catalogue billed per token, so the resource it economises is your existing plan.
- Its policy is deliberately sticky: switching engine mid-thread is a real context handoff, so Auto stays on the engine already driving a thread and leaves only when that engine is out of quota, signed out or uninstalled.
- Even then it needs a real margin before it moves, which stops it thrashing between two nearly equal options and losing thread continuity each time.
- Within one engine it re-picks the model every turn, which is cheap because it is an override rather than a handoff. Turns are scored on complexity, whether they carry images needing vision, and whether the assembled context needs a large window.
- The candidate pool is deliberately small, roughly a cheap, middle and strong rung per engine, so the choices stay explainable, and models that would bill to usage credits instead of plan limits are excluded so Auto never spends credits unasked.
Before and after
| Area | Choosing per message | Choosing once |
|---|---|---|
| A one-line rename | You reach for the strong model because it is already selected | A cheap rung handles it |
| A screenshot in the prompt | You remember halfway through that this model cannot see images | A vision-capable model is picked because the turn carries an image |
| A large assembled context | The request is truncated and the answer is confidently wrong | A large-window model is picked for that turn |
| Your plan resets in ten minutes | You find out when the run dies | Headroom is part of the decision |
The decision you make forty times a day
Every coding session starts with a small question: which model. It looks free because it takes a second, and it is not, because you answer it dozens of times and the answer is only sometimes right.
The failure modes are predictable. You leave the strongest model selected and burn your weekly limit on renames and typo fixes. Or you leave a fast model selected and hand it a task that needed the careful one, and spend twenty minutes reviewing work you have to throw away. Or you paste a screenshot into a model that cannot read images.
None of these are interesting problems. They are exactly the kind of thing software should decide.
Routing over what you already pay for
This is the part that separates Auto from a per-prompt API router. It does not send your work to a catalogue of hosted models billed by the token. It routes over the local, subscription-limited engines you already have installed and signed into: the same Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode you would otherwise have picked from a menu.
So the resource it is being careful with is your existing plan, not a new bill. When it chooses a cheaper rung for a trivial turn, the saving lands as headroom left in your weekly limit rather than as a smaller invoice from us. Pathrule does not resell model access and does not charge per token.
Why sticky beats optimal
A stateless router evaluates each prompt in isolation and picks the best model for it. That is correct when a prompt is a standalone request. A coding conversation is not: it has a working directory, a running process, a history of what has already been tried, and an engine that has been building an understanding of the task for the last twenty minutes.
Moving that to another engine is a context handoff. The new engine has to be given the thread rather than continuing it, and something is always lost in the transfer. So Auto stays on the engine already driving the thread and leaves only when that engine genuinely stops being an option: its limit is reached, you signed out, or it is no longer installed.
Even then it does not move for a rounding error. Another engine's best option has to beat the current one by a real margin before Auto pays the cost of the handoff. Without that margin a router flip-flops between two nearly equal choices and pays the transfer cost every time.
Models change every turn, engines do not
Inside one engine, changing model is cheap: an override on the next turn, no handoff at all. That is where most of the work happens.
Each turn is read for what it actually needs. How complex is it, from trivial to hard. Does it carry images that only a multimodal model can read. Is the assembled context large enough to need a big window rather than a fast one. A cost and quality dial decides how those are weighed, and it leans thrifty by default, so a trivial turn does not get the expensive model merely because it is available.
The candidate pool is small on purpose: roughly a cheap, a middle and a strong rung per engine. A router that can reach forty models makes choices nobody can explain. One that reaches nine or ten makes choices you can predict, and predictability is most of what you want from something making decisions on your behalf.
One omission worth stating
A model that would bill to usage credits rather than run inside your plan's limits stays out of the pool, even when your account technically has access to it. Auto is not allowed to spend credits you did not agree to spend, so choosing that model stays a deliberate manual pick.
That is a small rule with a large consequence: Auto can never surprise you with a bill. The worst it can do is use the plan you are already paying for.
The same policy runs in the Tasks board, in scheduled runs and in work drained from another device, so a card that runs while you are asleep makes the same choices you would have got sitting in front of the app. The [Pathrule Auto documentation](/docs/studio/pathrule-auto) has the full policy.