Which AI model gets which task — decided in ten seconds, thirty times a day. The routing discipline behind a one-person web studio.
I run a one-person web studio. Client sites, shop rebuilds, dashboards, product builds — no employees, no subcontractors. The thing that makes that workload possible isn't a secret prompt. It's a routing decision.
Most people route by importance: "this task matters, so it gets the big expensive model." That instinct is wrong, and it's expensive in both directions. You burn frontier-model quota on grunt work, and you hand genuinely hard problems to models that produce confident, wrong output you then spend an hour unpicking.
The variable that actually matters is ambiguity.
Could I hand this spec to a competent contractor, as written, and get the right result first time?
The specific models will date; the tiers won't. Plot every task on the spectrum, then send it to the matching tier.
The problem isn't fully defined yet. Architecture, system design, spec-writing, "should we even build this."
→ Frontier reasoning model. The deliverable is a spec, never code.
Well-specced, multi-file, needs judgement in the small. Implementation from a written spec, refactors, integration work.
→ Strong coding model in an agentic CLI, with the spec in the prompt verbatim.
Mechanical, high-volume, repetitive. Categorisation, data cleanup, bulk content enrichment, format transforms.
→ Local model via Ollama. A 14B model on an old 11GB GPU handles this fine — effectively free, private, always on.
Notice what's not a column: how important the task is. A make-or-break client deliverable that's fully specced is still Tier 2. A throwaway internal tool with a fuzzy brief is Tier 1 until the brief isn't fuzzy.
Every token of top-tier quota spent renaming fields or categorising products is quota you don't have when a real architectural decision shows up. Worse, it trains a habit: the big model becomes your default, and you stop noticing which tasks never needed it.
The sneaky one, because the failure is invisible at first. A fast model given an under-specified task doesn't ask clarifying questions — it picks an interpretation and runs. The output looks done. The cost surfaces later as rework, and rework always costs more than the tokens you saved.
In practice, Tier 1 and Tier 2 chain together. The spec is the artifact that makes the routing work — skip it and you're back to importance-routing with extra steps.
Take the ambiguous problem to the reasoning model. The deliverable is a written spec: decisions made, tradeoffs named, edge cases enumerated, done-criteria explicit. Argue with it. This is where the model earns its price.
Hand that spec to the executor model in an agentic CLI. Because the ambiguity has been removed, a cheaper model now performs like an expensive one.
Your review effort goes where the spec meets the implementation — did the executor honour the decisions? — not into re-litigating the decisions themselves.
Tier 3 gets dismissed because local models benchmark poorly against frontier ones. Irrelevant — you're not asking them frontier questions. For mechanical work, a 14B model running on a secondhand GPU is effectively free, private, and always on. Product catalogue enrichment, transaction categorisation, format transforms: real work that used to eat paid quota and now costs electricity.
If you're buying hardware for it: used-market VRAM-per-pound is the metric that matters, not benchmark charts.
This is how I actually work, not a theory. If you're a solo builder trying to ship without hiring, this routing discipline is the highest-leverage habit I know.