Engineering brief
The Cheaper Model That Costs More: Why Custom Evals Matter
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- Now
- Warnings
- None
Cheaper AI models often cost more per task because they waste tokens. Vals AI shows how custom evaluations saved his team 90% on AI spend while maintaining output.
Model selection based on token price alone is leading to hidden cost overruns. Custom evals are the fix.
Watch if you are actively deploying AI agents and want to avoid budget surprises from token inefficiency.
Summary
The proposal. Model cards and broad benchmarks give a misleading picture of real-world model performance. Rayan Krishnan from Vals AI argues that the "jagged frontier" — inconsistent performance across specific tasks — means organizations cannot rely on aggregate scores to choose models. For example, a cheaper model like Opus 5.5 ($4 input) appears cost-effective on paper but actually costs 14% more than Fable 5.1 on a tax benchmark because it uses more tokens to compensate for lower intelligence.
The cost paradox. Cheaper models can become more expensive in practice. The speaker shows that on an Excel modeling benchmark for LBO tasks, the apparent leader falls off the Pareto frontier when you isolate that subcategory. Teams that buy cheaper models based on input/output token costs often end up spending more per task while getting worse results. This directly challenges the common assumption that optimizing for token price is a good cost-control strategy.
The internal case study. Krishnan’s own team of 10-12 engineers spent $1.5 million on AI tokens in a single month when given unlimited access. That is roughly 10x their monthly salary cost. The solution was to build custom evaluations that measured which models actually solved their tasks efficiently. By using these evals to right-size model usage, the team cut token spend by 90% while maintaining output. This is a concrete, if extreme, example of the ROI of eval infrastructure.
The eval framework. To build useful evals, the speaker emphasizes three properties: validity (do the tests reflect real work?), reliability (enough samples for consistent results), and discriminability (can the evals distinguish between models?). He also warns against reward hacking — agents that call other models or give multiple answers to increase scores. Evaluations must be multi-turn and sandboxed properly. The source of data matters: companies should mine their own history of work (PRs, emails, SharePoint) to create relevant tasks.
The competitive advantage. Krishnan claims that most organizations have institutional knowledge locked in employees' heads or legacy systems. Custom evals allow codifying that knowledge into reproducible tests. Once built, evals enable right-sizing, negotiation with vendors, intelligent routing between models, and fine-tuning. This transforms AI cost management from guesswork into engineering discipline.
The vendor angle. This talk is a product pitch for Vals AI's evaluation services. While the data and case study are compelling, the speaker sells the solution. Engineering leaders should take the message — build internal evals — but beware of over-relying on a third-party benchmark provider whose incentives are to sell more evaluations. The operational challenge of curating work-history datasets is undersold.
My take
I find the cost paradox compelling but not new to anyone who has run models at scale. The real value is the framework for building evals: validity, reliability, discriminability. However, the talk quietly assumes you have the data to create meaningful evals. Most organizations don't have clean PR histories or email archives ready for this. The operational lift of curating those datasets is undersold. I'm also skeptical that a single benchmark provider can serve every organization's specific needs. The message to build evals is right; the solution being sold might not be the only one. Teams should start by instrumenting their own AI usage and building simple pass/fail tests before buying a platform.
What to do with this
- Audit your current AI token spend per task across all models used.
- Identify one recurring workflow and create a small eval suite with 10-20 representative tasks.
- Run a pilot comparing a cheaper model vs your go-to model on that eval to measure total cost.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
Cheap models beat frontier models at writing like a human
Tone-Bench tests whether AI models can write like one specific human. Its most practical lesson: cheaper models with long prompts may beat frontier models on…
Why a faster model can make your users wait 8x longer
MiniMax's M3.1 flash is faster per token, but doubling concurrency lifted p95 wait from 1.5s to 11.3s. Evaluate the whole job, not the model.
AI's messiest test: insurance claims buried in faxes and 8GB PDFs
Insurance claims remain paper, fax, and 8GB PDFs. AI gets useful only after clean data, human review, and portfolio analysis. A vendor benchmark shows why.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.