Most bloated AI bills don't come from using an expensive model -- they come from using the right model the wrong way. Here's the checklist I use before scaling any integration to production.
Before optimizing anything, you need to know where the money is going. Most teams optimize blind: they drop to a cheaper model, notice quality drops, and go back to the expensive model without understanding what happened. The real first step is counting tokens before you spend, not after.
With this you can build a real cost-per-request dashboard, by endpoint, by customer. Without that visibility, any "optimization" is a shot in the dark.
The most expensive mistake is using the same model for everything. A typical production pipeline has tasks of very different complexity: classifying a support ticket isn't the same as drafting a contract. Current per-million-token prices illustrate the gap well:
| Model | Input | Output | Typical use | |---|---|---|---| | Claude Haiku 4.5 | $1.00 | $5.00 | Classification, simple extraction, routing | | Claude Sonnet 5 | $3.00* | $15.00* | Production volume, agents, coding | | Claude Opus 4.8 | $5.00 | $25.00 | Maximum-complexity tasks, long reasoning |
*Sonnet 5 has an introductory price of $2.00/$10.00 through August 31, 2026.
The practical rule: if 80% of your volume is classification or deterministic extraction tasks, that 80% doesn't need the most expensive model. Reserve the large model for the 20% that actually justifies it -- and measure, don't assume, which is which.
If your application resends the same system prompt, the same tool set, or the same context document on every call -- and most do -- you're paying full price for identical text over and over. Prompt caching solves this directly: tokens read from cache cost roughly 10% of the normal price.
I dedicate a full article to this technique later because its impact is usually the largest of all -- but the short rule is: any block of text repeated across more than two consecutive requests should carry `cache_control`.
If your use case doesn't need an instant response -- mass classification of historical tickets, overnight summary generation, dataset processing -- the Batch API costs 50% less than normal synchronous calls, with no change in model quality.
Combining Batch API with Haiku for mass classification tasks can cut that part of the pipeline's cost by an order of magnitude compared to synchronous calls on the top model.
It's easy to obsess over reducing input tokens and forget that output is also billed -- and at a price 5x higher than input on most models. Two adjustments that lower output cost without degrading quality:
- **Explicit effort.** The `effort` parameter (`low`/`medium`/`high`/`xhigh`/`max`) controls how much the model "thinks" before responding. For routine tasks, `medium` or even `low` usually gives results equivalent to `high` at a fraction of the reasoning-token spend. - **Ask for exact format, not prose.** A structured output (`output_config.format` with a JSON schema) prevents the model from adding explanations, preambles, or courtesy text no one will read.
Sending too much also costs money. It's common to see RAG pipelines that stuff in 15 documents "just in case" when the model only needs 3 to answer well. Every extra document is paid tokens that also dilute the model's attention toward what's relevant (the "lost in the middle" problem). Before raising the retrieved-context limit, measure whether it actually improves the answer or just inflates the bill.
Combining these six techniques -- measure before optimizing, tier models, aggressive caching, batch for async work, effort/format control, and disciplined RAG -- typically cuts total cost by 40% to 70% with no difference the end user would notice in quality.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel