Baseten Grid pose une question simple. Combien coûte une tâche de développement terminée ?

Un agent de programmation produit une modification propre pour un test en échec. Le changement ne passe pas l’intégration continue et le développeur lui demande de réessayer. La deuxième tentative touche une partie plus large du dépôt, et une personne passe une demi-heure à vérifier un correctif censé prendre cinq minutes. Quel modèle a coûté le moins cher ?

Le 4 novembre, Baseten a présenté Grid en aperçu public. Le service réunit une passerelle pour modèles autorisés, un routeur et des contrôles centralisés sur l’usage et les garde-fous. Il peut prendre place entre les outils de développement compatibles et leurs modèles, pour appliquer une même politique à plusieurs demandes. La page d’accès anticipé renvoie les équipes vers une liste d’attente.

Le dénominateur change la lecture des coûts

Coût par tâche acceptée. Illustration originale de Telli.sh.

Un prix par jeton mesure une unité d’utilisation du modèle. Une équipe doit livrer un changement qui répond à ses critères d’acceptation. Une demande peut produire une réponse, une exécution peut produire un diff et la tâche peut rester inachevée. Comptabiliser ces événements séparément rend l’essai de routage exploitable.

Imaginons deux routes qui reçoivent chacune 100 tâches comparables. La plus économique dépense 50 dollars sur l’ensemble des tentatives et fournit 50 résultats acceptables. L’autre dépense 90 dollars et en fournit 90. Dans cet exemple, les deux dépensent un dollar de modèle par résultat accepté. Si l’on ajoute le temps de relecture, les outils et l’attente liée aux nouvelles tentatives, l’écart peut évoluer dans un sens ou dans l’autre.

Gardez le coût des échecs au numérateur. Une route qui abandonne les demandes difficiles paraît plus efficace si les tentatives abandonnées disparaissent du calcul. Conservez aussi une définition stable de la réussite. Pour modifier de la documentation, un diff approuvé peut suffire. Une migration exige des tests sur les données existantes et un moyen de revenir en arrière.

Le type de tâche compte. Une migration d’API dans tout un dépôt peut être difficile parce qu’elle demande du contexte, de la coordination et beaucoup de petits changements. Un correctif d’une ligne peut être plus délicat à cause d’un problème de concurrence peu visible. Le nombre de fichiers et la longueur de la demande ne sont utiles que s’ils prédisent les résultats dans votre environnement.

L’expérience du routeur met en évidence un compromis

Essai de routage. Illustration originale de Telli.sh.

Le rapport technique de Baseten compare l’utilisation systématique d’Opus 5.5 à un routage entre ce modèle et GLM 5.3 Flash. Sur un mélange de tâches DeepSWE, SWE Atlas QnA et Terminal-Bench, l’entreprise rapporte un point de fonctionnement à 72 % de coûts en moins, avec un taux de réussite à moins de 0,8 point de pourcentage de celui obtenu en utilisant toujours Opus. Le rapport compare aussi le routeur à une affectation aléatoire à coût comparable. Cette comparaison compte, car envoyer davantage de tâches à un modèle moins cher suffit à réduire le coût moyen, même si le choix se fait au hasard.

Le seuil traduit un choix sur le prix que l’on accepte de payer pour la réussite attendue. En privilégiant les coûts, on peut envoyer davantage de tâches vers la route économique. Un autre réglage peut favoriser le modèle plus performant lorsque le résultat a plus de conséquences. Les chiffres de Baseten dépendent des modèles, des tâches et des hypothèses tarifaires choisis. Votre équipe rencontrera d’autres tâches et d’autres coûts en cas d’échec.

Dans l’annonce produit, Baseten mentionne séparément une réduction de coût arrondie allant jusqu’à 70 % dans ses premiers benchmarks. Distinguez cette affirmation du résultat de 72 % et de la comparaison des taux de réussite qui l’accompagne. Le rapport technique montre comment le coût varie avec la probabilité de réussite. L’équipe peut choisir le point qui correspond à ses priorités, puis le confronter à des tâches réelles.

Une passerelle peut rendre les règles visibles

L’annonce de Grid mentionne des modèles autorisés, des contrôles par équipe et une visibilité sur l’usage. Une équipe plateforme peut donner accès aux modèles déjà évalués par son organisation tout en suivant la répartition de leur utilisation. Cela aide à comprendre où part l’argent avant même de déléguer le choix du modèle.

Plusieurs décisions se posent dans la pratique. Quel fournisseur peut voir le code propriétaire ? Quel modèle est autorisé pour un dépôt donné ? Quelle équipe assume le coût des nouvelles tentatives ? Qui peut déroger à la règle après un incident ? Une passerelle peut regrouper ces décisions en un même point, à condition que les administrateurs sachent ce que chaque contrôle couvre.

La passerelle de modèles et l’environnement de l’agent sont deux points de contrôle distincts. La première peut décider quel modèle reçoit la demande. Le second détermine si l’agent peut lire des identifiants, écrire dans un fichier ou effectuer une requête réseau. Les restrictions de routage aident lorsqu’elles fonctionnent avec ces autorisations d’exécution. Une route économique exige les mêmes limites pour les outils privilégiés.

La question des traces compte aussi. Les journaux de routage peuvent expliquer une variation des coûts, mais peuvent contenir du code, des chemins ou des détails sur un incident client. Décidez ce que la plateforme peut enregistrer, qui peut le consulter et combien de temps le conserver. Une règle invisible pour les développeurs complique le diagnostic quand une demande est refusée ou dirigée ailleurs que prévu.

Testez le routage avant de modifier le choix par défaut

1. Choisissez deux ou trois familles de tâches fréquentes. Incluez une catégorie simple, comme la mise à jour habituelle des tests, et une plus difficile, comme une migration avec rétrocompatibilité.
2. Définissez au préalable les preuves nécessaires à l’acceptation. Il peut s’agir d’un test de régression réussi, d’un diff propre, d’une revue approuvée et de l’absence de fichiers modifiés par surprise.
3. Mesurez une référence avec le modèle actuellement utilisé par défaut. Comptez les échecs, les nouvelles tentatives et les tâches qu’un développeur termine à la main. Conservez les contraintes de sécurité et de données appliquées en production.
4. Comparez le routage sur des tâches équivalentes. Si vous avez accès au service, consultez la documentation officielle sur les outils et autorisations avant de connecter un compte.
5. Décidez quand passer à un autre modèle. Un échec au premier essai peut justifier un second modèle. Des tentatives sans limite peuvent coûter plus cher que de commencer par un modèle plus puissant. Fixez une limite et consignez la raison de chaque bascule.
6. Gardez une possibilité de dérogation pour les tâches où un mauvais résultat aurait de lourdes conséquences. Après l’essai, examinez les exceptions en même temps que le coût global et le taux d’acceptation.

Dans un pilote interne, comparez une période de choix des modèles par les développeurs à une période de routage, sur des tâches similaires. Le premier groupe peut tirer parti de sa connaissance du dépôt. Le second peut profiter d’une politique cohérente et d’une meilleure visibilité. Documentez les différences entre les tâches pour comprendre où l’automatisation aide et où le jugement humain reste utile.

Comparez les mêmes tâches dans les mêmes conditions

Un mois de pull requests terminées offre un point de départ. Classez-les d’après la demande initiale, par exemple une mise à jour de dépendance, un défaut reproductible, une modification touchant plusieurs dépôts ou une enquête ouverte sur un déploiement en échec. Sauvegardez la révision du dépôt et un critère d’acceptation pour chaque tâche. Rejouez un échantillon avec une référence stable puis avec le routeur. Gardez les mêmes outils, durées et environnements de test.

La mise à jour d’une dépendance laisse peu de place à l’interprétation. La tâche est réussie si la dépendance demandée change, si les vérifications de compatibilité passent et si la pull request ne contient aucune modification étrangère. Une tâche qui touche un contrat de facturation demande une relecture plus stricte. Des exigences incomplètes peuvent aussi nécessiter une décision humaine. Garder ces familles distinctes permet de voir d’où vient la baisse des dépenses moyennes. Si la route économique convient aux dépendances mais multiplie les tentatives sur la facturation, l’équipe peut les traiter différemment.

Mesurez le temps qu’une personne consacre à décider si le résultat est acceptable. Supposons que le système de référence donne 19 résultats acceptés sur 20 pour 19 dollars, contre 18 pour 9 dollars avec le routeur. Le coût de modèle par résultat accepté s’établirait dans cet exemple à 1 dollar et à 0,50 dollar. Si une personne passe vingt minutes de plus à réparer un échec du routeur, la comparaison évolue. L’organisation peut intégrer cette reprise en gardant des mesures distinctes pour l’argent et le temps.

Identifiez les tâches sur lesquelles le routeur a appris

Le rapport de Baseten cite DeepSWE 1.1, SWE Atlas QnA et Terminal-Bench 2.1. L’étude compare Claude Opus 5.5 et GLM 5.3 Flash, puis évalue le routeur sur des données mises de côté. Ces détails éclairent la portée du résultat. Les questions de navigation dans un dépôt ne suivent pas la même structure de coûts que les tâches qui lancent un terminal, utilisent des outils externes ou modifient plusieurs fichiers. L’essai du client doit représenter les demandes qu’il prévoit réellement d’envoyer.

Le rapport présente Cost, Balanced et Intelligence comme des réglages par requête qui déplacent le seuil de routage. Une équipe produit peut s’en servir pour effectuer une comparaison parallèle. Testez les réglages sur un ensemble fixe de requêtes autorisées et consignez le modèle choisi si l’intégration l’indique. Examinez les désaccords. Si les choix coûteux portent principalement sur des cas jugés sensibles ou difficiles, la règle peut être utile. S’ils concernent surtout une tâche simple et fréquente, il peut être pertinent d’ajuster le classement des tâches ou la règle.

Examinez les tâches les plus lentes et les plus coûteuses

La latence moyenne peut cacher l’attente liée à un correctif difficile qui est passé par plusieurs modèles. Mesurez le temps écoulé entre la demande et le résultat accepté. Signalez les nouvelles tentatives, les bascules, les délais dépassés et les transferts. Un tableau qui n’affiche que le temps de réponse du premier modèle peut montrer un gain alors qu’il a fallu relancer la tâche. Incluez les coûts et les délais qui suivent ces transferts.

Encadrez l’essai avant de l’étendre. Fixez un budget pour la tâche entière et une règle pour interrompre le traitement ou passer à un modèle plus puissant. Une tentative échouée doit laisser assez de traces pour permettre la suite. Évitez de relancer des tests ou de relire les mêmes fichiers pour la seule raison que le routeur a sélectionné un autre modèle. Ce qui compte, c’est la progression réelle du travail.

Commencez le déploiement par une famille limitée, dont l’acceptation peut être testée automatiquement et dont les exceptions peuvent être relues. Ajoutez ensuite une catégorie qui demande une appréciation humaine. Comparez séparément le coût par tâche acceptée, la part des bascules et le temps de revue. Si l’avantage persiste, l’organisation dispose de meilleures raisons de retenir un réglage par défaut.

Gardez une référence exploitable après les changements de modèle

Un résultat relevé une semaine peut devenir obsolète si un modèle, un outil ou le dépôt change. Conservez l’identifiant du modèle, la révision testée et les règles d’acceptation avec la décision de routage. Rejouez quelques tâches représentatives lorsque vous modifiez la règle. Gardez aussi quelques échecs coûteux, dont les conséquences tendent à disparaître dans les moyennes.

Demandez à une personne de relire un cas de désaccord sans lui dire quel modèle a été sélectionné. Si elle ne peut pas déterminer quel résultat est acceptable, précisez le critère d’acceptation avant de lancer d’autres essais. Il est plus simple de comparer deux règles lorsque l’équipe sait comment reconnaître une réussite.

La politique de routage doit évoluer avec le travail

Le routage rend service lorsqu’il évite à l’équipe de refaire sans cesse le même petit choix. Il devient particulièrement utile lorsqu’on mesure les performances et les prix sur la même unité de travail. Avec le temps, modèles, tarifs et dépôt évoluent. Conservez vos tâches de référence et actualisez le jeu de test pour que la politique suive ces changements.

Le chiffre à apporter à une réunion de planification est ce que l’équipe a payé pour livrer des tâches acceptées, avec une description claire des compromis. C’est une donnée sur laquelle la direction technique et la personne responsable du budget peuvent agir ensemble.

Sources

• Annonce de Baseten du 4 novembre sur l’aperçu de Grid
• Rapport technique de Baseten du 4 novembre sur le routeur

---

Pour retrouver facilement la trace des conversations et décisions liées à votre travail, créez un compte Telli.sh.