Unbiased Pareto Is Billed as a Composite, and That Changes the Arithmetic

A composite model breaks an assumption that every comparison table in this industry is built on. The assumption is that one row equals one network: you pick a model, you send it a prompt, it produces tokens, you pay its rate. This release, listed on 17 September 2026 in a third-party public directory, is not that. It is a system that assembles answers from more than one underlying model, and it is billed as a single composite rate under a single name. The name is what the catalogue shows; the thing behind the name is a routing decision you do not control. In this month’s new LLM models that makes it the most interesting entry to price and the hardest to reason about, because the number you pay and the number of models that ran are no longer the same quantity. On OrcaRouter the new llm models catalogue lists each entry with the rate you would be charged, and on a composite that rate is the only part of the arrangement that is fully disclosed.

What a composite actually is

The design goal is straightforward: different models are better at different things, so route each request to whichever underlying model is likely to answer it best.

In practice that means a dispatch mechanism sits in front of several models. It may classify the incoming request, consult a routing policy trained on preference data, sample several candidates and compare their answers, or fall back to a second model when the first declines. Some composites are a small committee whose outputs are merged; others are a dispatcher that picks one.

Two properties follow, and both matter to a buyer.

The system’s behaviour is not the behaviour of any of its parts. Its failure modes are new — a routing mistake produces an answer that is confidently wrong in a way none of the constituent models would have been — and its strengths are new in the same way.

And the system’s latency is the latency of the whole path, not of the fastest member. If the composite consults three models before answering, the wait is closer to the sum than to the minimum, and it is more variable because routing decisions vary per request.

Why a composite rate is a different kind of price

A rate is a price per unit of work. On a single model, the unit is unambiguous: tokens in, tokens out. On a composite, the unit is still tokens, but the work behind each token varies.

If the dispatcher sends ten percent of traffic to an expensive member and ninety percent to a cheap one, the operator’s cost is a blend. A single composite rate prices that blend. It is a perfectly reasonable way to sell the product — it is simpler for the buyer than a menu of members plus a routing policy — and it is simultaneously the point where the comparison stops working.

You cannot compare a composite rate with a single model’s rate as if they were two prices for the same thing, because the composite rate is an average over a distribution of underlying costs. Whether it is good value depends on how the routing distributes your particular traffic. Send a composite only easy requests and you are paying a blended rate for work the cheapest member could have done. Send it only hard requests, and it may route everything to its most expensive member while still charging you the blend — which is a good deal, and also a reminder that the operator’s margin depends on traffic shape rather than on yours.

The measurement that does answer the question

Because the routing is opaque, the useful evaluation is behavioural. You cannot read the routing policy, so you measure its effects.

Build a task set that spans the difficulty range you actually serve, with a known correct answer or a defined acceptance criterion for each. Run it through the composite and record, per task: cost, latency, and whether the criterion was met. Then do the same with the single models you would otherwise use, chosen at the two price points the composite sits between.

The comparison you get is the only one that matters: cost per accepted task, at matched or better quality, against a named alternative. If the composite wins on that measure across your distribution, its internal opacity is an implementation detail. If it wins only on the easiest third of your traffic, you have learned that the routing is not doing what you hoped, and that is worth knowing before you build a dependency on it.

The operational questions a composite creates

Three questions come up in practice and none of them has a benchmark answer.

Determinism. Does the same input produce the same output twice? If routing depends on a policy that adapts, or on sampling across candidates, it may not. For interactive chat that is invisible. For a system with an audit trail, or any workflow where a request must be reproducible, it is a requirement to check before adoption.

Attribution. When an answer is wrong, which component was wrong? With a single model you can at least characterise its failure distribution. With a composite you may not be able to tell whether the dispatcher chose badly or the chosen member answered badly, and that makes debugging slower.

Portability. The composite is a name attached to a routing policy. If the operator changes which models are behind it, the name stays and the behaviour changes. That is a real risk for anyone building a long-lived dependency, and it is not visible in a per-token price. The mitigation is regression testing on your own task set, run on a schedule rather than once.

What this entry signals about where the catalogue is going

A composite appearing as a row beside ordinary models is a structural change, not just another release, and it is worth naming as one.

The catalogue’s implicit contract has been that a name identifies a set of weights. Composites break it from below; serving tiers and reasoning modes break it from above by attaching several prices to one set of weights. Between the two, the row has stopped being a reliable unit of comparison, and the field that used to carry the least information — the price — is now the one doing the most work, because it is the only field that tells you what you are actually buying.

The practical response is not to avoid composites. It is to stop treating a model name as a specification and start treating it as a product, with all the usual questions that implies: what is inside it, who can change it, how do I measure it, and what happens to me if it changes. Those questions are ordinary in every other kind of software procurement. Model catalogues are only now growing up enough to need them.