Économie de tokens

Le coût d’un pipeline agentique n’est pas un curseur à ajuster en production : c’est une contrainte de forme, décidée au moment de la conception, comme le budget mémoire ou la latence acceptable.

La thèse

Dans la littérature sur le développement produit, le coût d’un lot de travail est décidé bien avant son exécution — par la taille du lot, les dépendances, le nombre de boucles de retour. Donald Reinertsen le formule ainsi :

« The cost of queuing delays is determined by the shape of the flow, not by the speed of individual activities. » — Reinertsen, D. G., The Principles of Product Development Flow, 2009.

Appliqué à un pipeline d’agents, cette intuition se traduit directement : les tokens consommés par une exécution SKRAFT ne sont pas principalement pilotés par le contenu de la requête de l’utilisateur, mais par la forme architecturale du pipeline — combien d’agents sont instanciés, quels outils ils voient, quelle classe de modèle leur est allouée, et combien de fois le contexte doit être rechargé de zéro.

Cette forme est décidée au moment de l’écriture des agents et des skills, pas au moment de l’invocation. C’est pourquoi SKRAFT traite l’économie de tokens comme un invariant de conception — un budget, pas un espoir.

Les leviers

SKRAFT applique quatre leviers issus de la discipline Genesis pour tenir ce budget. Chaque levier agit sur une dimension distincte de la dépense.

Ces leviers ne sont pas indépendants. La discipline de cache et la classe par rôle se renforcent mutuellement : un modèle de classe basse rechargeable depuis le cache KV coûte une fraction de ce qu’un modèle de classe haute recalculé coûterait. La surface d’outils et le dispatch par scénario des paliers les plus durs bornent la surface de décision à l’intérieur de chaque tour, ce qui raccourcit la réponse et réduit la fenêtre de contexte nécessaire.

Mesures réelles

Les deux premiers leviers — discipline de cache et classe de modèle — ont été mesurés sur un run réel du pipeline SKRAFT exécuté en agentic workflow (gh-aw), via le schéma Effective Tokens (ET v0.2.0) du harness. Les chiffres ci-dessous proviennent des fichiers agent_usage.json émis par huit exécutions d’agents et de reviewers — ils ne sont pas estimés.

Discipline de cache — −42,6 % de tokens effectifs

Le taux de réussite du cache KV est stable autour de 48 % de l’entrée totale sur les huit exécutions. Le schéma ET pondère un token lu depuis le cache à 0,1× contre 1,0× pour un token recalculé — dix fois moins cher.

Le gain découle de la forme des prompts : un préfixe système stable, non réécrit entre les tours, reste éligible au cache. C’est précisément le levier que les hooks préservent côté infrastructure — un invariant tenu par du code ne déplace pas le préfixe, là où un invariant ré-injecté en prose le ferait rater.

Classe de modèle — séparation de 27×

Le même schéma applique un multiplicateur par modèle. Sur ce run, deux classes ont été observées : 9,0× pour la classe frontier (claude-sonnet-5) et 0,33× pour la classe capable (claude-haiku-4.5). À travail normalisé égal, allouer la classe capable plutôt que frontier coûte donc 9,0 / 0,33 ≈ 27× moins en tokens effectifs — ce qui fait du choix de classe le multiplicateur dominant de la dépense.

Provenance : run gh-aw SDLC sur l’issue #72 du dépôt meetup-coding-with-ai, schéma Effective Tokens v0.2.0, modèle de référence claude-sonnet-4.5.

Sans rogner la qualité

L’économie décrite ici provient exclusivement de la forme : mise en cache, classe de modèle, volume de sortie, effort alloué. Elle ne touche jamais aux mécanismes qui garantissent la fiabilité des livrables.

Cette séparation relevait de la discipline ; elle relève désormais du fait. La barre tient dans une seule skill, skraft-quality-bar, et rien ne lit de réglage pour l’abaisser : score de mutation à 100 % sur Domain et Application et 80 % sur API et Infrastructure, couverture de lignes à 100 % sur Domain et Application, les quatre lentilles adversariales sur chaque revue, la gate Gherkin, un ADR pour toute décision non triviale, Object Calisthenics sur le Domain. Chaque gate bloque. Les niveaux advisory et warning n’existent plus, pas plus que la rationale qui achetait autrefois une dérogation.

Les lentilles de revue adverse, leurs pondérations, leur protocole de synthèse et le score seuil d’acceptation sont donc hors périmètre de l’économie de tokens. Réduire le nombre de lentilles ou abaisser les seuils n’est pas un levier d’économie — c’est une dégradation de la qualité, et ce n’est plus exprimable. Pour comprendre pourquoi ces gardes-fous ne se négocient pas, voir la page La revue avant la revue.

Ce que cela coûte

Disons-le franchement : le framework n’échange plus de la rigueur contre des tokens. Le curseur de profondeur repo-wide qui faisait exactement cela — fan-out de la revue à 1, 2 ou 4 lentilles, périmètre des runs de mutation, gate Gherkin activée ou non — a été supprimé, et il était aussi le gouverneur de coût du pipeline. Chaque run paie désormais la forme complète : quatre lentilles à chaque revue, les deux runs de mutation séquencés, la gate Gherkin toujours active. C’est une hausse réelle et permanente du coût plancher d’un run, que rien ne compense côté qualité. Le propriétaire du dépôt a accepté l’arbitrage délibérément : la qualité ne se négocie pas, et un curseur qui permet à un run d’acheter son passage sous la barre n’est pas une économie — c’est un défaut différé.

Ce qui reste — et c’est la plus grosse moitié de la dépense — ce sont les leviers de forme : classe de modèle, discipline de cache, surface d’outils, volume de sortie. La distinction est importante en pratique : quand un run dépasse un budget de tokens estimé, la première question n’est pas « quels reviewers désactiver ? » — cette question n’a plus de réponse — mais « quel levier de forme n’est pas encore appliqué ? ».

Ce qui est en place — ce qui arrive

En place

La classe de modèle est réellement appliquée : un résolveur déterministe (plugins/skraft-framework/src/, Clean Architecture, zéro dépendance) lit le cost_role_class et le plancher model_requirement de chaque agent, puis pinne le champ model: de son descripteur .md au modèle concret résolu. Le tableau de la section « Mesures réelles » décrit la politique : reviewer → claude-haiku-4.5, implementer → claude-sonnet-4.5, planner → claude-sonnet-5, le plancher Sonnet relevant les deux exceptions (software-engineer, software-engineer-reviewer). Une seule source de vérité ; un linter CI (resolve-model --check) échoue si un agent dérive de la politique. Avec la discipline de cache, ce résolveur constitue le gouverneur principal de la dépense à l’heure actuelle — et désormais le seul : le curseur de profondeur qui partageait ce rôle a été supprimé, si bien que le versant qualité d’un run est un coût fixe et non plus une variable. La gate de mutation l’illustre : chaque adaptateur quality-gates-<tech> embarque deux scripts séquencés, core (Domain, Application) puis boundary (API, Infrastructure), chacun portant sa valeur attendue jusqu’au --break-at du runner, de sorte que le code de sortie fait le verdict. Les deux tournent, à chaque fois.

Conçu, pas encore implémenté

Le plus grand levier encore non activé est le schéma de verdict hors-LLM : faire rendre les verdicts de revue dans un format structuré (JSON), puis les transformer en rapport Markdown par un moteur de template — sans passer par le modèle pour la mise en forme. Ce rendu est aujourd’hui encore confié au LLM, ce qui représente une taxe non négligeable sur la sortie des reviewers (estimé). Ce levier est conçu ; son implémentation n’est pas encore dans le pipeline principal.

Voir aussi

• Concepts clés — phases, agents, gates, artefacts
• Architecture — comment les agents s’assemblent
• Le substrat HVE-Core — le socle sur lequel SKRAFT s’appuie
• La revue avant la revue — pourquoi les lentilles ne se négocient pas
• Référence : patterns — le catalogue complet des motifs Genesis

Sources

« The cost of queuing delays is determined by the shape of the flow, not by the speed of individual activities. » — Reinertsen, D. G., The Principles of Product Development Flow, 2009.