OpenAI's Ultrafast tier: measure wall clock, not tokens

Speed became a product SKU this week. On August 13, OpenAI opened a limited preview of Ultrafast, a service tier that runs GPT-5.6 Sol on Cerebras hardware at up to 750 output tokens per second. OpenAI's headline is "up to 14× the speed" of Standard processing. The number that should actually change how you build is buried further down the page: 5.6× end to end on real work.

What actually happened

Per Cerebras' engineering writeup, Ultrafast serves the same GPT-5.6 Sol weights on wafer-scale silicon with 44 GB of SRAM per chip, which keeps model weights on-chip and sidesteps the memory-bandwidth wall that caps GPU token rates. Cerebras clocks it at roughly 11× Claude Fable 5 and 5× Opus 4.8 in Fast mode.

Two benchmarks carry the story. On Humanity's Last Exam, Ultrafast worked through all 2,500 questions in 11 hours 11 minutes; Fable 5 took 78 hours 27 minutes for comparable conclusions. On GDP-Val — a benchmark built around economically valuable knowledge work — OpenAI reports a 5.6× end-to-end speedup over Standard with no quality degradation.

It ships as a limited preview to selected API customers, expanding "as capacity grows." No pricing has been published.

Why inference speed matters for your business

14× tokens does not mean 14× done. The gap between 14× raw generation and 5.6× wall clock is where your agent actually lives: tool calls, database round trips, retries, waiting on a payment API. We wrote in July that speed is a dial you buy rather than a property of the model. That still holds — but the dial only moves the generation slice of your latency budget. Instrument the whole loop before you pay for the fast tier, because if 70% of your agent's wall clock is your own Postgres queries, Ultrafast buys you almost nothing.

A limited preview is not a roadmap. "Selected customers, expanding with capacity" means capacity is the constraint, and small studios are not first in line. Design the workflow so it works at Standard speed and gets nicer when a fast tier arrives. Never the reverse.

Latency is a routing decision, not a purchase. The right pattern is the same one that survives every price and capacity shift: one interface, several tiers configured behind it, per-task cost and wall clock logged. Route the customer-facing agent to whatever is fastest today and the overnight reconciliation job to whatever is cheapest.

Sources: Cerebras, OpenAI.