Statut legacy et principe stateless

L’endpoint Chat Completions dans l’écosystème xAI

L’API xAI propose deux endpoints principaux pour interagir avec les modèles Grok : l’API Responses (endpoint principal) et l’endpoint Chat Completions. Ce dernier est marque comme legacy : il reste pleinement fonctionnel, mais les nouvelles fonctionnalités sont désormais ajoutées en priorité à l’API Responses.

Pourquoi alors s’y intéresser ? Parce que Chat Completions reste l’endpoint le plus largement adopté dans l’écosystème. 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 à chaque requête

Le principe fondamental de Chat Completions est qu’il est stateless : le serveur ne conserve aucun historique de conversation. À chaque appel, vous devez inclure l’intégralité des messages précédents dans votre requête.

Concrètement, cela signifie que pour une conversation de 10 échanges, votre 11e requête doit contenir les 10 messages précédents (user + assistant) en plus du nouveau message. C’est à votre application de gérer cet historique.

{
  "model": "grok-4.20-0309-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 représentent l’historique de la conversation. Seul le dernier est le nouveau message de l’utilisateur. Le modèle a besoin de tout ce contexte pour produire une réponse cohérente.

Implications pratiques

Cette approche stateless à plusieurs conséquences :

• Contrôle total : vous décidez exactement quels messages sont envoyés au modèle. Vous pouvez filtrer, résumer ou modifier l’historique avant chaque appel.
• Coût proportionnel : chaque requête est facturée pour l’ensemble des tokens envoyés, y compris l’historique. Plus la conversation est longue, plus chaque échange coûte cher.
• Pas de persistance serveur : aucune donnée n’est stockée côté xAI entre les requêtes. C’est un avantage pour la confidentialité, mais cela vous impose de gérer vous-même la persistance.

Comparaison avec l’API Responses

L’API Responses, elle, est stateful : elle conserve l’historique côté serveur via previous_response_id. Vous n’avez pas besoin de renvoyer les messages précédents — un simple identifiant suffit. Les réponses peuvent être stockées jusqu’à 30 jours avec store: true.

Le choix entre les deux dépend 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’entrée naturel. Pour un nouveau projet, l’API Responses est recommandée.

Points clés à retenir

• Chat Completions est marque legacy mais reste pleinement fonctionnel et compatible avec l’écosystème OpenAI
• L’endpoint est stateless : vous devez renvoyer tout l’historique à chaque requête
• Le coût de chaque requête inclut l’ensemble des tokens de l’historique
• L’API Responses offre une alternative stateful avec persistance côté serveur
• Pour les modèles de raisonnement, un timeout de 3600 secondes est recommandé