Comment exécuter des agents GPT-6.1 Sol dans Sharkly

OpenAI a lancé GPT-6.1 Sol lors du DevDay le 29 septembre, au même tarif catalogue que GPT-6 Sol : 2 $ par million de tokens en entrée et 10 $ par million en sortie, avec un coût d'entrée en cache réduit de moitié à 0,10 $. Pour une équipe exploitant plusieurs agents Codex, le détail le plus crucial est plus discret. L'écran de démarrage dans la documentation de la CLI Codex affiche désormais gpt-6.1-sol medium. Sur tout Computer ne verrouillant pas de version de modèle, vos Agents changent de modèle dès qu'une personne met à jour Codex sur ce Computer, et non pas quand l'équipe décide qu'ils le devraient.

Sharkly n'affichera pas ce changement. L'Agent s'aligne sur le modèle par défaut du Runtime sans afficher son nom : dès cette semaine, deux Agents dotés d'instructions identiques peuvent donc tourner sur des modèles différents selon le Computer utilisé, alors même que leurs Tasks semblent identiques sur le tableau. Savoir quel agent tourne sur quel modèle et quel résultat provient duquel devient alors une énigme que l'on ne résout que de mémoire. Ce guide se concentre uniquement sur les nouveautés par rapport à notre guide sur GPT-6 Sol : d'où provient cette nouvelle valeur par défaut, quand la verrouiller, les deux paramètres modifiés, et comment une Crew doit répartir la charge de travail maintenant que le niveau intermédiaire se rapproche du sommet.

En résumé

GPT-6.1 Sol s'intègre à Sharkly par le biais du Runtime Codex sur chaque Computer, sans qu'aucune modification visible n'apparaisse dans Sharkly. Vérifiez le build de Codex utilisé par chaque Computer et si son fichier ~/.codex/config.toml verrouille un modèle. Les Computers non verrouillés adoptent la valeur par défaut de la CLI, que la documentation indique désormais comme étant gpt-6.1-sol avec un effort medium. Les Computers configurés d'après notre guide précédent restent sur gpt-6-sol tant qu'une ligne n'a pas été modifiée. Remplacez tout niveau d'effort none par low, attendez-vous à voir la baisse de 50 % sur le cache se refléter sur les Computers facturés par clé API plutôt que sur les forfaits avec connexion de compte, et considérez la table de routage ci-dessous comme une règle à tester sur vos propres Tasks, et non comme un verdict définitif.

Ce qui change sous le Runtime Codex

La documentation des Agents explique bien pourquoi cet article traite des Computers plutôt que des Agents : « L'Agent suit le modèle par défaut du Runtime. Il ne garantit ni n'affiche de nom de modèle spécifique. Modifiez les modèles dans la configuration des outils du Runtime ou du Computer, et non sur l'Agent. » La mise à niveau est un événement lié au Runtime. Voici ce qui change concrètement pour une Crew :

La mise à jour de la CLI Codex introduit également la voix, une vue /agents, l'édition de prompts, la reprise de session et les worktrees sur l'ensemble des forfaits. Ces fonctionnalités valent le détour lorsque vous utilisez Codex manuellement depuis un terminal. En revanche, dès que le travail incombe à l'équipe, la Task devient la référence partagée. En mode Temporaire, Sharkly attribue à chaque Task son propre répertoire et, lors d'interventions sur un dépôt, peut préparer un nouveau worktree ; le statut, les logs, les questions et le résultat de l'exécution remontent ensuite directement dans la Task, à disposition du collaborateur suivant.

Figer le modèle ou laisser chaque Computer suivre la valeur par défaut

Commencez par un inventaire, car la réponse peut varier d'un Computer à l'autre. La commande sharkly computer list affiche les Computers enregistrés auprès de votre organisation, et sharkly computer show <computer-id> renvoie un Computer précis accompagné de ses Runtimes. Sur le Computer lui-même, lancer codex affiche le build et le modèle utilisés. Le journal des modifications de Codex indique que la version 0.159.1 (29 septembre) a fait de GPT-6.1 Sol le modèle par défaut, et la session d'exemple de la documentation indique model: gpt-6.1-sol medium.

Soyez attentif à deux éléments. Premièrement, le binaire exécuté. Sur macOS, un Computer dépourvu de Codex autonome peut enregistrer comme Runtime la CLI Codex intégrée à l'application de bureau ChatGPT ; or, la documentation de Sharkly recommande plutôt une version de Codex installée manuellement et accessible dans le PATH. Deuxièmement, le niveau de configuration qui définit le modèle. Les notions de base sur la configuration de Codex placent les valeurs personnelles par défaut dans ~/.codex/config.toml, permettent à un dépôt de les surcharger avec son propre fichier .codex/config.toml (chargé uniquement pour les projets approuvés), tandis que l'option -m ou --model en ligne de commande l'emporte sur les deux.

Deux cas de figure s'offrent à vous. Laissez un Computer suivre la valeur par défaut lorsqu'il n'appartient qu'à une seule personne, qu'il exécute quelques Tasks par semaine et que son utilisateur préfère suivre le modèle recommandé par OpenAI plutôt que de gérer une ligne de configuration. Figez le modèle lorsque plusieurs personnes assignent des tâches à des Agents sur ce Computer, lorsqu'une Crew s'étend sur plusieurs Computers ou en plein milieu d'un Sprint, où une modification silencieuse ferait passer à tort le résultat du mardi et celui du jeudi pour comparables dans la Task.

Pour le figer, modifiez le fichier de configuration utilisateur sur le Computer qui exécute le Runtime Codex :

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

Ces deux clés figurent dans la documentation de configuration de Codex avec ces valeurs. Si vous aviez suivi notre guide sur GPT-6 Sol, ce fichier contient déjà model = "gpt-6-sol", et ce Computer ne basculera pas lors d'une mise à jour. Ne modifiez cette ligne que lorsque vous y serez prêt.

Mettez à jour Codex à l'aide de l'outil d'installation mentionné dans la documentation aussi bien pour l'installation que pour la mise à jour, ou demandez à Sharkly de lancer la mise à jour de la CLI pour un Runtime donné :

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

Lancez ensuite la nouvelle analyse ou le test de connexion dans la vue détaillée du Computer et confirmez que le Runtime Codex indique l'état Disponible. Enfin, notez le modèle sélectionné dans la description de l'Agent. La personne chargée de relire un diff ne devrait pas avoir à ouvrir un shell sur un Computer pour savoir quel modèle l'a produit.

Les deux paramètres modifiés : effort et cache

L'option none a disparu. GPT-6.1 Sol accepte low, medium, high, xhigh et max, mais refuse none et minimal. Un Computer dont la configuration demande none — un choix naturel pour un traitement rapide avec GPT-6 Sol — doit passer à low avant de migrer, et les résultats méritent d'être réexaminés, car low continue de raisonner. Si une exécution échoue avec l'ancien paramètre, le journal d'exécution conserve le titre et la réponse d'origine du service de modèle, et la consigne de dépannage de Sharkly face à une option non prise en charge est de vérifier le modèle et les paramètres de requête plutôt que de relancer aveuglément.

Le cache représente un gain plus discret mais précieux. OpenAI facture les tokens d'entrée en cache 0,10 $ par million, soit « 95 % de moins que le tarif d'entrée standard et 50 % de moins que le tarif d'entrée en cache de GPT-6 Sol ». C'est sur les Agents à exécution longue que l'effet se fait sentir. Un agent qui travaille sur un même dépôt pendant une heure renvoie continuellement une grande partie du même contexte, et les membres d'une Crew qui partent de la même structure de dépôt, des mêmes règles et des mêmes commandes de test réutilisent le même préfixe tout au long de la journée.

Trois nuances importantes méritent d'être soulignées. L'économie par token n'apparaît que sur un Computer où Codex facture sur une clé API ; un Computer connecté via un compte doté d'un abonnement ChatGPT consomme le quota du forfait, ce qui fait l'objet d'un article complémentaire sur l'utilisation de GPT-6.1 Sol sans clé API. Le tarif catalogue de base n'a pas changé, le travail non mis en cache coûte donc exactement la même chose que la semaine passée. Enfin, les contextes longs entraînent une surfacturation : pour tout prompt dépassant 272 000 tokens en entrée, OpenAI facture 2 fois le tarif de l'entrée et du cache, et 1,5 fois la sortie sur l'ensemble de la requête ; un Agent qui traîne un contexte massif à chaque échange devrait donc d'abord bénéficier d'un préfixe plus restreint et stable avant de se voir allouer un budget plus élevé.

Orienter le travail de la Crew : Astra, 6.1 Sol, Luna ou un Runtime Claude

L'argumentaire d'OpenAI pour 6.1 Sol repose sur des performances proches d'Astra pour une fraction de son coût, et chacun des chiffres avancés est issu des propres tests d'OpenAI. Sur DeepSWE v1.1, OpenAI affirme que 6.1 Sol égale Astra à environ un cinquième du coût et dépasse le meilleur score de GPT-6 Sol de 6,4 points avec un niveau d'effort inférieur. Sur OSWorld 2.0, un benchmark d'utilisation de l'ordinateur, il se situe à seulement 2,1 points d'Astra à l'effort maximal pour environ un septième du coût par tâche. OpenAI explicite également ses limites : Astra conserve le score le plus élevé sur Terminal-Bench Science avec 68,1 %, et OpenAI recommande d'employer Astra pour les travaux scientifiques les plus exigeants.

Le guide de sélection des modèles d'OpenAI classe la gamme selon la même logique : Astra pour les problèmes ambigus, 6.1 Sol pour les projets complexes où le temps et le coût comptent, Luna pour les tâches bien délimitées et le tri préalable — tout en précisant que ces recommandations constituent une base de départ. Comme le modèle est défini dans la configuration du Runtime, une règle de routage dans Sharkly revient à une règle sur les Computers : un Agent rattaché à un Computer dont le Codex est configuré par défaut sur Astra utilisera Astra. Voici une règle de départ à mettre à l'épreuve :

La dernière ligne formalise une stricte neutralité vis-à-vis des fournisseurs, sans prétention liée à un benchmark. Claude Sonnet 5.5 est sorti la veille de 6.1 Sol aux mêmes tarifs de 2 $ et 10 $, et l'article d'OpenAI compare 6.1 Sol à Opus 5.5 et Fable 5.1, jamais à Sonnet 5.5. Aucun fournisseur n'ayant publié ce face-à-face, la seule comparaison valable reste celle que vous mènerez sur vos propres Tasks. L'argumentaire complet en faveur d'une règle documentée prévoyant une chaîne d'escalade manuelle est détaillé dans notre article sur le routage de modèles pour les Crews.

Rien de tout cela ne change le bout de la chaîne. Obtenir des résultats proches d'Astra à moindre coût signifie davantage d'exécutions terminées par jour, mais chacune d'entre elles aboutit toujours à une personne qui examine le diff. Les Agents effectuent les recherches, exécutent, testent et rendent compte. Les humains donnent la direction, accordent les autorisations et valident le résultat. Le véritable enjeu cette semaine consiste à s'assurer que le tableau de bord permette de savoir quel Computer a exécuté quel modèle, ce qui s'est achevé avec succès, ce qui a échoué en raison d'un paramètre d'effort obsolète et ce qui est en attente de relecture. Si vous jonglez encore manuellement entre plusieurs terminaux Codex, l'article sur la gestion de multiples agents Codex détaille d'abord la méthode manuelle.

Vous pouvez mettre cela en place manuellement avec des worktrees, ou utiliser Sharkly pour orchestrer ce workflow.