API GPT-6 Astra : premier appel et migration depuis GPT-5.6 Sol

Pour un premier smoke test BetterToken, remplacez le Model ID par gpt-6-astra et envoyez une requête courte à l’endpoint Chat Completions compatible OpenAI. La migration d’une application exige davantage : GPT-6 Astra n’accepte pas le reasoning effort none, plusieurs paramètres de sampling et logprobs doivent disparaître, et le tool calling doit passer par Responses API.

La procédure commence par du texte simple, puis applique le plus petit diff contrôlé depuis gpt-5.6-sol. Ce chemin est documenté ; nous n’avons pas effectué d’appel payant avec une vraie API Key pour préparer l’article.

Prérequis et premier appel

Au 6 septembre 2026, le catalogue public BetterToken listait gpt-5.6-sol et gpt-6-astra dans le groupe GPT. Il faut votre propre compte, une Key créée pour le groupe actuel, la Base URL https://www.bettertoken.ai/v1 et un client HTTP capable d’envoyer un Bearer token et du JSON.

Créez un compte BetterToken et une API Key pour GPT-6 Astra

Vérifiez le Model ID dans le catalogue et dans Setup. Ne publiez jamais la Key dans du code, une issue, une screenshot ou un message au support. Exportez-la localement :

export BETTERTOKEN_API_KEY="YOUR_API_KEY"

Utilisez la référence API publique BetterToken :

curl "https://www.bettertoken.ai/v1/chat/completions" \
  -H "Authorization: Bearer $BETTERTOKEN_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "gpt-6-astra",
    "messages": [
      {
        "role": "user",
        "content": "Reply with exactly: ASTRA_OK"
      }
    ]
  }'

Une réponse réussie contient le texte dans choices[0].message.content ; ce fixture attend ASTRA_OK. Vérifiez l’absence de 401, 403 et model not found, la présence d’un texte non vide, puis l’enregistrement de gpt-6-astra, du statut et des tokens input/output/cache dans Dashboard. Cela confirme Key, endpoint, Model ID et format de base, pas les tools, le streaming du SDK, la qualité production ni l’équivalence avec Sol.

Diff minimal depuis GPT-5.6 Sol

 {
-  "model": "gpt-5.6-sol",
+  "model": "gpt-6-astra",
   "messages": [
     {"role": "user", "content": "Summarize this incident report."}
   ]
 }

Si l’ancien appel utilisait le reasoning effort none ou minimal, commencez Astra avec low. Dans Chat Completions, le champ est reasoning_effort :

{
  "model": "gpt-6-astra",
  "reasoning_effort": "low",
  "messages": [
    {
      "role": "user",
      "content": "Summarize this incident report. Preserve dates and owners."
    }
  ]
}

Si Sol utilisait déjà un autre niveau effectif, OpenAI recommande de le conserver lors de la première comparaison. Augmenter effort partout modifie également latence et consommation.

Supprimez les paramètres incompatibles :

 {
   "model": "gpt-6-astra",
   "reasoning_effort": "low",
-  "temperature": 0.2,
-  "top_p": 0.95,
-  "top_logprobs": 5,
-  "logprobs": true,
   "messages": [
     {"role": "user", "content": "Summarize this incident report."}
   ]
 }

OpenAI cite temperature, top_p et top_logprobs ; dans Chat Completions, retirez aussi logprobs. Inspectez le JSON sérialisé si le SDK ajoute des valeurs par défaut.

Chat Completions pour le texte, Responses pour les tools

GPT-6 Astra accepte les deux endpoints, mais OpenAI impose Responses pour le tool calling. La référence générale publique de BetterToken documente Chat Completions ; Responses figure séparément dans la configuration Codex.

Objectif	Chemin
Valider Key, Model ID et texte	POST https://www.bettertoken.ai/v1/chat/completions
Utiliser des tools dans Codex	custom provider avec wire_api = "responses" selon le guide Codex
Appeler raw Responses depuis votre application	Confirmez d’abord le contrat de votre canal ; la référence générale ne le publie pas encore

Ne transposez pas le schema de tools en changeant uniquement l’URL : input items, appels, continuité d’état et extraction du texte diffèrent. La compatibilité du transport ne garantit pas non plus le même style ou choix d’outils.

Migration contrôlée et rollback

Créez des fixtures réels : réponse exacte, structured output validé par JSON Schema, prompt long, workflow avec tools et requête volontairement invalide. Pour Sol, conservez Model ID, endpoint, reasoning effectif, body sérialisé et acceptance check. Exécutez le même ensemble sur Astra avec le diff minimal.

Déplacez le trafic uniquement si tous les fixtures passent, si le monitoring distingue gpt-5.6-sol de gpt-6-astra et si le rollback restaure modèle et paramètres sans nouveau release. Commencez par un flux interne ou une faible proportion adaptée au risque ; il n’existe pas de pourcentage universel. Gardez la configuration Sol pendant l’observation.

Diagnostic rapide

• 401 Unauthorized : vérifiez Authorization: Bearer ..., l’environment du processus et les espaces copiés ; ne loguez pas la Key complète.
• 403 ou model not found : vérifiez le groupe et copiez exactement gpt-6-astra.
• 400 : supprimez temperature, top_p, top_logprobs et logprobs, puis remplacez none ou minimal par low.
• Le texte fonctionne, pas les tools : contrôlez l’endpoint. Le smoke test ne prouve pas Responses. Conservez wire_api = "responses" dans Codex.
• La réponse réussit, mais l’UI est vide : sauvegardez le raw response sans secrets et contrôlez choices[0].message.content, status, finish reason et l’adapter.

La migration est terminée quand Astra passe les fixtures, s’observe séparément et revient en arrière par configuration. Le premier 200 confirme la connectivité, pas toute la migration.