What OpenAI's 'ultrafast' service tier for Agents actually signals

TL;DR: OpenAI’s Python SDK just added an “ultrafast” service tier for Agents and typed Live sideband events, which tells you more about where agent latency is headed than any keynote has.

The source here is the openai-python changelog, specifically v3.35.0, released 2026-10-17, followed by a small bug-fix release v3.35.1 a day later. Two feature lines in the 3.35.0 notes are worth reading closely: “add ultrafast service tier for Agents” (PR #4101) and “add typed Live sideband events” (PR #4099). Both touch the same nerve: making agents feel responsive in real time instead of waiting on a slow turn.

One caveat up front. A changelog is a first-party artifact, but it is a thin one. The SDK adding support for an “ultrafast service tier” means the API surface now accepts it. It does not, by itself, tell you the price, the regional availability, the rate limits, or how much faster “ultrafast” actually is. OpenAI has not published a pricing or docs page in these sources describing the tier. So treat the mechanics below as what the SDK exposes, not as a confirmed product spec. When OpenAI puts out docs, those numbers win.

What is the “ultrafast” service tier for Agents?

OpenAI already ships service tiers. The existing ones, documented in their API, are “auto,” “default,” “flex,” and “priority.” Flex trades latency for lower cost. Priority trades cost for lower latency and more consistent performance. The pattern is a dial: you pick where you sit on the speed-versus-price curve per request.

“Ultrafast” reads as a new notch on that dial, scoped specifically to Agents. That scoping is the interesting part. OpenAI did not add a general ultrafast tier for all chat completions. The changelog says “for Agents,” which suggests this is tuned for the agent loop: many short, dependent calls where each one blocks the next step.

Why does that distinction matter? A single chat completion that takes two seconds is fine. An agent that chains eight tool calls, each gated on the last, turns two seconds into sixteen. Latency compounds in agent workflows in a way it does not in one-shot generation. If “ultrafast” shaves the per-step latency, the payoff is multiplicative, not additive. That is the only reason I can think of to build a tier specifically for Agents rather than for everyone.

The honest unknown: we do not know the cost. Priority tier carries a premium today. An ultrafast tier almost certainly carries a bigger one. Whether the economics work for your use case depends entirely on numbers OpenAI has not published in these notes. Do not budget against a tier whose price you cannot see.

Why do “typed Live sideband events” belong in the same release?

The other feature, typed Live sideband events (PR #4099), and the pair of realtime bug fixes (PR #4098 in 3.35.0, PR #4102 in 3.35.1, both about preserving byte reads on websockets 13), all point at the same layer: the Realtime and Live APIs. These are the streaming, bidirectional connections that power voice agents and interactive sessions.

“Sideband events” are the out-of-band signals that flow alongside the main audio or token stream: things like tool-call notices, status updates, interruptions, turn boundaries. Making them “typed” is a developer-experience change. Instead of parsing loose dictionaries and guessing at shapes, you get structured objects with known fields. That is a small thing that saves real debugging time when you are building something that has to react to a user mid-sentence.

Put the two features together and the theme is coherent. Ultrafast tier cuts the time per agent step. Typed sideband events make the real-time control plane easier to reason about. Both serve the same goal: agents that respond at conversational speed and let you handle the in-flight events cleanly. This is plumbing for live, interactive agents, not batch pipelines.

What should a builder actually do with this?

First, know what you can verify today. You can pull openai-python 3.35.1 and see that the service_tier parameter accepts the new value and that the Live event types exist. You cannot verify speed or cost from the package alone. So the sane sequence is: upgrade, read the actual API docs when OpenAI publishes the tier details, then benchmark on your own workload before you commit anything to it.

Second, measure the right thing. If you test ultrafast on a single chat call, you will underweight it, because the compounding effect only shows up across a multi-step agent run. Instrument end-to-end latency on a realistic chain of tool calls, not a one-shot prompt. That is where a per-step improvement either pays for itself or does not.

Third, watch the websockets detail. Both releases include fixes for “websockets 13,” the Python websockets library. If you run Realtime or Live sessions in production and you are on that library version, the 3.35.1 fix for preserving byte reads (PR #4102) is the reason to take the patch rather than sit on 3.34. Realtime audio bugs are miserable to diagnose. A byte-read regression on your websocket layer looks like random audio corruption, not an SDK issue, so you can burn a day chasing the wrong thing.

The larger signal is about where OpenAI is spending effort. Not a new model in this release. Not a bigger context window. Latency and the real-time control plane for agents. That is a tell about which problems they think are blocking production agent deployments right now. Speed and clean streaming, not raw capability.

My practitioner’s take: upgrade to 3.35.1 if you touch Realtime or Live, because the websocket byte-read fix is a genuine reliability patch. Hold off on wiring the ultrafast tier into anything until OpenAI publishes price and availability, because an unpriced speed tier is a trap you can design your whole architecture around and then can’t afford. When the docs land, benchmark it on a full agent chain, not a single call, since that is the only test where “ultrafast” has a chance to earn its premium. The catch most people will miss: the typed sideband events are the quietly useful part here, and they cost nothing extra. Clean, structured control-plane events will do more for your voice agent’s reliability than shaving a few hundred milliseconds off each turn.