- Un estándar open source y ecosistema orientado a la interoperabilidad entre múltiples proveedores de LLM, que define una interfaz común basada en la OpenAI Responses API
- Describe solicitudes y respuestas con un esquema compartido, lo que permite ejecutar de la misma manera en varios proveedores de modelos con un trabajo mínimo de conversión
- Organiza componentes comunes como mensajes, llamadas a herramientas, streaming y entradas multimodales en una estructura consistente, adecuada para implementar flujos de trabajo de agentes
- Con una estructura que permite extensiones específicas por proveedor sobre un núcleo estable, busca al mismo tiempo extensibilidad y ausencia de fragmentación
- Operado sobre una comunidad con participación de múltiples builders, entre ellos OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI y vLLM
Resumen general
- Open Responses es una especificación open source y un ecosistema de herramientas basado en la OpenAI Responses API
- Está diseñado para permitir realizar llamadas a modelos de lenguaje, procesar resultados en streaming y construir agentes de forma independiente del proveedor
- Ofrece una experiencia de interfaz única mediante un esquema común y una capa de tooling
Por qué Open Responses
- Aunque las APIs de LLM comparten componentes similares como mensajes, llamadas a herramientas, streaming y entradas multimodales, actualmente usan formas de codificación distintas
- Open Responses ofrece una especificación común abierta que unifica esto y reduce la carga de implementaciones duplicadas
- La estructura de solicitudes y salidas definida una vez puede reutilizarse con varios proveedores
Principios de diseño
- Con un diseño multproveedor desde el inicio, un único esquema puede mapearse a diversos proveedores de modelos
- Usa el concepto de items como unidad mínima de eventos de streaming, patrones de llamada a herramientas y salidas del modelo, ofreciendo una estructura amigable para flujos de trabajo de agentes
- Permite extensiones específicas por proveedor para funciones no generalizables, pero prioriza mantener la estabilidad del núcleo
Comunidad y ecosistema
- Se gestiona como un proyecto de comunidad abierta pensado para entornos multivendor
- Diversas organizaciones como OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI y vLLM aparecen como participantes mediante sus logotipos
- Se ha formado una comunidad centrada en desarrolladores que valora la portabilidad, la interoperabilidad y una base común
Características de la especificación
- Con un esquema común centrado en items, expresa mensajes/llamadas a herramientas/estado de razonamiento con la misma unidad; tanto la entrada como la salida se intercambian como items
- Define respuestas e items como una máquina de estados, gestionando explícitamente ciclos de vida como
in_progress→completed/failed/incomplete
- Estandariza el streaming no como fragmentos de texto sino como semantic events, fijando un patrón que comienza con
response.output_item.added y cierra con delta→done
- Distingue las herramientas entre ejecución externa (desarrollador/terceros) y ejecución interna (alojada por el proveedor), y ofrece una capa de control que fuerza el alcance de llamadas posibles con
tool_choice/allowed_tools
- Con
previous_response_id, el servidor reconstruye como contexto la entrada+salida previa para continuar conversaciones/minimizar reenvíos, y con truncation se puede elegir entre “permitir recorte vs fallar si se excede”
- Las extensiones fuera del estándar se separan con el prefijo
provider_slug:; las hosted tools personalizadas deben proporcionar obligatoriamente un tipo de item correspondiente para dejar un “recibo” que permita logs/round-trip
- Los errores se devuelven como un error object estructurado, y los errores durante el streaming terminan con el evento
response.failed
1 comentarios
Oh... había algo que estaba implementando, creo que debería usar esto como base.