Unbiased Pins Pareto 26.9 to Its Own Model String: The Stable Version Has a Name Now

Unbiased's Pareto 26.9 stopped being a version number mentioned in someone else's footnotes and became an addressable model on October 13, 2026, when the release that has been serving as the stable default since September picked up its own version-qualified identifier. The context matters: the same vendor's Pareto 26.10 Preview has been sold as an opt-in preview since October 1 under a string of its own — pareto-26.10-preview — while pareto stayed on the stable release and, in the vendor's own words, "does not select this preview." For the eleven days between those two events, the version you were actually calling was decided by a changelog line rather than by anything in your request body. As of this week, it has a name you can pin.

That is a small piece of housekeeping on the vendor's side and a real change on yours. A model string that silently means "whatever we last shipped" is fine until the week it means something else; the difference between a preview and a stable release is the difference between a benchmark sheet that may change before final publication and one you can put in a contract. Unbiased has now published both, side by side, with rates attached.

What actually changed — and what didn't

Two things moved, and neither is the model itself.

• The stable release got an identifier. The version that has been answerable as pareto since September 17 now resolves to a dated, version-qualified slug whose canonical form carries the original ship date. For the first time you can name the release you mean instead of the alias that follows the vendor's calendar.

• The alias follows the stable release again. Unbiased's October 1 changelog is unambiguous about which way the alias points: use pareto-26.10-preview to opt in, because pareto "remains the default release alias and does not select this preview." The stable path is the default path.

The model behind the stable string is unchanged from what shipped in September, and the vendor's documentation has not moved on it either. Pareto is described — by the company selling it — as a blended model that engages multiple models on every request in parallel and synthesises one answer from the results. That is a claim about mechanism, not a spec, and there is no independent verification of it. What is verifiable is the wrapper around it.

On the vendor's documented surface, since the last check: input is text and image, output is text only, the maximum response is 131,072 tokens, and the model accepts tools, tool_choice, response_format, temperature, top_p and max_tokens, with tool_choice restricted to auto — you cannot force a tool call. There is no Hugging Face identifier anywhere in the record, so the weights remain closed.

The pricing is the part that has genuinely drifted

When Pareto was first listed in September, the rate card read $2.50 per million input tokens, $7.50 per million output, and $0.25 for cached input. On the vendor's pricing page today, the same stable release is published at $0.80 input, $3.20 output and $0.03 cached input — roughly a third of the original input rate on the dollar figure, and a little over 40% on output.

Read that as what it is, because it is easy to misread in both directions. It is a vendor-published rate, dated only by the page being live now; Unbiased has not published a dated price-change entry, so there is no citable "on this day the price fell" line and no promotional end date either. The honest version is that the current stable release is sold at the lower card, that the higher numbers are still circulating in coverage written from the September listing, and that nothing binds the vendor to the lower one. Anyone building a cost model this month should use $0.80 / $3.20 and re-check it, not treat it as fixed.

The one structural discount worth pricing is the cache rate, because of how this model is built. Cached input at $0.03 is under 4% of the standard input rate. If Pareto really does hold the same blended configuration across a conversation rather than re-selecting a model turn by turn, prompt caching survives the whole trajectory — which is exactly the saving the vendor says a conventional router gives up when it swaps models mid-conversation. Unbiased is also selling subscriptions with weekly token allowances alongside pay-as-you-go credits, from $10 a month for 25M tokens a week up to prepaid team credits with no weekly cap, so for steady personal use the per-token arithmetic is not even the bill.

This is the part a routing layer changes the shape of, and it is worth being precise about where we stand. OrcaRouter passes the provider's list price straight through with 0% markup, so a vendor rate change is live on our side the same day it lands rather than on a renewal cycle — but we do not carry any Unbiased model, so if you want Pareto 26.9 specifically, call it through Unbiased's own API. What a router does buy you here is one key and one integration for the models on both sides of the decision, so comparing Pareto against what you run today does not mean a second contract and a second SDK. Availability for this one is through the vendor's own API.

What the stable release is scored at — and what that score is worth

Unbiased publishes one comparable number for the stable release, and it comes with more caveats than the number is large.

• Pareto 26.9 on DeepSWE v1.1 — 70.0%, at a reported mean cost of $0.29 per task. The vendor dates this run to September 20, 2026.

• The size of that run — a 30-task slice, not the full DeepSWE v1.1 set. Unbiased says so on its own model card rather than in a footnote somewhere else.

• The other score the vendor lists for 26.9 — Humanity's Last Exam, reported without the text-only qualifier that the preview's HLE number carries, which the model card also flags as a difference.

• The classification of all of it — preliminary, vendor-run, and transcribed into a comparison the vendor itself describes as "not independently validated."

Put the stable release next to the preview and the scores are, within any single-run error bar, the same: 70.0% at $0.29 on the 30-task slice for 26.9, 69.9% at $0.24 on the full set for 26.10 Preview, both DeepSWE v1.1, both run by the company that sells the model. That is not a reason to conclude the preview is worse. It is a reason to conclude that the published numbers are not sharp enough to separate the two releases, and that nobody selling you either one has a reason to run the experiment that would.

Independent evidence for Pareto 26.9 specifically is currently absent. Artificial Analysis, the board most teams check before trusting a new name on a price sheet, has no page for it — the model route returns a 404 rather than a score. There is no leaderboard placement, no third-party latency or throughput figure, and no reproduction of any of the above by anyone outside the vendor. What Unbiased does offer instead is more interesting than a score: a public evaluation harness that points at any OpenAI-compatible endpoint, including the one you already use, so the claim moves from "trust our number" to "rerun our number." That is a genuinely better offer than most vendors make, and it is still not the same thing as a verified number. Nobody has published the rerun.

Stable versus preview, on the dimensions that decide a migration

If you are picking between the two releases today, these are the differences that matter, and they are not the ones the scores suggest.

• Context window — 262,144 tokens on Pareto 26.9 versus 1,048,576 on Pareto 26.10 Preview, a four-fold difference and by itself the strongest argument for the preview.

• Published rate — $0.80 / $3.20 / $0.03 cached per million tokens for the preview; $2.50 / $7.50 / $0.25 for the stable release as listed when it first appeared, against a vendor pricing page that currently publishes the lower card for the stable path too. Treat the stable figure as moving until the vendor dates it.

• Contractual status — 26.9 is a release; 26.10 Preview is a preview that Unbiased says "may change without notice" and explicitly does not bind.

• Benchmark transparency — the preview has four published scores with cost per task; the stable release has one comparable score on a 30-task slice.

• Access tier — both sit under the same evaluation-access terms, where commercial or production deployment requires a separate written agreement.

• Weights — closed on both, with no license document and no repository.

Read together, the choice is not about quality. It is about whether you would rather have four times the context on a model that may be replaced under you without notice, or a narrower window on a build the vendor has stopped advertising as changeable. A team building a long-document or long-agent-session product will find the first trade hard to refuse and the second hard to rely on; the answer is usually to run the preview behind a fallback rather than to pick one and forget it.

The operational caveats nobody puts on a model card

The wrapper around this model is a beta, and Unbiased documents the sharp edges rather than hiding them, which makes them easy to plan around.

• GET /v1/models is not implemented. You cannot enumerate what is available; you send the string you mean and find out.

• Unknown model identifiers are not rejected. A typo can go somewhere you did not intend and you will not get a clean error, which is a strong argument against hand-typing a version string in more than one place.

• The documented surface is chat completions and messages only — no embeddings, no image generation, no audio, no model listing.

• Access is evaluation access under the Terms, with accounts reviewed by hand before a key is issued. Production use requires a written agreement first.

• One serving provider. There is no second host in the record and therefore no failover target inside the vendor's own stack.

The last line is the one that decides how much of this you should put in a production path. A single-provider beta with a documented gap in model discovery is exactly the case where a fallback chain earns its keep, and where it should be configured before you commit traffic rather than after an incident. OrcaRouter's automatic failover and routing DSL are how that is set up on our side — a chain that sends a request to your primary model and moves to a named alternative when the primary errors or times out, expressed as configuration rather than code you maintain. We do not host Pareto 26.9, so the failover target on our side would be a model we do serve, not another copy of this one.

Who should pin the string this week, and who should wait

Pin it if you already call Pareto by name and your workload is stable enough that a mid-week version change would be a surprise rather than a feature. That is the whole payoff of a version-qualified identifier: an alias that follows the vendor's release calendar is a convenience right up to the moment it becomes an unreviewed dependency update. Pinning also makes your own cost tracking subtractable, since the two releases carry different published rates and a mixed month will not decompose after the fact.

Wait on the price if you are modelling spend. The stable release's own card has moved from $2.50 / $7.50 to $0.80 / $3.20 without a dated entry explaining the move, so any figure you bake into a budget this week is an observation, not a commitment — check it again before you sign anything based on it.

Wait on the quality question regardless. With one vendor-run score on a 30-task slice for the stable release, four preliminary scores for the preview, and no independent evaluator covering either, the decision you can actually make today is about interface and reliability: which context window you need, whether you can tolerate a preview, and whether the vendor's beta gaps fit your deployment. Those are answerable. Which of the two is the better model is not, and the honest position is to rerun the published harness on your own workload before you decide that it is.

Questions that come up

Which release does pareto select today, and has that changed? The alias points at the stable release, per Unbiased's October 1 changelog, which states plainly that it does not select the preview. That is the same direction as the original September arrangement; what changed this week is that the stable release is now also addressable by a version-qualified identifier, so the alias is no longer the only way to name it. If you have code that sends pareto and expects the newest thing, that expectation was never supported — the preview was opt-in by name from the day it shipped.

Should you pin the dated identifier or keep the alias? Pin if you need reproducibility or cost attribution; keep the alias if you genuinely want the vendor's current stable build without a change of your own. The failure mode to avoid is the middle: pinning the string in one place and leaving it drifted in another, in an API where unknown identifiers are not rejected and cannot be listed.

Is there any independent benchmark for Pareto 26.9? None as of this week. The only figures available are the vendor's, run on the vendor's harness, published with the vendor's own caveats about the run size and about comparisons it describes as not independently validated. The public harness is the strongest thing in that picture, because it is testable, and nobody has published a rerun against it.

The final thing worth watching is not a benchmark. It is whether the vendor dates its next rate change, because an undated move from $2.50 to $0.80 is a better deal and a worse signal — it tells you the card can move without an entry in the log that would let you explain it later. For a model whose entire pitch is that the numbers are receipts, that is the detail to hold it to.

A release is also the moment to check what has gone wrong before: the documented AI incidents and agent failures around models in this class are collected in the OrcaRouter AI Incident Archive , where each entry carries its own sources, severity, confidence grade and disputed flag.