Open Responses - Une spécification ouverte pour l’interopérabilité entre LLM

• Un écosystème et une spécification open source visant l’interopérabilité entre plusieurs fournisseurs de LLM, qui définit une interface commune à partir de l’API OpenAI Responses
• Les requêtes et les réponses sont décrites à l’aide d’un schéma partagé, afin de pouvoir s’exécuter de la même manière chez plusieurs fournisseurs de modèles avec un minimum de transformations
• Les composants communs comme les messages, les appels d’outils, le streaming ou les entrées multimodales sont organisés dans une structure cohérente, adaptée à l’implémentation de workflows d’agents
• Une architecture qui autorise des extensions propres à chaque fournisseur au-dessus d’un cœur stable, en recherchant à la fois extensibilité et continuité
• Fonctionne sur la base d’une communauté réunissant de nombreux builders, parmi lesquels OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI et vLLM

---

Aperçu

• Open Responses est une spécification open source et un écosystème d’outils basés sur l’API OpenAI Responses
• Conçu pour permettre des appels à des modèles de langage, le traitement de résultats en streaming et la composition d’agents de manière indépendante du fournisseur
• Offre une expérience d’interface unique grâce à un schéma commun et une couche d’outillage

Pourquoi Open Responses ?

• Les API de LLM partagent des composants similaires — messages, appels d’outils, streaming, entrées multimodales — mais utilisent des modes d’encodage différents
• Open Responses fournit une spécification commune ouverte qui les unifie et réduit la charge liée aux implémentations redondantes
• Les structures de requête et de sortie définies une fois peuvent être réutilisées auprès de plusieurs fournisseurs

Principes de conception

• Une conception pensée nativement pour plusieurs fournisseurs, avec un schéma unique pouvant être mappé vers divers fournisseurs de modèles
• Utilise le concept d’items comme unité minimale pour les événements de streaming, les patterns d’appels d’outils et les sorties de modèle, offrant une structure adaptée aux workflows d’agents
• Les fonctionnalités qui ne se généralisent pas peuvent être étendues par fournisseur, mais la priorité reste le maintien de la stabilité du cœur

Communauté et écosystème

• Un projet communautaire ouvert conçu pour un environnement multi-fournisseurs
• Différentes organisations comme OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI et vLLM y affichent leur participation via leurs logos
• Une communauté centrée sur les développeurs s’est formée autour de la portabilité, de l’interopérabilité et d’une base commune

Caractéristiques de la spécification

• Un schéma commun centré sur les items exprime messages, appels d’outils et état du raisonnement dans la même unité, avec une structure où entrées et sorties circulent toutes deux sous forme d’items
• Les réponses et les items sont définis comme une machine à états, gérant explicitement des cycles de vie comme in_progress → completed/failed/incomplete
• Le streaming est standardisé non pas comme des fragments de texte mais comme des semantic events, avec un pattern fixe commençant par response.output_item.added puis se terminant par delta → done
• Les outils sont distingués entre exécution externe (développeur/tiers) et exécution interne (hébergée par le fournisseur), avec une surface de contrôle qui impose le périmètre d’appel via tool_choice/allowed_tools
• Avec previous_response_id, le serveur reconstruit les entrées et sorties précédentes comme contexte afin de prendre en charge la reprise de conversation / minimisation des renvois, et truncation permet de choisir entre « autoriser la coupe » ou « échouer en cas de dépassement »
• Les extensions hors standard sont séparées par le préfixe provider_slug: ; les hosted tools personnalisés doivent obligatoirement fournir un type d’item correspondant afin de laisser un « reçu » exploitable pour les logs et les aller-retours
• Les erreurs sont renvoyées sous forme d’un objet d’erreur structuré et, en streaming, une erreur met fin au flux via l’événement response.failed