Ultrafast API access looks set to widen beyond the small group of companies OpenAI let in six weeks ago. On Saturday 26 September 2026, TestingCatalog reported that OpenAI is preparing a broader rollout of Ultrafast, its Cerebras-powered speed tier for GPT-5.6 Sol, and that a hidden “Speed” selector is being built into the Responses API Playground. Developers would pick Standard, Fast or Ultrafast for a request in the same way they already pick a model.
We checked the evidence ourselves. OpenAI’s live Platform code, deployed on 26 September, contains the selector, a feature flag named api_playground_ultrafast and a routing rule that gives Ultrafast requests their own header. A day earlier, OpenAI’s public API specification extended the ultrafast service tier to its Agents API. None of this is an announcement, but it is the plumbing a launch needs, and it lands three days before OpenAI DevDay on Tuesday 29 September.
This article explains what changed, how the Ultrafast API sits alongside OpenAI’s Standard and Fast tiers, what the Playground selector does, what 750 tokens per second means in practice, and what is still unknown about price and model support. It ends with the workloads where the speed pays for itself and how to prepare. For context, see our coverage of OpenAI’s always-on assistant, “o” and the Free, Prototype and Accelerate plans for AI app hosting, two more platform pieces that have surfaced ahead of DevDay.
Table of contents
- What Changed This Week for the Ultrafast API
- How the Ultrafast API Fits OpenAI’s Service Tiers
- The Ultrafast API Speed Selector Hidden in Playground
- Ultrafast API Speed: What 750 Tokens per Second Means
- The Cerebras Hardware Behind the Ultrafast API
- Ultrafast API Pricing: What Is Known and What Is Not
- Which Models Will the Ultrafast API Support?
- Where the Ultrafast API Makes Business Sense
- The Ultrafast API and OpenAI DevDay 2026
- Risks and Trade-offs of the Ultrafast API
- How to Prepare for Wider Ultrafast API Access
- Ultrafast API FAQ
- References
What Changed This Week for the Ultrafast API
Three pieces of evidence surfaced within about 31 hours. Each one alone would be a footnote. Together they show OpenAI wiring the Ultrafast API into its public specification, its developer console and its billing screens at the same time.
The Agents API specification commit
At 05:45 UTC on Friday 25 September, OpenAI’s automated publisher account pushed a commit to the public openai-openapi repository on GitHub with the message “Add ‘ultrafast’ service tier option to improve request speed”. The change is small: nine lines added and three removed across the JSON and YAML copies of the specification. It adds ultrafast to two lists of allowed values, next to auto, default, flex, priority and fast, with the description “Uses the ultrafast service tier.”
Both lists belong to the Agents API, which OpenAI released in public beta on 10 September. One is “The service-tier policy configured for an agent”; the other is “The service tier used for model requests.” In plain terms, a developer running an agent on OpenAI’s managed harness will be able to put that agent’s model calls on the Ultrafast API tier. The X user @imjustnewatai spotted the commit and posted it at 07:45 UTC on 26 September as an addition to OpenAI’s “cloud-agent API docs”.
The Responses API already had it
That commit was an extension, not a first appearance. We searched the specification’s history and found that the Responses API’s service_tier parameter gained its ultrafast value at 19:31 UTC on 13 August, the day of the preview. Its description is the most precise public statement of how the tier works: requests go to “the access-controlled Ultrafast Processing service tier”, which “is currently available for gpt-5.6-sol“, and “a response served through it will show service_tier=ultrafast“. The settings for GPT-Live voice sessions that hand work to a Responses backend list the same value.
The Playground and billing code
The third piece is in the OpenAI Platform itself. We downloaded the Platform’s main JavaScript bundle, which the server reports as last modified at 12:44:59 GMT on 26 September, and searched it. It defines the api_playground_ultrafast feature flag and a helper that adds an OpenAI-Service-Tier: ultrafast header to Responses calls, but only when the chosen tier is Ultrafast. The selector’s own code sits in a separate Playground file, covered below.
The billing code is further along than most coverage suggests. The usage dashboard already has labels for an “Ultrafast tier”, a view titled “View all-project Ultrafast tier usage” and a filter value of ultrafast-tier beside Flex, Scale tier and the Data sharing incentive tier. The capacity code treats Ultrafast as its own kind of commitment, separate from “Reserved tier” commitments. We return to what that implies for Ultrafast API pricing below.
What OpenAI has said officially
OpenAI’s only official statement is still its 13 August preview. It described Ultrafast as “a new service tier that runs GPT‑5.6 Sol up to 14× faster than Standard processing”, generating “up to 750 output tokens per second”, and said it was “available in a limited preview today to a select group of customers” with access expanding “as capacity grows”. OpenAI has not given a date for wider Ultrafast API availability. TestingCatalog’s view that it will come around DevDay is an inference from timing, not a confirmed plan.
| Date (UTC) | Source | What it shows |
|---|---|---|
| 14 Jan 2026 | OpenAI | 750 MW Cerebras partnership, capacity in tranches through 2028 |
| 30 Jul 2026 | OpenAI changelog | Priority processing renamed Fast mode, up to 2.5x faster at twice the price |
| 13 Aug 2026 | OpenAI and Cerebras | Ultrafast previewed for GPT-5.6 Sol; ultrafast added to the Responses spec |
| 10 Sep 2026 | OpenAI changelog | Agents API released in public beta |
| 25 Sep, 05:45 | GitHub commit fe4f7a1 | ultrafast added to the Agents API service tiers |
| 26 Sep, 07:45 | @imjustnewatai on X | Commit spotted and shared |
| 26 Sep, 12:24 | TestingCatalog | Hidden Standard, Fast and Ultrafast selector reported in Playground |
| 26 Sep, 12:44 | Platform code (our check) | Feature flag, header routing, selector labels and usage views confirmed |
| 29 Sep 2026 | OpenAI DevDay | Expected window for wider access (unconfirmed) |
How the Ultrafast API Fits OpenAI's Service Tiers
OpenAI sells the same model at different speeds and prices through one request parameter, service_tier. Understanding that parameter is the quickest way to understand what the Ultrafast API is and is not. It is not a new model. It is a new lane for an existing model, with different hardware behind it and a different price.
Standard, Batch and Flex
Standard processing is what a request gets by default. Batch and Flex sit below it: they trade speed and predictability for a discount, and suit background jobs where nobody is waiting for the answer. On the current pricing page, Batch halves the Standard price, so GPT-6 Sol output drops from $10 to $5 per million tokens.
Fast mode, formerly Priority processing
Fast mode is the paid step up. OpenAI launched it as Priority processing in June 2025 and renamed it Fast mode on 30 July 2026, when it also raised the speed for GPT-5.6 Sol to “up to 2.5×” Standard. The change was backward compatible, so service_tier: "priority" and service_tier: "fast" do the same thing. Fast mode costs twice the Standard rate, shares Standard’s rate limits and can be switched on per request or as a project default.
The Ultrafast API tier
Ultrafast is the next step, and a far bigger one: up to 14× Standard against Fast mode’s 2.5×. OpenAI has not said what hardware serves Fast mode, but it has said Ultrafast is powered by Cerebras. The specification text calls it “access-controlled”, which is the key difference for developers today: an account has to be granted the tier, and the parameter alone does not unlock it.
How a request finds out which tier it got
When a request sets service_tier, the reply carries a service_tier field showing the tier actually used, which “may be different from the value set in the parameter”. Fast mode uses that field to report downgrades: traffic that ramps too quickly is served at Standard, billed at Standard and labelled default. The Ultrafast API reports ultrafast when it is used, so the same field is how an application will know whether it really got the fast lane.
| Tier | How to request it | Speed vs Standard | Price vs Standard | Availability |
|---|---|---|---|---|
| Batch | Batch API | Asynchronous | 50% | General |
| Flex | flex | Slower, may queue | Discounted | Selected models |
| Standard | default | 1x | 1x | General |
| Fast mode | fast or priority | Up to 2.5x (GPT-5.6 Sol) | 2x | Pay as you go |
| Scale tier | Capacity commitment | Provisioned Priority capacity | Committed spend | Sales-led |
| Ultrafast | ultrafast | Up to 14x (GPT-5.6 Sol) | Not published | Access-controlled preview |
The gap between the two paid speed tiers is the story in one picture. Fast mode’s ceiling is less than a fifth of the Ultrafast API’s.
The Playground is where developers try prompts and settings before writing code, so a speed control there matters more than it looks. It turns the service tier from a line in an API reference into a visible choice. The Playground code shows exactly how that choice will be presented.
Three options with one-line descriptions
The code defines three options under the label “Speed”: Standard, described as “Default speed”; Fast, “Faster responses”; and Ultrafast, “Fastest available responses”. When Ultrafast is selected, the button switches to a solid, highlighted style, while Fast gets a coloured icon. It is a small design choice, but it makes the premium tier hard to leave switched on by accident.
It only offers the tiers a model supports
The list is not fixed. The Playground reads the service tiers each model reports as available and hides any option not on that list, while Standard always appears. If a model supports nothing beyond Standard, the control is greyed out with the tooltip “Only the default service tier is available for this model.” The same Playground will therefore look different depending on the model and, very likely, on whether an organisation has Ultrafast API access at all.
Responses API only, and locked while streaming
The control appears only when the Playground is set to the Responses API and the api_playground_ultrafast flag is on for the account, which is why TestingCatalog calls it “currently hidden”. It is disabled while a response is streaming or models are loading, so the tier cannot change mid-answer. Choosing Standard removes the parameter from the request rather than sending default.
Why a Playground selector matters
For teams evaluating the Ultrafast API, this is the part that saves time. Instead of wiring up a test harness, a developer will be able to run the same prompt at each speed and compare wall-clock time and output side by side. That is the comparison OpenAI used to sell the preview: its demo video showed GPT-5.6 Sol on Ultrafast and on Standard building the same 3D warehouse simulator from one text prompt.
Ultrafast API Speed: What 750 Tokens per Second Means
OpenAI gives two headline numbers for the Ultrafast API: “up to 14×” Standard and “up to 750 output tokens per second”. Both are ceilings rather than averages, and OpenAI does not say they were measured on the same workload. They are still useful for a rough sense of scale.
A worked example
If both figures described the same workload, Standard GPT-5.6 Sol would run at about 750 ÷ 14 ≈ 54 tokens per second, and Fast mode at 2.5× would reach about 134. A 2,000-token answer, roughly a long code change or a detailed report section, would then take about 37 seconds on Standard, 15 on Fast and under 3 on the Ultrafast API. Reasoning models also produce hidden reasoning tokens before the visible answer, so on hard problems the felt gap can be larger still.
| Tier | Implied output speed | 500 tokens | 2,000 tokens | 10,000 tokens |
|---|---|---|---|---|
| Standard | ~54 tokens/s (750 ÷ 14) | ~9 s | ~37 s | ~3 min 7 s |
| Fast mode | ~134 tokens/s (54 × 2.5) | ~4 s | ~15 s | ~75 s |
| Ultrafast | Up to 750 tokens/s | ~0.7 s | ~2.7 s | ~13 s |
Cerebras’s own benchmarks
Cerebras published three comparisons alongside the preview. On Humanity’s Last Exam, 2,500 expert-level questions, it says GPT-5.6 Sol on Ultrafast finished in 11 hours 11 minutes, while Claude Fable 5 took 78 hours 27 minutes “to arrive at the same conclusions”, nearly 7× longer at comparable accuracy. On GDP-Val, a benchmark of economically valuable knowledge work, it reports a 5.6× end-to-end speedup over Standard “with no quality degradation”. Citing Artificial Analysis output speeds, it adds that Ultrafast runs 11× faster than Fable 5 and 5× faster than Opus 4.8 in fast mode.
Converted to hours, the Humanity’s Last Exam run is 11.2 hours against 78.5, a ratio of 7.0.
Read the benchmarks with care
These are vendor numbers, produced by Cerebras on its own hardware, and the exam comparison pits two different agent harnesses against each other at their highest reasoning settings. The 5.6× GDP-Val result is also well below the 14× headline, a useful reminder that real tasks include tool calls, retrieval and waiting on other systems, none of which a faster chip speeds up. Expect the Ultrafast API to shrink model time dramatically and total task time by less.
The Cerebras Hardware Behind the Ultrafast API
Ultrafast is the first named product to come out of the OpenAI and Cerebras deal announced on 14 January 2026. OpenAI said it would add 750 MW of “ultra low-latency AI compute” to its platform, coming online “in multiple tranches through 2028”. CNBC and Bloomberg reported the deal as worth more than $10 billion, citing people familiar with the terms.
Why wafer-scale chips suit this job
Cerebras argues that fast inference is a data movement problem. On GPUs, model weights have to be moved between on-chip memory and off-chip storage to generate each token, so memory bandwidth becomes the ceiling. Cerebras builds a single wafer-sized processor with 44 GB of on-chip SRAM, keeps the weights on the chip and pipelines the model’s layers across several wafers. That design suits the thing the Ultrafast API is sold on: generating long outputs quickly from a very large model.
Why capacity limits access
The same design helps explain the limited preview. Wafer-scale systems are specialised, and a frontier model spread across several wafers ties up a lot of hardware for one deployment. OpenAI’s repeated promise to expand access “as capacity grows” reads naturally as a link to those tranches coming online, though OpenAI has not tied the two together publicly. Our earlier piece on Cerebras’s IPO filing covers the company behind the chips in more detail.
A second lane inside OpenAI’s stack
For OpenAI, Ultrafast also spreads where inference runs. Sachin Katti of OpenAI described the strategy in January as “a resilient portfolio that matches the right systems to the right workloads”. The Ultrafast API is the first place developers can see that portfolio as a choice in a drop-down menu, rather than something happening invisibly behind the model name.
Ultrafast API Pricing: What Is Known and What Is Not
OpenAI has not published a price for the Ultrafast API. Its public pricing page lists four processing options for current models, Standard, Batch, Flex and Fast mode, and Ultrafast is absent. The preview page offers only a sign-up form. So any Ultrafast figure quoted today is a guess.
What Fast mode tells us
The closest reference is Fast mode, which costs exactly twice Standard. For GPT-6 Sol that means $4 per million input tokens and $20 per million output tokens instead of $2 and $10. GPT-6 Astra goes from $10 and $50 to $20 and $100. A tier delivering several times Fast mode’s speed on specialist hardware would be surprising at anything below Fast mode’s premium.
| Model (per 1M tokens, short context) | Standard input | Standard output | Fast input | Fast output | Ultrafast |
|---|---|---|---|---|---|
| GPT-6 Astra | $10.00 | $50.00 | $20.00 | $100.00 | Not listed |
| GPT-6 Sol | $2.00 | $10.00 | $4.00 | $20.00 | Not listed |
| GPT-6 Luna | $0.10 | $0.50 | $0.20 | $1.00 | Not listed |
| GPT-5.6 Sol | $4.00 | $20.00 | $8.00 | $40.00 | Preview, unpriced |
For GPT-6 Sol output, the published ladder runs from Batch to Fast mode, with no Ultrafast API rung yet.
Clues that point to commitments
The Platform code hints at a different model from Fast mode’s pay-as-you-go. Its capacity screens sort commitments into two kinds, “Reserved tier” and “Ultrafast”, and the dashboard shows its dedicated Ultrafast usage panel only when an organisation holds an active Ultrafast commitment. The same code describes the Scale tier as “Provisioned Priority capacity”. That suggests the Ultrafast API may be sold, at least at first, as reserved capacity bought in advance, which would fit scarce hardware. It is an inference from code, not a statement from OpenAI.
How to budget before the price is public
Budget per task, not per token. A premium tier makes sense only where a faster answer is worth money: a shorter outage, a sale that does not stall, a call that resolves without a hold. Whatever multiplier OpenAI chooses, the Ultrafast API will look cheap to a trading desk and absurd for overnight summaries. Work out the value of a minute saved in each workflow now, so the price, when it arrives, becomes a quick yes or no.
Which Models Will the Ultrafast API Support?
Only one model is confirmed: GPT-5.6 Sol, and the specification still says the tier “is currently available for gpt-5.6-sol“. Since the preview began, OpenAI has released GPT-6 Astra on 3 September and GPT-6 Sol and GPT-6 Luna on 22 September. TestingCatalog calls support for the newer models “a key thing to watch”, and notes that no one has confirmed every GPT-6 model will support Ultrafast at launch.
The Playground is built for more than one model
The selector does not name any model. It shows Ultrafast wherever a model reports the tier as available, which means OpenAI can switch it on model by model without shipping new Playground code. That design is consistent with a wider roll-out, but it does not prove one is imminent.
What Fast mode’s rules suggest
OpenAI’s Fast mode documentation warns that “Future GPT models may support Fast mode, but support isn’t guaranteed for every model.” The GPT-6 generation also arrived with different terms: Fast mode for GPT-6 Astra carries no latency SLA, and EU data residency for GPT-6 Astra, Sol and Luna is available only with Standard processing. Expect similar model-by-model caveats for the Ultrafast API when it widens.
Why GPT-6 Sol is the likely next candidate
GPT-6 Sol costs half as much as GPT-5.6 Sol at Standard rates, which makes it the model many developers will move to. A Cerebras deployment has to hold a model’s weights in on-chip memory across wafers, so model size matters, and OpenAI does not publish parameter counts. If DevDay brings Ultrafast to a GPT-6 model, Sol looks the most natural fit. That is our reading of the evidence, not a leak.
Where the Ultrafast API Makes Business Sense
OpenAI named five scenarios in its preview, and four early customers went on record. The common thread is a person or a system waiting for the answer while something is still happening.
Incident response
When production fails, engineers need to read logs, traces and recent changes while the outage is still running. OpenAI says its own teams use Ultrafast to “quickly read logs, analyze traces, synthesize conversations, identify the next checks, and help prepare or validate a fix”, while engineers keep responsibility for judgement and deployment. Every minute the model saves comes straight off the downtime clock.
Customer support and voice
Voice is the clearest case, because silence on a phone call is expensive. Podium’s Courtland Lykins said the speed “completely changes the call experience for the more complex work”. The architecture is already in place: GPT-Live 1, generally available since 10 September, hands reasoning to a backend Responses model, and its delegation settings accept ultrafast. A faster backend means shorter pauses on the line.
Financial research and security
Market signals, suspicious transactions and fraud checks lose value by the second. Rogo’s Alex Wang said Ultrafast “makes complex financial research feel like a real-time interaction”, and Jane Street’s John Crepezzi said the speed makes it practical for developers “to work in a more focused and productive way”. Cerebras also pitches the tier at cybersecurity teams that “must quickly detect and respond to bad actors”.
Commerce
OpenAI’s commerce example is answering product questions, checking inventory, personalising recommendations and fixing checkout problems “while the shopper is still deciding, before hesitation becomes an abandoned cart”. For a retailer, the Ultrafast API case rests on conversion data: if latency measurably costs sales, the premium can be priced against that loss.
Research and coding loops
The last case is iteration. OpenAI says its researchers used to launch experiments overnight and review them in the morning; with Ultrafast, that loop tightens to several iterations in a working day. Basis co-founder Mitch Troyanovsky made the related point that “the barrier to truly fast products is not just tokens per second, but also model intelligence”.
| Workload | Who is waiting | Suggested tier | Why |
|---|---|---|---|
| Production incident triage | On-call engineers and customers | Ultrafast | Downtime costs more than tokens |
| Voice agent reasoning | A caller on the line | Ultrafast or Fast | Pauses break the conversation |
| Checkout and product questions | A shopper deciding | Fast, Ultrafast for complex cases | Latency can cost conversions |
| Interactive coding and research | A developer in flow | Fast or Ultrafast | More iterations per day |
| Report drafting and summaries | Nobody in real time | Standard | Speed adds cost without value |
| Nightly classification and evals | Nobody | Batch or Flex | Half price, deadline is hours away |
The Ultrafast API and OpenAI DevDay 2026
DevDay takes place in San Francisco on Tuesday 29 September. OpenAI has not published an agenda that mentions Ultrafast, but this week’s changes point that way, and the Ultrafast API is one of several platform pieces to surface in the past fortnight.
A platform week in the making
TestingCatalog has separately spotted new Platform onboarding plans, including an Accelerate option for production workloads, which we covered as OpenAI’s Free, Prototype and Accelerate plans. ChatGPT’s own code has revealed an always-on assistant called “o”, and its pricing strings describe the Pro plans with “More”, “Faster” and “Fastest” Work and Codex. Add an Agents API that now carries an Ultrafast setting per agent, and a DevDay focused on production infrastructure looks likely.
Why agents need speed most
Agents multiply latency. An agent that makes twenty model calls to finish a task pays the wait twenty times. A per-agent service-tier policy lets a developer put only the time-critical agents on the Ultrafast API and leave the rest on Standard. Cerebras quoted OpenAI researcher Jeffrey Wang on what that feels like: a task “finishes for me before I even have the opportunity to context-switch”.
What to watch on the day
Five questions will decide how much the launch matters. Does Ultrafast open to all paying customers, or to a waitlist or sales-led tier? Does a price appear on the pricing page, and is it pay-as-you-go or commitment-based? Which models are supported, especially GPT-6 Sol? Does the Playground selector go live for everyone? And do ChatGPT or Codex users get an Ultrafast API-backed option of their own?
Risks and Trade-offs of the Ultrafast API
Speed is rarely free, and the Ultrafast API carries costs beyond its price. Five deserve attention before any team routes production traffic to it.
Costs that scale with success
A premium tier on a busy workflow is a budget line that grows with every customer. Fast mode already charges double, and an Ultrafast rate above that would make runaway usage expensive quickly. Put the tier behind a spending alert from day one, and group usage by service tier in the dashboard, which OpenAI already supports for Fast mode.
Capacity and fallback behaviour
Fast mode has a ramp rule: once traffic reaches one million input tokens per minute, OpenAI advises growing it by no more than 50% every 15 minutes, or some requests are downgraded to Standard. Since 2 September, traffic that rises too quickly can also receive a 429 error with the code slow_down. An access-controlled tier on scarce hardware is unlikely to be more forgiving, so plan for the fast lane being full.
Faster agents make faster mistakes
Speed shrinks the window in which a person can notice something going wrong. An agent that acts fourteen times faster also errs fourteen times faster, and OpenAI’s own analysis of the five ways misaligned agents cause trouble online is a reminder that autonomy needs guardrails. Keep approvals on irreversible actions, however quick the model is.
One supplier and data residency limits
The Ultrafast API depends on a single hardware partner, which concentrates supply risk in one company’s roadmap. Data residency is another constraint: for GPT-6 models, EU residency is available only on Standard processing, and OpenAI has said nothing yet about where Ultrafast traffic is served. Regulated workloads may simply not qualify at first.
Benchmarks are the vendor’s own
Every speed figure so far comes from OpenAI or Cerebras. Independent measurements will follow wider access. Until then, treat “up to” as the ceiling it is, and test the Ultrafast API against your own prompts before committing budget.
How to Prepare for Wider Ultrafast API Access
Nothing here requires waiting for DevDay. Most of the work is measuring what speed is worth to you and making the tier a setting rather than a rebuild.
Measure your latency budget
List the workflows where someone waits on the model, and time them end to end. Note how much of each wait is model generation and how much is tools, retrieval and network. Only the generation share shrinks with the Ultrafast API, so this split tells you where the premium would actually buy something.
Make the tier a configuration, not a code change
Read service_tier from configuration, so a workflow can move between Standard, Fast and Ultrafast without a deployment. Log the service_tier value each response returns, which reveals downgrades, and record cost per task by tier. When access opens, you can switch one workflow over and compare real numbers within a day.
Pick one pilot workflow
Choose a single, measurable, latency-bound workflow for a first Ultrafast API trial: incident triage, a voice agent or a checkout assistant. Define success in business terms before you start, such as minutes of downtime saved or calls resolved without a hold, rather than tokens per second.
Register interest and ask the right questions
OpenAI’s preview page has a sign-up form for access updates, and Enterprise customers can ask their account director directly. Ask about price structure, supported models, rate limits, fallback behaviour and data residency. If you need help deciding where the speed would pay back, our AI strategy service covers exactly these trade-offs.
Keep people on the critical decisions
A faster model should shorten the time to a good decision, not remove the decision-maker. Keep humans responsible for deployments, payments and customer commitments, as OpenAI itself does in its incident-response use of the Ultrafast API.
Ultrafast API FAQ
Is the Ultrafast API available now?
Only in a limited, access-controlled preview for selected customers, running GPT-5.6 Sol. OpenAI says access will expand as capacity grows, and this week’s code changes suggest a wider roll-out is being prepared, possibly around DevDay on 29 September.
How fast is Ultrafast?
OpenAI says up to 14× faster than Standard processing and up to 750 output tokens per second for GPT-5.6 Sol. Fast mode, by comparison, is up to 2.5× Standard. Real end-to-end gains will be smaller where tools and retrieval dominate.
How much does the Ultrafast API cost?
OpenAI has not published a price. Fast mode costs twice the Standard rate, which is the nearest reference point. Platform code suggests Ultrafast may be sold as a capacity commitment, at least initially.
How do you request Ultrafast in code?
The API specification accepts ultrafast as a service_tier value on the Responses API, and now on the Agents API too. It is access-controlled, so the value only works for accounts that have been granted the tier. The response’s service_tier field confirms which tier served the request.
What is the Playground speed selector?
A hidden “Speed” control in the Responses API Playground offering Standard, Fast and Ultrafast. It lists only the tiers a model supports and is currently behind a feature flag, so most accounts cannot see it yet.
Is Ultrafast the same as Fast mode?
No. Fast mode is the renamed Priority processing tier, generally available at twice the Standard price and up to 2.5× faster. Ultrafast is a separate, much faster tier running on Cerebras hardware, with its own service_tier value.
References
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
