What Open Responses changes for AI developers

AI developers should be able to support models from multiple providers without writing separate code to send requests and handle responses for each one.

Today, supporting multiple model providers often means maintaining adapters for each one. Each provider's API uses different formats for common tasks such as sending context, describing tools, receiving tool calls, and returning results. Those differences become ongoing work whenever a provider adds a feature or changes how its API behaves.

Open Responses was built to give that exchange a shared specification. Based on OpenAI's Responses API, it defines a common format for the requests and responses exchanged through an API endpoint, the address an agent sends model requests to. AI developers can then reuse their integration across endpoints that implement the specification.

What changes for an agent builder

Consider a coding agent asked to find and fix a failing test. It sends the user’s request and its available tools to a model, receives a request to read a file, executes that tool, and sends the result back. The model might then request another file, propose an edit, or ask the agent to run the tests.

The same request in different APIs

For a simple step in that workflow, the agent might ask a model to explain why a test is failing. Anthropic's Messages API sends the prompt in messages, while Google's generateContent API uses contents and parts. The following request bodies show the same prompt and output limit.

The code an agent builder maintains

Those differences require separate code to build requests. The simplified JavaScript below compares that code with a shared Open Responses request builder.

Without Open Responses

function buildRequest(provider, model, prompt) {
  if (provider === "anthropic") {
    return {
      url: "https://api.anthropic.com/v1/messages",
      body: {
        model,
        max_tokens: 512,
        messages: [
          { role: "user", content: prompt }
        ]
      }
    };
  }

if (provider === "google") {
    return {
      url: `https://generativelanguage.googleapis.com/v1beta/models/${model}:generateContent`,
      body: {
        contents: [{
          role: "user",
          parts: [{ text: prompt }]
        }],
        generationConfig: {
          maxOutputTokens: 512
        }
      }
    };
  }

throw new Error(
    `Unsupported provider: ${provider}`
  );
}

With Open Responses

function buildRequest(endpoint, model, prompt) {
  return {
    url: endpoint,
    body: {
      model,
      input: prompt,
      max_output_tokens: 512
    }
  };
}

With Open Responses, the endpoint and model identifier become configuration rather than branches in the code, whether the endpoint comes from a model provider, gateway, or local serving platform. The service exposing that endpoint implements the specification, with gateways handling translation to the provider APIs behind them. The shared format also covers tool calls and streaming responses, while the agent retains control over tool execution and permissions.

The specification applies to the API, so adopting it doesn't require changing or retraining a model. The common format also allows providers to introduce their own capabilities.

How providers add features

The specification allows extensions for features such as a hosted search tool or additional information about how a request was processed, without changing the meaning of the standard request and response fields.

For example, the specification permits additional streaming events that report timing or cache information. Agents that understand those events use them to show more detail to users, while other agents safely ignore them and continue processing the standard response. Provider-specific names identify these additions so features from different implementations don't conflict.

AI developers choose which additions to support while keeping their common Open Responses integration. When a feature gains broad adoption, the community has a process for proposing its inclusion in the shared specification.

How implementations make the contract useful

Existing implementations give AI developers access to models through the shared API format.

Databricks Model Serving exposes an Open Responses endpoint for Claude, Gemini, and Databricks-hosted open models. Databricks translates requests into each provider’s native format, which means the client sends the shared request format while the serving platform handles the provider translation.

Vercel AI Gateway also exposes an OpenResponses API, giving applications a common endpoint for accessing models through its gateway.

These services accept the shared request format shown above, giving AI developers a way to use the specification today.

Why Open Responses is now a part of AAIF

As more services implement the contract, changes to it affect both the endpoints and the applications built against them. Providers need a way to propose new capabilities, and AI developers need a way to explain how those changes affect their clients.

Joining the Agentic AI Foundation gives providers and AI developers a neutral home to develop the specification together, with changes informed by the experience of people implementing and using it.

If you maintain an agent, client library, model API, or serving platform, try the specification against a workflow you already support. Share where it removes an adapter, where information gets lost, or where a feature needs a clearer definition. Those concrete examples help us improve the contract for everyone using it.

Read the specification, explore the repository, and join the technical discussions.