Reprise du message précédent :
oui ?

J'aime bien l'idée également.
En revanche pour le moment je ne peux pas grandement aider car souvent je fais mes propres skills( why not )

J'utilise CAVEMAN au quotidien mais honnêtement je n'ai pas de mesures pour vérifier si j'y gagne réellement.

J'ai testé graphify et pour le coup je n'ai pas remarqué de gain, plutôt l'inverse même puisqu'il fallait régulièrement build/mettre à jour le graph

ajoute un bouton "offre moi une bière" dans le github

J'aimerais bien trouver un chatbot pour le faire le support de mon site, qu'on puisse adapter facilement à son propre contenu, vous pensez que ça existe en public sur github ?
 
Edit : bon, un peu tôt pour ça, on verra quand mon projet sera plus avancé, Glaude m'a gentiment dit qu'il ne fallait pas mettre l'huile avant le tournesol

drap

Oui c'est pour quoi?

et bien ça yeah je cause avec mon ollama en local.  
ce truc de fou

j'ai plus qu'à le config quelques part sur un dual nvidia.
j'avais une erreur avec openclaw, allors j'ai lancé ollama run phi3 et boum j'ai un assistant LLM qui fonctionne.

 
Pour la question sur caveman j'ai trouvé cette analyse intéressante: https://codepointer.substack.com/p/ [...] s-with-rtk
TLDR: ça fait bien ce que ça dit faire, mais selon ton usage (évidemment) en fait l'impact sur la conso/facture est.. faible.

Je n'ai pas vraiment confiance en des outils comme rtk ou caveman, je pense que le gain est nul, léger, voir négatif et que ça rajoute des contraintes et de l'incertitude sur les réponses des outils.
Il vaut mieux utiliser des outils plus performant que les verbeux classiques et savoir manager son contexte.

Ce que dit l'article
 
Attention au titre : l'article n'est pas une promo de RTK, c'est une enquête critique. L'auteur teste trois outils open-source (rtk, headroom, caveman) qui promettent de réduire la consommation de tokens LLM de 60-90 %… et démontre que dans la vraie vie le gain combiné est d'environ 3,7 % (et 0,5 % pour RTK seul).
 
RTK, c'est quoi
 
Un wrapper en ligne de commande qui intercepte les commandes shell avant exécution et compacte leur sortie avant que le modèle ne la lise.
 
- Fonctionne via un hook PreToolUse : git status devient rtk git status.
- Filtres spécialisés par type de commande (grep, git diff, git log, ls…) : déduplication, troncature, résumés.
- Exemple ls -la : 37 lignes avec permissions/propriétaire/dates → arbre compact + ligne "Summary: 23 files, 10 dirs (13 .md, 2 .json…)".
- Garde-fous : si le parsing échoue → sortie brute ; les diffs tronqués gardent un marqueur [full diff: rtk git diff --no-compact].
 
Promesses vs réalité
                                       Promesse (microbench)                                                                 Réel (replay de vraies sessions)
grep                                99 % (ex. rg registerSingleton sur VS Code : 694k → 2,4k tokens)         —
git diff                              33-99 %                                                                                         —
Part réelle de la facture.     60-90 %                                                                                         0,5 %
 
Pourquoi l'écart est énorme :
 
1 - Problème de dénominateur : la promesse divise par une seule commande ; la facture réelle se divise sur des centaines de tours.
2 - 78 % des tokens d'outils contournent RTK : ils passent par les outils natifs Read/Grep/Glob/WebFetch de Claude Code, qui n'appellent jamais le hook shell.
3 - Structure de prix : l'essentiel de la facture (42 % cache_create, 29 % output) ne touche jamais le flux de RTK ; les gains tombent sur les tokens les moins chers (cache_read, ~0,50 $/M contre 5-25 $/M).
4 - Les lectures de fichiers contiennent peu de redondance → les stratégies de dédup de RTK n'y mordent pas.
 
Risques
 
- Sécurité : le hook s'exécute sur le shell → une release compromise = exécution de commandes arbitraires, potentiellement invisible (headroom télécharge le binaire RTK automatiquement → exposition supply-chain).
- Perte de données silencieuse : la troncature peut couper un warning critique que l'agent avait demandé.
Conclusion de l'auteur : gains réels marginaux (~0,5 %) à mettre en balance avec le fait de donner à un binaire tiers un accès direct à ton shell. Pour la plupart des gens, le risque l'emporte sur le bénéfice.
 
Est-ce intéressant pour toi ?
Honnêtement, non — pas l'outil. Et c'est encore plus net dans ton cas que dans le cas générique de l'article :
 
- Tu utilises massivement les outils natifs (Read, Grep, Glob, les agents Explore/audits). Or c'est précisément ce flux (les 78 %) que RTK ne touche pas. Le gain serait encore plus proche de zéro que la moyenne.
- Sécurité : tu bosses sur une app en prod avec des PII réelles (cf. tes mémos sur les audits-secrets/PII). Greffer un binaire à hook shell téléchargé automatiquement, c'est exactement le type de dette que tes propres garde-fous (audit-secrets, audit-3rd-party, supply-chain) sont censés éviter. Mauvais ratio.
- Tu as déjà 35+ hooks PreToolUse très réglés. Ajouter un wrapper qui ré-écrit tes commandes shell crée un risque de collision/effets de bord avec ton tooling existant, pour un gain de ~0,5 %.
 
Ce qui est récupérable, en revanche, c'est l'idée — pas le produit :
 
- Préférer des grep/rg ciblés (avec -l, -c, head) plutôt que des dumps massifs — tu le fais déjà via tes agents Explore qui lisent des extraits.
- Éviter de faire avaler à l'agent des sorties verbeuses inutiles.
 
Le vrai enseignement de l'article pour toi est plutôt méthodologique : se méfier des promesses « -90 % de tokens » qui comparent une seule commande au lieu de la facture réelle. Le levier qui compte vraiment sur ta facture, c'est le cache (cache_create/cache_read) et l'output, pas la compaction de sorties shell.

Pour le gain de headroom on est largement au delà des 3.7% (je suis plus autour de 37% pour le coup).  
RTK je suis plus dubitatif parce qu'effectivement souvent les agents voient que l'output est tronqué et passe par un Read non tronqué, donc au final tu consommes plus.
 
 
 

headroom + caveman c'est vraiment le top
RTK beaucoup moins même si ça aide un petit peu mais c'est bien plus limité

url headroom ?

https://github.com/chopratejas/headroom
 
c'est intégré dans tamag0, le build avec support codex arrive

ce lobbying

abusé les artefacts claude
https://forumhfr.github.io/artifact [...] d-spacing/

grave

j'ai installé un autre assistant ollama/phi3 sur une autre machine pour comparer.
c'étrange, mais les 2 assistants n'ont pas le même comportement.
 
il y en a un : mon premier est très coopératif dans ce que je lui demande,
du genre des infos sur le sys et des commandes à tapper pour résoudre tel ou tel pb.
notamment sur openclaw...
 
le 2nd : le plus jeune essaye de me vendre des tokens de cloud alors que je lui dis qu'il tourne en local.
il arrete pas de me repeter que c'est microsoft à distance qui gère ses réponses...
 
hallucinant

 
Ha oui c'est une différence drastique là. Comment ça se fait?

peut être la façon dont le bench a été fait, c'est pas de l'usage réel au final, il a sample 500 sessions et a fait des tests dessus. Mon hypothèse c'est que comme la compression de headroom n'est pas immédiate à se construire et qu'il y a un petit temps d'apprentissage, ca doit biaiser sa méthode de mesure.