Aller au contenu
Dispatch

Budget d'agents : ton garde-fou peut mentir

Sébastien Giband · Dev Symfony/TypeScript · terminal-first ·
PHP/Symfony TypeScript/React terminal-first pi omp OpenCode Go

TL;DR

Un garde-fou local peut autoriser une tâche que le serveur coupera avant son seuil d'alerte. Réconcilie les fenêtres serveur, les plafonds par modèle et la valorisation locale avant de lui faire confiance. Les relevés de septembre montrent pourquoi un catalogue périmé suffit à casser cette protection.

budget opencode-go inference-cost coding-agents model-routing

Le 10 septembre 2026, mon garde-fou de budget pour les agents de code autorisait encore GPT 5.6 Luna jusqu’à 6 $ sur cinq heures. Le plafond publié pour ce modèle était de 3 $. Le serveur pouvait donc couper la tâche avant que l’alerte locale arrive. Le script tournait ; sa protection reposait sur une valeur fausse.

Le même relevé a trouvé grok-4.5 retiré du catalogue, alors qu’il occupait encore le rôle de review profonde. Les appels directs renvoyaient 400 Model is unavailable. Un budget disponible pour un modèle indisponible ne permet aucune review.

Ces observations personnelles datent des 4 et 10 septembre 2026, avec omp v18.1.17 pour le relevé du 10. Elles n’ont pas été rejouées le 8 octobre. La documentation publique Go est évolutive : les montants historiques ci-dessous ne constituent pas un tarif actuel.

Quel montant surveille ton compteur ?

Les dollars du quota représentent une valorisation des tokens consommés aux tarifs du catalogue. Ils ne donnent pas la facture de l’abonnement. Un seuil de 3 $ sur cinq heures exprime une capacité d’usage ; il ne signifie pas que trois dollars seront débités en plus.

La documentation Go publie des plafonds mensuels par modèle et des fenêtres à 20 % sur cinq heures, 50 % sur une semaine, 100 % sur le mois. Au relevé du 10 septembre, 15 $ mensuels donnaient donc 3 $ sur cinq heures. L’ancien agrégat local à 12 $/5 h ne suffisait plus à décider si Luna pouvait partir.

Ce que ça coûte

Prix relevés le

Luna : ancien seuil local Seuil historique incorrect, exprimé en valorisation API.
6 $ / 5 h
Luna : plafond publié relevé 20 % de 15 $ mensuels de quota. Aucun de ces montants n'est le prix de l'abonnement.
3 $ / 5 h

Le catalogue de prix avait aussi dérivé. Pour DeepSeek V4 Pro, mon estimation utilisait 0,435 $ en entrée et 0,87 $ en sortie par million de tokens, des prix MiMo. Le relevé du 10 septembre donnait 0,66 $ et 1,98 $ hors pointe. Une fenêtre correctement filtrée avec le mauvais prix reste un mauvais calcul de coût d’inférence .

La fenêtre serveur et le détail local

Au 10 septembre, omp usage exposait les fenêtres serveur, avec usedFraction et resetsAt. La commande publique dans omp v18.1.17 prévoit aussi une sortie JSON :

omp usage
omp usage --json

Le relevé affichait 0 % sur cinq heures, 1 % sur sept jours et 44 % sur le mois. Mon scan local ne retrouvait que 5,89 $ sur le cycle du 26 août au 10 septembre. Les sessions d’une autre machine et les appels non persistés échappaient à ce scan. Seule la télémétrie serveur donnait l’usage global réel du compte.

Le script personnel model-budget gardait une autre utilité : attribuer la consommation aux modèles dans les sessions pi et omp présentes sur la machine, puis estimer une review. Son détail est local et son estimation dépend des prix enregistrés. Il ne reconstruit pas la consommation absente et ne remplace pas les fenêtres serveur.

Un feu vert utile porte une date

La méthode proposée consiste à rapprocher ces lectures avant une tâche longue. Commence par la fenêtre serveur et son reset, puis vérifie le plafond du modèle dans la documentation. Compare enfin ce plafond à la consommation locale attribuable et à l’estimation de la tâche. Une discordance laisse le budget disponible incertain ; elle mérite un arbitrage manuel.

Dans mon outillage personnel, les commandes existantes permettent cette dernière lecture :

model-budget report
model-budget check gpt-5.6-luna
model-budget estimate --depth deep

Ces commandes décrivent le script relevé en septembre, pas une fonction native de Go. Elles n’automatisent pas la réconciliation serveur. Pour rendre ton propre garde-fou relisible, conserve avec ses seuils la date du catalogue et la version du harnais. Après un changement de modèle, vérifie aussi les chaînes de routage et de repli : le remplacement de Grok concernait plusieurs entrées.

Ce qui restait incertain

La review du garde-fou lui-même avait trouvé des bugs de comptage, un cache périmé et une bande d’alerte inatteignable. Cinq rounds, le 8 août, représentaient environ 1 $ de valorisation API :

Ce que ça coûte

Prix relevés le

Review du garde-fou, cinq rounds Consommation historique documentée. Ce montant n'est ni une facture supplémentaire ni un tarif de review garanti.
~1 $ de valorisation API

Guidelines vs guardrails défend une contrainte appliquée. Ici, son efficacité dépend aussi des données qui l’alimentent. Le harnais est une ligne de budget traite déjà son entretien ; le problème présent est la validité du feu vert.

Le guide de layering reste utile pour affecter les rôles, avec ses chiffres de juillet à lire comme historiques. Pour l’arbitrage de coût, le guide d’optimisation complète la méthode. Aucun résultat après recalibrage n’est mesuré ici. Tu peux commencer par dater tes seuils et confronter une tâche prévue à la fenêtre serveur : si les lectures divergent, ton compteur local doit rester une estimation.

Aller plus loin