Claude Fable 5.2 a assemblé un jeu de tir en navigateur en 8 heures pour environ 550 $

Laisser une IA assembler un prototype pendant la nuit est une idée séduisante, jusqu'à l'arrivée de la facture au matin. L'histoire du jeu de tir en navigateur Saltline montre ce qu'il faut surveiller à l'avance : l'agent doit se voir retransmettre le contexte de la tâche à de nombreuses reprises, et ce flux entrant peut coûter plus cher que le code produit. Pour une équipe qui teste le développement autonome, c'est un poste budgétaire très concret.

Selon l'ingénieur d'Anthropic Felix Rieseberg, Claude Fable 5.2 a créé Saltline en huit heures environ, à partir d'un seul prompt initial et sans retour humain en cours de travail. Le coût annoncé aux tarifs de l'API est d'environ 550 $. L'auteur indique aussi environ 2,7 millions de tokens en sortie et 445 millions en entrée, dont une part importante est passée par le cache. Les liens vers le post de l'auteur et vers le jeu accompagnent le message d'origine ; nous ne disposons pas d'une ventilation des coûts vérifiée.

Ce qui est sorti en huit heures

Saltline est un jeu de tir à la première personne en navigateur, avec une seule mission. D'après la description de l'expérience, le modèle a créé le code, les modèles, les sons et les textures. C'est un exemple intéressant de tâche où plusieurs éléments doivent être coordonnés : l'image, les commandes, le gameplay et le son doivent fonctionner ensemble.

Le titre « Call of Duty pour 550 $ » crée une attente trop large. Une seule mission ne permet pas d'estimer le coût d'un grand jeu avec campagne, modes en réseau, prise en charge de différents appareils et tests prolongés. Il est plus utile de voir l'expérience comme une tentative d'obtenir un prototype de jeu limité en une seule exécution prolongée.

Autre point : un seul prompt ne signifie pas une seule réponse du modèle. Sans retour humain, l'agent peut tout de même effectuer de nombreuses étapes, appeler des outils, recevoir des résultats et poursuivre son travail. Les chiffres fournis ne permettent pas de savoir quelles vérifications ont été effectuées lors de cette exécution. Il vaut donc mieux transposer ce résultat à son propre projet au moyen d'un petit essai.

Pourquoi les tokens d'entrée étaient 165 fois plus nombreux

Imaginez que l'agent ajoute une porte au jeu. On lui transmet la tâche et le code nécessaire. Après la modification, il reçoit le résultat de l'outil, puis corrige une erreur ou passe à l'objet suivant. La requête suivante contient de nouveau une partie du matériel précédent, plus de nouvelles données. Au fil d'une longue session, le volume d'entrée facturé s'accumule.

Diviser 445 millions par 2,7 millions donne environ 165 tokens d'entrée pour un token de sortie. C'est le rapport des volumes totaux sur l'exécution. Il ne prouve pas que le modèle recevait tout le projet à chaque étape ni que le contexte grossissait en continu : pour une telle conclusion, il faut un journal des requêtes.

Le cache permet de traiter à moindre coût la partie répétée de l'entrée. Pour autant, le modèle ne reçoit pas de mémoire à long terme automatique : le développeur doit toujours gérer les éléments qui entrent dans la requête. L'intérêt pratique du cache est particulièrement net lorsque l'agent travaille de nombreuses fois avec les mêmes instructions et de gros fragments de contexte.

Ce que l'on peut réellement calculer

Anthropic indique pour Fable 5.2 des tarifs de base de 8 $ par million de tokens en entrée et de 40 $ par million en sortie. À ces tarifs, 2,7 millions de tokens en sortie coûtent 108 $. Si les 445 millions en entrée étaient payés au tarif de base, cela ferait 3 560 $ de plus. Au total, 3 668 $, soit environ 6,7 fois plus que les 550 $ annoncés.

Mais il s'agit d'un calcul théorique sans cache, et non d'une facture reconstituée de l'expérience. Si l'on prend le total de 550 $ et le coût de sortie de 108 $, il reste environ 442 $ pour l'entrée, soit environ 0,99 $ par million de tokens en moyenne. Le taux exact de succès du cache ne peut pas en être déduit sans ventilation par lecture, écriture et tarifs appliqués.

Avant un tel lancement, le développeur devrait activer le suivi de ces catégories de dépenses et fixer un plafond monétaire. Le product manager devrait définir à l'avance les critères d'achèvement : la mission se lance-t-elle, peut-on la terminer, sur quels appareils fonctionne-t-elle. Pour le fondateur, la prochaine étape utile consiste à répéter plusieurs fois une tâche limitée et à comparer le coût du résultat retenu. Une exécution réussie montre une possibilité ; le budget d'un produit exige aussi de la prévisibilité.