The AI price war is real. The simple story is not.
If model prices keep falling, why does shipping an AI feature still require careful cost design?
Because a token price is only one line in the bill. A production request also carries context retrieval, tool calls, retries, observability, storage, moderation, and the human cost of a wrong answer. The useful question is not “which provider is cheapest?” It is “which system produces an acceptable result for this job at a predictable total cost?”
What the official price cards actually say
Provider price pages are the source of truth, and they change. OpenAI’s published GPT-5.2 price card lists $1.75 per million input tokens and $14 per million output tokens, with cached input at $0.175. Anthropic’s current platform page lists Fable 5 at $10 per million input tokens and $50 per million output tokens. DeepSeek publishes separate cache-hit, cache-miss, peak, and off-peak rates for its V4 models.
Those numbers are not directly comparable without matching the workload. An application that sends a large repeated system prompt may benefit from caching. A batch classifier may qualify for a different processing tier. A tool-using agent may generate more output and more external calls than a short answer endpoint.
| Cost question | Why it matters |
|---|---|
| Input tokens | Long instructions and retrieved documents can dominate spend. |
| Output tokens | Reasoning and verbose answers often cost more than the prompt. |
| Cached input | Repeated context may be billed differently from new context. |
| Processing tier | Batch, standard, and priority paths can have different prices and latency. |
| Tool and platform calls | Search, storage, reranking, and execution can sit outside token billing. |
The comparison that survives a price change
Build a small evaluation set from real requests, not a leaderboard screenshot. Include easy, ordinary, ambiguous, and failure-prone examples. Record:
- Whether the answer meets the task’s acceptance rule.
- Input and output tokens, including cached tokens where the provider exposes them.
- Retries, tool calls, and timeouts.
- Human review time and the cost of an incorrect answer.
- Tail latency, not only the average.
Then calculate cost per accepted task. A model that costs more per token can still win if it needs fewer tokens, fewer retries, or less review. Conversely, a very cheap model can be expensive when its output has to be checked or repaired.
Where competition helps builders
Competition gives teams more room to experiment. It also makes architecture choices less permanent. You can use a smaller model for extraction, reserve a stronger model for ambiguous cases, and move repeated context into a cache or retrieval layer. The design should be based on measured quality and failure behavior rather than a permanent promise about any vendor.
The strongest savings usually come from reducing unnecessary work:
- Retrieve only the passages needed for the request.
- Put a limit on output length and tool-loop depth.
- Cache stable instructions and repeated context when the provider supports it.
- Route by task difficulty, then review the routing errors.
- Use batch processing for work that does not need an immediate response.
These controls also improve reliability. Smaller prompts are easier to inspect, bounded loops are easier to recover, and an explicit fallback is easier to explain to a user.
What not to conclude from a price table
Do not treat a promotional rate as a long-term budget. Do not infer quality from a provider’s model name. Do not compare one provider’s cached-input price with another provider’s uncached price. Do not call a consumer subscription an API cost substitute. And do not claim a percentage saving unless you can show the traffic mix, token counts, evaluation rule, and time window behind it.
Pricing pages also do not answer questions about data handling, regional availability, retention, rate limits, or service reliability. Those belong in the provider’s current terms and developer documentation, then in your own deployment review.
A practical decision rule
Start with two or three candidates and a fixed test set. Choose the least expensive option that meets your quality, safety, latency, and operational requirements. Re-run the set whenever you change prompts, retrieval, model versions, or traffic shape. Keep the measured result in your release notes so a future price cut is an input to a decision, not the decision itself.
The next question is more valuable than “who won the price war?” Ask: what does one successful, reviewed task cost in my product, and what would make that number worse?
Sources
Checked 2026-08-29.
