← Explained

Living cornerstone · v0 · Last reviewed 2026-07-30

Which model should I use?

“Which model?” is a moving question — release cycles move the capability ceiling every few months, price changes move the cost floor between them, and last quarter's obvious pick quietly becomes this quarter's overpay.

So this page holds the part that stays true: six use cases, and for each one the questions that decide. Run them against whatever exists the week you are choosing — and when specific picks land here, it will be because the desk tested them, never because a launch post said so.

Coding

What is the hardest task it must clear — and inside which harness?

  • Capability ceiling: judge candidates on your hardest recurring task — a cross-file refactor, a real debugging session — not on autocomplete, which nearly everything now handles.
  • Latency: an in-editor completion has to feel instant, while a background agent fixing a ticket can take minutes — decide which job you are hiring for before you time anything.
  • Context needs: how much of the repo must be in view at once — one file, a module, or the whole service and its tests?
  • Ecosystem: the editor, CLI, or agent harness you already work in decides which candidates you can actually drive all day.
  • Cost floor: a coding assistant runs from morning to night, so a small per-task difference compounds into a real line item across a team and a year.

How to decide: Pull a dozen real tasks from your own last two weeks — the bugs, the refactors, the reviews — and run every candidate through the harness you would actually use, on your actual repo. Grade the diffs, not the demos. Let the hardest recurring task set the bar and the most common task set the budget; when two candidates clear the bar, take the cheaper, faster one. Re-run the same tasks whenever a major release or a price change lands — the answer has a shelf life.

Writing

Whose draft needs the least editing to sound like you?

  • Capability ceiling: holding an argument and a voice across two thousand words is a different skill from polishing one sentence — test at the length you publish.
  • Revision behaviour: a strong writing model applies an edit note surgically; a weak one rewrites the whole piece and loses what was working.
  • Context needs: your style guide, source notes, and past pieces have to fit in the window if the output should sound like you rather than the internet average.
  • Latency: rarely the constraint here — one good draft an hour beats ten instant mediocre ones, so buy quality, not speed.
  • Cost floor: writing volume is tiny next to automation workloads; optimising pennies on prose is effort spent in the wrong place.

How to decide: Take three pieces you already shipped, hand every candidate the same brief and the same source notes, and compare each draft to what you actually published. The measure is edit distance: how much work stands between the draft and something you would sign. Then test one revision round — give it a single pointed note and watch whether it fixes that and only that. Blind-read the results before you check which candidate wrote what.

Research & analysis

Can you audit its claims back to the source faster than doing the work yourself?

  • Faithfulness: the expensive failure is a confident wrong number, not a slow answer — how reliably does a candidate ground its claims in the documents you gave it?
  • Context needs: whole filings, transcripts, and datasets in the window beat summaries of summaries — window size decides what you can hand over intact.
  • Capability ceiling: multi-step quantitative reasoning — margins, growth rates, unit conversions across documents — is where candidates actually separate.
  • Latency: minutes are acceptable for work that would otherwise take you a day, which makes this the use case where slower, reasoning-heavy settings earn their keep.
  • Tool use: whether a candidate can run a calculation or a search to check itself, instead of reciting from memory, changes how far you can trust the output.

How to decide: Build a small private eval from documents where you already know the answers — a filing you have modelled, a report you have already picked apart. Score every candidate on grounded citations and numerical accuracy, and weigh cost per corrected error rather than cost per token: a cheap model that quietly gets numbers wrong is the most expensive option on this page. Whatever you pick, never accept a claim you cannot trace back to a page you provided.

High-volume automation

What is the smallest model that clears your accuracy bar?

  • Cost floor: at millions of calls the bill is price times volume and almost nothing else — the cheapest model that clears your accuracy bar wins the economics.
  • Accuracy bar: decide the acceptable error rate before testing anything, or the first impressive demo will decide it for you.
  • Throughput: rate limits, batch pricing, and queue depth matter more than single-request latency once volume is the point.
  • Routing: most requests are easy — send the easy majority to a small model and escalate the hard minority, rather than paying ceiling prices for floor work.
  • Stability: pin versions and re-run your eval before any upgrade — a silent model swap changes outputs across the entire pipeline at once.

How to decide: Label a few hundred real examples as a golden set and write down the error rate you can live with before you test anything. Then try candidates from cheapest upward and stop at the first that clears the bar — capability beyond the bar is margin you are donating. Price the winner at your real volume, and check whether a router that splits easy traffic from hard beats any single model on the blended bill.

Local & private

Which constraint is real — and what does it actually forbid?

  • Privacy: name the binding constraint precisely — regulation, a client contract, or preference — because each forbids different things, and some are satisfied by paperwork rather than hardware.
  • Hardware ceiling: memory and GPU decide which open-weight sizes and quantisations you can run at all — capability follows hardware here, not the other way round.
  • Ecosystem: licences, runtimes, and quantised builds vary widely across the open-weight world — the practical question is what runs well on your stack, not what tops a chart.
  • Operational burden: running your own models makes you the platform team — serving, upgrades, and evals all land on your calendar.
  • Cost structure: owned hardware is a fixed cost you pay even at idle, while per-token rental costs nothing when quiet — utilisation decides which is cheaper.

How to decide: Write the constraint down in one sentence and check what it actually forbids — "no training on our data" is a contract clause, "data never leaves the building" is a hardware purchase, and confusing the two is the expensive mistake. If the answer is genuinely local, size candidates to the hardware you have, quantisation included, then test whether the quality that fits still clears your task bar. Run the ownership arithmetic before you buy anything.

Agents

What does a completed task cost — not a token?

  • Capability ceiling: per-step error compounds — a small gap in single-step reliability becomes a chasm across a forty-step run, so the ceiling matters more here than anywhere.
  • Tool-calling reliability: following a schema exactly, recovering from a failed call, and knowing when to stop separate candidates faster than raw intelligence does.
  • Context needs: long trajectories have to stay coherent — the model must still act on what step three found when it reaches step thirty.
  • Latency: wall-clock time is per-step latency multiplied by step count, so a slightly slower model can double the length of a run.
  • Cost floor: an agent multiplies tokens through every step and retry — judge cost per completed task, never cost per request.

How to decide: Measure end-to-end completion on your own workflows — the task finished to standard with no human stepping in — because single-turn performance barely predicts multi-step behaviour. Count interventions, divide total spend by completed tasks, and compare candidates on that number alone. Once a loop works at all, test whether a stronger model planning while cheaper models execute beats one model doing everything.

Run the numbers

Two legs of this decision are pure arithmetic, and the desk keeps instruments for them.

Changelog

  • 2026-07-30 — framework published; picks pending hands-on review

Last reviewed 2026-07-30. Amendments land as changelog entries — nothing on this page changes silently.