GPT-5.6 Sol Ultrafast vs GPT-5.6 Sol: Same Weights, Different Service Tier

GPT-5.6 Sol Ultrafast is not a new model, and this is not a launch story. The vendor announced the mode on August 13, 2026, and the same day the value ultrafast appeared in the company's public OpenAPI schema, inside the specification's ServiceTierResponses description — which scopes the tier by its own wording to the gpt-5.6-sol endpoint and marks it access-controlled. What put this page back in our queue is smaller and more specific: on September 25, 2026, commit fe4f7a1 extended that value into two further enumerations, the request-level service-tier parameter and the agent service-tier policy field. Six weeks after the announcement the tier is still waitlisted, still has no published price, and is now wired into more of the API surface than it can actually serve. GPT-5.6 Sol Ultrafast and GPT-5.6 Sol are the same model; the only thing this comparison can decide is who controls the pointer and who has told you the cost.

So the matchup in the headline is an unusual one. GPT-5.6 Sol Ultrafast and GPT-5.6 Sol are the same model. Same weights, same checkpoint, same reasoning behaviour, same 1.05-million-token context window, same 128K maximum output, same answers. OpenAI's own framing is "more useful work per second," not a smarter model. The only thing that differs between the two columns of this comparison is how the tokens are produced and what the tier is called in your request body — which makes it the cleanest control experiment in the current lineup, and also the hardest one to shop for, because one of the two tiers has no published price at all.

What actually changed this week

The evidence for the September change is a commit, not a blog post. OpenAI maintains openai-openapi, the repository that publishes the machine-readable schema for its API, and commit fe4f7a1 — dated 2026-09-25 — adds ultrafast to two enumerations: the service-tier policy attached to agents, and the request-level field the spec describes as "the service tier used for model requests." That is an extension, not a debut: before this commit those two lists read auto, default, flex, priority, fast, and the tier had already been in the schema since August 13. The commit is worth noting because of which field it reached — the policy field an agent is configured with, which is a different surface from a per-request override.

The description that matters dates from the August 13 commit, not this one, and it is the most specific statement OpenAI has published about the tier anywhere. Alongside the new value, the spec reads: "If set to 'ultrafast', then the request will be processed with the access-controlled Ultrafast Processing service tier. This tier is currently available for gpt-5.6-sol; a response served through it will show service_tier=ultrafast."

Read that sentence twice, because it settles two questions this comparison page would otherwise have to hedge. The tier is scoped to one model — the GPT-5.6 Sol flagship and nothing else in the lineup — and it is access-controlled rather than open, which matches OpenAI's framing of a waitlisted preview. It also tells you how you would know you got it: the response echoes back which tier actually served the request, so a fallback to standard processing is visible in the response body rather than something you have to infer from latency. The same description appears in both the standard and Beta Responses schemas, and has since August 13.

A second, weaker signal arrived the next day. Reporting on September 26 describes a new Speed selector — Fast, Standard, and Ultrafast — coming to the Responses API Playground, with wider Ultrafast availability expected after OpenAI's DevDay developer conference. We have not seen the selector ourselves and OpenAI has not published a rollout note, so treat that as a single-source report rather than a shipped feature. The parts that are checkable today are the two spots in the public schema and the fact that no rate card has appeared for the tier.

What has not changed is as important. There is still no Ultrafast price. OpenAI's pricing page, read on September 27, contains the four tabs it had before — Standard, Batch, Flex, and Fast — and the string "ultrafast" does not appear on it anywhere. Access is still described as a limited preview for select customers, expanding as capacity grows. The tier is in the contract and out of the price list at the same time, and that is the honest state of it.

The two tiers, side by side

Because no capability separates these two, the comparison collapses almost entirely onto serving and billing. Every line below carries both sides on one row.

• Model — GPT-5.6 Sol Ultrafast runs the identical GPT-5.6 Sol checkpoint vs GPT-5.6 Sol standard processing, same checkpoint, no distillation, no size reduction.

• Output throughput — up to 750 output tokens per second, up to 14× standard, per OpenAI's August 13 announcement vs standard GPT-5.6 Sol processing on GPU clusters, which is the figure the 14× is measured against.

• Hardware — Cerebras wafer-scale chips, weights resident in on-chip SRAM, the first product of OpenAI's January 2026 compute partnership with Cerebras reportedly worth about $10 billion over three years vs conventional GPU inference, where much of the time goes to moving weights between memory and compute.

• Price — not published as of September 27, 2026 vs $4.00 input / $20.00 output per million tokens, OpenAI's current promotional rate, plus $0.40 per million for cached input.

• Availability — waitlisted limited preview for select customers vs the default lane, callable by anyone with an API key.

• Answers you get back — identical, in principle vs identical, in principle; if they diverge on the same prompt, that is a finding, not a feature.

The speed claim, and the ceiling on it

The headline number is 14× and it deserves the same care the rest of this page gets. OpenAI states up to 750 output tokens per second versus standard processing — a throughput figure for output tokens, not a claim that every request finishes 14 times sooner. End-to-end time also contains input processing and the model's own reasoning, neither of which the wafer-scale hardware compresses at the same ratio. That is why the company labels 14× a maximum rather than a measurement.

The published comparisons are vendor-reported on both sides of the table, and one of them spans two vendors' stacks. A Humanity's Last Exam run of 2,500 questions is reported as finishing in 11 hours 11 minutes on Ultrafast against 78 hours 27 minutes for Claude Fable 5, with comparable accuracy — that is OpenAI and Cerebras telling us about a benchmark that includes a rival's model, and independent coverage of the launch quoted a narrower roughly 11× generation-speed comparison on the same run while Cerebras's own figures imply about 7× for total test time. The gap between 14×, 11×, and 7× is not a contradiction; it is what happens when three parties measure different portions of one workload. Cerebras separately reports 5.6× end-to-end on GDP-Val with no measurable quality loss. None of it has been reproduced by a third party.

The price list has a hole in it

Here is where the two tiers stop being symmetric. GPT-5.6 Sol has four published rate cards and Ultrafast is not one of them.

• Standard GPT-5.6 Sol — $4.00 / $20.00 per million tokens, with cached input at $0.40 and a long-context tier at $8.00 / $30.00 once input passes roughly 272K tokens.

• Fast mode — $8.00 / $40.00, exactly double the standard rate. This is the tier that was renamed from Priority processing on July 30, 2026, and the API accepts either service_tier: "priority" or service_tier: "fast". It buys up to about 2.5× output speed.

• Batch and Flex — $2.00 / $10.00, a flat 50% off standard in exchange for looser scheduling.

• Ultrafast — no rate card. Not a blank we filled in with a guess; a blank OpenAI has left.

That Fast-mode row is the only real prior anyone can price Ultrafast against, and it is a sobering one for anyone planning a budget: the one speed tier OpenAI has actually put a number on costs exactly twice the standard rate for two and a half times the speed. Ultrafast is a larger speed claim resting on scarcer hardware — Cerebras wafer capacity is not a commodity — so the direction of the eventual premium is not in doubt. Its size is. Until a rate card exists, any "GPT-5.6 Sol Ultrafast price" figure you see quoted anywhere is somebody's inference, including any inference of ours.

How you would actually call it

The schema change tells you the shape of the eventual call. If the tier follows the pattern of the others, it arrives as an extra field on a request you are already making: you keep model gpt-5.6-sol, keep your prompt, and add the tier selector — the same way Fast mode is selected today by swapping priority for fast. Nothing about your response parsing changes, because nothing about the model changes. That is the whole appeal of a serving tier over a model swap, and the reason a comparison page like this one has so little to compare.

What you cannot do today is call it. The enumeration value exists; the capacity behind it does not, for most accounts. So the practical question for the next few weeks is not which of the two tiers to pick — it is what to run while the choice is unavailable.

That is a question a gateway answers better than a waitlist. The standard tier of the model is live on OrcaRouter right now as openai/gpt-5.6-sol, served at the provider's own rate with zero markup on tokens, through the OpenAI-compatible endpoint at api.orcarouter.ai/v1 — so OpenAI's promotional $4 / $20 and its long-context $8 / $30 step are passed straight through rather than re-priced by us, and a change to them lands on our side the same day it lands on OpenAI's. The same key carries 200+ models, which matters more than usual here: because you cannot set service_tier: "ultrafast" and get an answer, the way to buy latency today is to route the work differently — send the interactive calls to whichever model on the catalogue clears your quality bar fastest, and keep the overnight batches on the cheapest lane that passes. When the tier does open, the router is where you would flip the switch, and until then it is the difference between a waitlist and a plan.

Which one belongs in production

Ignore the word "versus" for a moment, because there is no quality decision to make here. If you are optimising for cost per token, standard GPT-5.6 Sol is the answer, and the 50%-off Batch lane is the answer for anything that can wait. If you are optimising for how long a human sits in front of a spinner, Ultrafast is the answer the moment you can get it — and the workloads OpenAI is naming for the preview show exactly why: incident response with logs and diffs open on a live outage, fraud checks against moving data, support conversations where a half-second of silence reads as a broken product, and research loops that used to run overnight being compressed into a working session.

The tell is the shape of your request graph, not the size of your prompt. A single long generation gains 14× on paper and rather less in practice, because input processing and reasoning do not compress at that ratio. Forty sequential tool calls behind one user-visible action gain something much closer to the full multiplier, because every one of those round trips is latency the user is sitting through. If your workload looks like the second one, the tier is aimed at you; if it looks like the first, the standard lane was always going to be fine.

Two things to watch, and neither is a rumour we can settle from here. First, the rate card: a premium tier without a price cannot be budgeted, and the Fast-mode precedent suggests it will not be small. Second, whether the waitlist actually lifts around DevDay as reported — because a service_tier value that most accounts cannot use is documentation, not availability, and the difference between the two is the difference between a plan and a promise.