Responses API ou Chat Completions

Responses API et Chat Completions envoient toutes deux des instructions à des modèles de langage, mais organisent différemment les entrées, les sorties, les outils et le streaming. Le choix doit partir du contrat partagé par le client et le modèle, et non de l’idée qu’un endpoint plus récent fonctionnerait automatiquement chez tous les fournisseurs.

La règle la plus simple est la suivante :

• Utilisez Responses API pour un agent de développement ou une application qui attend déjà des éléments typés, des événements d’outil et le cycle de streaming de Responses.
• Utilisez Chat Completions pour les clients de chat largement compatibles et les familles de fournisseurs qui exposent leur format OpenAI en passthrough Chat Completions.

Vérifiez toujours le format pris en charge dans Modèles et tarifs.

Comparaison des protocoles

Question	Responses API	Chat Completions
Entrée principale	input et éléments typés	Tableau messages
Modèle de sortie	Éléments de sortie et événements typés	Choix de messages assistant et deltas
Streaming	Flux d’événements Responses	Flux de fragments Chat Completions
Outils	Appels et résultats sous forme d’éléments typés	Appels rattachés aux messages assistant
Cas d’usage privilégié	Agents, outils de code et applications natives Responses	Clients de chat et fournisseurs OpenAI-compatibles largement pris en charge
Portabilité des modèles	Modèles vérifiés pour Responses uniquement	Modèles vérifiés pour Chat Completions uniquement

Ce tableau décrit le contrat sur le réseau. Il ne signifie pas que Modelflare convertit toutes les fonctions d’un fournisseur entre les deux formats.

Quand choisir Responses API

Choisissez /v1/responses lorsque le client traite une exécution comme une suite d’éléments typés, plutôt que comme un seul message assistant. C’est fréquent dans les agents de programmation qui doivent distinguer texte visible, résumés de raisonnement, arguments de fonctions, entrées d’outils personnalisés et autres événements.

Exemple minimal :

curl -sS https://modelflare.dev/v1/responses \
  -H "Authorization: Bearer $MODELFLARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "input": "Indique les trois vérifications à effectuer avant une migration d’API.",
    "stream": true
  }'

Validez le streaming Responses de bout en bout. Un client qui sait ouvrir la connexion mais ne comprend que les fragments Chat Completions peut se connecter correctement sans parvenir à afficher une sortie utile.

Quand Chat Completions est le choix le plus sûr

Choisissez /v1/chat/completions lorsque l’application s’appuie sur les messages system, user, assistant et tool, ou lorsque le fournisseur documente précisément un endpoint Chat Completions compatible avec OpenAI.

curl -sS https://modelflare.dev/v1/chat/completions \
  -H "Authorization: Bearer $MODELFLARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_CHAT_MODEL",
    "messages": [
      {"role": "system", "content": "Réponds de façon concise."},
      {"role": "user", "content": "Que doit vérifier un contrôle d’état de l’API ?"}
    ],
    "stream": true
  }'

Pour les familles qui ne viennent pas d’OpenAI, Modelflare peut transmettre Chat Completions sans transformation afin que des champs privés — commandes de raisonnement ou de recherche, par exemple — arrivent intacts au fournisseur. Cette garantie volontairement précise vaut mieux qu’une promesse générale de compatibilité Responses.

Ne pas choisir à partir du seul nom du modèle

Trois contrôles distincts sont nécessaires :

1. La clé API accède au modèle. L’accès dépend de la clé et des groupes disponibles.
2. Le modèle accepte l’endpoint. La présence dans /v1/models ne vaut pas prise en charge des deux formats.
3. Le client comprend le flux. Les événements Responses et les fragments Chat Completions sont deux contrats clients différents.

Si l’un de ces contrôles échoue, changer uniquement le chemin de l’endpoint peut transformer une erreur explicite en réponse vide ou partiellement affichée.

Migrer les outils et les sorties structurées

Avant de déplacer une intégration réelle :

• comparez le schéma de définition des outils ;
• vérifiez comment reviennent les identifiants d’appel et les résultats ;
• conservez les valeurs optionnelles explicites telles que 0 et false ;
• repérez les champs privés qui doivent être transmis sans modification ;
• testez les réponses qui ne contiennent que des appels d’outils, sans texte visible ;
• confirmez la manière dont le client détecte la fin et l’utilisation.

Obtenir un texte similaire avec le même prompt ne suffit pas à valider un protocole. Le test doit couvrir les fonctions dont dépend réellement l’application.

Parcours de sélection recommandé

1. Choisissez le modèle et le groupe dans Modèles et tarifs.
2. Confirmez le format d’API pris en charge.
3. Suivez un guide adapté au client dans la documentation Modelflare, s’il existe.
4. Envoyez une requête sans streaming.
5. Envoyez une requête en streaming.
6. Exercez les outils ou la sortie structurée.
7. Vérifiez statut, temps, jetons et coût dans les journaux d’utilisation.

Responses API ne remplace pas Chat Completions dans tous les cas, et Chat Completions n’est pas obsolète. Le bon format est celui que prennent en charge ensemble le client, le modèle choisi et le contrat du fournisseur.