14 pontos por GN⁺ 2026-01-17 | 1 comentários | Compartilhar no WhatsApp
  • Um padrão open source e um ecossistema voltados para a interoperabilidade entre múltiplos provedores de LLM, definindo uma interface comum com base na OpenAI Responses API
  • Descreve requisições e respostas com um schema compartilhado, permitindo executar da mesma forma em vários provedores de modelos com o mínimo de trabalho de conversão
  • Organiza componentes comuns como mensagens, chamadas de ferramentas, streaming e entradas multimodais em uma estrutura consistente, adequada para implementar workflows de agentes
  • Com uma estrutura que permite extensões específicas de cada provedor sobre um núcleo estável, busca ao mesmo tempo expansibilidade e ausência de fragmentação
  • Operado com base em uma comunidade com participação de vários builders, incluindo OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI e vLLM

Visão geral

  • Open Responses é um padrão open source e um ecossistema de ferramentas baseado na OpenAI Responses API
  • Foi projetado para permitir executar chamadas de modelos de linguagem, processamento de resultados em streaming e composição de agentes de forma independente do provedor
  • Oferece uma experiência de interface única por meio de um schema comum e de uma camada de tooling

Por que Open Responses

  • Embora as APIs de LLM compartilhem componentes semelhantes, como mensagens, chamadas de ferramentas, streaming e entradas multimodais, elas usam formas de codificação diferentes
  • Open Responses fornece uma especificação comum aberta que unifica isso e reduz o custo de implementações duplicadas
  • A estrutura de requisição e saída definida uma vez pode ser reutilizada em vários provedores

Princípios de design

  • Um design multi-provedor por padrão, em que um único schema pode ser mapeado para diferentes provedores de modelo
  • Usa o conceito de items como unidade mínima de eventos de streaming, padrões de chamada de ferramentas e saídas do modelo, oferecendo uma estrutura amigável para workflows de agentes
  • Para recursos que não podem ser generalizados, permite extensões por provedor, mas prioriza a manutenção da estabilidade do núcleo

Comunidade e ecossistema

  • É operado como um projeto de comunidade aberta partindo do pressuposto de um ambiente multi-vendor
  • OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI e vLLM aparecem com seus logos como participantes
  • Forma uma comunidade centrada em desenvolvedores que valoriza portabilidade, interoperabilidade e uma base comum

Características da especificação

  • Com um schema comum centrado em Items, expressa mensagens/chamadas de ferramentas/estado de inferência na mesma unidade, com uma estrutura em que tanto entrada quanto saída circulam como item
  • Define respostas e items como uma máquina de estados, gerenciando explicitamente ciclos de vida como in_progresscompleted/failed/incomplete
  • Padroniza o streaming não como fragmentos de texto, mas como semantic events, fixando um padrão que começa em response.output_item.added e se fecha com delta→done
  • Separa ferramentas em execução externa (desenvolvedor/terceiros) e execução interna (hospedada pelo provedor), fornecendo um plano de controle que impõe o escopo de chamadas possíveis com tool_choice/allowed_tools
  • Com previous_response_id, o servidor reconstrói entradas + saídas anteriores como contexto, oferecendo suporte a continuação de conversa/minimização de reenvio, e com truncation é possível escolher entre “permitir truncamento vs falhar em caso de excesso”
  • Extensões fora do padrão são separadas com o prefixo provider_slug:, e hosted tools customizadas devem obrigatoriamente fornecer o tipo de item correspondente, deixando um “recibo” que pode ser registrado em logs e percorrido em round-trip
  • Erros são retornados como um error object estruturado, e erros durante streaming encerram com o evento response.failed

1 comentários

 
softer 2026-01-18

Oh... eu estava implementando algo assim, acho que vou usar isso como base.