Tutoriel API GPT-6 Astra : créez un agent de contrôle de release avec outils async et steering

Qu’est-ce que l’API GPT-6 Astra ?

L’API GPT-6 Astra est le moyen d’accéder au nouveau modèle phare d’OpenAI, publié le 3 septembre 2026, via l’API Responses. Pour ce tutoriel, l’important est la surface : gpt-6-astra accepte des entrées texte et image via l’API Responses d’OpenAI. Son effort de raisonnement varie de low à max, sans option none. 

Les exemples de ce tutoriel utilisent client.responses.create plutôt que client.chat.completions.create, mais la migration exige aussi des changements de formats pour la requête, la sortie et les résultats d’outils. Supprimez également les réglages personnalisés temperature, top_p et les probabilités de logs, car Astra ne les prend pas en charge. Avant le premier appel, regardons la tarification.

Combien coûte GPT-6 Astra ?

Pour les requêtes avec au plus 272 000 tokens d’entrée, la tarification standard est de 10 $ par million de tokens d’entrée ordinaires et 50 $ par million de tokens de sortie. L’entrée mise en cache coûte 1 $ par million et les écritures de cache 12,50 $ par million. 

Au-delà de ce seuil, OpenAI applique un multiplicateur 2× sur l’entrée et le cache, et 1,5× sur la sortie. Les taux majorés s’appliquent à toute la requête, pas seulement aux tokens au-dessus du seuil. Aucune des exécutions de ce tutoriel ne s’en est approchée.

Que va‑t‑on construire avec l’API GPT-6 Astra ?

L’app de staging est un petit tableau de tâches Flask : une page d’accueil, un formulaire pour ajouter une tâche, un bouton pour marquer une tâche comme terminée et un endpoint /health. Le code complet, app de staging incluse, se trouve dans ce dépôt GitHub.

Trois tâches pré-remplies apparaissent avant les tests. Image de l’auteur.

L’app a un défaut intentionnel. L’agent dispose de trois contrôles, mais seule la suite de tests est conçue pour les attraper.

Pourquoi l’app accepte‑t‑elle des titres de tâche vides ?

L’endpoint de création de tâche ne rejette pas un titre vide. J’ai laissé ce comportement pour que l’agent ait une défaillance connue à trouver sans la révéler dans le prompt.

Quels contrôles de release l’agent peut‑il exécuter ?

L’agent peut appeler trois outils :

• run_test_suite exécute pytest, y compris un test d’import en masse avec environ 250 requêtes HTTP. 

• check_ui_flow utilise Playwright pour ajouter une tâche et confirmer son affichage. 

• check_staging_health envoie une requête GET vers /health. 

Les trois s’exécutent sur le staging, sans mocks. Le contrôle navigateur utilise un code figé ; la démo d’usage de l’ordinateur rédigée par le modèle vient ensuite.

Comment configurer l’API GPT-6 Astra en Python

Vous avez besoin d’une clé d’API OpenAI avec l’accès à gpt-6-astra. Créez une clé sur platform.openai.com/api-keys et vérifiez que votre projet a gpt-6-astra activé. Les espaces de travail Enterprise ont Astra désactivé par défaut au lancement.

Les commandes ci-dessous utilisent Windows PowerShell et installent tous les packages nécessaires pour ce tutoriel, y compris le module realtime d’OpenAI pour la démo de steering.

python -m venv .venv
.venv\Scripts\Activate.ps1
Copy-Item .env.example .env
pip install "openai[realtime]" flask pytest playwright pydantic matplotlib python-dotenv streamlit
playwright install chromium

Sur macOS ou Linux, remplacez la commande d’activation par source .venv/bin/activate et la commande de copie par cp .env.example .env. 

Ajoutez ensuite la clé d’API dans le nouveau fichier .env : ouvrez le fichier .env que vous venez de copier et ajoutez OPENAI_API_KEY=sk-.... python-dotenv la charge et le SDK la récupère automatiquement : vous n’avez donc jamais à passer la clé dans le code.

Si les dépendances spécifiques au projet ou les fichiers .env sont nouveaux pour vous, nos guides sur les environnements virtuels et les variables d’environnement les expliquent. Vérifiez que la clé fonctionne avant de bâtir dessus.

Si votre clé API fonctionne déjà avec l’API Responses, ignorez la sous‑section suivante et commencez par la boucle d’outils synchrone. La première requête ne fait que vérifier la configuration.

Effectuez votre premier appel à l’API GPT-6 Astra

Une fois la clé en place, elle doit être chargée avec dotenv. Ensuite, vous pouvez créer un client OpenAI et envoyer votre première requête avec la fonction client.responses.create(). La requête minimale ressemble à ceci :

from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()

client = OpenAI()
response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "low"},
    input="In one sentence, what is a staging environment used for?",
)
print(response.output_text)

Le champ usage de la réponse répertorie les comptes de tokens nécessaires pour le calcul de coût ultérieur.

Construire une boucle d’outils synchrone avec GPT-6 Astra

Les extraits ci‑dessous sont des morceaux ; les versions exécutables sont dans le dépôt GitHub associé.

Avant de toucher à l’async, j’ai construit la version ordinaire : 

1. Appeler le modèle

2. Vérifier un élément function_call

3. Exécuter l’outil correspondant

4. Renvoyer le résultat avec previous_response_id

5. Répéter jusqu’à ce que le modèle cesse de demander des outils. 

Cette boucle bloquante sert de référence pour la comparaison async.

for turn in range(max_turns):
    response = client.responses.create(
        model="gpt-6-astra",
        reasoning={"effort": "low"},
        tools=TOOLS,
        input=next_input,
        previous_response_id=previous_response_id,
    )
    calls = [item for item in response.output if item.type == "function_call"]
    if not calls:
        final_text = response.output_text
        break
    outputs = [
        {"type": "function_call_output", "call_id": call.call_id, "output": run_tool(call)}
        for call in calls
    ]
    next_input, previous_response_id = outputs, response.id

Ce qu’a trouvé l’exécution de base

Dans la référence, le modèle a appelé chaque outil à son tour. Il a trouvé la défaillance de validation connue et a rendu une décision no‑go. Sur trois exécutions, le temps moyen au mur s’établit à 23,40 secondes. Cette moyenne couvre l’ensemble de l’exécution, pas les temps de chaque outil.

Comment fonctionne l’appel d’outils async avec GPT-6 Astra ?

Marquez un outil avec "async": true dans son schéma, et votre app peut différer ce résultat pendant que le modèle continue de travailler ou attend. Votre application exécute toujours l’outil et gère le job en arrière-plan.

Comment exécuter des contrôles indépendants en parallèle

J’ai marqué run_test_suite et check_ui_flow en async, et ajouté un outil wait_for_tasks défini par l’app, sans arguments, puisque cette démo n’a qu’un lot de travaux en attente à la fois. Cette attente sans argument garde l’exemple léger. 

En production, identifiez les jobs avec des handles, liez chaque handle à son call_id d’origine, et n’attendez que lorsque l’étape suivante dépend d’un résultat en attente.

Renvoyez chaque résultat terminé sur son call_id d’origine, puis renvoyez l’état d’attente sur le call_id de l’outil d’attente.

TOOLS = [
    {"type": "function", "name": "run_test_suite", "async": True, ...},
    {"type": "function", "name": "check_ui_flow", "async": True, ...},
    {"type": "function", "name": "check_staging_health", ...},
    {"type": "function", "name": "wait_for_tasks", ...},
]

Pour cette exécution, l’app a soumis chaque appel marqué à un pool de threads. Pendant que les contrôles en arrière-plan tournaient, elle a effectué le contrôle de santé synchrone, rapide. Elle s’est ensuite bloquée sur wait_for_tasks jusqu’à la fin des contrôles en attente.

L’async réduit‑il le temps au mur ?

Sur trois exécutions, l’async a réduit le temps moyen au mur de 19,1 %, de 23,40 s à 18,94 s. La moyenne semblait nette jusqu’à voir les exécutions individuelles : le graphique ci‑dessous montre leur variabilité. Trois runs suffisent à expliquer ce qui s’est passé ici, pas à prédire la latence en production.

Des variations en temps réel dans les deux modes. Image de l’auteur.

Pourquoi les contrôles concurrents ont‑ils causé une condition de course ?

Exécuter en même temps le contrôle navigateur et le test d’import en masse a parfois fait échouer l’assertion d’import, car les deux contrôles modifiaient la même liste de tâches en mémoire. Cela a cassé l’hypothèse d’accès exclusif du test. Isoler les données dans le runner ou dans les tests éviterait la course.

Usage de l’ordinateur borné avec GPT-6 Astra pour les tests UI

Pour l’usage de l’ordinateur, la doc de GPT‑6 Astra recommande l’exécution de code, tandis que l’outil structuré computer reste pris en charge en alternative. Avec l’exécution de code, un appel peut combiner plusieurs actions, boucles et conditions, alors que l’outil computer renvoie une action souris/clavier structurée à la fois, que votre application traduit et rejoue.

Comment limiter le runner d’usage de l’ordinateur

J’ai nommé la classe BrowserSandbox, mais ce nom surestime sa protection. Elle fournit au code rédigé par le modèle une page Playwright, une fonction log() et un helper expect_text(). Python peut toujours injecter des built‑ins dans exec(), et la page peut naviguer vers une autre origine.

sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)

Considérez‑le comme un runner de démo, pas une barrière de sécurité. Le code rédigé par le modèle nécessite un processus ou un conteneur isolé avec des restrictions système de fichiers, processus, réseau et origine.

Que s’est‑il passé dans le contrôle UI ?

J’ai plafonné la boucle à huit tours car un contrôle borné a besoin d’un arrêt dur. Le modèle a inspecté la page, trouvé le champ du formulaire, créé le titre « UI flow check, cobalt otter 73921 », soumis la tâche et confirmé l’apparition du titre, le tout en 13 secondes. Notre tutoriel sur l’usage de l’ordinateur avec GPT‑5.4 détaille un exemple complet avec un prédécesseur d’Astra.

Comment fonctionne le steering en cours de tour avec GPT-6 Astra ?

Le steering en cours de tour n’est disponible que pour gpt-6-astra via une connexion WebSocket.

Ouvrez une connexion et créez une réponse, puis envoyez un évènement response.steer avec de nouvelles instructions pendant la génération. Un évènement response.steer.accepted signifie que la mise à jour est en file d’attente, pas encore appliquée. Avant de créer la continuation automatique, le serveur termine l’élément de sortie en cours et tout travail d’outil hébergé déjà en exécution. 

S’il a encore besoin d’un résultat d’outil côté client ou d’une approbation, response.steer.pending identifie l’entrée manquante.

async with client.responses.connect() as connection:
    await connection.response.create(model="gpt-6-astra", input=TASK)
    async for event in connection:
        if event.type == "response.created" and initial_response_id is None:
            initial_response_id = event.response.id
            await asyncio.sleep(1.0)
            await connection.response.steer(
                previous_response_id=initial_response_id,
                input="Also add a rollback plan, but skip mobile.",
            )

Le délai d’une seconde s’aligne sur le code d’expérimentation et laisse le temps à la première réponse de démarrer. Sans ce délai, on testerait un autre point du cycle de vie.

Qu’est‑ce que le steering ne change pas ?

Le steering ne réécrit pas la réponse d’origine. Si la mise à jour l’interrompt, cette réponse se termine avec status: "incomplete" et incomplete_details.reason: "steered". Une réponse successeur continue alors avec la nouvelle instruction. 

Si la première réponse se termine avant que la mise à jour ne prenne effet, elle reste complète. Le steering n’annule pas les actions côté client déjà lancées ; cela reste votre responsabilité. Le steering en file d’attente n’existe que sur la connexion WebSocket en cours : enregistrez la mise à jour avant toute reconnexion.

Le chemin de comparaison laisse la première réponse finir, puis envoie une nouvelle requête avec les instructions combinées. Sur deux exécutions, le steering a duré en moyenne 26,91 s contre 50,02 s pour « finir puis redémarrer ». Cette comparaison n’inclut pas une politique « annuler et redémarrer » ni une évaluation de la correction du texte final.

Moyennes sur deux exécutions pour le temps et le coût. Image de l’auteur.

Le chemin de redémarrage génère deux réponses complètes couvrant en partie les mêmes requêtes, ce qui explique une part de l’écart : je n’en ferais pas une référence générale pour le steering.

Comment changer l’effort de raisonnement de GPT-6 Astra en cours de conversation

gpt-6-astra prend en charge un effort de low à max. Un effort plus élevé peut augmenter l’usage de tokens de raisonnement, sans garantir une réponse différente. Un configuration_update change les réponses suivantes jusqu’à ce qu’une autre mise à jour le remplace, tandis que le réglage au niveau de la requête reste inchangé. 

Dans ce pipeline, le rapport clôt la conversation, donc la mise à jour n’affecte que cette dernière étape.

response = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=previous_id,
    reasoning={"effort": "low"},  # default remains low
    input=[
        {"type": "configuration_update", "reasoning": {"effort": "high"}},
        {"role": "user", "content": "Diagnose the root cause and recommend a fix."},
    ],
)

J’ai utilisé la même trace d’échec aux deux niveaux d’effort et comparé le diagnostic et l’usage de tokens.

Une subtilité : le champ reasoning.effort de la réponse rapporte toujours le réglage au niveau de la requête, pas l’effort sélectionné par configuration_update. Ne l’utilisez pas pour vérifier si la mise à jour a pris effet.

Un effort élevé a‑t‑il changé le diagnostic ?

Dans l’exécution complète, l’étape escaladée a utilisé 108 tokens de raisonnement. Toutes les autres étapes en low ont utilisé zéro. Dans un test isolé antérieur avec une trace d’échec plus longue, l’effort faible a utilisé zéro token de raisonnement, et l’effort élevé 318. Les deux versions ont identifié le bug de validation : l’effort plus élevé a modifié la consommation, pas le diagnostic.

Les mises à jour de configuration ne fonctionnent que dans des requêtes standards mono‑agent. L’API rejette les mises à jour adjacentes, et elles sont incompatibles avec la compaction ou la troncature automatiques.

Comment utiliser les sorties structurées de GPT-6 Astra

La dernière étape du pipeline appelle client.responses.parse pour remplacer le texte libre par un modèle Pydantic validé.

class GoNoGoReport(BaseModel):
    decision: str
    summary: str
    checks_completed: list[str]
    failures: list[str]
    risks: list[str]
    follow_up_actions: list[str]
    confidence: float

response = client.responses.parse(
    model="gpt-6-astra",
    previous_response_id=previous_id,
    text_format=GoNoGoReport,
    input=[...],
)

Pydantic vérifie les types déclarés ici. Il ne prouve pas que le rapport correspond aux preuves, et cette version ne restreint pas decision à deux valeurs ni confidence à une plage.

Qu’a détecté le rapport go/no‑go ?

Le rapport a renvoyé decision: "no_go". Il a classé la défaillance de validation mentionnée plus haut sous failures et le problème de concurrence sous risks. Pour ce dernier, il a écrit : « possible interference from concurrent UI checks against shared staging data. » Le prompt ne nommait pas ce risque.

Gardez la latence et le coût hors de ce schéma et calculez‑les en code. Le modèle remplit les champs à partir des preuves des outils.

L’interface Streamlit consomme le même générateur que le runner en ligne de commande. Elle affiche chaque évènement d’outil à son arrivée, puis montre le rapport parsé dans les onglets Report et JSON.

Progression en direct de l’agent à côté du rapport final. Vidéo de l’auteur.

Le tableau de bord exécute le pipeline de release async combiné avec son contrôle navigateur figé, la mise à jour d’effort de raisonnement, le rapport structuré et l’affichage du timing. Son panneau de coût lit le même grand livre que le runner en ligne de commande. Il n’exécute pas les démos séparées d’usage de l’ordinateur rédigé par le modèle ni de steering.

Comment suivre l’usage de tokens et le coût de l’API GPT-6 Astra

Pour la partie tokens du modèle dans ces exécutions, le champ usage contient les quatre comptes nécessaires pour tarifer chaque réponse. Les écritures de cache ont leur propre tarif : ne les regroupez pas avec l’entrée ordinaire. Les outils ici tournent dans votre application ; si vous ajoutez un outil hébergé avec une facturation séparée, incluez‑la aussi.

details = usage.input_tokens_details
cached_tokens = details.cached_tokens
cache_write_tokens = details.cache_write_tokens
ordinary_tokens = usage.input_tokens - cached_tokens - cache_write_tokens

cost = (
    ordinary_tokens * PRICE_INPUT
    + cached_tokens * PRICE_CACHED_INPUT
    + cache_write_tokens * PRICE_CACHE_WRITE
    + usage.output_tokens * PRICE_OUTPUT
) / 1_000_000

Ce calcul couvre une réponse. Le grand livre l’applique après chaque réponse, puis additionne les totaux d’appel.

Journalisez cache_write_tokens même lorsque la valeur est zéro. Sinon, une écriture de cache future peut se cacher dans le compte d’entrée ordinaire — une manière irritante de découvrir une erreur de facturation.

Considérations de production pour un agent GPT-6 Astra

La démo a besoin de ces changements avant de pouvoir bloquer des déploiements.

Permissions et isolation des outils

Préservez la frontière de staging et isolez BrowserSandbox comme décrit ci‑dessus. Ne lui donnez ni accès à la base de données ni accès production.

Cycle de vie des jobs async

Dans la démo, chaque job en attente se termine et rien d’autre ne l’affecte. En production, il faut survivre aux cas contraires. Il faut, pour chaque entrée en attente :

• Une échéance et un état final, pour qu’aucune tâche ne reste en attente indéfiniment
• Un drapeau de livraison, afin qu’un callback et une relance n’envoient pas deux fois le même résultat
• Des horodatages de début et de fin, pour distinguer un timeout d’une fin tardive mais valide
• Un rejet des appels en double, pour éviter de lancer deux fois la même tâche
• Une gestion des erreurs des threads d’arrière‑plan, pour surfacer les exceptions au lieu de les perdre dans le pool
• Une annulation, ce qui implique d’ignorer un résultat tardif et d’arrêter tout travail externe déjà engagé

Steering et actions irréversibles

Un steer peut changer les instructions futures, mais ne peut pas annuler un effet de bord accompli. Si un outil a déjà modifié un système externe, une action séparée doit compenser.

Surveillance de mésalignement

L’arrêt automatique s’applique aux requêtes Responses API qui utilisent le raisonnement persistant, les WebSockets ou la compaction OpenAI. Les autres requêtes peuvent déclencher des alertes, mais ne sont pas arrêtées automatiquement. 

Avant le streaming, la surveillance de mésalignement peut bloquer une exécution couverte avec un HTTP 403 et le code misalignment_policy_violation. Un client en streaming peut au contraire recevoir une erreur après le début de la sortie. L’API ne fournit pas de reprise générale pour la conversation arrêtée.

Checklist de déploiement d’un agent GPT-6 Astra

Avant de passer de la démo locale au déploiement, ajoutez ces contrôles. Ils appartiennent au code de l’application, pas aux instructions du modèle.

• Définir des timeouts explicites sur les appels HTTP de l’app de staging et sur la connexion WebSocket

• Journaliser l’entrée ordinaire, l’entrée mise en cache, les écritures de cache, la sortie, l’ID de réponse et le nombre de tours

• Alerter sur les exécutions incomplètes ou celles qui atteignent le plafond de tours. Définir une alerte séparée pour les dépassements de budget

• Épingler la version du SDK openai et revérifier les comportements async, steering et configuration_update avant toute mise à niveau

Quand utiliser les outils async ou le steering avec GPT-6 Astra ?

Choisissez le chemin le plus simple adapté au besoin.

• Commencez par une requête synchrone et des sorties structurées quand les outils répondent vite et que les exigences restent stables.
• Ajoutez l’appel d’outils async lorsque le modèle ou un autre outil peut faire un travail utile pendant un appel lent, et que le gain de temps justifie la gestion supplémentaire des jobs.
• Utilisez le steering en cours de tour lorsque les exigences changent pendant l’exécution.

Conclusion

Le contrôle de release synchrone est devenu plus utile une fois les outils lents superposés, même si le résultat n’est pas une victoire nette. Sur trois exécutions, l’async a réduit le temps moyen de 23,40 s à 18,94 s, puis a exposé une course sur état partagé que la boucle séquentielle masquait. 

J’isolerais le navigateur et les données de test, je garderais les tours routiniers en low, et n’augmenterais l’effort que lorsque les preuves méritent un examen plus poussé. Si les outils finissent vite et que les exigences restent stables, restez sur la boucle synchrone avec sorties structurées. Utilisez l’async lorsque des travaux indépendants peuvent se chevaucher, et le steering lorsque les instructions changent pendant une réponse.

Pour les bases de l’API, je vous recommande notre cours Working with the OpenAI API. Pour des systèmes d’agents à grande échelle, consultez notre cours Building Scalable Agentic Systems.