Requesty
Back|AUG '26AI MODELS / COST OPTIMIZATION
5 MIN READ|

36x the price for 22% more quality: the Pareto data that should decide your model mix

Last updated

The most useful number published in the last week of August was not a benchmark score. It was a ratio.

Glean released a Pareto frontier analysis across 37 models and reasoning configurations over 1,000 enterprise tasks. The finding: the gap between the cheapest and the priciest frontier model was 36x on price and 22% on quality score.

Not 36x for 36x. Not even 36x for double. 36x for 22%.

If that ratio holds anywhere near your workload, then any deployment that sends all of its traffic to one premium model is paying an order of magnitude premium for a fraction of a quality band, on the majority of requests that never needed it.

The ratio shows up everywhere once you look for it

Glean's number is the cleanest statement of the pattern, but it is not the only measurement from that week.

Reasoning effort, same model, 2x cost inversion. Cline benchmarked Opus 5 at different effort levels on FrontierCode and found medium effort ranked second at $4.31 per task while xhigh ranked sixteenth at $9.14 per task. Half the cost and ten percent better output. The expensive configuration was also the worse configuration. Most agent harnesses default to high effort.

Provider spread, identical weights, 11x. Brett Harrison found an 11x spread between the cheapest and most expensive provider of a single open weight model on one marketplace. Same weights. Same model card. We measured the same phenomenon in depth in same weights, twelve providers.

Cache hit rate, same task, 5x effective input cost. A developer running the same coding workload across three surfaces measured 96% cache hit on two of them and 19% on the third. Given that 86% of agentic token burn is cached input against 7.3 trillion tokens per week of agent traffic, cache configuration is close to the entire cost story for agents.

Model tier, real enterprise spend, 11% share. FT reporting via Ramp data put Anthropic's most capable model at just 11% of corporate AI spending on that platform, with cost named as the reason. The market is already voting with a mix.

Four independent measurements, four different mechanisms, all pointing at the same conclusion: above a capability floor, price and quality have largely decoupled, and the variance that remains lives in configuration rather than in model choice.

What a real model mix looks like

Bindu Reddy published a compact version of the allocation logic in the same window, predicting that within six months 95% of tasks will be handled by small open weight models with the large models reserved for genuinely complex work, and that the majority of token volume will sit on the small side.

Our own routing data agrees with the shape. Here is the allocation we see working, expressed as task classes rather than model names, because the names change monthly and the classes do not.

Cheap tier, high volume. Classification, extraction, tagging, routing decisions, short summarisation, format conversion, first pass linting, embedding preparation. This is usually 60 to 80% of request volume and it should be on a Flash tier model. With GLM-5.3-Flash at $0.15 per million input and Qwen3.8-Flash at $0.16, the price of this tier fell again in August, which we covered in the open weight frontier post.

Mid tier, working horse. Routine code edits, test generation, document Q&A, structured output with a defined schema, multi step tool use with a short horizon. The mid tier is where recent price cuts hit hardest: OpenAI dropped GPT-5.6 Sol by over 20% for three months, which Cline reported as Sol at 50% off inside their product and more than 3x cheaper than the top Anthropic tier.

Premium tier, judgment only. Architecture decisions, long horizon planning, ambiguous requirements, adversarial review, anything where a wrong answer is expensive to detect. This should be a small share of volume and a meaningful share of spend, and that is fine.

The mistake is not using premium models. The mistake is using one tier for everything, in either direction. A user who put $10 into a cheap model as an overflow lane and burned it on simple tasks discovered the other failure mode: a cheap model in an unoptimised loop with high effort and no caching beats an expensive model in a tuned one.

The five things to fix before you change model

Switching models is the most visible lever and usually not the largest one. In order of return per hour of work:

1. Audit reasoning effort per route. Find every call site that sets effort high or xhigh and justify it individually. Cline's data says the default is often both more expensive and worse. Requesty exposes this through reasoning controls, and it is worth noting that providers do not all honour the parameter identically, which we documented in reasoning effort ignored by providers.

2. Verify your cache hit rate is high. Not that caching is enabled. That the hit rate is 90% or better. Turn on automatic caching, then read the real number out of usage analytics. A 19% hit rate on an agent loop is a five figure annual line item hiding in plain sight.

3. Constrain provider selection on open weight models. An 11x spread means the default provider is a coin flip on cost. Load balancing policies and latency routing let you express the tradeoff once instead of per request.

4. Get per route cost attribution before you optimise. Cost tracking plus request metadata attribute spend to a feature, a user or an agent step. Without this you are guessing which 20% of traffic is 80% of the bill. For agent specific patterns see how to cap runaway agent spend.

5. Only then change the model. And change it via a managed policy so that the next change is a config edit, with fallback policies behind it so a provider incident does not become an outage.

Why the ratio will get wider, not narrower

The obvious objection is that a 36x spread is a temporary artifact of a young market and will compress. Our read is the opposite, for a structural reason.

Premium model pricing is anchored to frontier training and serving economics, which are not falling quickly. Cheap tier pricing is anchored to open weight competition, which is intensifying: five open weight releases landed in nine days in August, several at Flash prices with 1M token context windows and permissive licenses. Dax Patel put the margin argument bluntly, arguing that token prices could be much lower and that intermediaries renting GPUs are adding 40% or more on top.

Two price curves with different slopes produce a widening gap, not a converging one. And every point of widening increases the return on getting your mix right.

The teams that treat model selection as a per task routing decision rather than a per project procurement decision will run the same quality at a fraction of the cost. That is not a prediction, it is arithmetic on published numbers.

See current prices for every model and provider in the models catalog, the cheapest model rankings and our pricing comparison. For a like for like on routing platforms, we keep honest pages on OpenRouter, LiteLLM, Portkey and Helicone.

Start routing on Requesty and stop paying premium rates for classification.

Frequently asked questions

What did the Glean Pareto analysis measure?
Glean published a Pareto frontier analysis covering 37 models and reasoning configurations evaluated across 1,000 enterprise tasks. The reported headline was a 36x price gap between the cheapest and the priciest frontier model, for a 22% difference in quality score.
Does that mean I should always use the cheapest model?
No. It means quality and price are close to independent above a capability floor, so the right unit of decision is the task class, not the deployment. Route judgment and long horizon planning to a strong model, and route classification, extraction, summarisation and routine edits to a cheap one.
Where does the extra cost usually come from if the model is already cheap?
Three places in our data: reasoning effort defaults set too high, cache hit rate collapsing on one surface, and provider selection on open weight models where the spread between hosts reaches 11x for identical weights.
How do I implement a model mix without maintaining routing logic in application code?
Define routing policies in the gateway and have the application ask for an intent rather than a model. The policy holds the model choice, the fallback chain and the effort setting, so tuning the mix never requires a deploy.
Related reading

Start building with Requesty

One line of code. 600+ models. Full control.

Speak to founders