| Sommaire | Effet attendu |
|---|---|
| Utilisez l’API Responses | Qualité, coût, latence, fiabilité |
| Choisissez un modèle GPT-5.6 | Qualité, coût, latence |
Configurez reasoning.effort | Qualité, coût, latence |
Configurez text.verbosity | Qualité, coût, latence |
Configurez le paramètre phase de l’assistant | Qualité, coût |
Utilisez tool_search | Coût, latence |
| Utilisez l’appel d’outils par programmation | Qualité, coût, latence |
| Utilisez Multi-agents pour travailler en parallèle | Qualité, coût, latence |
| Tirez parti des outils intégrés | Qualité |
| Tirez parti du compactage | Coût |
| Optimisez la mise en cache des prompts | Latence, coût |
Utilisez reasoning.encrypted_content | Qualité, latence |
| Choisissez le niveau de détail des images à bon escient | Qualité, coût, latence |
| Envoyez un identifiant de sécurité | Sécurité, fiabilité |
Utilisez background=True | Reprise du travail |
| Utilisez le mode WebSocket | Latence |
Utilisez l’API Responses
Commencez toujours par l’API Responses. C’est l’API phare d’OpenAI et le meilleur moyen d’accéder aux comportements les plus récents des modèles, aux outils intégrés, aux workflows avec état et aux fonctionnalités des agents.
Choisissez un modèle GPT-5.6
Choisissez un modèle GPT-5.6 adapté à la charge de travail plutôt
que d’acheminer chaque requête vers la gamme la plus performante. Utilisez gpt-5.6 ou
gpt-5.6-sol pour bénéficier des capacités des modèles phares, gpt-5.6-terra pour de solides performances
à moindre coût, et gpt-5.6-luna pour traiter efficacement de gros volumes.
Lors de la migration, conservez le rôle du modèle actuel dans la charge de travail et son effort de raisonnement effectif pour la première comparaison. Exécutez des évaluations représentatives avant de modifier les prompts ou d’ajouter de nouvelles capacités. Comparez la réussite des tâches, la latence, les tokens d’entrée, de sortie, de raisonnement et d’écriture en cache, ainsi que le coût par tâche réussie.
Configurez reasoning.effort
Utilisez reasoning.effort pour déterminer l’effort de réflexion que le modèle doit fournir avant de
répondre.
Pour les modèles GPT-5.6, les valeurs prises en charge sont none, low, medium, high,
xhigh et max. La valeur par défaut est medium. Un effort moindre accélère la réponse et consomme
moins de tokens de raisonnement. Un effort plus élevé donne au modèle davantage de temps pour la planification,
le débogage, la synthèse et les arbitrages en plusieurs étapes.
Utilisez low lorsque la tâche consiste principalement à extraire, router ou classer des données, ou à effectuer une
réécriture courante. Utilisez medium ou high lorsque le modèle doit diagnostiquer un
problème, comparer des options, rédiger un plan ou raisonner sur du code. Utilisez xhigh ou
max uniquement si des évaluations représentatives montrent que le gain de qualité justifie
la latence et le coût supplémentaires. Lors d’une migration depuis GPT-5.5 ou GPT-5.4, commencez par
l’effort actuel et comparez ce réglage au niveau immédiatement inférieur. GPT-5.6 peut
souvent maintenir ou améliorer la qualité avec moins de tokens de raisonnement. Le réglage inférieur
peut donc aussi réduire la latence et le coût.
Pour les charges de travail les plus difficiles où la qualité prime, comparez également
reasoning.mode: "pro" au
mode standard avec le même effort. Le mode et l’effort de raisonnement sont indépendants.
Le mode Pro peut améliorer la fiabilité en faisant travailler davantage le modèle avant de renvoyer une
réponse finale unique, mais il augmente la latence et la consommation de tokens.
from openai import OpenAI
client = OpenAI()
prompt = """
Our CI job started failing after a dependency bump.
Error:
TypeError: Timeout.__init__() got an unexpected keyword argument 'connect'
Identify the likeliest root cause and the smallest safe fix.
"""
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "xhigh", "mode": "pro"},
input=prompt,
)
print(response.output_text)Configurez text.verbosity
text.verbosity est le principal paramètre permettant d’équilibrer concision et exhaustivité.
Utilisez une verbosité plus faible lorsque le produit nécessite une réponse rapide et compacte, et plus élevée
lorsque la réponse doit fournir des explications plus détaillées, une structure plus claire ou
un contexte complet. Une verbosité plus faible signifie moins de tokens de sortie : le modèle
génère donc moins de contenu et le renvoie plus vite.
Pour la programmation, medium et high tendent à produire des réponses plus longues et mieux organisées,
avec une structure plus claire. low permet de garder une réponse plus concise et limitée à l’essentiel.
GPT-5.6 tend à être plus concis par défaut que GPT-5.5. Lors de la migration, vérifiez
si des consignes générales comme « Soyez concis » restent utiles. Dans certains cas, elles peuvent
rendre les réponses trop brèves. Ne les conservez que si elles restent utiles et privilégiez
text.verbosity pour contrôler le niveau de détail par défaut. Utilisez ensuite le prompt pour
préciser le contenu requis, la structure et, le cas échéant, une longueur plus précise.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-6-astra",
text={"verbosity": "low"},
input="""
Summarize this incident for the next on-call engineer.
- checkout latency spiked from 220 ms to 4.8 s
- only us-east-1 was affected
- rollback is complete
- likely trigger: cache stampede after deploy
""",
)
print(response.output_text)Configurez le paramètre phase de l’assistant
phase est une étiquette associée aux messages de l’assistant dans l’historique de la conversation. Elle
indique au modèle si un message précédent de l’assistant était un commentaire intermédiaire
sur le travail en cours ou la réponse finale. Utilisez phase: "commentary" pour les points
d’avancement, les notes précédant un appel d’outil et les autres messages intermédiaires. Utilisez
phase: "final_answer" pour la réponse achevée.
L’assistant pourrait dire, par exemple :
{
"role": "assistant",
"phase": "commentary",
"content": "I'm checking the logs and comparing them to the last successful deploy."
}Ce n’est pas la réponse, mais un point d’avancement. Plus tard, l’assistant pourrait dire :
{
"role": "assistant",
"phase": "final_answer",
"content": "The deploy failed because the migration referenced a column that does not exist in production."
}Cela est utile dans les workflows de longue durée ou qui font largement appel aux outils, où l’assistant peut
afficher des points d’avancement avant de terminer. Lorsque vous renvoyez cet historique
dans les requêtes suivantes à gpt-5.3-codex et aux modèles ultérieurs,
conservez et renvoyez phase dans les messages de l’assistant afin que le modèle puisse distinguer
les points d’avancement du résultat final. Cela contribue à réduire les arrêts prématurés,
et l’agent est ainsi plus susceptible de poursuivre jusqu’à la réponse finale.
Utilisez tool_search
Au lieu de charger tout le catalogue d’outils dans chaque requête, utilisez
la recherche d’outils : ajoutez
{"type": "tool_search"} et marquez les définitions d’outils coûteuses avec
defer_loading: true. Le modèle peut alors charger uniquement les outils dont il a besoin à l’exécution.
Au début de la requête, le modèle ne voit que le nom et la description de l’outil de recherche. Si
le modèle estime avoir besoin d’un outil à chargement différé, il lance la recherche d’outils. Ce n’est qu’alors
que les définitions correspondantes sont chargées dans le contexte. Le modèle peut ensuite
appeler ces outils. Cela économise des tokens et préserve les performances du cache.
La recherche d’outils propose deux modes :
- La recherche d’outils hébergée est l’option la plus simple. Utilisez-la lorsque vous savez déjà quels outils pourraient être disponibles pour la requête.
- La recherche d’outils exécutée côté client convient aux cas où votre application doit déterminer quels outils sont disponibles, par exemple en fonction du tenant, du projet, des autorisations ou du registre interne de l’utilisateur.
Commencez par la recherche d’outils hébergée , sauf si votre application doit vraiment gérer elle-même la découverte des outils.
Regroupez vos outils selon l’intention de l’utilisateur. Utilisez des espaces de noms ou des serveurs MCP lorsque c’est possible. Le modèle choisit plus facilement parmi quelques groupes bien définis que dans une longue liste de fonctions non structurée. Nous recommandons de limiter chaque espace de noms à moins d’une dizaine de fonctions pour optimiser l’utilisation des tokens et les performances du modèle.
Rédigez des descriptions courtes qui permettent de bien distinguer les espaces de noms. Placez les instructions détaillées dans les définitions des outils à chargement différé. Évitez de tout regrouper dans un seul espace de noms démesuré.
from openai import OpenAI
client = OpenAI()
billing_namespace = {
"type": "namespace",
"name": "billing",
"description": "Billing tools for invoices, payments, taxes, and credits.",
"tools": [
{
"type": "function",
"name": "lookup_invoice",
"description": "Look up invoice state, taxes, credits, and payment attempts.",
"parameters": {
"type": "object",
"properties": {
"invoice_id": {"type": "string"},
},
"required": ["invoice_id"],
"additionalProperties": False,
},
"strict": True,
"defer_loading": True,
}
],
}
crm_namespace = {
"type": "namespace",
"name": "crm",
"description": "CRM tools for account ownership, plans, health, and payment history.",
"tools": [
{
"type": "function",
"name": "get_account",
"description": "Fetch account owner, plan, health, and payment history.",
"parameters": {
"type": "object",
"properties": {
"account_id": {"type": "string"},
},
"required": ["account_id"],
"additionalProperties": False,
},
"strict": True,
"defer_loading": True,
}
],
}
response = client.responses.create(
model="gpt-6-astra",
input=(
"Find the right billing tool and explain why invoice INV-1043 still "
"shows overdue after a payment yesterday."
),
tools=[billing_namespace, crm_namespace, {"type": "tool_search"}],
)
print(response.output)Utilisez l’appel d’outils par programmation
L’appel d’outils par programmation permet à GPT-5.6 d’écrire du JavaScript qui appelle les outils admissibles et réduit le volume de leurs résultats intermédiaires dans un environnement d’exécution hébergé. Utilisez-le pour des étapes délimitées où le code peut filtrer, joindre, classer, dédupliquer, combiner ou vérifier des résultats d’outils volumineux avant de renvoyer au modèle un résultat structuré plus compact.
Ajoutez l’outil programmatic_tool_calling et activez cette possibilité pour chaque outil admissible. Utilisez
allowed_callers: ["programmatic"] pour les outils réservés aux programmes, ou
allowed_callers: ["direct", "programmatic"] lorsque le modèle peut aussi appeler
l’outil directement. Conservez les appels directs lorsque chaque résultat peut modifier la prochaine
décision du modèle, qu’une action nécessite une approbation ou que la réponse finale doit préserver
des citations ou des artefacts natifs. Documentez les champs renvoyés par les outils et leur comportement en cas d’erreur afin
que le modèle puisse écrire un programme correct sans devoir d’abord examiner un résultat.
Votre boucle d’exécution des outils doit gérer les éléments program et program_output, ainsi que
les éléments function_call émis par les programmes et les éléments function_call_output correspondants.
Conservez chaque call_id et copiez le champ caller de l’appel de fonction dans sa sortie pour
que le service puisse reprendre le bon programme.
Testez à la fois program_output et le message final de l’assistant. Un résultat de programme correct
peut tout de même donner lieu à une réponse finale incomplète. Comparez la réussite de la tâche,
les éléments probants requis, le nombre total de tokens, la latence et le coût à ceux du même workflow
utilisant des appels d’outils directs.
Utilisez Multi-agents pour travailler en parallèle
Multi-agents est une fonctionnalité de GPT-5.6 qui permet à un agent principal de déléguer des travaux indépendants à des sous-agents et de synthétiser leurs résultats. Utilisez-la lorsque vous pouvez décomposer un travail de recherche, d’analyse ou d’implémentation en tâches concrètes et délimitées qui utilisent des contextes distincts et s’exécutent en parallèle.
Définissez multi_agent.enabled sur true dans la requête. Pour HTTP, utilisez le SDK
Responses en bêta avec client.beta.responses et transmettez responses_multi_agent=v1
dans betas. Pour les connexions HTTP brutes ou WebSocket, envoyez
OpenAI-Beta: responses_multi_agent=v1. Les schémas des éléments peuvent changer tant que
Multi-agents est en bêta.
Privilégiez un seul agent pour les tâches courtes, les séquences où chaque étape dépend de la
précédente ou les travaux qui écrivent dans la même ressource modifiable. Les sous-agents peuvent augmenter
la consommation de tokens : commencez donc avec la valeur par défaut de max_concurrent_subagents, soit 3,
et mesurez la qualité, la latence et le coût de bout en bout. Pour les workflows Multi-agents de longue durée ou
qui font largement appel aux outils, le mode WebSocket peut réduire le surcoût lié aux reprises.
Avant d’activer Multi-agents, tenez compte de ses limites actuelles :
/responses/compact, reasoning.summary et max_tool_calls ne sont pas
pris en charge. Le serveur compacte automatiquement le contexte de l’agent principal et celui
de chaque sous-agent.
Tirez parti des outils intégrés
Les outils intégrés sont des fonctionnalités natives de l’API. Au lieu de développer vous-même chaque outil, vous pouvez donner au modèle accès à des outils qui fonctionnent déjà dans l’API Responses. Le modèle peut ensuite décider quand les utiliser.
OpenAI ajoute régulièrement de nouveaux outils natifs : commencez donc par les outils intégrés lorsqu’ils conviennent à votre workflow. Développez des outils personnalisés lorsque les options natives ne couvrent pas la tâche. Les outils intégrés et les options associées actuellement disponibles comprennent :
- Recherche web : Recherchez des informations à jour sur le web
- Recherche de fichiers : Effectuez des recherches dans les fichiers importés ou les bases vectorielles
- Interpréteur de code : Exécutez du Python pour l’analyse, les calculs, les graphiques et le traitement de fichiers
- Shell : Exécutez des commandes shell dans un conteneur hébergé ou votre propre environnement d’exécution
- Utilisation de l’ordinateur : Interagissez avec une interface à l’aide de captures d’écran, de clics, de saisies et de défilements
- Génération d’images : Générez ou modifiez des images
- MCP/connecteurs : Connectez le modèle à des services et outils externes
- Skills : Joignez des ensembles d’instructions réutilisables et des fichiers de workflow
- Application de patchs : Effectuez des modifications structurées du code
La qualité des résultats du modèle est une autre raison de les privilégier. Les outils intégrés correspondent à la distribution de données utilisée lors de notre post-entraînement : les modèles sont entraînés et évalués sur les formats, les comportements et les sorties de ces outils. Avec les outils intégrés, les modèles OpenAI sélectionnent mieux les outils, les exécutent plus proprement et rencontrent moins d’échecs qu’avec de nouveaux outils.
Tirez parti du compactage
Le compactage est un outil d’ingénierie du contexte : il détermine quelles informations le modèle conserve au fil des tours. Pour les agents qui s’exécutent sur une longue durée, le problème ne se limite pas à la question « Vais-je atteindre la limite de contexte ? » Les anciens messages, les journaux d’outils, les nouvelles tentatives et les détails obsolètes finissent par évincer les informations d’état dont le modèle a besoin.
Le compactage permet de réduire la taille du contexte de façon contrôlée tout en préservant l’état nécessaire aux tours suivants. Après une étape importante, comme la fin d’une phase de débogage ou une identification plus précise de la cause racine, vous pouvez compacter la fenêtre précédente et poursuivre à partir de la sortie compactée. Le modèle reste ainsi efficace, car le tour suivant s’appuie sur les informations d’état importantes, plutôt que sur l’ensemble des raisonnements intermédiaires, des commandes ayant échoué et des pistes de raisonnement obsolètes.
Vous pouvez utiliser le compactage de deux façons :
- Laissez le serveur s’en charger : si vous utilisez
previous_response_id, activezcontext_managementavec un seuilcompact_threshold. Le serveur compacte automatiquement la conversation lorsqu’elle devient trop volumineuse. Vous continuez à envoyer uniquement le dernier message de l’utilisateur. - Gérez-le vous-même : si vous gérez vous-même l’intégralité du tableau d’entrée, appelez
client.responses.compact(). Cet appel renvoie une fenêtre de contexte plus petite. Utilisez directement la sortie renvoyée dans l’appel suivant àresponses.create().
Ne modifiez pas la sortie compactée. Ce n’est pas un résumé destiné à un humain, mais un état machine qui aide le modèle à poursuivre. Transmettez-la telle quelle, puis ajoutez le message suivant de l’utilisateur.
from openai import OpenAI
client = OpenAI()
# Full window collected from a long debugging session:
# user messages, assistant outputs, tool calls, and tool outputs.
long_window = session_items
compacted = client.responses.compact(
model="gpt-6-astra",
input=long_window,
)
next_response = client.responses.create(
model="gpt-6-astra",
store=False,
input=[
*compacted.output, # Use compact output as-is.
{
"type": "message",
"role": "user",
"content": (
"We found the bad cache invalidation path. Write the fix plan "
"and the verification checklist."
),
},
],
)
print(next_response.output_text)Optimisez la mise en cache des prompts
La mise en cache des prompts réduit automatiquement la latence et le coût lorsque les requêtes réutilisent le même long préfixe. Placez d’abord les instructions stables, les exemples et les documents de référence, puis le contenu dynamique propre à l’utilisateur. Conservez les définitions des outils et leur ordre, et ajoutez les nouveaux tours de conversation sans réécrire le contexte antérieur.
GPT-5.6 a introduit la mise en cache explicite des prompts. La mise en cache implicite reste
le comportement par défaut, mais les modèles GPT-5.6 et les familles de modèles ultérieures prennent aussi en charge
les points de délimitation explicites du cache et une politique de cache applicable à toute la requête. Si un suffixe variable suit
un préfixe stable, ajoutez un prompt_cache_breakpoint explicite à la fin de la partie réutilisable. Définissez
prompt_cache_options.mode sur explicit uniquement si la requête doit utiliser exclusivement
les points de délimitation que vous fournissez, sans aucun point implicite. Les modèles antérieurs continuent
à utiliser uniquement la mise en cache automatique des prompts.
Avec les modèles GPT-5.6 et les familles de modèles ultérieures, les écritures dans le cache coûtent 1,25 fois
le tarif des tokens d’entrée non mis en cache. Consignez cached_tokens et cache_write_tokens, puis
comparez le volume des écritures aux lectures ultérieures du cache pour mesurer le coût net et ajuster
l’emplacement des points de délimitation.
Utilisez une valeur prompt_cache_key stable pour les requêtes qui partagent un préfixe réutilisable afin
de faciliter l’acheminement des requêtes liées vers le même cache et d’optimiser le taux de succès du cache sur
les modèles antérieurs à GPT-5.6. Pour les groupes à fort trafic, suivez les recommandations pour répartir
le trafic sur davantage de clés.
Avec GPT-5.6 et les modèles ultérieurs, prompt_cache_key est facultatif : vous pouvez obtenir un taux
de succès du cache optimal sans l’utiliser. Vous pouvez vous en servir pour comptabiliser séparément l’utilisation du cache
par client, utilisateur ou espace de travail. Cela peut faciliter l’explication de l’utilisation des tokens mis en cache et de leur facturation
pour chaque groupe. Attribuez une clé distincte à chaque client et
conservez-la pour toutes les requêtes liées de ce client. Des clés distinctes contribuent aussi
à empêcher un client de tester la présence de données d’autres clients dans le cache. Consultez Comptabilisez séparément l’utilisation du cache avec
des clés.
from openai import OpenAI
client = OpenAI()
instructions = """
You are the support agent for Acme.
Follow the Acme support policy and escalation rubric.
Use the same tone, safety rules, and tool plan for each ticket.
"""
response = client.responses.create(
model="gpt-6-astra",
prompt_cache_key="tenant-acme-support-agent",
instructions=instructions,
input="Summarize the current escalation for the on-call lead.",
)
print(response.output_text)Utilisez reasoning.encrypted_content
GPT-5.6 peut conserver le raisonnement d’un appel
à l’autre. Utilisez
reasoning.context: "all_turns" lorsque les objectifs, les hypothèses et
les priorités de la tâche restent stables. Utilisez current_turn lorsque le raisonnement antérieur n’est plus
pertinent et risque de maintenir le modèle dans une approche dépassée. Si vous omettez
reasoning.context ou le définissez sur auto, examinez le champ
reasoning.context de la réponse pour confirmer le mode effectivement utilisé.
La persistance du raisonnement
ne fonctionne que si les éléments de raisonnement antérieurs sont disponibles. Utilisez previous_response_id
pour les réponses stockées. Si vos exigences en matière de politique de non-conservation des données
(ZDR) ne permettent pas
de stocker les données des réponses, le contenu chiffré du raisonnement permet de passer le relais
sans conserver d’état côté serveur.
Les éléments de raisonnement dans la sortie de la réponse incluent par défaut du contenu
de raisonnement chiffré. Vous pouvez y accéder à partir de la propriété
encrypted_content de chaque élément de raisonnement. Votre application n’a pas besoin d’interpréter cette
valeur. Elle conserve simplement chaque élément de raisonnement exactement tel qu’il est renvoyé et le transmet à nouveau
au tour suivant, afin que le modèle puisse l’utiliser pour poursuivre le workflow.
from openai import OpenAI
client = OpenAI()
history = [
{
"role": "user",
"content": "Investigate why invoice INV-1043 has mismatched tax totals.",
}
]
first = client.responses.create(
model="gpt-6-astra",
store=False,
reasoning={"effort": "medium", "context": "current_turn"},
input=history,
)
history.extend(item.model_dump(exclude={"status"}) for item in first.output)
history.append(
{
"role": "user",
"content": "Now write the customer-facing explanation in plain English.",
}
)
second = client.responses.create(
model="gpt-6-astra",
store=False,
reasoning={"effort": "medium", "context": "all_turns"},
input=history,
)
print(second.output_text)Choisissez délibérément le niveau de détail des images
Sur les modèles GPT-5.6, l’omission du paramètre d’image detail et l’utilisation de detail: "auto" produisent le même
comportement de dimensionnement que original. Le service conserve les dimensions d’entrée,
sauf pour les images dont un côté dépasse 65 535 pixels, qui sont réduites pour
respecter cette limite. L’API rejette les images qui dépassent encore la
limite de 30 000 patchs,
au lieu de les redimensionner pour la respecter. Les grandes images peuvent consommer davantage de tokens d’entrée et
ainsi augmenter la latence.
Choisissez la valeur de detail
en fonction de la tâche. Redimensionnez l’image, utilisez low lorsque les détails visuels fins ne sont pas
importants, ou high pour une compréhension d’image standard à haute fidélité. Réservez
original aux tâches portant sur des images volumineuses ou denses, exigeant des coordonnées précises, ou relevant de l’OCR, de la localisation ou de
l’inspection visuelle, lorsque les détails supplémentaires améliorent la qualité. Mesurez
la consommation de tokens d’image et la latence dans le pire des cas avant le déploiement.
Envoyez un identifiant de sécurité
Si votre application s’adresse à des utilisateurs finaux individuels, envoyez
un identifiant safety_identifier stable et respectueux de la vie privée
avec chaque requête.
Il aide OpenAI à détecter les usages abusifs et fournit à votre équipe un moyen stable
de retracer les violations des politiques. Il réduit également le risque que l’usage abusif d’un utilisateur
perturbe l’accès du reste de votre organisation.
Hachez le nom d’utilisateur ou l’adresse e-mail de l’utilisateur au lieu d’envoyer des informations permettant de l’identifier. Pour les utilisateurs non connectés, utilisez un identifiant de session stable.
Utilisez background=True
Utilisez background=True pour les requêtes susceptibles de prendre
beaucoup de temps. Au lieu de maintenir la connexion client ouverte, l’API lance une tâche
et renvoie un identifiant. Votre application peut interroger périodiquement l’état de cette tâche jusqu’à sa réussite, son échec ou son
annulation. Utilisez ce mode pour les analyses volumineuses, les exécutions d’outils de longue durée ou les traitements qui nécessitent un suivi d’état
et un mécanisme de nouvelle tentative.
# Replace the illustrative IDs and URLs below with your own resource values.
from openai import OpenAI
import time
client = OpenAI()
log_bundle_file_id = "file_123"
job = client.responses.create(
model="gpt-6-astra",
background=True,
store=False,
input="Analyze this large log bundle and cluster the primary failure modes.",
tools=[
{
"type": "code_interpreter",
"container": {
"type": "auto",
"file_ids": [log_bundle_file_id],
},
}
],
)
while job.status in {"queued", "in_progress"}:
time.sleep(2)
job = client.responses.retrieve(job.id)
print(job.output_text)Vous pouvez le combiner avec stream=True pour recevoir des événements de progression, mais le premier événement
peut mettre plus de temps à arriver qu’avec une requête normale.
Du point de vue de l’interface, le mode en arrière-plan indique : « L’exécution est en cours ; voici son état ; le résultat apparaîtra ici dès qu’il sera prêt. »
Utilisez le mode WebSocket
Le mode WebSocket est conçu pour les flux de travail de longue durée
qui font de nombreux appels d’outils : vous maintenez une connexion persistante ouverte et
poursuivez en envoyant uniquement les nouveaux éléments d’entrée accompagnés de previous_response_id. Pour
les exécutions comportant au moins 20 appels d’outils, cette approche est environ 40 % plus rapide
de bout en bout.
Fonctionnement : le premier message ressemble à une requête Responses normale :
modèle, instructions, outils et entrée utilisateur. Le serveur renvoie un flux d’événements. Si
le modèle demande un outil, votre application l’exécute. Ensuite, au lieu d’envoyer une nouvelle
requête HTTP, vous envoyez un autre événement response.create sur le même socket avec
le previous_response_id précédent et le nouvel élément. C’est ce qui permet
de réduire la latence. En HTTP classique, chaque échange suivant nécessite une nouvelle requête. En mode WebSocket,
la connexion reste ouverte et l’état de la réponse la plus récente reste disponible en
mémoire pour cette connexion. Lorsque le tour suivant poursuit cette réponse,
le backend a moins de travail de préparation à effectuer.
Si votre workflow se limite à une requête et une réponse, conservez HTTP. Si votre workflow fonctionne comme un agent qui s’exécute sur une longue durée, essayez le mode WebSocket.
Une connexion WebSocket ne traite qu’une seule réponse en cours à la fois ;
le travail en parallèle nécessite donc plusieurs connexions. La durée des connexions est actuellement limitée à 60
minutes. Pour poursuivre l’exécution, previous_response_id suit les mêmes règles qu’en mode HTTP,
avec un cache propre à la connexion pour la réponse la plus récente.
Remarque : le mode WebSocket est compatible avec ZDR, car vos données ne sont pas stockées sur disque, mais uniquement en mémoire.
L’exemple Python utilise pip install "openai[realtime]>=3.8.0".
L’exemple JavaScript utilise npm install openai@^7.10.0 ws.
L’exemple Ruby utilise gem install openai async-websocket.
from openai import OpenAI
client = OpenAI()
with client.responses.connect() as connection:
# Use the same typed parameters as client.responses.create(...).
connection.response.create(
model="gpt-6-astra",
store=False,
input=[
{
"type": "message",
"role": "user",
"content": [
{
"type": "input_text",
"text": (
"Find the flaky test in this run, call the tools "
"you need, and keep going until you can explain "
"the root cause."
),
}
],
}
],
tools=[test_log_tool, code_search_tool],
)
first_event = connection.recv()
print(first_event.type)À retenir
L’API Responses est la base pour créer des applications OpenAI plus intelligentes et plus performantes. Son principal avantage est de permettre aux développeurs de passer de prompts ponctuels à des workflows persistants qui utilisent des outils, tiennent compte du contexte et s’adaptent à la complexité de la tâche. Suivez ce guide pour améliorer les performances de vos déploiements réels.