LeanCTX avec Codex : retour d’expérience après presque deux mois

Bonjour à tous, depuis que j’utilise Codex directement sur mon serveur comme agent (Pwny), je me suis retrouvé avec un problème très connu : pour être vraiment badass, l’agent doit lire un grand volume d’information. Fichiers de configuration, journaux d’événements, le résultat de tests, et le même fichier est relu parfois trois fois pendant qu’on affine un projet. Tout ce texte part dans le contexte du modèle sous forme de fameux tokens, et un contexte rempli de lignes déjà vues est plus cher, plus lent, et… pas forcément plus intelligent.

J’ai donc testé LeanCTX avec Codex. Presque deux mois plus tard, j’avais assez de recul pour répondre à trois questions simples : qu’est-ce que cet outil fait réellement, est-ce qu’il m’a apporté quelque chose, et pourquoi je n’ai pas empilé un autre optimiseur comme RTK par-dessus ?

LeanCTX, c’est quoi au juste ?

Imaginez Codex comme le meilleur stagiaire que vous aurez jamais : rapide, bien informé, bosseur, etc., et à qui vous transmettez le résultat de vos commandes et les fichiers qu’il doit examiner. Sans LeanCTX, si vous lui donnez 5 000 lignes de logs pour retrouver une erreur, les 5 000 lignes arrivent dans sa todo, aka « fenêtre de travail » pour une IA. Et ce, même lorsqu’il y a 4 950 lignes répétitives et seulement trois lignes intéressantes.

LeanCTX se place entre Codex et ces lectures. Il ne modifie pas vos fichiers, n’exécute pas d’action à votre place et ne donne pas de droits en plus à l’agent. Son rôle est plus simple : quand Codex demande à lire, chercher ou lancer une commande, il essaie de lui présenter le résultat sous une forme plus utile. Un résumé de log garde les erreurs, un fichier peut être lu par structure avant d’être lu en entier, et une relecture du même fichier inchangé peut devenir une petite référence au lieu d’un second pavé identique.

En gros, c’est un filtre local pour limiter le contexte inutile, rien de magique en réalité. Si l’agent a besoin d’un morceau précis, il peut demander les lignes concernées. S’il a besoin de la sortie exacte, il peut toujours la récupérer.

Pour les curieux, Codex parle à LeanCTX via son MCP (un protocole qui ajoute des outils à l’agent). Des hooks observent aussi les commandes Bash lancées pendant une session. Mais il n’est pas nécessaire de connaître ce vocabulaire pour l’utiliser : l’idée à retenir est simplement « envoyer moins de bruit à l’agent, sans lui fermer l’accès à la preuve originale si nécessaire ».

Un exemple concret, avec et sans le filtre

Prenons une commande de logs un peu bavarde. Sans filtre, Codex demandera ce dont il a besoin et recevra potentiellement toutes les lignes. Avec LeanCTX, il reçoit d’abord les erreurs, les changements d’état et les éléments utiles pour comprendre ce qui se passe. Les centaines de lignes répétitives ne disparaissent pas de la machine, elles ne sont simplement pas poussées dans le contexte par défaut.

Le même principe vaut pour une relecture. La première lecture d’un fichier donne son contenu ou son plan. Si rien n’a changé, LeanCTX va répondre quelque chose du type « déjà lu, voici la référence », et Codex demandera une zone précise seulement si nécessaire. Dans mon test contrôlé, une lecture de 2 181 tokens est devenue une référence de 25 tokens à la relecture. Voilà le gain le plus facile à comprendre (et probablement le moins risqué).

Et si je veux absolument tout voir, tel que la commande l’a produit ? Pwny peut demander la sortie brute avec cette commande précise :

lean-ctx -c --raw "journalctl -u mon-service --since '15 minutes ago'"

Le --raw signifie ici : « ne résume rien, donne-moi la sortie originale ». C’est utile pour confirmer une heure, un identifiant, une ligne d’erreur ou tout élément qui doit être cité exactement. Et si on cherche à diagnostiquer LeanCTX lui-même, lean-ctx-off le désactive temporairement dans le shell courant. Ce n’est pas une commande du quotidien, juste la marche arrière quand il faut vérifier le filtre.

Le mode « proxy HTTP/API » de LeanCTX reste désactivé chez moi. Codex conserve donc son chemin normal vers son fournisseur (OpenAI) : LeanCTX intervient uniquement sur les outils locaux, pas sur les requêtes envoyées au modèle. J’avais déjà raconté comment Codex pouvait travailler directement sur un serveur dans ce post sur Codex en Remote SSH. LeanCTX ne remplace aucun des garde-fous décrits là-bas.

Presque deux mois de mesures, pas une promesse marketing

Le 10 octobre 2026, le tableau local de KPI LeanCTX indiquait environ 12 millions de tokens évités, 34,5 % de compression sur le trafic effectivement traité par LeanCTX, et 19 449 commandes observées. Le registre signé, plus strict, comptait 1 669 événements, une chaîne SHA-256 valide et 11,7 millions de tokens nets après déduction des relectures rebondies.

Attention au périmètre : ce n’est pas une réduction de toute ma facture IA. LeanCTX ne compte que les lectures et sorties qui passent par lui. Une commande native, une sortie brute volontaire ou le reste de la requête au modèle ne sont pas mesurés de la même manière. C’est moins vendeur qu’un gros pourcentage balancé tout seul, mais c’est beaucoup plus honnête.

Les gros contributeurs sont sans surprise les lectures de fichiers et les commandes shell. C’est cohérent avec mon usage : investigation, administration, développement, puis relecture du même fichier parce qu’on a changé d’idée entre-temps. Pour vérifier cela, vous pouvez utiliser ces commandes :

lean-ctx gain --deep
lean-ctx savings summary
lean-ctx savings verify
lean-ctx verify-cache --json

gain donne la vision pratique, savings le registre vérifiable, et verify-cache teste réellement le mécanisme de relecture. Une économie affichée sans périmètre ni test, ce n’est que du joli ASCII art.

L’optimiseur a lui aussi un coût

Ajouter LeanCTX à Codex ajoute aussi des outils à l’agent, qu’il faut décrire en consommant des tokens dans la fenêtre de contexte. C’est le prix d’entrée : avant de pouvoir demander une lecture optimisée, Codex doit savoir que cette lecture existe. Mon profil lean expose douze outils et représente 3 677 tokens fixes par session. Après comparaison avec les outils natifs déjà présents et prise en compte du cache de prompt, l’outil estime environ 160 tokens de surcoût effectif par tour dans ma configuration.

Le rapport a repéré un outil de graphe jamais utilisé et un outil d’expansion rarement appelé. J’aurais pu économiser environ 330 tokens par session en les retirant. Je ne l’ai pas fait. L’outil d’expansion est justement celui qui permet de récupérer un résultat archivé si l’on s’est montré trop agressif. Gratter quelques miettes en supprimant la sortie de secours serait une drôle de définition de l’efficacité.

Pourquoi je n’ai pas ajouté RTK

RTK est un outil concurrent qui cherche lui aussi à alléger ce qu’un agent IA reçoit, notamment autour des sorties de terminal.

Ma décision est d’abord architecturale. LeanCTX couvre déjà les lectures, les recherches, les sorties shell et le cache. Ajouter une seconde couche qui intercepte et réécrit potentiellement les mêmes sorties aurait rendu le diagnostic pénible : qui a résumé quoi, qui a masqué une ligne, qui a cassé une commande ? Pour un serveur d’administration, une seule couche mesurable et réversible est plus saine.

RTK reste donc une vraie piste de comparaison. Si une famille de commandes montre un jour des faiblesses avec LeanCTX, je pourrai faire un « test A/B » propre : même tâche, même version de Codex, même dépôt, cache froid puis cache chaud, et une seule couche active à la fois. En attendant, pas de double compression juste pour collectionner les optimiseurs.

TOON, intéressant pour les tableaux, pas pour tout le reste

Une lecture sur TOON m’a poussé à regarder le sujet. TOON, Token-Oriented Object Notation, est une façon plus compacte de représenter des données JSON. Son intérêt apparaît surtout quand on répète une même structure. Au lieu d’envoyer vingt fois les clés id et name dans vingt objets JSON, TOON peut les déclarer une fois et garder seulement les valeurs :

users[2]{id,name}:
  1,Ada
  2,Bob

Pour une liste homogène de résultats, c’est malin, lisible, et il y a moins de texte à donner au modèle. Mais TOON n’est pas un compresseur universel (comme de la poudre de licorne). Un log, un fichier Markdown et une sortie de test ne deviennent pas plus efficaces parce qu’on leur colle une extension .toon.

Mais bonne nouvelle : LeanCTX 3.9.18 détecte déjà TOON comme un format compact et le préserve tel quel au lieu de le recomprimer. J’ai vérifié ce point avec son diagnostic local. En revanche, je n’ai pas ajouté de convertisseur automatique JSON vers TOON. La spécification est encore un Working Draft et le réglage qui remodèle certains JSON verbeux reste désactivé tant qu’un cas réel, reproductible et réversible n’a pas montré un gain sans perte de lisibilité ni de fidélité.

Si vous échangez énormément de tableaux JSON uniformes avec un agent, faites un test sur vos propres données. Mesurez les tokens, puis vérifiez que le modèle répond encore correctement aux mêmes questions. Sinon, gardez JSON et votre tranquillité.

Le point sécurité qui mérite vraiment deux minutes

LeanCTX conserve localement des éléments de contexte et de cache. J’ai donc limité leur rétention, maintenu le PathJail, c’est-à-dire la limitation des lectures au projet demandé, et la détection de secrets. J’ai aussi désactivé les captures automatiques de connaissance, la synchronisation cloud, la télémétrie et le proxy. Pas de daemon LeanCTX persistant, pas de port réseau exposé, pas de dashboard lancé pour faire joli, juste un passe-plat simplifiant.

J’ai aussi désactivé explicitement la publication automatique du récapitulatif des métadonnées (qui doivent rester un choix…). Voilà la configuration minimale que je recommande de vérifier :

proxy_enabled = false
shadow_mode = false
shell_activation = "agents-only"

[gain]
auto_publish = false
leaderboard = false

[telemetry]
enabled = false

[cloud]
auto_sync = false

Avant de faire confiance aux statistiques, lancez aussi lean-ctx doctor, vérifiez les processus et les sockets, puis relisez le fichier de configuration. Les économies de tokens ne valent pas une ouverture réseau involontaire.

Mon verdict après ce retour d’expérience LeanCTX avec Codex

Pour mon usage où Codex lit, cherche et lance beaucoup de commandes Bash, LeanCTX avec Codex est très adapté. Le bénéfice mesuré est réel, la relecture de fichiers est particulièrement rentable, et le chemin brut me permet de garder la main quand un détail compte.

Le vrai bon plan n’est pas d’empiler les outils, ni de convertir tous les formats à la mode. C’est de choisir le bon outil d’optimisation de tokens et de regarder régulièrement s’il mérite encore sa place. Bref, moins de contexte jeté dans le vide, plus de vérifications, et une licorne un peu moins noyée sous les logs. Geekez bien !