The Hidden Cost of a Cheap AI Model
Key takeaways
- Benchmarks are useful when their tasks resemble the work you need done.
- Cost per usable result includes model charges, retries, and human review.
- Speed should measure how long it takes to finish the job.
- Agents can use different models for different steps, but the whole workflow needs testing.
Summarizing one email is easy to experiment with. Processing 1,000 emails a day makes every retry, delay, and manual correction part of the operating cost. Before asking whether a cheaper model is good enough, define what “good enough” means for the job.
Set a passing grade before checking the leaderboard
A benchmark measures performance on specific tasks under specific conditions. That makes it useful evidence, but its relevance depends on how closely those tasks match yours.
Classifying customer emails and interpreting ambiguous contract clauses demand different things. For classification, you want consistent choices from a fixed set of categories. Contract review requires attention to context and exceptions, with potentially greater consequences when something gets missed.
Start with a small set of real work. For example, collect 10 emails to classify, 10 documents to summarize, and 10 replies to draft. Define the passing criteria before comparing models:
- Classification: Choose the correct category from the approved list.
- Summarization: Preserve dates and amounts without adding unsupported information.
- Drafting: Include the necessary guidance without making unverified promises.
Those 30 examples are a starting point. They can reveal which tasks repeatedly need human correction, but they cannot establish that rare failures are under control.
A model’s score on your work gives you something concrete to compare with its benchmark reputation.
Count the cost of a usable result
Token pricing belongs in the calculation. Tokens are the units models use to process text, and your bill depends on how much input and output each task requires.
The bill also keeps growing when an answer needs another attempt. If someone then spends time checking and fixing it, that labor belongs in the calculation too.
A useful measure is cost per usable result:
(model charges + retry charges + human review costs) ÷ results actually used
Consider a hypothetical batch of 1,000 tasks. Model A costs ₩10,000 to run and requires two hours of corrections. Model B costs ₩30,000 and requires 20 minutes.
The extra ₩20,000 buys back 100 minutes of review time. Whether that is worthwhile depends on the value of that time in your workflow. The example is a purchasing calculation, not a claim about any particular model.
If quality and review time are comparable, the cheaper model has a straightforward advantage. If they differ substantially, the token price tells only part of the story. Someone still has to pay for the cleanup.
Measure the time until the work is finished
“Fast” needs a definition.
In a chat interface, the delay before the first text appears can matter a great deal. For a batch of 100 documents, the more useful question is when all 100 summaries will be ready.
Agents expand that measurement further. An agent can search for information, use workplace tools, and save results. Each step adds waiting time, so the model’s response speed is only one part of the total.
Suppose one model answers in two seconds but needs three rounds of revision. Another takes five seconds and produces a usable answer on its first attempt. The second model can finish the job sooner despite responding more slowly.
Track task completion time, including revisions and tool calls. Look beyond the average when response times vary widely. The unusually slow cases help explain where users spend too long waiting—and where they may abandon the task.
A quick first sentence feels good. A completed job is what lets someone move on.
Match each agent step to its difficulty
A customer support workflow might classify a request, retrieve relevant information, draft a reply, and determine whether a refund is allowed. Those steps vary in difficulty and in the consequences of a mistake.
That gives you room to test less expensive models for classification and information extraction. For complicated exceptions, use a model that performs better on your evaluation of that specific work.
Splitting the workflow introduces its own problem: handoffs. If an early step drops a crucial detail, the next model may make a perfectly plausible decision from incomplete information.
Measure end-to-end completion rate alongside the performance of individual steps. Did the agent choose the right tool? Did it pass the correct information? Did the requested result actually get created?
Fluent prose is one part of success. An agent also has to carry the task through.
The best model choice depends on the total cost of finishing work to your required standard. Compare what you spend on model usage with what you spend reviewing, correcting, and waiting. The useful question is how much a finished job costs.
Comments
Loading comments...