New LLM Releases: Why "Lower Unit Prices, Higher Total Bills" Happen—and How to Evaluate Models Properly
When a new generation of large language models ships, marketing pages highlight faster outputs and lower per-token prices. But the total cost of completing a real task may actually rise, because newer models tend to generate far more output tokens. This article breaks down the pricing logic behind that gap, explains why models are becoming more verbose, and offers a practical evaluation framework based on real-task benchmarks, effective output ratio, and tiered model routing.
1. A Billing Pattern Worth Watching
Every time a new generation of LLM is released, the marketing pages feature a few eye-catching numbers: 30% faster output, 20% lower unit prices. Taken individually, these look like genuine concessions. But if you shift your perspective from “how much does a token cost” to “how much does it cost to complete an entire task,” the conclusion can be completely different.
A recent public industry benchmark revealed a telling case: a new model’s average output per task grew from roughly 100,000+ tokens in the previous generation to more than 270,000 tokens—more than doubling. After recalculating with the discounted unit price, the total cost per task didn’t drop at all. Instead, it rose from about $13 to over $26.
This can be abstracted into a simple arithmetic model:
Cost per task = output tokens × unit price + input tokens × unit price= task inflation factor × original output × (1 - discount rate) × original unit price
When the task inflation factor exceeds 2 and the discount is only 20%, the total bill is guaranteed to rise. Unit prices get cheaper, but every task costs more—this is not unique to one vendor. It’s the “new pricing art” taking shape across the industry: unit price cuts make headlines, verbosity multiplies on the bill. The feeling of saving money is real, and so is the extra spending.
2. Why Models Are Becoming More Verbose
Understanding this phenomenon requires looking beyond marketing tactics to the technical nature of how model capabilities evolve.
First, deeper reasoning means longer chains of thought. Newer models generally introduce explicit or implicit reasoning processes. To solve complex problems, the model must decompose subproblems, generate intermediate hypotheses, and verify them step by step. More reasoning steps naturally consume more tokens. This isn’t waste—it’s the direct price of “thinking deeper.”
Second, self-checking causes branching explosions. Stronger models often validate their own answers through multiple paths: propose a solution, question it, then generate alternatives for comparison. This “branch–backtrack–converge” process manifests at the token level as multiplied output.
Third, long contexts and multi-turn tool calls stack up. In modern agentic workflows, models repeatedly read tool results, correct parameters, and retry failed calls. Each interaction round accumulates both input and output costs.
This leads to a structural conclusion: within this generation’s capability framework, “smart” and “concise” are inherently in tension. What vendors sell you is intelligence; what they bill you for is verbosity. This trade-off can’t be fully engineered away in the short term, so users need to confront it explicitly during model selection.
3. From Price Lists to Total Costs: A Practical Evaluation Method
Since price lists no longer reflect real costs, developers need an evaluation process built around total spending:
1. Benchmark with real tasks, not generic leaderboards. Pick 3–5 representative tasks from your own business—say, a full code refactoring, a technical design document, or a data-cleaning script—and run them end to end on candidate models. Record input/output token counts, call rounds, and the final bill.
2. Separate the “capability bill” from the “efficiency bill.” Of all the tokens in a response, how many are actionable conclusions, and how many are repetitive arguments and redundant checks? A simple metric can capture this:
Effective output ratio = information in the final deliverable / total output tokens
A model with a low effective output ratio may not be cost-effective overall, even if its unit price is cheap.
3. Route tasks by difficulty. Send hard problems to deep-reasoning, high-cost models; route routine tasks to cheap, concise ones. In practice, most day-to-day development work—format conversion, simple Q&A, boilerplate code—never needs a flagship model’s “brain.” Flagship models are for hard cases, not everyday colds—keep seeing the cheap doctor for those. A tiered model routing strategy can often cut inference costs by more than half.
4. Watch for hidden limits in subscription tiers. Some premium subscriptions advertise strong capabilities, but their usage quotas may be only half—or even less—of mid-tier plans. Calculate the actual usable allowance carefully, or you may end up with “a gym membership you can never book a class on.”
4. Signals Beyond Benchmarks: Collaboration and Capability Tiering
Two signals matter more than benchmark scores when evaluating new models.
First, spontaneous division of labor among multi-agent systems. The industry has seen news of “thousands of agents collaborating for dozens of hours to complete a large formal-verification task,” sparking “AI cracked math” discussions. A sober take: formalization is essentially translating proofs humans have already written into machine-verifiable form—compressed verification engineering, not the discovery of new mathematics. But the genuinely valuable signal is that the division of labor among thousands of agents was negotiated autonomously, with no one preassigning roles. This is the dividing line between a “tool” and a “work crew”—a sign that models are beginning to exhibit emergent, organization-level capabilities.
Second, frontier models are starting to hold back. One vendor has been observed deliberately keeping its new model’s performance on AI R&D directions (such as low-level kernel optimization and architecture improvements) at the previous generation’s level, citing concerns about distillation. This points to an emerging trend: the strongest capabilities never ship; public releases are watered down. Models used to differ only by version—going forward, we may see capability tiering between “internal” and “public” editions. Once that tiering forms, public leaderboards may only show the versions vendors want you to see, and benchmark scores deserve a discount in credibility.
5. Closing Thoughts
LLM selection is shifting from “reading spec sheets” to “computing the total bill.” Unit price, speed, and benchmark scores still matter, but what truly determines cost is how much a model’s output inflates on your real tasks—and whether your business actually needs to pay for “deeper thinking.” Build an evaluation system centered on real-task benchmarks, effective output ratio, and tiered routing, and you’ll be able to defend your budget against the “price cut” marketing narrative.
