In a post on X, @imjustnewatai reported that OpenAI had added “ultrafast” to its cloud-agent API documentation. The linked OpenAI OpenAPI commit shows a narrower but concrete change: “ultrafast” was added to the permitted service-tier values in OpenAI’s public API definitions.

That documents a new schema option—a permitted value in the machine-readable API definition. It does not, by itself, show that the tier is enabled for public API users, that requests using it will succeed in production, or that it delivers a particular latency improvement.

What the OpenAI API change adds

The commit adds ultrafast after fast in two related parts of the API schema. One definition describes the service-tier policy configured for an agent. The other describes the service tier used for model requests.

The change appears in both the JSON and YAML versions of the OpenAPI files. For the agent policy definition, the permitted values shown in the diff are default, flex, priority, fast and ultrafast. The model-request definition receives the same addition, along with the description: “Uses the ultrafast service tier.”

Screenshot of an OpenAI OpenAPI commit showing ultrafast added alongside default, flex, priority and fast in a service-tier list.
Screenshot of an OpenAI OpenAPI commit showing ultrafast added alongside default, flex, priority and fast in a service-tier list.

Image credit: @imjustnewatai on X

The commit’s title describes the addition as a service-tier option intended to improve request speed, but the diff does not include latency measurements, capacity information or a service-level commitment.

How “ultrafast” appears alongside the other tiers

The schema lists several service-tier choices:

  • default

  • flex

  • priority

  • fast

  • ultrafast

The descriptions attached to this allowed-value list say that the options use the default, flex, priority, fast or ultrafast service tier. The same section also includes a description for automatic service-tier selection, but the supplied diff does not provide further operational details about how that selection works.

These entries tell API tooling and developers which string values the schema recognises. They do not explain how the tiers differ in price, queueing, capacity, eligibility or guaranteed response time. The names suggest an ordering of speed or service priority, but the supplied evidence does not measure or define those differences.

What the commit does not confirm

The schema addition leaves several practical questions unanswered for developers:

  • whether ultrafast is available to public API accounts;

  • whether it can currently be selected successfully in production requests;

  • which models or agent configurations support it;

  • whether it has separate pricing or eligibility requirements;

  • what rate limits, capacity rules or quota policies apply; and

  • how its latency compares with fast, priority, flex or default.

The GitHub page records a change to OpenAI’s OpenAPI definitions. It does not provide API usage instructions, a rollout announcement or test results. The supplied X post points to that change but adds no operational documentation in the available text.

What developers should look for next

Developers should treat ultrafast as a documented schema value until OpenAI provides evidence about its operation. The useful confirmation would be an official API reference or announcement explaining how to request the tier, which accounts and models can use it, how it is billed, and what performance or capacity expectations apply.

Until those details are available, the commit supports saying that OpenAI’s API schema now includes an ultrafast option for agent service policies and model requests. It does not support calling the option generally available, claiming that it is faster in measured use, or assuming that adding the string to a request will activate a working production tier.

Sources