Réduire les tokens Codex sans ajouter plus de règles

En bref

Problème : mes sessions Codex brûlaient le quota plus vite que ce qui me semblait raisonnable, surtout quand un repo contenait des logs bruyants, de gros diffs, de la découverte répétée et de longs fichiers d’instructions.
Ce que j’ai testé : un workflow local Token Frugal, installé dans des copies de deux vrais repos, avec les JSONL de session Codex pour mesurer les tokens entrants, entrants mis en cache, sortants, de raisonnement, le total de tokens et un coût estimé équivalent API.
Résultat : le principe garde du sens, mais le lab n’a pas prouvé une réduction nette des tokens dans mon setup. Sur un petit repo, le prompt direct est devenu moins cher. Sur un repo plus gros et déjà très chargé en process, la couche en plus a souvent rendu la session plus coûteuse.
Leçon : avant d’ajouter des hooks, des wrappers, des agents ou plus de règles dans AGENTS.md, j’ai probablement besoin d’une V2 qui harmonise et simplifie la pile d’instructions déjà en place.

Le point de départ

Le déclencheur était une note ChatGPT très ordinaire. J’essayais de transformer une frustration vague, “Codex consomme trop vite ses tokens”, en quelque chose que je pouvais vraiment tester. Cette note est devenue un repo local que j’ai appelé Token Frugal.

J’ai eu le même réflexe que beaucoup de personnes quand un agent paraît trop coûteux : lui dire d’être plus prudent, lui demander d’être concis, ajouter une règle, ajouter un helper, ajouter un hook.

L’idée était raisonnable. Au lieu de laisser Codex lire des logs bruts, des fichiers JSON entiers, de grands arbres de fichiers, de gros diffs et les mêmes instructions de repo en boucle, je voulais installer quelques habitudes :

des lectures compactes plutôt que des dumps complets ;
des sorties de commandes bornées ;
des fichiers de handoff courts ;
des logs bruts sauvegardés localement au lieu d’être recopiés dans la conversation ;
une petite section AGENTS.md plutôt qu’un second manuel ;
des hooks qui préviennent avant les commandes bruyantes ;
une vraie mesure depuis les JSONL de session Codex plutôt qu’une estimation grossière au nombre de caractères.

En principe, je pense toujours que c’est la bonne direction. Si le modèle voit moins de contexte inutile, il devrait dépenser moins de tokens et prendre moins de décisions à partir de bruit.

Mais mon lab a rendu la conclusion moins propre.

Ce que j’ai mesuré

J’ai utilisé deux copies locales de repos.

CodexTodo est le plus petit et le plus direct. Les tâches étaient ciblées : inspecter quelques fichiers connus, lancer un test Web UI précis, résumer le doctor check et rapporter le résultat.

BannerGenerator est plus lourd. Il a déjà plus de process autour de lui : règles d’orchestration, agents, runbooks, politique de validation, conventions spécifiques au repo et consignes de sécurité. La tâche restait bornée, mais le repo portait déjà beaucoup de contexte opérationnel.

La mesure venait des JSONL de session Codex. Pour chaque run, j’ai extrait le modèle, les tokens entrants, les tokens entrants mis en cache, les tokens sortants, les tokens de raisonnement et le total de tokens. J’ai aussi calculé une estimation de prix équivalente API à partir du modèle parsé. Cette estimation est utile pour comparer, mais je ne la traite pas comme une preuve de facturation du quota ChatGPT ou Codex.

J’ai aussi séparé deux coûts qu’il est facile de mélanger :

le démarrage : installer Token Frugal dans un repo ;
l’usage récurrent : les prompts lancés après le bootstrap du repo.

Cette distinction compte. Un bootstrap peut être un investissement ponctuel. Il faut le mesurer parce que c’est du vrai travail, mais il ne faut pas le compter comme s’il se répétait à chaque tâche.

La trace détaillée n’est pas dans cet article. J’ai gardé la matrice de commandes, les identifiants de sessions, les chemins vers les sorties brutes et les tables de tokens dans le RESULTATS.md du lab. Si je publie plus tard un repo de lab public, c’est cet artefact qui devra l’accompagner. Ici, je ne garde que les chiffres nécessaires pour expliquer la leçon.

Les chiffres étaient mitigés

Le dernier run a rendu cette séparation visible.

Mesure	Total tokens	Coût estimé
Démarrage Token Frugal	1 455 983	$0.444158
Quatre prompts récurrents après démarrage	939 012	$0.229363
Référence précédente sur quatre runs	872 385	$0.237918

Le run récurrent était un peu moins cher en coût estimé, mais il utilisait plus de tokens au total. Rien que ça suffit à éviter un titre trop facile.

Le comportement repo par repo était plus utile que l’agrégat.

Sur CodexTodo, le prompt direct sur le repo bootstrappé était meilleur que la baseline précédente :

Run CodexTodo	Total tokens	Coût estimé
Baseline précédente	181 956	$0.047421
Repo bootstrappé, prompt direct	138 461	$0.033401

C’est la version de l’expérience où Token Frugal ressemblait à une aide réelle. Le repo était assez petit, la tâche assez étroite, et les consignes ont probablement réduit la découverte inutile.

Sur BannerGenerator, l’effet est allé dans l’autre sens :

Run BannerGenerator	Total tokens	Coût estimé
Baseline précédente	190 528	$0.038538
Repo bootstrappé, prompt de type traitement	270 349	$0.057467

Ce repo avait déjà trop de couches. Token Frugal ne les a pas remplacées. Il s’est posé au-dessus.

Le problème du gros repo

La leçon de BannerGenerator n’est pas que le contexte compact est mauvais. C’est que la discipline de contexte peut devenir une source de contexte en plus.

Ce repo avait déjà des instructions d’orchestrateur, des définitions d’agents, des runbooks, des règles de validation, des conventions de process et des garde-fous propres au projet. Quand Token Frugal est entré dans cet environnement, Codex avait un système de plus à comprendre avant de faire la tâche.

Dans le run de traitement, Codex a encore dépensé des tokens à apprendre la syntaxe du wrapper :

tfctx --help ;
tfctx read --help ;
tfctx test --help.

C’est exactement le coût que j’essayais d’éviter. J’avais ajouté un outil pour réduire l’exploration inutile, et le modèle a exploré l’outil.

Sur un gros repo, le coût fixe de “comment suis-je censé travailler ici ?” peut dominer les petites économies obtenues par des lectures bornées. Si les règles existantes sont déjà denses, une couche de plus peut rendre l’agent plus prudent, plus bavard, et plus tenté d’expliquer le process que de traverser la tâche.

La leçon du petit repo

CodexTodo était différent.

Le prompt direct sur le repo bootstrappé est resté concentré. Il a lu les extraits demandés, lancé le test Web UI ciblé, résumé le doctor check et conservé le signal de validation utile :

tests/test_web_ui.py: 60 passed

C’est plus proche du but initial. La surface Token Frugal a donné à Codex assez de guidage pour éviter l’exploration large, sans transformer le repo en labyrinthe.

Mais même là, le wrapper gardait un problème de qualité.

Quand une tâche du même genre est passée par tfctx test, le test Web UI a échoué :

56 failed, 4 passed

L’échec était lié au binding de sockets locales. La commande directe passait, la commande wrappée échouait. Cela veut dire que le wrapper n’était pas neutre pour cette classe de validation.

Pour moi, c’est plus important que le nombre de tokens. Un outil qui économise des tokens mais change le sens d’un test n’est pas prêt à devenir le chemin par défaut.

Ce qui s’est probablement passé

Le lab pointe vers trois causes.

D’abord, Token Frugal aide surtout quand le repo a une surface d’instructions simple. Sur CodexTodo, les consignes ont pu réduire la découverte. Sur BannerGenerator, elles se sont ajoutées à un système déjà chargé.

Ensuite, les wrappers doivent être ennuyeux. Si Codex doit apprendre le wrapper, ou si le wrapper change le comportement d’une commande, il peut dépenser plus de tokens et réduire la confiance en même temps.

Enfin, le bootstrap et l’usage récurrent sont deux questions différentes. Le bootstrap est un investissement. Il peut valoir le coup si chaque session suivante devient moins chère et plus propre. Mais les tâches récurrentes sont la vraie preuve. Dans mon dernier run, le coût estimé récurrent a un peu baissé, mais pas le total de tokens.

Ce n’est pas un résultat assez fort pour dire : “Token Frugal réduit la consommation de tokens de Codex.”

C’est assez fort pour dire : “Mesurer correctement ce problème a changé ce que je pense de la prochaine version.”

Ce que devrait probablement être la V2

Mon premier réflexe était d’ajouter des contrôles. La V2 devrait probablement supprimer et fusionner des contrôles.

Je commencerais par un audit des instructions :

ce qui doit rester dans le AGENTS.md racine ;
ce qui doit vivre dans un runbook ;
ce qui doit vivre dans un hook ;
ce qui doit vivre dans un outil ;
ce qui ne doit plus vivre nulle part.

Ensuite, je rendrais Token Frugal moins semblable à une couche de plus et plus proche d’une passe de simplification.

Le but devrait être une petite manière canonique de travailler dans un repo, pas cinq versions qui disent toutes “fais attention”. Sur un repo qui a déjà des orchestrateurs, des agents, des runbooks et une politique de validation, Token Frugal devrait sans doute commencer par harmoniser ces règles avant d’installer quoi que ce soit de nouveau.

Je rendrais aussi tfctx test conservateur :

préserver le comportement des commandes aussi fidèlement que possible ;
détecter les tests qui bindent des sockets locales ;
recommander un chemin brut ou de bypass quand le wrapping peut changer le résultat ;
garder une sortie bornée sans changer la manière dont le sous-processus s’exécute.

La version ennuyeuse est la version utile.

Ce que je garderais aujourd’hui

Je garderais tout de même plusieurs parties de l’expérience.

Je garderais les lectures bornées. Je n’ai pas besoin que Codex ingère un fichier JSON entier quand un résumé ou quelques clés répondent à la question.

Je garderais les logs bruts hors de la conversation par défaut. Sauvegarder un log complet localement et n’afficher qu’une courte fin de fichier est une bonne habitude.

Je garderais un handoff court. Il réduit la redécouverte quand une session reprend.

Je garderais la mesure d’usage depuis les JSONL. Elle donne une discussion bien meilleure que deviner à partir de la longueur du prompt ou se plaindre que le quota paraît élevé.

Et je garderais la séparation entre coût ponctuel et coût récurrent. Sans elle, les chiffres deviennent trop faciles à mal utiliser.

Ce que je ne ferais pas, c’est installer des hooks et des wrappers aveuglément dans chaque repo. Plus le repo est chargé en process, plus je demanderais d’abord : quelles règles existantes peuvent être supprimées, fusionnées ou raccourcies ?

L’échec utile

Ce n’était pas l’article que je pensais écrire.

Je suis parti d’une idée assez optimiste : réduire le contexte brut, guider Codex vers des surfaces compactes, et regarder la consommation de tokens baisser. Le lab a bien montré une partie de ça. Mais il a aussi montré que mes propres repos ont déjà accumulé beaucoup de process autour des agents.

Dans cet environnement, une couche de plus n’aide pas automatiquement.

La règle la plus utile est plus simple :

Réduire le contexte, puis simplifier les règles, puis ajouter l’outillage.

Token Frugal V1 m’a aidé à voir le problème. La V2 devrait moins chercher à faire obéir Codex à une instruction de plus, et plus à rendre les instructions existantes plus faciles à suivre.