¿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.

Prueba Apidog hoy

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:

Operación	Qué hace
POST /responses (createResponse)	Crear una respuesta, con streaming o no
WebSocket en /responses	Mismo modelo de respuesta sobre un socket persistente (añadido 2026-04-24)
POST /responses/compact (compactResponse)	Retornar una ventana de entrada compactada para conversaciones largas

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_outputere 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 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