Case note
The true cost of reasoning models vs cheap models
A practical buyer question: what is the true cost of a reasoning model compared with a cheaper or open-weight model?
A rate card answers what one call is billed at. It does not answer what a completed, accepted job costs. Two defaults hide that difference.
The first default is to send almost everything to a top reasoning model. Those models earn their keep on extended analysis, tradeoffs, or multi-step planning. They are a poor fit for lookup, extraction, formatting, or filling a template. When the done definition does not use that extra capability, you still pay for a longer call.
The second default is to send almost everything to a cheaper hosted model, or to an open-weight model, because the inference line looks smaller. Cheap per call is not cheap per finished job. Unusable outputs get sent again. Reviewers rewrite. Failures get escalated. Open-weight models also add serving, upgrades, evaluation, and reliability work, so their cost is not only the hardware or the API line.
Hot take, stated as opinion and not as a measurement: defaulting every task to one tier costs more than picking the "wrong" sticker price. A reasoning model is the expensive mistake when the job never needed that thinking. A cheap or open-weight model is the expensive mistake when retries, review, failure handling, and operations become the real bill.
Synthetic example. A team sends field mapping through its strongest reasoning model, and messy analysis to a cheap model, then to an open-weight setup when that route fails. The mapping did not need extended analysis. The analysis needed extra attempts and review. This illustration is not customer data.
What to inspect
- Usage exports by model name or tier, including cheaper hosted models and open-weight routes.
- Attempt counts, finish reasons, and IDs that group attempts for the same task.
- Work records: accepted, rewritten, or abandoned, plus notes on extra review.
- Failure-handling records: escalations, fallbacks, and operational tickets for open-weight routes.
Vague jobs make any tier look worse. See Requirements and task decomposition for AI agents. To test a routing change, use Before and after: measuring AI quality, cost, and time. See also proof.
One next action
Sample completed tasks from one workflow. Tag each as extended analysis, or as extract, format, lookup, or template work. Note the route used, and whether extra attempts, review, or failure handling appear in the records.
If you want help lining those usage and work rows up, Overdrive helps you maximize your AI spend from inside your AI assistant. It is a remote MCP server with OAuth sign-in, and it works today in Claude, ChatGPT, and Grok Bot (setup steps). Start with a labeled sample pack and expand the lineage on each figure. Using Overdrive with your own company data is still in security review. The plan is for you to connect the tools you already use instead of uploading files, and those connectors are not available yet.
Claims and caveats
- This post claims that the billed price of a call is not the same as the cost of a completed job, that a reasoning model can be more than a task needs, and that cheaper or open-weight models can carry retries, review time, failure handling, and operations.
- The routing default described as a "hot take" is opinion. It is not a measurement, and it is not presented as a result.
- The post does not report totals, rates, or money outcomes. It does not compare token prices or publish a benchmark, and it does not say what any team would have spent under a different policy.
- The short illustration is a synthetic example. It is not customer data and it is not a result.