Statut legacy et principe stateless

L’endpoint Chat Completions dans l’ecosysteme xAI

L’API xAI propose deux endpoints principaux pour interagir avec les modeles Grok : l’API Responses (endpoint principal) et l’endpoint Chat Completions. Ce dernier est marque comme legacy : il reste pleinement fonctionnel, mais les nouvelles fonctionnalites sont desormais ajoutees en priorite a l’API Responses.

Pourquoi alors s’y interesser ? Parce que Chat Completions reste l’endpoint le plus largement adopte dans l’ecosysteme. Tous les SDKs OpenAI existants, les frameworks comme LangChain ou LlamaIndex, et des milliers de tutoriels utilisent ce format. Si vous migrez depuis un autre fournisseur ou si vous travaillez avec des outils tiers, c’est probablement l’endpoint que vous utiliserez en premier.

Un endpoint stateless : tout renvoyer a chaque requete

Le principe fondamental de Chat Completions est qu’il est stateless : le serveur ne conserve aucun historique de conversation. A chaque appel, vous devez inclure l’integralite des messages precedents dans votre requete.

Concretement, cela signifie que pour une conversation de 10 echanges, votre 11e requete doit contenir les 10 messages precedents (user + assistant) en plus du nouveau message. C’est a votre application de gerer cet historique.

{
  "model": "grok-4.20-reasoning",
  "messages": [
    {"role": "system", "content": "Tu es un assistant utile."},
    {"role": "user", "content": "Bonjour !"},
    {"role": "assistant", "content": "Bonjour ! Comment puis-je vous aider ?"},
    {"role": "user", "content": "Explique-moi le deep learning."}
  ]
}

Dans cet exemple, les trois premiers messages representent l’historique de la conversation. Seul le dernier est le nouveau message de l’utilisateur. Le modele a besoin de tout ce contexte pour produire une reponse coherente.

Implications pratiques

Cette approche stateless a plusieurs consequences :

• Controle total : vous decidez exactement quels messages sont envoyes au modele. Vous pouvez filtrer, resumer ou modifier l’historique avant chaque appel.
• Cout proportionnel : chaque requete est facturee pour l’ensemble des tokens envoyes, y compris l’historique. Plus la conversation est longue, plus chaque echange coute cher.
• Pas de persistance serveur : aucune donnee n’est stockee cote xAI entre les requetes. C’est un avantage pour la confidentialite, mais cela vous impose de gerer vous-meme la persistance.

Comparaison avec l’API Responses

L’API Responses, elle, est stateful : elle conserve l’historique cote serveur via previous_response_id. Vous n’avez pas besoin de renvoyer les messages precedents — un simple identifiant suffit. Les reponses peuvent etre stockees jusqu’a 30 jours avec store: true.

Le choix entre les deux depend de votre cas d’usage. Si vous travaillez avec un SDK OpenAI existant ou migrez depuis un autre fournisseur, Chat Completions est le point d’entree naturel. Pour un nouveau projet, l’API Responses est recommandee.

Points cles a retenir

• Chat Completions est marque legacy mais reste pleinement fonctionnel et compatible avec l’ecosysteme OpenAI
• L’endpoint est stateless : vous devez renvoyer tout l’historique a chaque requete
• Le cout de chaque requete inclut l’ensemble des tokens de l’historique
• L’API Responses offre une alternative stateful avec persistance cote serveur
• Pour les modeles de raisonnement, un timeout de 3600 secondes est recommande