¿Qué es Open Responses?

Open Responses es una especificación abierta, publicada como un documento OpenAPI 3.1, que describe una forma de solicitud y respuesta para llamar a modelos de lenguaje a través de proveedores. Se basa en la API de Respuestas de OpenAI: envías model, input y opcional tools a POST /v1/responses, y obtienes elementos tipados y eventos de streaming semánticos en lugar de un formato específico de proveedor. OpenAI lanzó Open Responses el 15-01-2026, está licenciado bajo Apache 2.0, y el 22-10-2026 OpenAI lo contribuyó a la Agentic AI Foundation (AAIF), el organismo de la Linux Foundation que también alberga MCP.

Ese último paso es la noticia: la especificación ahora cuenta con un acta técnica, un comité directivo y un hogar neutral. Esta publicación cubre lo que define, quién lo implementa, lo que cambia el movimiento de AAIF y cómo verificar si un endpoint al que dependes cumple con ella. Si eres nuevo en la API subyacente, comienza con cómo usar la API de Respuestas de OpenAI.

Lo que define Open Responses

La especificación describe el problema de forma clara: los proveedores han convergido en los mismos bloques de construcción (mensajes, llamadas a herramientas, streaming, entrada multimodal), pero cada uno los codifica de manera diferente. Open Responses elige una codificación y la escribe.

El actual documento OpenAPI es la versión 2026-04-24 y cubre una pequeña superficie:

El cuerpo de la solicitud acepta los campos que esperarías si has utilizado la API de OpenAI: model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key y algunos más. El objeto de respuesta (ResponseResource) lleva id, status, output, usage, error y un eco de los ajustes que enviaste. El documento define 108 esquemas en total, la mayoría son tipos de elemento y eventos de streaming.

Tres ideas sustentan el diseño.

Los elementos son la unidad de contexto

Todo lo que el modelo lee o produce es un elemento: un message, una function_call, una function_call_output, un elemento reasoning. Los elementos son bidireccionales, por lo que la salida de un turno puede ser devuelta directamente como entrada para el siguiente. Cada tipo de elemento se discrimina por su campo type y tiene su propio esquema.

Los elementos también son máquinas de estados: cada uno pasa de in_progress a completed o incomplete (el presupuesto de tokens se agotó), y un elemento incomplete debe ser el último emitido, con toda la respuesta marcada como incompleta. Un estado no dice nada sobre si el servidor almacenó el elemento; la persistencia es una preocupación separada.

El streaming son eventos semánticos, no deltas brutos

Cuando configuras stream: true, el servidor debe responder con Content-Type: text/event-stream y una secuencia de eventos definida. Un elemento de salida comienza con response.output_item.added; el texto dentro de él llega como response.content_part.added, luego eventos repetidos response.output_text.delta, después response.output_text.done y response.content_part.done; el elemento se cierra con response.output_item.done. El stream debe terminar con un evento terminal: response.completed, response.failed o response.incomplete. Un [DONE] final es opcional, y los clientes deben manejar un stream que finalice sin él.

Esto es más importante para el código del cliente: si dos proveedores emiten los mismos eventos en el mismo orden, un solo analizador SSE funciona para ambos. Nuestra guía de pruebas de SSE muestra cómo inspeccionar estos streams evento por evento.

Un núcleo estable con extensiones con espacio de nombres

Los proveedores pueden añadir sus propios tipos de elementos, herramientas y eventos de streaming, pero deben prefijarlos con un slug de proveedor. El ejemplo propio de la especificación es openai:web_search_call. Un cliente que no reconozca un tipo prefijado puede saltárselo sin romper. Así es como la especificación permanece portátil mientras las herramientas alojadas como la búsqueda web o la búsqueda de archivos siguen siendo características de proveedores.

El resto del contrato

Hay algunas reglas más que vale la pena conocer antes de construir sobre la especificación:

• Dos tipos de herramientas. Las herramientas alojadas externamente (funciones, servidores MCP) se ejecutan fuera del proveedor; para funciones, el modelo emite una function_call, tú la ejecutas y envías de vuelta una function_call_output con el call_id coincidente. Las herramientas alojadas internamente (la búsqueda de archivos de OpenAI, por ejemplo) se ejecutan dentro del proveedor sin devolver el control.
• tool_choice y allowed_tools. tool_choice acepta auto (el predeterminado), required, none o un objeto que name una función. allowed_tools restringe qué herramientas puede llamar el modelo mientras sigue mostrando todas ellas, para que no invalides un prompt en caché editando el array tools. Los servidores deben aplicarlo como un límite estricto.
• previous_response_id. El servidor debe tratar la nueva solicitud como previous_response.input + previous_response.output + input, en ese orden, para que no envíes el historial de nuevo.
• Los elementos de razonamiento pueden llevar content sin procesar, un bloque encrypted_content opaco, un summary seguro para el usuario, o cualquier mezcla.
• Los errores llevan un type (server_error, invalid_request, not_found, model_error, too_many_requests), además de code, param y message; en medio del stream, un error es seguido por response.failed.

La revisión 2026-04-24 (changelog) añadió el transporte WebSocket: cada turno comienza con un mensaje response.create, una conexión procesa una respuesta a la vez, las conexiones tienen un límite de 60 minutos (código de error websocket_connection_limit_reached), y las continuaciones con store: false viven en la memoria local de la conexión, fallando con previous_response_not_found una vez que ese estado se desvanece. La misma revisión añadió /responses/compact, un campo phase opcional en los mensajes del asistente (commentary o final_answer), y hizo que logprobs sea opcional.

Open Responses vs Chat Completions

Chat Completions sigue siendo la interfaz de LLM más copiada. La diferencia es la forma: Chat Completions retorna opciones que contienen un mensaje, con llamadas a herramientas metidas dentro, mientras que el modelo Responses retorna una lista plana de elementos tipados. Un paso de razonamiento, tres llamadas a herramientas y un mensaje final se convierten en objetos separados y ordenados con su propio estado, lo que se adapta mejor a los bucles de agente.

Comparamos los tres formatos dominantes lado a lado, con solicitudes reales, en Chat Completions vs Anthropic Messages vs Responses API. Si estás eligiendo entre las superficies de OpenAI, el desglose Agents API vs Responses API vs Agents SDK cubre dónde se ubica Responses.

Quién lo implementa

La lista de partidarios incluye AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel y vLLM, junto con OpenAI. Anthropic y Google no están entre los partidarios nombrados; ambos todavía envían sus propios formatos nativos.

“Apoya” cubre una amplia gama, así que revisa los detalles para el entorno de ejecución que utilizas:

• Ollama añadió POST /v1/responses en v0.13.3. Su documentación de compatibilidad dice “solo se soporta la versión no con estado”: funcionan el streaming, las herramientas de funciones y los resúmenes de razonamiento, pero no previous_response_id, conversation y truncation. Tú reenviás el historial tú mismo.
• LM Studio hizo su endpoint http://localhost:1234/v1/responses compatible en la versión 0.3.39, incluyendo previous_response_id, URLs de imagen remota para modelos de visión y logprobs. Consulta nuestra guía de LM Studio para la configuración.

Para tener una idea de la magnitud, API Evangelist tomó una línea base el 13 de septiembre: de 120 proveedores que reclaman compatibilidad con OpenAI y que publican un documento OpenAPI legible, 26 declaran POST /responses, frente a 105 que declaran POST /chat/completions. El punto de la línea base es medir si la gobernanza neutral mueve ese número.

Lo que cambia el movimiento de Agentic AI Foundation

AAIF anunció Open Responses el 22-10-2026 en AGNTCon + MCPCon North America en San José, junto con tres nuevos proyectos: Agent Skills (de Anthropic), OpenEnv (de Hugging Face) y OpenSandbox (de Alibaba). Esto lleva a AAIF a 10 proyectos alojados en su primer año, junto a MCP, el protocolo Agent2Agent, AGENTS.md, goose, agentgateway y Agent Router. Si estás tratando de entender cómo encajan, nuestro explicador MCP vs A2A es un buen punto de partida.

Lo que cambia:

• Gobernanza. El proyecto es ahora “Open Responses a Series of LF Projects, LLC”, con un acta técnica adoptada el 21-10-2026. Un Comité Directivo Técnico, inicialmente los mantenedores del proyecto, posee las decisiones técnicas, y la participación está abierta a cualquier persona que siga el acta.
• Credibilidad para otros vendedores. Una especificación propiedad de una compañía es un producto. Una especificación bajo una fundación es más fácil de adoptar para un competidor sin parecer que sigue a un rival.

Lo que no cambia:

• La propia API de OpenAI. La API Responses en api.openai.com mantiene sus propias características y calendario de lanzamiento. Open Responses describe el núcleo portable; las herramientas específicas de OpenAI permanecen detrás del prefijo openai:.
• El formato del cable. Ninguna nueva versión de la especificación vino con el movimiento. El último lanzamiento sigue siendo 2026-04-24, y los lanzamientos fechados son inmutables.
• Conformidad. Estar en la lista de partidarios no significa que un endpoint pase las pruebas. Nadie publica un índice de aprobado/reprobado todavía, así que tú verificas los endpoints de los que dependes.

Ver un endpoint con las pruebas de aceptación

El proyecto envía sus propias pruebas de aceptación. La página de cumplimiento ejecuta 10 pruebas en el navegador contra cualquier URL base, modelo y clave: respuesta de texto básica, streaming, prompt del sistema, llamada a herramientas, entrada de imagen, historial de múltiples turnos, etiquetas phase del asistente, el endpoint de compactación y una prueba negativa para una solicitud compacta que falta model. Siete pruebas adicionales de WebSocket (turnos secuenciales, continuación store: false, recuperación de reconexión, eliminación de caché después de una continuación fallida) se ejecutan solo desde la CLI:

git clone https://github.com/openresponses/openresponses
cd openresponses && bun install
bun run test:compliance --base-url http://localhost:11434/v1 --api-key ollama

Cada solicitud HTTP y cada turno de WebSocket tiene un plazo de 30 segundos, y un timeout falla solo esa prueba. Espera que un entorno de ejecución no con estado como Ollama falle las pruebas de continuación por diseño.

Deja que tu agente de codificación lo pruebe con Apidog CLI

Las pruebas de aceptación te dicen si un servidor cumple con la especificación hoy. No vigilan el endpoint que tu aplicación llama cada vez que implementas, actualizas Ollama o cambias de proveedor. Para eso, importa la especificación en un proyecto de Apidog y deja que tu agente de codificación escriba y ejecute pruebas de regresión contra ella con Apidog CLI.

Instala la CLI y la habilidad del agente una vez:

npm install -g apidog-cli@latest
apidog auth login --with-token 
npx -y skills add https://apidog.com # elige tu agente al ser preguntado

Luego dame a Claude Code, Codex o Cursor un solo prompt:

Descarga https://www.openresponses.org/openapi/openapi.json e impórtalo en el proyecto de
Apidog . Crea un entorno "local-ollama" con base URL
http://localhost:11434/v1. Agrega casos de prueba para POST /responses: uno que espere 200,
estado "completed" y un elemento de salida de tipo "message"; uno con stream: true que
espere text/event-stream terminando en response.completed; uno sin "model" que
espere un error 4xx con un campo error.type. Ejecútalos y resume cualquier fallo.

El agente lee los esquemas, valida sus payloads antes de escribir algo y ejecuta los casos:

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project --format openapi --file ./openapi.json
apidog environment create local-ollama --project --base-url http://localhost:11434/v1
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project --file case.json
apidog run --test-case --project -e -r cli,json

La entrada servers de la especificación apunta a https://api.openai.com/v1, así que añade un entorno por proveedor y ejecuta los mismos casos contra cada uno: esa es la afirmación de portabilidad, probada. Coloca la línea apidog run ... -r junit en tu pipeline para que una actualización de entorno de ejecución que omita un campo falle la compilación (Guía de CI/CD); Apidog CLI in Claude Code cubre la configuración del agente en detalle.

FAQ

¿Es Open Responses lo mismo que la API de Respuestas de OpenAI? No. Open Responses es una especificación derivada de ella. La API de Respuestas de OpenAI es una de las implementaciones con funciones extra solo de OpenAI; Ollama, LM Studio y vLLM son otras.

¿Quién es el dueño de Open Responses ahora? Desde el 22-10-2026 es un proyecto de Agentic AI Foundation bajo la Linux Foundation, operado como una serie de LF Projects con un Comité Directivo Técnico. Está licenciado bajo Apache 2.0.

¿Anthropic apoya Open Responses? Anthropic no está entre los partidarios nombrados. Contribuyó con Agent Skills a AAIF el mismo día, pero la interfaz nativa de Claude sigue siendo Messages API.

¿Dónde está el archivo de la especificación? En https://www.openresponses.org/openapi/openapi.json, con lanzamientos fechados en el repositorio de GitHub.

Siguiente paso

Elige el endpoint que tu producto llama más, ejecuta las pruebas de aceptación en el navegador contra él e importa la especificación en Apidog para que tu agente pueda seguir realizando esas verificaciones en cada despliegue. Descarga Apidog para comenzar.