Regardez ce que votre équipe a produit la semaine dernière. Une petite partie correspondait à la fonctionnalité discutée en standup. Le reste, c'était tout l'environnement : triage des bugs, étiquettes, un changelog, des commentaires de première passe sur onze pull requests, l'échafaudage de tests pour un module que personne ne veut prendre en charge, des mises à jour de dépendances, une page de documentation devenue obsolète quand la forme d'une réponse a changé. Volume élevé, gloire minime, et jusqu'à cette semaine, cela coûtait le même prix par token que le travail intéressant, parce que tout tournait sur le même runtime.
OpenAI a livré GPT-6 Luna le 22 septembre à 0,10 $ par million de tokens en entrée et 0,50 $ par million en sortie, identifiant API gpt-6-luna, fenêtre de contexte de 1 M. C'est le palier auquel appartiennent les 80 % ennuyeux. La question utile n'est pas de savoir si Luna est bon, mais quels travaux descendre à ce niveau, lesquels ne doivent surtout pas y descendre, et comment rédiger une Tâche qu'un runtime bon marché peut mener à bien.
TL;DR
Orientez le travail vers le palier bon marché selon sa vérifiabilité, pas selon sa difficulté. Si un résultat peut être vérifié sans être refait, et qu'une mauvaise réponse coûte à un relecteur une minute plutôt qu'un après-midi, il a sa place sur Luna. Gardez les jugements de valeur, tout ce sur quoi le board automatise des actions, et tout ce que personne ne vérifiera sur le runtime coûteux. Rédigez des critères d'acceptation qu'une machine peut évaluer, gardez un effort modeste pour les tâches courtes, et faites revenir chaque résultat dans la Tâche où une personne l'accepte.
Le tarif de Luna, et ce à quoi il est comparé
Les comparaisons publiées par OpenAI pour Luna portent sur le coût par tâche plutôt que sur des positions dans un classement, ce qui est le bon cadre pour ce travail.
| Résultat publié | Luna | Comparé à |
|---|---|---|
| DeepSWE 1.1 | 66,6 % à effort maximal | Comparable à Claude Opus 5 et Fable 5 à effort moyen, à un coût par tâche inférieur de 93 % à celui d'Opus 5, et de 96 % à celui de Fable 5 |
| AutomationBench 1.0.6 | +5,4 points de pourcentage par rapport à son prédécesseur à effort élevé | Coût par tâche inférieur de 58 % |
| OSWorld 2.0 hors ligne | Bat GPT-5.6 Sol à effort moyen | Environ un dixième du coût |
| Factualité | Égal à GPT-5.6 Sol à effort plus élevé | Environ un centième du coût |
Deux nuances accompagnent ces chiffres. OpenAI décrit Sol et Luna comme 50 % moins chers que le tarif promotionnel de GPT-5.6. « Promotionnel » est le mot employé par OpenAI et il compte : la référence est une remise, pas le tarif catalogue. Par rapport au prix catalogue de GPT-5.6 Luna que notre propre couverture du lancement avait documenté, soit 1 $ par million en entrée et 6 $ par million en sortie, la baisse à 0,10 $ et 0,50 $ approche plutôt 90 % en entrée et 92 % en sortie. La réduction réelle est plus importante que le chiffre mis en avant, et ce chiffre mis en avant est mesuré par rapport à une promotion.
Et toutes les comparaisons avec Anthropic dans ce tableau portent sur Claude Opus 5. Anthropic a remplacé Opus 5 par Opus 5.5 le jour même de la publication d'OpenAI, à 4 $ par million en entrée et 20 $ par million en sortie, contre 5 $ et 25 $ pour Opus 5. Lisez ces écarts comme mesurés par rapport à la génération précédente, parce que c'est bien le cas. Nous ne désignons aucun vainqueur entre les deux fleurons actuels, et aucun des deux fournisseurs n'a publié cette comparaison directe.
Artificial Analysis, un tiers plutôt que l'un ou l'autre fournisseur, place Luna à 37 sur son indice d'intelligence, contre 58 pour Opus 5.5. Luna n'est pas un modèle de pointe et n'est pas vendu comme tel. C'est un travailleur compétent au tarif d'une commodité, et c'est tout l'intérêt.
La propriété qui détermine ce qui migre
Les équipes trient le travail des agents par difficulté. C'est le mauvais axe : la difficulté est une propriété du problème, tandis que votre exposition est une propriété de la boucle de relecture. Triez plutôt par vérifiabilité.
Un travail a sa place sur le palier bon marché quand ces deux conditions sont réunies. Le résultat peut être vérifié sans être refait, par un test, un diff, une règle de lint ou dix secondes de lecture. Et un mauvais résultat coûte à un relecteur une minute, pas un après-midi, parce que le rayon d'impact se limite à une étiquette, un commentaire ou un fichier.
C'est ce couple qui fait qu'un échafaudage de tests est éligible et qu'une revue de sécurité ne l'est pas, bien que les deux soient de la génération de texte sur le même dépôt. Un test généré s'exécute ou ne s'exécute pas, et on le sait dans la minute. Une faille d'autorisation manquée dans un commentaire de revue ressemble exactement à un commentaire impeccable.
Ce qu'il faut déléguer
| Travail | Ce que l'Agent renvoie | Comment c'est vérifié | Rayon d'impact en cas d'erreur |
|---|---|---|---|
| Triage des rapports de bug entrants | Résumé, composant suspecté, tentative de reproduction, suggestion de priorité | Quatre lignes lues au moment de prendre la Tâche | Une Tâche mal orientée |
| Étiquetage et métadonnées | Étiquettes et type de Tâche, en nommant la règle appliquée | Visible sur le board | Une étiquette erronée |
| Changelog et notes de version | Notes préliminaires à partir des diffs fusionnés d'un Sprint | Diff par rapport aux commits | Éditorial, détecté avant la livraison |
| Commentaires de revue de première passe | Observations sous forme de commentaires, explicitement pas une approbation | Le relecteur les lit ou les ignore | Du bruit, si rien n'en dépend |
| Échafaudage de tests | Fichiers de test qui compilent et s'exécutent, avec les lacunes évidentes signalées | L'exécution des tests | Build en échec |
| Mises à jour de dépendances | Une mise à jour par Tâche, avec un extrait du changelog et le résultat des tests | CI | Un revert |
| Suivis de documentation après une fusion | Modifications de la doc citant le diff source | Relecture du diff | Une page obsolète le reste |
Le schéma unificateur : chacun renvoie un artefact que quelqu'un d'autre évalue en quelques secondes, sur la base des preuves jointes par l'Agent. Aucun n'a le dernier mot sur quoi que ce soit, ce qui est le test à appliquer quand vous étendez la liste à tout ce que votre équipe prend en charge ensuite.
Ce qu'il ne faut pas déléguer
Trois lignes de démarcation méritent d'être énoncées, car un palier bon marché invite à ces erreurs.
Une revue de première passe n'est pas une revue. Un Agent qui publie des observations sur un diff produit de la matière à lire. Ce n'est pas une approbation, et dès qu'une équipe traite une première passe impeccable comme le signal qu'un changement est sûr, le palier bon marché a été promu au rang de décision d'acceptation. Soyez précis sur ce qu'un agent de revue peut et ne peut pas vérifier, et qualifiez le commentaire de première passe dans le commentaire lui-même.
Une étiquette sur laquelle le board automatise est une décision, pas une note. Si le passage d'une Tâche à un statut déclenche une exécution, ou si la priorité détermine ce que l'équipe prend ensuite, un Agent d'étiquetage fixe la direction. Soit vous désactivez l'automatisation sur ces champs, soit vous gardez l'étiquetage sur le palier auquel vous confiez la direction.
Un travail que personne ne vérifiera ne devient pas moins cher, il devient invisible. Une mauvaise réponse bon marché n'est bon marché que quand quelqu'un la remarque. Si un travail n'a pas de lecteur, la solution est de supprimer ce travail, pas d'adopter un runtime moins cher.
Le couple de décision, donc. Utilisez Luna quand le travail est volumineux, délimité et vérifié par autre chose que la confiance. Utilisez Sol ou Opus 5.5 quand une Tâche doit conserver le contexte pendant des heures, traverse plusieurs modules, ou coûte plus cher à interrompre à mi-parcours que les tokens ne coûteraient. Si vous faites tourner un seul Agent sur un seul dépôt, ne séparez pas les paliers du tout : choisissez le runtime qui convient à votre travail le plus exigeant.
Rédiger une Tâche qu'un runtime bon marché peut mener à bien
Un Agent dans Sharkly est une configuration de travail enregistrée plutôt qu'un prompt ponctuel. Ses instructions, son Runtime, ses Skills, ses dépôts, son environnement et ses paramètres d'exécution façonnent sa manière de traiter le travail, de sorte que la bonne unité est un Agent par type de travail ennuyeux, pas un Agent astucieux qui fait les sept. Une équipe peut conserver des Agents distincts pour les modifications de code, la revue, les tests, la documentation ou le triage opérationnel sans réécrire les instructions à chaque Tâche.
Un runtime bon marché a besoin d'un périmètre étroit et d'une ligne d'arrivée mécanique :
SH-312 Triage: 9 unassigned bug reports from this week
Assignee: Triage Agent (Codex Runtime, gpt-6-luna)
For each report, return on the Task:
- one-sentence restatement of the observed behavior
- the suspected component, with the file or module that led you there
- whether you could reproduce it locally, and the exact command you ran
- a priority suggestion with one reason
Do not change files. Do not close or merge anything.
Finish with any question that must be answered before implementation.
Trois éléments de cette Tâche font le travail. Le périmètre est une seule passe sur neuf éléments, donc un échec est peu coûteux à écarter. Chaque affirmation porte sa preuve, donc la vérification relève de la lecture plutôt que d'une nouvelle investigation. Et les deux dernières lignes fixent la limite : cet Agent rapporte, il n'agit pas.
Un réglage mérite d'être décidé volontairement. Les gains publiés de Luna se situent à effort de raisonnement élevé et maximal, et l'effort est une décision de coût et de latence plutôt qu'un bouton de qualité à laisser au maximum. Artificial Analysis, là encore un tiers, a mesuré la variante à raisonnement maximal à 153,9 tokens de sortie par seconde pour Luna, avec environ 124 secondes jusqu'au premier token. [VERIFY] Quelle que soit la valeur actuelle, la tendance tient : à effort maximal, les modèles bon marché ne sont pas ceux qui démarrent vite. Un travail d'étiquetage qui réfléchit pendant deux minutes semble bloqué sur un board. Faites tourner les tâches courtes à effort modeste et réservez les réglages élevés aux Tâches qui les méritent.
Deux remarques sur l'accès, puisque c'est sur ce palier que les équipes font leurs premiers pas. Luna fonctionne dans Codex et ChatGPT Work pour les offres Plus, Pro, Business, Enterprise et Edu, et les comptes Free et Go y ont accès dans l'application de bureau. Il n'est pas encore dans Chat. Dans Sharkly, le modèle se règle dans la configuration du Runtime ou de l'outil Computer, jamais sur l'Agent, et Sharkly ne vous réaffichera pas le nom du modèle.
Ce qu'une baisse de prix ne règle pas
Neuf résumés de triage aux tarifs de Luna coûtent presque rien. Ils produisent quand même neuf choses qu'une personne doit lire. Une équipe qui fait migrer tout son environnement vers un palier bon marché n'a pas réduit les décisions en attente d'un humain : elle les a seulement rendues moins chères à produire, ce qui n'est pas la même chose que moins chères à accepter. C'est pourquoi la file de relecture reste le plafond quel que soit le tarif des tokens.
Ce que vous pouvez changer, c'est la lisibilité de cette file. Conservez l'objectif, l'exécution, les preuves, les obstacles et la relecture humaine sur la Tâche, de la demande à la livraison, de sorte qu'un commentaire de première passe soit visiblement une première passe, qu'un résumé de triage porte la commande qui l'a produit, et que les éléments qui vous attendent réellement soient distinguables de ceux qui ne sont que bruyants. Les Agents recherchent, exécutent, testent et rapportent. Les personnes fixent la direction, accordent l'autorité et acceptent le résultat.
Si vous faites tourner plusieurs agents et que les agents bon marché s'apprêtent à se multiplier, Sharkly vous offre un seul endroit pour assigner leurs Tâches, voir ce que chaque exécution a produit et décider ce qui part en production. Connectez un seul Computer, créez un Agent pour votre travail le plus ennuyeux, et assignez-lui une vraie Tâche.
