Open Responses

What it is

Open Responses is an open specification, together with a supporting ecosystem, for interfaces to large language models that work across more than one provider. It builds on the OpenAI Responses API, and defines a shared schema and a tooling layer on top of it. The purpose of that layer is practical: an application should be able to call models, stream results back to the user and compose agentic workflows through one set of conventions, whether or not it matters which provider is serving the model.^[1]

The problem it starts from

The project begins with an observation about how model APIs have evolved. Over time they have converged on a small set of primitives — messages, tool calls, streaming and multimodal inputs — so different providers are, broadly speaking, offering the same building blocks. What has not converged is the encoding. Each provider represents those same ideas in its own way, which means an application that wants to work with several of them ends up maintaining a separate translation layer for each one. Open Responses takes the shared primitives as common ground and specifies a single way to express them.^[1]

Design choices

The specification treats the item as the atomic unit of model output and of tool use. Instead of handling a whole reply as one opaque object, an application deals with discrete items, and streaming is described by a consistent set of events attached to them.^[1] When the project launched it described those streaming events as semantic, and paired them with item lifecycle rules — conventions for when an item appears, changes and is complete.^[2]

A second choice is about scope. The specification keeps a stable core while deliberately leaving room for provider-specific features that do not generalize yet.^[1] A capability that only one provider offers can stay outside the shared core until it turns out to be broadly useful, rather than being standardized early and then having to be changed. That keeps the common layer small enough to be adopted quickly, at the cost of not covering everything any single provider can do.

Timeline

The changelog dates the launch to 15 January 2026, as an open, multi-provider specification with a shared schema, semantic streaming events and item lifecycle rules.^[2] A revision on 24 April 2026 added WebSocket transport for the /v1/responses path and a POST /v1/responses/compact endpoint.^[2] In October 2026, OpenAI contributed the project to the Agentic AI Foundation.^[3] The foundation described it as covering how applications talk to models across providers.^[3]

Where it sits

The foundation's description places the specification at the boundary between applications and models: it is about the conversation between the two, not about the models themselves.^[3] It is a specification and an ecosystem rather than a model or a hosted service, so adopting it means implementing or using a client that follows the schema.^[1] Its stated bet is that the primitives of model APIs are already shared, and that what is missing is agreement on how to encode them — a question that a specification, unlike a vendor SDK, can answer for several providers at once.^[1]