Choosing a Model for Vibe Coding

The tool determines how you work; the model determines how well it reasons. Confusing the two is behind most bad choices.

Why the model matters more than expected

Three properties differ across tiers and directly affect the work:

Reasoning depth. Holding many relations at once. The gap is widest here: a subtle bug gets found by a strong model while a weaker one circles it.

Behaviour over a long chain. An agentic task is dozens of steps. A model that loses the goal midway is useless regardless of individual answer quality.

Honesty about not knowing. A model that admits uncertainty is cheaper to debug than one that invents confidently.

With an honest caveat: the difference between models is smaller than the difference between a good and a bad brief. A precise address and a checkable criterion buy more than moving up a tier.

Cheap versus expensive in practice

A cheap, fast model wins where the solution is known and needs applying carefully: mechanical edits, repository reconnaissance, generating glue, uniform changes across a list. The quality difference on such tasks is near zero while the speed difference is immediate.

An expensive model pays off where thinking is required: the cause is unknown, many constraints must be held, the cost of error is high, no automatic check exists.

The practical marker: if you can describe exactly what to do, take the cheap one. If you need somebody to figure it out, take the expensive one.

Routing

The pattern that yields most of the saving without losing quality:

Analysis and plan on the strong model. Once, expensive, short.
Execution of the plan on the fast one. Many steps, cheap.
Verification as a separate pass, ideally on a different model: the same one repeats the same wrong assumption.

It works because a plan is short text that is expensive to devise and cheap to apply. The mechanics on a real project are on the blog: the model router that cut our costs.

What actually cuts spend

In order of effect, and it is not the order people expect:

Context. Every step resends the accumulated history. A long dirty conversation on a cheap model easily beats a short session on an expensive one for cost. One session, one task.
A precise task address. “Look at this function” rather than “figure out why it is broken”: the second sends the agent through half the repository and you pay for everything it read.
Step limits. An agent restarting failing tests twenty times spends more than the gap between tiers.
Delegating reconnaissance. Searching a large repository returns three pages of output; a subagent reads them in its own context and returns a paragraph.
And only then, changing model.

The conclusion worth remembering: changing model changes price per token, while a bloated context multiplies the token count at every step. The second is stronger.

Context spend in detail: Claude Code limits and agent memory. Choosing a model by criteria: the best AI for code. The overview is in the vibe coding guide.

FAQ

What affects the result more, the tool or the model?

The model drives code quality; the tool drives how you work. The same model in chat and in an agent gives different results, because the agent sees test output. So more precisely: the tool decides whether the model can check itself, and the model decides how well it reasons.

How do I reduce spend when working with an agent?

Shrink context rather than downgrading the model. Every step resends the whole accumulated history, so a long dirty conversation on a cheap model easily costs more than a short session on an expensive one.

What is model routing?

A pattern where simple steps go to a fast cheap model and hard ones to a strong model. Analysis and planning happen once on the expensive model, and mechanical execution of that plan happens on the cheap one. This is where most of the saving comes from without losing quality.