Signal, model choice

The Cheapest Correct Answer Wins

Match the model tier to the task, or pay twice: once in wasted tokens, once in silent failure.

The Curio Team · 3 min readWritten with AI from the sources below and checked against them before publishing.

Most teams pick one model and route everything through it. That default is quietly expensive. A frontier model summarizing a two-line email wastes tokens and adds latency you never needed. A tiny model asked to reason through a multi-step migration fails, but it fails politely, returning confident text that looks fine until it breaks in production.¹

Here is the rule we live by. The cheapest correct answer wins. Not the smartest model, not the fastest, our cheapest option that still gets the task right every single time.

The cheapest correct answer wins.

Model families ship in tiers for a reason. Anthropic offers Haiku, Sonnet, and Opus. OpenAI splits its lineup by capability and price the same way. Each step up buys deeper reasoning and costs more per token, often several times more. That gap is the whole decision.^{1 2}

So we match the tier to the task. Classification, extraction, short rewrites, routing, tagging: these are light work. A small fast model handles them for pennies, and it answers in a fraction of a second. Save the heavyweight for tasks that actually need it.

When does a task need it? When the work has many steps, hidden constraints, or a right answer that is hard to check by eye. Code that must compile. Legal or medical nuance. Long documents where one missed clause changes the meaning. Here a light model's silent failure costs far more than the token savings.

The trap is that failure is invisible. A weak model rarely says I cannot do this. It produces a plausible answer, and plausible is the most expensive kind of wrong. You ship it, a user trusts it, and you pay in support tickets and lost trust instead of cents.²

Cost is not the only axis. Latency compounds too. A frontier model might take three or four seconds where a light one returns in under one. In a chat product that lag is the difference between a tool people use and one they abandon. Speed is a feature, and the smaller tier often delivers it for free.¹

Routing gives you the best of both. Send every request to a cheap classifier first, let it label the task as easy or hard, then forward only the hard ones to your strong model. This one pattern often cuts our bill in half while keeping quality flat on the work that matters.

We test both ways before we commit. Run your real prompts through a cheap tier and a strong tier on the same twenty examples. If the cheap one matches on all twenty, ship it. If it misses even one that matters, step up. Twenty examples is cheap insurance against a silent miss.

Watch the version notes too. Model families improve, and a task that needed your top tier last quarter may run fine on the mid tier today. We re-benchmark on a fixed set of examples every time a provider ships an update, because yesterday's right answer can get cheaper overnight.

Money and time both bend to this. Cutting an over-served task from a frontier tier to a mid tier can drop its cost by five to ten times and shave latency at the same time. Multiply that across every call, and the savings fund the few tasks that genuinely deserve our best model.²