Vous lancez trois exécutions avant midi. Quatre-vingt-dix secondes plus tard, deux des trois terminaux n'ont rien affiché du tout. L'un d'eux est en train de raisonner sur le dépôt. L'autre a reçu un 504 en chemin et ne reviendra jamais. Depuis votre siège, les deux ne sont qu'un même rectangle de scrollback avec un curseur dedans.
Le problème n'est pas nouveau, mais les sorties du 22 septembre 2026 l'ont aggravé d'une manière précise et mesurable. Les réglages de raisonnement les plus élevés des nouveaux modèles achètent de la précision en réfléchissant longuement avant de dire quoi que ce soit. Artificial Analysis a chronométré la variante de raisonnement « max » de GPT-6 Sol à 102,15 secondes jusqu'au premier token, et GPT-6 Luna à 124,23 secondes. Ce sont des mesures tierces sur une configuration précise, pas des chiffres du fournisseur, et cette nuance compte, mais la tendance ne fait aucun doute : le silence en début d'exécution est désormais assez long pour être indiscernable d'une panne.
TL;DR
Le temps jusqu'au premier token est le délai entre l'envoi d'une requête et l'arrivée du premier caractère de la réponse, et sur un modèle de raisonnement à effort élevé, c'est là que se déroule l'essentiel de la réflexion. Un terminal ne peut pas vous dire la différence entre une exécution qui réfléchit, une exécution qui attend un humain et une exécution morte depuis deux minutes, parce que les trois n'affichent rien. Un statut, si. Les agents font de la recherche, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat. Pour que ce contrat fonctionne, il faut un état d'exécution visible sans qu'une personne le surveille : Sharkly conserve le contexte, la progression, les blocages, les résultats et la revue humaine sur la Task, de la demande à la livraison, si bien qu'une longue réflexion et une exécution morte cessent de se ressembler.
L'attente s'est allongée, et le modèle bon marché n'est pas le plus rapide
Voici ce que disent les mesures tierces sur les deux nouveaux modèles GPT-6 à leur réglage de raisonnement maximal.
| Modèle | ID d'API | Vitesse de sortie | Temps jusqu'au premier token | Entrée / sortie par million de tokens |
|---|---|---|---|---|
| GPT-6 Sol (max) | gpt-6-sol |
115,2 tokens/s | 102,15 s | 2 $ / 10 $ |
| GPT-6 Luna (max) | gpt-6-luna |
153,9 tokens/s | 124,23 s | 0,10 $ / 0,50 $ |
Lisez les deux dernières colonnes ensemble. Luna coûte un vingtième de Sol par token et vous fait attendre plus longtemps avant de parler. Coût et latence sont deux axes distincts, et l'intuition selon laquelle un modèle moins cher serait plus réactif est tout simplement fausse ici.
Deux réserves honnêtes avant que quiconque construise un tableau de bord sur ces chiffres. Premièrement, ils proviennent d'Artificial Analysis et non d'OpenAI, et ils décrivent spécifiquement les variantes de raisonnement « max ». Les réglages d'effort inférieurs sont une autre paire de manches, et vos propres chiffres varieront selon la taille du prompt, la disponibilité des outils et la région où atterrit votre trafic. Deuxièmement, le temps jusqu'au premier token n'est pas la même mesure que la vitesse de sortie. Anthropic affirme que Claude Opus 5.5 produit sa sortie environ 30 % plus vite qu'Opus 5, ce qui concerne les tokens qui suivent le premier. Un modèle peut streamer rapidement et vous laisser quand même devant un écran vide pendant une minute et demie.
Un terminal silencieux n'est pas un statut
Le silence dans un terminal a au moins quatre causes, et le terminal les affiche toutes de façon identique :
- Le Runtime travaille. Le raisonnement est en cours, rien n'est encore affiché.
- L'exécution est terminée depuis un moment et attend qu'un humain réponde à une question.
- La requête a échoué. La documentation de Sharkly est sans détour sur la facilité de mal interpréter ce cas : « Timeout / 408 / 504 signifie que la requête a été lente, annulée ou retardée par une passerelle. Ce n'est pas la même chose que le Computer hors ligne. »
- Le Computer a réellement disparu, ou le répertoire dont l'exécution avait besoin n'a jamais été libre.
Un agent, un terminal : vous réglez la question en attendant une minute de plus. Cinq agents répartis sur trois dépôts et deux Computers : vous la réglez en passant d'une fenêtre à l'autre à l'aveugle. C'est la forme ordinaire du chaos des agents : pas une panne spectaculaire, juste une équipe qui dépense son attention sur la question « est-ce que celui-là est encore vivant ? » plusieurs fois par heure.
Le réflexe consiste à le tuer et à relancer. À effort de raisonnement élevé, ce réflexe coûte cher, et deux fois plutôt qu'une. Vous repayez toute l'attente du premier token, et vous jetez la réflexion qui était sur le point d'arriver.
Ce qu'un statut doit permettre de distinguer
Le modèle de Sharkly vaut la peine d'être repris, que vous utilisiez Sharkly ou non, parce qu'il sépare deux choses qu'un terminal fusionne. C'est la même dissociation qui rend les statuts d'exécution, les logs et les signaux de défaillance lisibles tout court. Une exécution possède un état d'exécution : Queued, Dispatched, Waiting for local directory, Running, Completed, Failed ou Canceled. Une Task possède un statut de cycle de vie, et un Agent possède par-dessus un état de travail : Working, Waiting for human reply, Waiting for human review ou Error. La documentation pose clairement la frontière : ces états d'exécution « n'impliquent pas automatiquement que la Task ait le même statut de workflow ».
Cette dissociation constitue à elle seule la réponse à la question « bloqué ou en train de réfléchir ? »
| Ce que montre le terminal | Ce que c'est peut-être en réalité | Ce qui permet de les distinguer | Qui agit ensuite |
|---|---|---|---|
| Rien, après 100 s | Running, avant le premier token | L'état d'exécution est Running, le log contient un horodatage de dispatch | Personne. Laissez tourner. |
| Rien, après 10 min | Waiting for human reply | L'état de travail a changé, la Task fait remonter un point d'attention dans Inbox | L'Assignee répond dans le contexte |
| Rien, indéfiniment | Failed | L'état d'exécution est Failed, le log d'exécution porte le titre et la réponse d'origine du service de modèle | L'Assignee lit le log avant de relancer |
| Rien, jamais démarré | Queued ou Waiting for local directory | L'état d'exécution, plus le pool de répertoires occupé | Libérer un répertoire ou augmenter la capacité parallèle |
Aucune de ces quatre lignes n'exige qu'une personne surveille au moment précis où la situation change. C'est tout l'intérêt. L'état est enregistré, et la question « est-ce qu'il réfléchit ou est-ce qu'il est bloqué ? » devient quelque chose que vous consultez plutôt que quelque chose que vous subissez.
Le timeout par Task que vous avez défini en mars
Un Agent dans Sharkly porte un nombre maximal de Tasks exécutées en parallèle et un timeout par Task. La plupart des équipes définissent ce timeout une fois, au début, en fonction du temps qu'elles étaient prêtes à fixer un terminal. Si ce chiffre est de deux minutes et que vous avez depuis passé un Agent en réglage de raisonnement max, vous avez configuré une politique qui annule les exécutions pendant la phase de réflexion et les signale comme des échecs.
Allez regarder le vôtre cette semaine. Le seuil minimal n'est pas « combien de temps suis-je prêt à attendre », mais « combien de temps ce Runtime met-il au niveau d'effort que j'utilise réellement, plus le travail lui-même ». Pour une exécution dont le premier token peut à lui seul prendre plus de cent secondes, un timeout inférieur à cinq minutes est un pile ou face déguisé en politique.
Deux réglages connexes méritent le même examen. Le nombre maximal de Tasks exécutées en parallèle est votre véritable limite de concurrence, et lorsque tous les répertoires configurés sont occupés, les nouvelles exécutions restent en Waiting for local directory au lieu d'échouer — un comportement correct qui ressemble à un blocage si vous ne surveillez qu'un terminal.
Le caching règle-t-il le problème ?
En partie, et pas la partie qui vous intéresse. Le prompt caching d'OpenAI pour GPT-6 offre une remise de 90 % sur les lectures d'entrée mises en cache, avec des taux de succès plus élevés par défaut, ajoute des breakpoints explicites pour que vous choisissiez où se termine un préfixe mis en cache, et ne casse plus le cache lorsque vous modifiez l'effort de raisonnement ou la disponibilité des outils. GitHub rapporte plus de 50 % de tokens de prompt en moins à retraiter à neuf sur des milliards de requêtes. C'est un vrai gain de coût et de latence sur le prompt, et la correction liée au changement d'effort est réellement utile pour les agents qui font monter une tâche d'un réglage bon marché à un réglage coûteux en cours de route.
Cela ne supprime pas la passe de raisonnement. Un cache chaud signifie qu'une moindre part de votre prompt est traitée à partir de zéro. Cela ne signifie pas que le modèle a déjà réfléchi à votre bug. Prévoyez l'attente malgré tout.
Quand payer l'attente, et quand l'éviter
Utilisez un réglage de raisonnement maximal quand la tâche est de celles que vous ne voulez pas exécuter deux fois : une migration, un refactoring transversal, tout ce où une mauvaise réponse coûte plus de quatre-vingt-dix secondes. OpenAI rapporte que Sol, à son réglage xhigh, obtient 33,2 % sur AutomationBench 1.0.6 pour 0,27 $ par tâche, ce qui résume bien l'arbitrage. La précision coûte peu en argent désormais et cher en temps réel.
Utilisez un réglage d'effort inférieur quand quelqu'un attend la réponse en face. Travail interactif, question rapide sur un fichier, petite correction bien délimitée : le problème du silence disparaît en grande partie à effort réduit, parce que le premier token arrive pendant que vous vous souvenez encore de ce que vous avez demandé.
Et la frontière honnête : si vous faites tourner un seul agent sur une seule Task, vous n'avez pas besoin d'un tableau pour ça. Suivez le log. Le problème d'état commence au moment où le nombre d'exécutions dépasse le nombre de terminaux que vous pouvez réellement surveiller, soit environ trois pour la plupart des gens.
Ce que cela ne règle pas
Un statut vous dit qu'une exécution est Working. Il ne vous dit pas qu'elle fait quelque chose d'utile, et un agent confiant mais dans l'erreur affiche le même état vert qu'un bon agent aussi longtemps que dure l'exécution, ce qui sur Opus 5.5 peut représenter 18 heures ou plus. Distinguer « en cours » de « en cours et bien » reste un problème de revue, et la revue reste le travail d'un humain. L'automatisation s'arrête là où le jugement de l'équipe est requis.
Si vous faites déjà tourner plusieurs agents en parallèle, le plus petit changement utile cette semaine n'est pas un nouveau modèle. C'est de rendre l'état de chaque exécution lisible sans ouvrir un terminal, pour que les quatre-vingt-dix prochaines secondes de silence soient une information plutôt qu'une question.
