When should you use Ultrafast on Amazon Bedrock?
Ultrafast speeds up GPT-6 Astra and GPT-6.1 Sol on Amazon Bedrock at 6x the per-token price. We tested different agentic workloads to show which gain enough speed to justify the premium.
Ultrafast is a premium service tier for OpenAI GPT-6 Astra and GPT-6.1 Sol on Amazon Bedrock. According to OpenAI, GPT-6 Astra on Ultrafast delivers up to 6x faster inference in the API, with up to 300 tokens per second. On both models, Ultrafast costs 6x the Standard price per token.
This post answers the question: when is Ultrafast worth it for your agent? It's a cost-latency tradeoff: every workload pays the same 6x premium, but how much faster that premium makes your agent depends on how it spends its time and the shape of its requests.
Choose your model and reasoning effort before you evaluate Ultrafast. A smaller model or lower reasoning effort can also reduce latency, at a possible cost to output quality. Ultrafast is a different lever: the same model at the same reasoning-effort setting, generating tokens faster. LLM inference has two main phases: prefill, which processes the prompt, and decode, which generates tokens, including reasoning tokens. In our tests, Ultrafast accelerated decode on both models.
Where Ultrafast is worth it
- A 6x faster model does not make an agent 6x faster. An agent's wall-clock time includes invoking the LLM, calling tools, and accessing external data, and Ultrafast speeds up only the model calls. Across our agents covering different use cases, Ultrafast on every call made them 1.5x to 3.3x faster on GPT-6 Astra and 1.7x to 3.9x faster on GPT-6.1 Sol. The larger the share of a workload spent on model calls, the larger the gain.
- Model calls that generate long outputs save the most time. Calls with short outputs, such as tool calls, finished 1.6x faster on GPT-6 Astra and 2.3x faster on GPT-6.1 Sol, while long outputs finished 3.7x and 4.8x faster.
- Higher reasoning effort saves more time before the final answer starts. Before a model gives its final answer, it can generate reasoning tokens, and the higher the reasoning effort, the more of them it generates. Ultrafast generates those tokens faster too, so it saves more time before the final answer appears. At high reasoning effort, the final answer started about 3x sooner than on Standard with GPT-6 Astra, and about 4x sooner with GPT-6.1 Sol.
How to keep Ultrafast cost-efficient
- Check your request shape and use prompt caching. A request with a small prompt and a long output spends most of its premium on output, which is where Ultrafast cuts latency. A request with a large uncached prompt and a short output spends most of its premium on the prompt, which Ultrafast does not process faster. Use prompt caching with Ultrafast: keep a stable prefix at the start of your prompts so repeated requests read it from the cache, which cuts the cost of that cached input by 90% on GPT-6 Astra and 95% on GPT-6.1 Sol.
- Keep each request under 272K input tokens. Both Standard and Ultrafast are priced in two bands. Above 272,000 input tokens, long-context prices apply to the entire request: input costs twice as much, including cached input, and output 1.5x as much. On Ultrafast, these multipliers stack with the 6x cost premium. If your agent compacts its context, set it to compact before the context reaches 272K tokens, and keep your stable prefix unchanged so it stays eligible for prompt-cache hits.
Hybrid patterns
- Use Ultrafast on only the slowest step or sub-agent. You set the tier per request, so you can run one step or one sub-agent on Ultrafast and keep the rest on Standard or on a different model. Watch the prompt cache when you do: in our tests, it did not carry across tiers. When we moved only our contract review agent's final step to Ultrafast, it kept about 85% of the time savings of Ultrafast on every request, but it lost the context the agent had cached on Standard, so it cost about as much as running every request on Ultrafast. The pattern fits best for a step or sub-agent with its own context, which has no cached context to lose. Before you adopt it, compare its cost per run with Ultrafast on every request for your own workload.
Summary table
Here's a table that captures when Ultrafast pays off:
How we know
We built three agents on AWS services and ran each one on Standard and on Ultrafast with both models. An analytics agent answers questions with SQL on Amazon Athena, a coding agent resolves SWE-bench Verified issues, and a contract review agent retrieves clauses from an Amazon Bedrock knowledge base and writes a memo. The goal was to test Ultrafast across agentic workloads that range from tool-heavy to generation-heavy. Our agents run their steps in sequence. With parallel steps, your users usually wait on the slowest branch. If model generation is what makes it slow, run that branch on Ultrafast. Because our results come from sequential agents, test this on your own workload.
Figure 1. End-to-end speedup with Ultrafast on every call, by agent and model, with 95% intervals over tasks.
Figure 2. Speedup per model call by output length, across about 3,500 calls. Shorter calls are mostly tool calls, and longer calls are generations such as code edits and contract memos.
Getting started
To use Ultrafast, set service_tier="ultrafast" on a Responses API request, either on bedrock-runtime through cross-Region inference (us.openai.gpt-6-astra or us.openai.gpt-6.1-sol, or the matching global. profiles) or on bedrock-mantle in us-east-1 (openai.gpt-6-astra or openai.gpt-6.1-sol). For most new applications, AWS recommends bedrock-runtime; see Inference endpoints supported by Amazon Bedrock . The GPT-6 Astra and GPT-6.1 Sol model cards have complete examples.
Conclusion
Ultrafast speeds up decode, so it pays off most for agents that spend their time generating long outputs and reasoning. Before you adopt it, set a response-time target, measure how your agent spends its time, and start with the request or component your users wait on. Use Ultrafast where the time it saves helps you meet that target and justifies the added cost per completed run. Keep prompts cache-friendly and under 272K input tokens.
Appendix: How we tested
We built each agent as a loop on the OpenAI Python SDK, calling the Responses API on Amazon Bedrock. The three agents range from tool-heavy to generation-heavy, as described in How we know. We ran the same tasks on Standard, on Ultrafast, and with Ultrafast on only the final step, with both models at the same reasoning effort, and graded every answer to assess quality. We measured end-to-end latency and compared each task's Standard run with its Ultrafast runs.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article