OpenAI previewed a new API service tier called Ultrafast on August 13, 2026, which runs GPT-5.6 Sol at up to 750 output tokens per second, or up to 14 times faster than Standard processing. The interesting part is not the multiplier, it is where the speed comes from. Ultrafast runs on Cerebras wafer scale hardware, which keeps model weights in 44 GB of on chip SRAM instead of streaming them from external memory on every token. That is a memory bandwidth story rather than a model story, and it changes which products are buildable. Access is a limited preview for selected customers, so treat the numbers as a direction, not a capacity plan.
The short answer
OpenAI previewed Ultrafast on August 13, 2026, a new API service tier that runs GPT-5.6 Sol at up to 750 output tokens per second. The model is unchanged, the hardware is not: Ultrafast runs on Cerebras wafer scale processors that keep weights in on chip SRAM rather than streaming them from external memory. Cerebras published a 5.6 times end to end speedup on the GDP-Val benchmark with no quality loss. Access is a limited preview for selected customers, in the API first, widening as capacity allows.
There is a threshold in every interactive system where waiting stops being a cost and starts being a design constraint. Below it you build one kind of product, above it you build another.
What was announced
On August 13, 2026, OpenAI previewed Ultrafast, a service tier in its API that runs GPT-5.6 Sol at up to 750 output tokens per second, described as up to 14 times faster than Standard processing. It is a tier, not a model. The weights are the ones you are already calling, and the announcement is about where they execute.
That execution happens on Cerebras hardware, confirmed by both companies on the same day. Availability is a limited preview for a selected group of customers, with a sign up form and a stated plan to widen access as capacity grows. Early testers named in coverage of the launch include Jane Street, Podium, Basis and Rogo, across coding, financial research, commerce and customer support.
The reason it is fast is not the reason people assume
Generating a token is not a compute problem. It is a memory problem.
For each token a decoder produces, the machine reads the model's weights. On a GPU, those weights sit in high bandwidth memory attached to the package, so every single token requires moving the working set across that link. Arithmetic units finish early and wait. This is why inference throughput tracks memory bandwidth far more closely than it tracks raw floating point capability, and why the usual way to go faster has been to make the model smaller so there is less to move.
Cerebras attacks the transfer instead of the model. Its wafer scale processor carries 44 GB of SRAM on the die, so weights live on the same piece of silicon that computes with them, and layers are pipelined so tokens flow without an off chip round trip in the inner loop. The quote OpenAI's Rohan Varma gave to accompany the launch is about keeping up with how people think, code and collaborate, but the engineering claim underneath it is narrower and more interesting: you can hold the model still and move the bottleneck.
Cerebras also published harness level results. A 5.6 times end to end speedup on GDP-Val with no quality loss is the load bearing one, because end to end includes the parts of a run that no amount of token throughput fixes. The most vivid figure is a full pass of Humanity's Last Exam finishing in 11 hours 11 minutes against 78 hours 27 minutes. These are the hardware vendor's own numbers, published to sell the hardware, so read them as a claim with a plausible mechanism rather than as an independent measurement.
What changes for people building things
Two categories move, and they are not the ones usually named first.
Voice is the obvious one. Spoken conversation has a hard budget, somewhere around a few hundred milliseconds, past which a pause reads as a fault rather than as thinking. Until now, meeting that budget meant choosing a smaller or specialised model and accepting worse answers. A tier that runs the full model inside the budget removes the trade, which is a genuinely different product decision.
The less obvious one is agent loops. When a task is forty sequential model calls, each waiting on the last, the wall clock is the sum, and the latency of a single call gets multiplied by the depth of the chain. This is the same pressure that has been showing up all over the toolchain this year, from CI clouds rebuilding themselves around agent generated pull requests to the capital being raised to build the underlying compute. The bottleneck keeps moving to whatever is sequential.
One OpenAI researcher's reaction, quoted in the Cerebras post, is the honest version of the user impact: it finishes before there is time to context switch. Losing the context switch is worth more than the seconds saved, because the seconds were never the expensive part.
How we would treat it this week
As a signal, not as a dependency.
It is a gated preview whose availability is explicitly tied to capacity, which means anything you ship against it needs a working fallback to the Standard tier, and needs it before you turn the feature on rather than after. Keep the tier in configuration. The same request should run on either path, and your timeouts should be set for the slow path, because that is the one you will be on when capacity is tight.
Then measure the right thing. Tokens per second is a component metric, and in a real request the model is one span in a trace that also holds retrieval, tool calls, serialisation and your own network. We would instrument the full span before and after, because a 14 times faster model call inside a request that spends 800 ms elsewhere is a much smaller win than the headline suggests, and knowing that number is what tells you whether the tier is worth designing around at all.
Sources and further reading
- Previewing Ultrafast mode: GPT-5.6 Sol at up to 14X the speed, OpenAI, August 13, 2026
- Accelerating GPT-5.6 Sol Ultrafast with OpenAI, Cerebras, August 13, 2026
- Cerebras Powers Ultrafast Mode for OpenAI's GPT-5.6 Sol, GlobeNewswire, August 13, 2026
- OpenAI introduces Ultrafast, a new mode that makes GPT-5.6 Sol work at 14x the speed, TechCrunch, August 13, 2026
- OpenAI introduces new Ultrafast mode for GPT-5.6 Sol delivering 14x faster tokens, Neowin, August 13, 2026
- Ultrafast mode preview in the API, OpenAI Developer Community, August 13, 2026
Frequently asked questions
What exactly is Ultrafast?
It is a new service tier in the OpenAI API, previewed on August 13, 2026, not a new model. The model is the same GPT-5.6 Sol you can already call. What changes is the hardware it runs on and therefore how fast tokens come back: up to 750 output tokens per second, which OpenAI describes as up to 14 times faster than Standard processing. It launched in the API first, as a limited preview for a selected group of customers, with a sign up form for everyone else. OpenAI says access will widen as capacity grows.
Why is Cerebras hardware faster for this?
Token generation is bound by memory bandwidth, not by arithmetic. To produce each token, the machine has to read the model weights. On a GPU those weights live in high bandwidth memory next to the chip, so every token means moving gigabytes across that link. Cerebras uses a wafer sized processor with 44 GB of SRAM on the die itself, so the weights sit where the computation happens and the token stream is not gated by an off chip transfer. That is why the speedup is large on generation specifically, and why it does not require a smaller or distilled model.
Does the speed cost accuracy?
Both companies say no, and the specific claim is worth reading precisely. Cerebras published a 5.6 times end to end speedup on the GDP-Val benchmark with no quality loss, which is a same weights, same outputs argument: the model is not quantised down or swapped for a lighter sibling, it is the same model executed faster. That is a vendor benchmark from the hardware vendor, so treat it as a claim to verify on your own evaluation set rather than as an independent result. The structural argument behind it is sound, since nothing about keeping weights in SRAM changes what the weights compute.
What does this actually unlock that was not possible before?
Anything where a human or a system is blocked waiting on the answer. OpenAI points at financial research, incident response, customer support, voice applications, commerce and live experimentation, and the common thread is that the value of the answer decays with time. Voice is the clearest case, because conversation has a hard latency budget of a few hundred milliseconds before it feels broken, and until now hitting that budget meant dropping to a smaller model. The second case is agent loops, where a task is dozens of sequential model calls and the wall clock is the sum of all of them.
Should we build on it now?
Not as a dependency, no. It is a preview with limited access and OpenAI is explicit that availability is gated on capacity, so anything you ship against it needs a working path back to the Standard tier. Two practical notes. Keep the tier a configuration value rather than an assumption baked into your prompts or timeouts, since the same code should run on either. And measure end to end latency, not tokens per second, because in most real applications the model is one span in a trace that also contains retrieval, tool calls and your own network hops, and a 14 times faster span can still leave the user waiting.