OpenAI Ultrafast Pricing: Speed Is the New Premium Tier, and It Costs 6x

OpenAI now charges 6 times its Standard rate for the same model to run faster. Ultrafast on GPT-6 Astra lists at $60 per million input tokens and $300 per million output tokens, against $10 and $50 on Standard. OpenAI Ultrafast pricing is the clearest sign yet that vendors have stopped selling bigger models first and started selling faster tokens. Most of your workloads should not pay for it.

The short answer. OpenAI Ultrafast costs 6x Standard per token, input and output, and OpenAI says it reaches up to 300 tokens per second. Anthropic fast mode costs 2x, Google Gemini Priority costs 75% to 100% more, and Amazon Bedrock Priority costs 75% more. Pay for speed only on calls where a person waits on the answer.

What OpenAI Ultrafast pricing actually charges

Ultrafast is a service tier, not a new model. You send the same request to the same model and set a different tier, and the response arrives faster at a higher per-token price.

The rate card is explicit. OpenAI's API pricing page lists GPT-6 Astra at $10 input and $50 output per million tokens on Standard, $20 and $100 on Fast, and $60 and $300 on Ultrafast. GPT-6.1 Sol follows the same pattern from a base of $2 and $10. Cached input and cache writes are multiplied by the same factor.

The speed claim comes from OpenAI's launch materials. VentureBeat, reporting on 29 September 2026, quoted OpenAI saying Ultrafast delivers up to 8x faster generation in Codex and 6x in the API, reaching as much as 300 tokens per second. The same report said Astra Ultrafast launched for Pro 500 and Enterprise customers, with a Sol version due shortly after.

Two other rows on the same page matter. Fast mode, priced at 2x, is not new: the pricing page notes that Priority processing was renamed Fast mode on 30 July 2026. Flex and Batch sit at 50% of Standard. That gives one model a published price ladder spanning 12x from the cheapest tier to the fastest.

Ultrafast on the smaller model costs more than Standard on the bigger one

This is the row most buyers miss. GPT-6.1 Sol on Ultrafast lists at $12 input and $60 output per million tokens. GPT-6 Astra on Standard lists at $10 and $50.

So for slightly less money you can run the larger model at normal speed. The choice is no longer "which model is smart enough". It is "would I rather have the better model, or the faster smaller one", and that is a product decision, not a procurement one. I would default to the bigger model at Standard for anything where a wrong answer costs more than a slow one.

The latency pricing rate card across four vendors

Every major vendor now publishes at least one tier above standard. They are labelled differently, priced differently and promise different things, which makes the comparison harder than it should be.

Every figure is taken from the vendor's own pricing or documentation page, listed in the references. Speed claims are vendor maximums. The 80% Gemini figure is calculated from the published Standard and Priority rows for Gemini 3.8 Flash.

For the base rates these multiples sit on top of, the Anthropic side is laid out in the checked list of every Claude plan and API rate. The same model priced across third-party hosts, where speed is a differentiator rather than a tier, is covered in the comparison of four inference providers' rate cards.

Three different products sold under one speed label

Lumping these tiers together is the most common mistake in AI pricing discussions. They solve three different problems, and paying for the wrong one is easy.

Speed tiers: faster generation per request

OpenAI Ultrafast and Anthropic fast mode change how quickly tokens come out. Anthropic is precise about this: its fast mode documentation says the benefit is focused on output tokens per second, not time to first token. It also says fast mode runs the same model weights and behaviour.

That detail matters. A speed tier helps a request that produces a long answer. It does little for a request whose delay is mostly the wait before the first token appears.

Priority tiers: a better place in the queue

OpenAI Fast, Gemini Priority and Bedrock Priority mostly buy position. Your requests are served ahead of standard traffic when the vendor is busy. Google's Gemini API priority page describes priority as non-sheddable with responses in seconds, against "seconds to minutes" for standard.

The value of a queue tier is consistency, not peak speed. On a quiet afternoon it may buy you almost nothing. During a demand spike it can be the difference between an answer and a timeout. Google states that overflow requests are downgraded to standard and billed at the standard rate, which is the fairest overflow rule in this set.

Reserved capacity: throughput on a contract

Vertex Provisioned Throughput, Bedrock Reserved and the old Anthropic Priority Tier sell guaranteed capacity for a term. Bedrock Reserved requires at least 100,000 input tokens per minute and 10,000 output tokens per minute, for 1 or 3 months. Prices go through an account team.

The commitment discount can be large where prices are published. On the Bedrock rate card, a Cohere Command model unit costs $49.50 per hour with no commitment and $23.77 per hour on a 6-month term, roughly 52% less. Reserved capacity is a finance decision about utilisation, and it belongs in the same conversation as any other cloud commitment.

Anthropic has already stepped back from this format. Its service tiers page now says Priority Tier commitments are no longer available for purchase. Fast mode cannot be combined with an existing Priority Tier commitment. My read is that per-token speed tiers are replacing capacity contracts as the default way labs sell latency.

Speed per dollar: the premium multiple against the speed claim

If you divide each vendor's claimed speed gain by its price multiple, the tiers stop looking alike. This is a crude ratio built on vendor maximums, but it is the only like-for-like view the published numbers allow.

Read the chart as a statement of what each vendor is selling, not as a ranking. Bedrock Priority's 0.71 is not a rip-off. AWS describes the tier as requests that "move ahead of standard requests for faster responses even during high-demand periods". The speed number is incidental to the queue guarantee.

Ultrafast lands at exactly 1.00 at its best case. You pay 6x to go up to 6x faster, so the tier is priced at parity with its own ceiling. Any request that gets less than the maximum speed gain pays more per unit of speed than Standard.

Anthropic fast mode is the only tier that claims to deliver more speed than it charges for. Whether it does on your traffic is something you have to measure, not assume.

The input-token tax hidden inside every latency premium

Every speed and priority tier listed above multiplies the input price as well as the output price. That is reasonable from the vendor's side, since a faster serving path costs more to run end to end. It is a poor fit for how most production workloads spend money.

Agent calls and retrieval calls are input-heavy. They send large contexts and get short answers back. The speed tiers accelerate generation, and generation is the small part of those calls.

Illustrative call shape chosen by the author, not measured traffic. Prices from the OpenAI API pricing page, short context. Cache write charges are excluded for simplicity, which slightly understates both columns.

In this example, output is about 22% of the Standard bill. The other 78% is input, and it gets multiplied by 6 even though the speed gain is concentrated in the 800 generated tokens. You pay $0.185 more per call to speed up roughly a fifth of what you were already paying for.

There is a second, quieter cost on the Anthropic side. Its documentation states that fast and standard speeds do not share prompt cache prefixes. If you route some calls fast and others standard, each speed builds its own cache, and you pay for cache writes twice. The real premium on a mixed workload is higher than the 2x on the rate card.

This is one more case of a pattern covered in why falling token prices still produce rising AI bills. The headline per-token rate is never the number that decides your invoice. The shape of your traffic is.

A latency-value test for your own workloads

You do not need a benchmark lab to decide whether a speed tier is worth it. You need three numbers per workload, and an honest answer about who is waiting.

Step 1: price the premium per call

Take a real sample of calls from your logs. Compute the cost on standard and the cost on the faster tier, including input, cached input and output. The difference is the premium per call. Do this from logged token counts, not from the vendor's calculator, because your input share is the thing that decides the answer.

Step 2: estimate the seconds actually saved

Measure your current output speed and time to first token on that sample. Then apply the vendor's claimed gain to the generation portion only, and treat the "up to" figure as a ceiling. A call that spends most of its time waiting for the first token barely moves.

Using the agent call above, and an assumed standard speed of 50 tokens per second, the 800 output tokens take 16 seconds. At 300 tokens per second they take about 2.7 seconds. That is about 13 seconds saved, at best, for $0.185.

Step 3: put a price on a waiting second

The break-even is the premium divided by the seconds saved. In the example, that is about $0.014 per second, or roughly $50 per hour of waiting. If the person blocked on that call costs your business more than $50 an hour, and they genuinely cannot do anything else while waiting, the premium pays.

Run the same numbers on a short chat reply of 2,000 input tokens and 500 output tokens. Standard costs $0.009, Ultrafast costs $0.054, and about 8 seconds are saved at the claimed peak. The break-even drops to roughly $19 per hour. Short, output-heavy, interactive calls are where speed tiers are cheapest to justify.

Halve the realised speed gain and the break-even roughly doubles. That is why step 2 matters more than the rate card. The test is only as good as your measured speed on your own traffic.

Which workloads justify paying the latency multiple

Run the test above and most workloads fall into one of five buckets. The table below is my judgement on each, based on the mechanics described in this post rather than measured outcomes.

The pattern is simple. Speed is worth buying where it changes a human's experience in the moment. Everywhere else, the same budget buys more by moving down the ladder to Flex or Batch, which every vendor here prices at about half of standard.

If your team already routes between models on cost, add service tier as a second routing dimension. The quality trade-offs of routing are covered in the analysis of where model routing loses quality, and the same logging discipline applies here. Tier the request, not the account.

One procurement point follows from all this. Ask any vendor selling you a speed tier for its measured speed distribution on your traffic, not its maximum. A rate card that publishes a price multiple but only an "up to" speed is asking you to pay a fixed premium for a variable benefit. That gap is part of a wider problem described in the case for a rate-limit and pricing transparency standard.

Where this argument is weakest

The analysis above leans on numbers the vendors chose to publish. That shapes its conclusions in ways worth stating plainly.

The speed figures are vendor ceilings, not measurements

Every speed multiple in this post is an "up to" figure. Zan Digital has not run independent latency tests on any of these tiers, and the break-even examples assume a 50 tokens per second baseline that your traffic may not match. If realised gains are well below the ceilings, the case for speed tiers is weaker than shown here. If baseline speeds on your traffic are slower, it is stronger.

The OpenAI speed and access details also come through VentureBeat's report of OpenAI's launch materials, because the OpenAI announcement pages could not be loaded for this post. The prices come from OpenAI's own pricing page.

Time is not priced linearly, and speed can change behaviour

The latency-value test treats a waiting second as worth a fixed hourly rate. Real users do not behave that way. A reply in 2 seconds may keep an engineer in flow, while a reply in 15 seconds sends them to another tab for 5 minutes. If that is your pattern, speed is worth far more than the hourly maths suggests.

The opposite case is also real. Faster responses can mean more requests, more iterations and a bigger total bill. A team that gets 6x speed may simply ask 3x more questions. Neither effect is measured in any public source I could find, so the test gives you a floor for the value of speed, not a ceiling.

Frequently asked questions

Where to start this week

Pull one day of logs for your three highest-volume AI workloads. For each, calculate the share of the bill that is input tokens, and write down who, if anyone, is watching the response arrive. That single table will tell you which workloads to move down to Batch before anyone asks about moving up to Ultrafast.

Then pick the one workload where a person is clearly blocked, and run a one-week split on the faster tier with speed measured on both arms. Decide on the measured break-even, not the rate card.

Related reading