A fast lane with a fare
At the start of October, OpenAI began selling a faster way to run GPT-6 Astra, its newest model. The option is called Ultrafast. NVIDIA, whose Blackwell GPUs sit underneath it, publicized the launch with a claim of output up to eight times quicker than the standard mode. OpenAI’s own developer notes are more specific: up to eight times in Codex, its coding agent, and up to six times through the API.
The price moves in step. Standard Astra lists at $10 per million input tokens and $50 per million output tokens. Ultrafast lists at $60 and $300, and cached input and cache writes rise by similar multiples. OpenAI’s guidance to developers is admirably direct: “Use it when speed justifies the higher cost.”
That sentence deserves more attention than the speed figure, because it hands the decision back to the buyer. Whether speed justifies the cost depends entirely on the work.
The warehouse solved this years ago
Anyone who has run a large data warehouse will recognize the shape of this offer. Mature platforms have long separated tactical work, such as a short query behind a customer service screen that must return in a second, from strategic work, such as a month-end reconciliation that can take an hour. Workload management gives each class its own priority, its own resource share and its own service level. Nobody pays premium resources to make an overnight batch finish at 2:00 a.m. instead of 4:00 a.m.
AI calls deserve the same discipline, and most organizations have not applied it yet. A useful first pass sorts every call by who is waiting on it.
- A person, in the moment. A customer in a chat, an analyst asking a question, a developer working with a coding agent. Latency here is felt directly, and a faster tier may pay for itself in time and attention.
- A process, on a deadline. An agent step that blocks a workflow, or a check that must clear before a transaction posts. Speed matters if the deadline is tight, and often a modest improvement is enough.
- No one, right now. Enrichment, classification, document summaries, back-office extraction run overnight. This is where most enterprise volume sits, and it belongs in the cheapest tier available, often a batch interface priced below standard.
In our experience the third group is by far the largest, which means a blanket move to the fast tier would multiply most of the bill to speed up work nobody was waiting for.
Read the conditions, not just the multiple
The fine print matters as much as the headline. The multiples come with no published test setup, so nobody outside the two companies can reproduce them, and each is qualified as a maximum. OpenAI’s guide also warns that the gain shrinks unless the client holds a connection open between requests, which means the speed a team sees depends on how its own systems call the model. Rate limits on the tier vary with the customer’s usage level.
There is also a governance condition that is easy to miss. At launch, data sent to Ultrafast can be kept in the US or processed globally, but there is no European endpoint. For any workload whose data must stay in Europe, the fast lane is closed regardless of price, and that needs to be on the classification sheet before anyone builds against it.
Price the task, not the token
The comparison that settles the decision is cost and time per completed task, measured on your own work. Take a representative sample from each workload class, run it on both tiers through your real integration, and record what a finished task costs and how long a person or process actually waited. A sixfold price can be a bargain where a slow answer loses a customer, and pure waste where the answer is read the next morning.
The organizations that benefit from priced speed will be the ones that already know which of their workloads someone is waiting on. For everyone else, the first step is to find out.
