Qu'est-ce que Open Responses ?

Open Responses est une spécification ouverte, publiée sous forme de document OpenAPI 3.1, qui décrit une forme de requête et de réponse pour appeler des modèles de langage chez différents fournisseurs. Elle est basée sur l'API Responses d'OpenAI : vous envoyez model, input et éventuellement tools à POST /v1/responses, et vous recevez en retour des éléments typés et des événements de streaming sémantiques au lieu d'un format spécifique à un fournisseur. OpenAI a lancé Open Responses le 15 janvier 2026, elle est sous licence Apache 2.0, et le 22 octobre 2026, OpenAI l'a cédée à l'Agentic AI Foundation (AAIF), l'organisme de la Linux Foundation qui héberge également MCP.

Essayez Apidog dès aujourd'hui

Cette dernière étape est la nouvelle : la spécification dispose désormais d'une charte technique, d'un comité de pilotage et d'un organisme hôte neutre. Cet article couvre ce qu'elle définit, qui l'implémente, ce que le transfert à l'AAIF change, et comment vérifier si un point de terminaison dont vous dépendez est conforme. Si vous découvrez l'API sous-jacente, commencez par comment utiliser l'API Responses d'OpenAI.

Ce que définit Open Responses

La spécification décrit clairement le problème : les fournisseurs ont convergé vers les mêmes briques de base (messages, appels d'outils, streaming, entrée multimodale) mais chacun les encode différemment. Open Responses choisit un encodage et le couche par écrit.

Le document OpenAPI actuel est en version 2026-04-24 et couvre une petite surface :

Opération	Ce qu'elle fait
POST /responses (createResponse)	Créer une réponse, avec ou sans streaming
WebSocket sur /responses	Même modèle de réponse sur une socket persistante (ajouté le 24 avril 2026)
POST /responses/compact (compactResponse)	Retourner une fenêtre d'entrée compactée pour les longues conversations

Le corps de la requête accepte les champs auxquels vous vous attendez si vous avez utilisé l'API d'OpenAI : model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key et quelques autres. L'objet de réponse (ResponseResource) contient id, status, output, usage, error et un écho des paramètres que vous avez envoyés. Le document définit 108 schémas au total, la plupart étant des types d'éléments et d'événements de streaming.

Trois idées portent la conception.

Les éléments sont l'unité de contexte

Tout ce que le modèle lit ou produit est un élément : un message, un function_call, un function_call_output, un élément reasoning. Les éléments sont bidirectionnels, de sorte que la sortie d'un tour peut être renvoyée directement comme entrée du tour suivant. Chaque type d'élément est discriminé par son champ type et possède son propre schéma.

Les éléments sont aussi des machines à états : chacun passe de in_progress à completed ou incomplete (le budget de tokens est épuisé), et un élément incomplete doit être le dernier émis, la réponse entière étant marquée incomplète. Un statut ne dit rien sur le fait que le serveur ait stocké l'élément ; la persistance est une préoccupation distincte.

Le streaming est constitué d'événements sémantiques, pas de deltas bruts

Lorsque vous définissez stream: true, le serveur doit répondre avec Content-Type: text/event-stream et une séquence d'événements définie. Un élément de sortie s'ouvre avec response.output_item.added ; le texte qu'il contient arrive sous forme de response.content_part.added, puis d'événements répétés response.output_text.delta, puis de response.output_text.done et response.content_part.done ; l'élément se ferme avec response.output_item.done. Le flux doit se terminer par un événement terminal : response.completed, response.failed ou response.incomplete. Un [DONE] final est facultatif, et les clients doivent gérer un flux qui se termine sans lui.

Cela compte surtout pour le code client : si deux fournisseurs émettent les mêmes événements dans le même ordre, un seul parseur SSE fonctionne pour les deux. Notre guide de test SSE montre comment inspecter ces flux événement par événement.

Un noyau stable avec des extensions qualifiées par espace de noms

Les fournisseurs peuvent ajouter leurs propres types d'éléments, outils et événements de streaming, mais ils doivent les préfixer par un identifiant de fournisseur. L'exemple de la spécification elle-même est openai:web_search_call. Un client qui ne reconnaît pas un type préfixé peut l'ignorer sans que cela casse quoi que ce soit. C'est ainsi que la spécification reste portable tandis que les outils hébergés comme la recherche web ou la recherche de fichiers restent des fonctionnalités propres au fournisseur.

Le reste du contrat

Quelques règles supplémentaires méritent d'être connues avant de construire sur la spécification :

• Deux types d'outils. Les outils hébergés en externe (fonctions, serveurs MCP) s'exécutent en dehors du fournisseur ; pour les fonctions, le modèle émet un function_call, vous l'exécutez, et vous renvoyez un function_call_output avec le call_id correspondant. Les outils hébergés en interne (la recherche de fichiers d'OpenAI, par exemple) s'exécutent à l'intérieur du fournisseur sans rendre le contrôle.
• tool_choice et allowed_tools. tool_choice prend auto (la valeur par défaut), required, none, ou un objet nommant une fonction. allowed_tools restreint les outils que le modèle peut appeler tout en les affichant tous, afin que vous n'invalidiez pas un prompt mis en cache en modifiant le tableau tools. Les serveurs doivent l'appliquer comme une limite stricte.
• previous_response_id. Le serveur doit traiter la nouvelle requête comme previous_response.input + previous_response.output + input, dans cet ordre, afin que vous ne renvoyiez pas la transcription.
• Les éléments de raisonnement peuvent porter un content brut, un blob opaque encrypted_content, un summary sûr pour l'utilisateur, ou n'importe quel mélange.
• Les erreurs portent un type (server_error, invalid_request, not_found, model_error, too_many_requests), plus code, param et message ; en plein flux, une erreur est suivie de response.failed.

La révision du 24 avril 2026 (journal des modifications) a ajouté le transport WebSocket : chaque tour commence par un message response.create, une connexion traite une réponse à la fois, les connexions sont limitées à 60 minutes (code d'erreur websocket_connection_limit_reached), et les continuations store: false vivent dans la mémoire locale à la connexion, échouant avec previous_response_not_found une fois cet état disparu. La même révision a ajouté /responses/compact, un champ phase facultatif sur les messages de l'assistant (commentary ou final_answer), et a rendu logprobs facultatif.

Open Responses vs Chat Completions

Chat Completions est encore l'interface LLM la plus largement copiée. La différence est la forme : Chat Completions renvoie des choix contenant un message, avec les appels d'outils imbriqués à l'intérieur, tandis que le modèle Responses renvoie une liste plate d'éléments typés. Une étape de raisonnement, trois appels d'outils et un message final deviennent des objets distincts et ordonnés avec leur propre statut, ce qui convient mieux aux boucles d'agents.

Nous avons comparé les trois formats dominants côte à côte, avec de vraies requêtes, dans Chat Completions vs Anthropic Messages vs Responses API. Si vous choisissez entre les surfaces propres à OpenAI, l'analyse Agents API vs Responses API vs Agents SDK couvre la place de Responses.

Qui l'implémente

La liste des partisans inclut AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel et vLLM, aux côtés d'OpenAI. Anthropic et Google ne font pas partie des partisans nommés ; les deux proposent toujours leurs propres formats natifs.

« Prend en charge » couvre un large éventail, alors vérifiez les détails pour le runtime que vous utilisez :

• Ollama a ajouté POST /v1/responses dans la v0.13.3. Sa documentation de compatibilité indique que « seule la variante non stateful est prise en charge » : le streaming, les outils de fonction et les résumés de raisonnement fonctionnent, mais previous_response_id, conversation et truncation non. Vous renvoyez l'historique vous-même.
• LM Studio a rendu son point de terminaison http://localhost:1234/v1/responses compatible dans la version 0.3.39, y compris previous_response_id, les URL d'images distantes pour les modèles de vision et les logprobs. Consultez notre guide LM Studio pour la configuration.

Pour donner une idée de l'échelle, API Evangelist a établi une base de référence le 13 septembre : sur 120 fournisseurs revendiquant une compatibilité OpenAI qui publient un document OpenAPI lisible, 26 déclarent POST /responses, contre 105 qui déclarent POST /chat/completions. Le but de cette base de référence est de mesurer si une gouvernance neutre fait évoluer ce nombre.

Ce que change le transfert à l'Agentic AI Foundation

L'AAIF a annoncé Open Responses le 22 octobre 2026 à l'AGNTCon + MCPCon North America à San Jose, en même temps que trois autres nouveaux projets : Agent Skills (d'Anthropic), OpenEnv (de Hugging Face) et OpenSandbox (d'Alibaba). Cela porte l'AAIF à 10 projets hébergés au cours de sa première année, aux côtés de MCP, du protocole Agent2Agent, AGENTS.md, goose, agentgateway et Agent Router. Si vous cherchez à comprendre comment tout cela s'articule, notre explication MCP vs A2A est un bon point de départ.

Ce qui change :

• Gouvernance. Le projet est désormais « Open Responses a Series of LF Projects, LLC », avec une charte technique adoptée le 21 octobre 2026. Un comité de pilotage technique, initialement les mainteneurs du projet, est propriétaire des décisions techniques, et la participation est ouverte à toute personne qui suit la charte.
• Crédibilité pour les autres fournisseurs. Une spécification détenue par une seule entreprise est un produit. Une spécification placée sous une fondation est plus facile à adopter pour un concurrent sans donner l'impression de suivre un rival.

Ce qui ne change pas :

• L'API d'OpenAI elle-même. L'API Responses sur api.openai.com conserve ses propres fonctionnalités et son propre calendrier de publication. Open Responses décrit le noyau portable ; les outils spécifiques à OpenAI restent derrière le préfixe openai:.
• Le format d'échange. Aucune nouvelle version de la spécification n'est venue avec le transfert. La dernière version est toujours 2026-04-24, et les versions datées sont immuables.
• Conformité. Figurer sur la liste des partisans ne signifie pas qu'un point de terminaison réussit les tests. Personne ne publie encore d'index de réussite/échec, vous devez donc vérifier vous-même les points de terminaison dont vous dépendez.

Vérifier un point de terminaison avec les tests d'acceptation

Le projet fournit ses propres tests d'acceptation. La page de conformité exécute 10 tests dans le navigateur contre n'importe quelle URL de base, modèle et clé : réponse texte de base, streaming, prompt système, appel d'outils, entrée d'image, historique multi-tours, étiquettes phase de l'assistant, le point de terminaison de compactage et un test négatif pour une requête compacte sans model. Sept autres tests WebSocket (tours séquentiels, continuation store: false, reprise après reconnexion, éviction du cache après une continuation échouée) s'exécutent uniquement depuis 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

Chaque requête HTTP et chaque tour WebSocket dispose d'un délai de 30 secondes, et un dépassement de délai ne fait échouer que ce test. Attendez-vous à ce qu'un runtime non stateful tel qu'Ollama échoue aux tests de continuation par conception.

Laissez votre agent de codage le tester avec Apidog CLI

Les tests d'acceptation vous indiquent si un serveur suit la spécification aujourd'hui. Ils ne surveillent pas le point de terminaison que votre application appelle à chaque déploiement, mise à niveau d'Ollama ou changement de fournisseur. Pour cela, importez la spécification dans un projet Apidog et laissez votre agent de codage écrire et exécuter des tests de régression avec Apidog CLI.

Installez la CLI et la compétence d'agent une fois :

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Ensuite, donnez une invite à Claude Code, Codex ou Cursor :

Download https://www.openresponses.org/openapi/openapi.json and import it into
Apidog project <id>. Create an environment "local-ollama" with base URL
http://localhost:11434/v1. Add test cases for POST /responses: one that expects 200,
status "completed" and an output item of type "message"; one with stream: true that
expects text/event-stream ending in response.completed; one without "model" that
expects a 4xx error with an error.type field. Run them and summarize any failures.

L'agent lit les schémas, valide ses charges utiles avant d'écrire quoi que ce soit, et exécute les cas :

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project <id> --format openapi --file ./openapi.json
apidog environment create local-ollama --project <id> --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 <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

L'entrée servers de la spécification pointe vers https://api.openai.com/v1, donc ajoutez un environnement par fournisseur et exécutez les mêmes cas sur chacun : c'est la promesse de portabilité, testée. Placez la ligne apidog run ... -r junit dans votre pipeline pour qu'une mise à niveau de runtime qui supprime un champ fasse échouer la compilation (guide CI/CD) ; Apidog CLI dans Claude Code couvre la configuration de l'agent en détail.

FAQ

Open Responses est-il identique à l'API Responses d'OpenAI ? Non. Open Responses est une spécification dérivée de celle-ci. L'API Responses d'OpenAI est une implémentation avec des fonctionnalités supplémentaires propres à OpenAI ; Ollama, LM Studio et vLLM en sont d'autres.

Qui possède Open Responses maintenant ? Depuis le 22 octobre 2026, c'est un projet de l'Agentic AI Foundation sous la Linux Foundation, géré comme une série LF Projects avec un comité de pilotage technique. Il est sous licence Apache 2.0.

Anthropic prend-il en charge Open Responses ? Anthropic ne fait pas partie des partisans nommés. Il a contribué Agent Skills à l'AAIF le même jour, mais l'interface native de Claude est toujours l'API Messages.

Où se trouve le fichier de spécification ? À https://www.openresponses.org/openapi/openapi.json, avec des versions datées dans le dépôt GitHub.

Prochaine étape

Choisissez le point de terminaison que votre produit appelle le plus, exécutez les tests d'acceptation du navigateur contre lui, et importez la spécification dans Apidog pour que votre agent puisse maintenir ces vérifications à chaque déploiement. Téléchargez Apidog pour commencer.