When a cheaper AI model produces better unit economics

A cheaper AI model has better unit economics when it meets the task’s acceptance criteria at a lower cost per accepted result. Price per token is only the first variable. Accuracy, retries, review time, latency, and escalation determine whether the cheaper request remains cheaper after the workflow is complete.

Use cost per accepted result, not price per request

The useful formula is:

Cost per accepted result = total model cost for the test ÷ number of outputs that pass the acceptance check.

Consider a hypothetical 100-task test. Model A costs $0.50 and produces 90 accepted results; Model B costs $2 and produces 98. Model A costs about $0.0056 per accepted result, while Model B costs about $0.0204. The cheaper model still wins in this example, but only if the ten rejected cases can be handled without adding more than the difference in retries or review work.

Start with the task, not the model family

Build a test set from the workflow you intend to ship. Classification needs known labels. Extraction needs expected fields and tolerance rules. Customer replies need policy checks and a human-readable rubric. Code changes need tests. A general benchmark cannot replace these product-specific acceptance conditions.

1. Collect representative easy, normal, and difficult cases.
2. Define what counts as accepted before running any model.
3. Use the same prompt, tools, and context where the APIs permit it.
4. Record token cost, retries, latency, and manual review time.
5. Compare the total workflow cost, not only the first call.

Routing can preserve savings without treating every task equally

A practical architecture sends routine tasks to the lower-cost model and escalates cases that fail a deterministic check, fall below a confidence rule supported by the application, or require capabilities the first model does not provide. The escalation condition should be observable. “This looks hard” is not a production rule.

Useful gates include schema validation, required-field checks, test execution, citation presence, policy rules, or a separate evaluator that has been tested against human decisions. Monitor both false acceptance and unnecessary escalation: the first harms quality, while the second quietly removes the cost advantage.

When the cheaper model may be the wrong choice

• The task is high-risk and a small quality difference has a large consequence.
• Volume is low enough that engineering and evaluation cost exceed token savings.
• Retries or human review erase the lower list price.
• The model lacks a required context size, modality, tool, region, or compliance option.
• Latency or rate limits do not fit the product even when token price does.

Build a decision table for each workflow

Question	Evidence to collect
Does it meet the quality bar?	Acceptance rate on representative tasks
Is it cheaper after failures?	Cost per accepted result, including retries
Can difficult cases escalate?	Observable routing rule and escalation rate
Does it fit operations?	Latency, rate limits, region, and required features
Will the answer stay valid?	Scheduled retest after model or prompt changes

Compare prices without turning price into a quality claim

The CostUse model rate table can narrow candidates by published input and output prices. It does not say which model will pass your test. Use official provider pages for the current rates, then evaluate the shortlist on the same tasks and acceptance criteria. Re-run the test when a model version, prompt, routing rule, or price changes.

Bottom line

Use the least expensive model that reliably clears a task-specific quality bar after retries and review are included. Keep escalation rules measurable, retain a difficult-case path, and monitor cost per accepted result in production. That approach produces defensible savings without pretending that a lower token price proves equal performance.