rtk vs graphify : deux bouts du même problème

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page est le face-à-face, et la version courte est que ces deux outils ne se concurrencent pas vraiment.

rtk ou graphify : lequel choisir ?

Ils interceptent des canaux différents, donc la réponse honnête dépend de l'endroit où partent réellement vos tokens. rtk se place sur le shell et réduit ce que renvoient les commandes. graphify se place sur votre projet et en construit une carte interrogeable, documentation, PDF, images et vidéos comprises — ce que les outils de code ignorent d'ordinaire. Si vos sessions sont dominées par cargo test et docker build, rtk touche votre problème et graphify non. Si elles sont dominées par un agent qui fouille un projet volumineux et riche en documents, c'est l'inverse. Je maintiens un benchmark ouvert des optimiseurs de tokens et je vends un outil concurrent : lisez le mécanisme plutôt que le classement. Sur ce benchmark, aucun des deux n'affiche d'économie de coût mesurable par rapport à ne rien faire, et les raisons diffèrent assez pour valoir la distinction.

Que fait rtk exactement ?

C'est un proxy CLI en Rust qui filtre les sorties de commandes avant qu'elles n'atteignent le modèle. Vous tapez git status, cargo build, pytest ; rtk intercepte, retire ce dont un modèle de langage ne tire rien, et transmet une version compactée. Plus de cent filtres spécifiques par commande — git, cargo, npm, pytest, docker, aws — plus un hook qui intercepte automatiquement, sans changer votre façon de taper. L'ingénierie est réellement bonne : un binaire unique, moins de 10 ms de démarrage, aucun coût en tokens pour l'intégration elle-même, et rtk gain rapporte ce qui a été économisé par commande. Sur les outils bavards, la réduction est forte et facile à constater — environ 90 % sur cargo test, environ 80 % sur les opérations git. Ses limites sont structurelles :

Le hook ne couvre que bash. Il ne touche pas aux outils intégrés de l'agent — Read, Grep, Glob — et dans une session agentique typique, ce sont eux qui portent l'essentiel des tokens. C'est la raison principale pour laquelle une grosse économie par commande ne devient pas une grosse économie par session.
Filtrage de sorties uniquement. Pas de recherche, pas de compression structurelle des fichiers sources, pas de report des manifestes MCP.
Pas de PowerShell natif sous Windows.
Installation manuelle via brew, curl ou cargo, plutôt qu'une détection automatique par agent.

Que fait graphify exactement ?

Il cartographie tout le projet dans un graphe de connaissances, pour que l'agent interroge le graphe au lieu de grepper des fichiers. Python, licence MIT, installable depuis PyPI, invoqué par une commande /graphify sur un large éventail d'agents — Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw et d'autres. Sa particularité, c'est la couverture. La plupart des outils de la catégorie indexent le code source et s'arrêtent là. graphify ingère aussi la documentation, les PDF, les images et la vidéo, ce qui compte dans les projets où la réponse à « pourquoi est-ce fait comme ça » vit dans un document de conception et non dans une fonction. Deux autres points à connaître :

Il produit un artefact persistant. graph.json, plus une vue HTML et un rapport Markdown. Le graphe peut être interrogé plus tard sans relire le dépôt, et la vue HTML permet à un humain d'auditer l'index au lieu de lui faire confiance à l'aveugle.
L'indexation est une étape explicite. Vous la relancez à mesure que le projet bouge. C'est le revers de l'artefact : un graphe périmé n'échoue pas bruyamment, il induit en erreur en silence.

Pourquoi les deux finissent-ils à l'équilibre sur une session longue ?

Pour des raisons différentes, et c'est la différence qui est utile. rtk y finit parce qu'il optimise un canal réel qui n'est en général pas le plus gros. Retirer 90 % de cargo test est une vraie économie sur une ligne qui peut ne représenter qu'une petite fraction de la session. Le reste — lectures de fichiers, relectures, manifestes d'outils, historique de conversation — passe intact. graphify y finit parce qu'un flux « interroger le graphe » ne paie que si l'agent l'emprunte. Une commande slash est opt-in par conception : l'agent ne consulte pas le graphe si rien dans la session ne l'y conduit, et la passe d'indexation a elle-même un coût. Ajoutez un graphe qui a dérivé par rapport à l'arbre de travail, et l'agent peut dépenser des tokens à réconcilier les deux. Aucun de ces résultats n'est un verdict sur l'ingénierie. C'est une affirmation sur la part d'une session entière que chacun est en position d'affecter.

Se composent-ils ?

Oui, et c'est la paire où composer a le plus de sens. Ils se placent à des endroits différents et aucun ne réécrit ce que l'autre a produit : rtk travaille en limite de shell, graphify travaille sur un index préconstruit que l'agent interroge. Faire tourner les deux est cohérent, là où faire tourner deux index de code ne l'est pas. Le coût est honnête — un runtime Python et un binaire Rust à maintenir installés, et un index de plus à garder frais — mais il n'y a aucune interférence entre eux.

Ce qu'aucun des deux ne couvre

Les lectures de fichiers entiers, les relectures et les manifestes MCP.

Les lectures de fichiers entiers. L'agent ouvre un fichier de 2 000 lignes pour en modifier quatre, et les 1 996 autres sont facturées. graphify lui dit quel fichier ; rtk ne voit jamais la lecture, parce que ce n'est pas une commande shell.
Les relectures. Le même fichier entrant quatre fois en contexte dans une session coûte quatre fois. Aucun des deux ne déduplique.
Les manifestes MCP. Chaque serveur connecté envoie ses définitions d'outils avant votre premier message, utilisées ou non. C'est un coût permanent à chaque tour, et il est invisible dans les rapports des deux outils.

C'est ce manque qui fait diverger économie par commande et économie par session, et c'est pourquoi un outil peut être bien construit, honnête sur ses chiffres, et ne pas bouger votre facture.

Lequel choisir ?

Prenez rtk si votre journée est dominée par le terminal : builds, tests, conteneurs, commandes d'infrastructure. L'économie sur ces blocs précis est réelle, immédiate et mesurable avec rtk gain. Sous Linux et macOS, la friction est quasi nulle. Prenez graphify si la connaissance de votre projet n'est pas toute dans les sources — documents d'architecture, spécifications, enregistrements de passation, PDF d'un prestataire. Rien d'autre dans la catégorie n'ingère cela, et un agent capable de les interroger arrête de vous solliciter. Ne prenez ni l'un ni l'autre pour l'instant si vous n'avez pas mesuré où partent vos tokens. Une semaine avec ccusage ou le panneau d'usage de votre agent vous dira si votre dépense est en sorties shell, en lectures de fichiers ou en historique de conversation — et ces trois-là désignent trois outils différents.

Comment appliquer ça aujourd'hui

Répartissez la dépense d'une session entre sorties shell et lectures de fichiers. Ce seul ratio tranche la comparaison à votre place, et aucune comparaison de fonctionnalités ne le remplace.
Si vous installez rtk, lisez rtk gain au bout d'une semaine et rapportez l'économie à votre total. Un gros pourcentage sur un petit canal reste un petit chiffre.
Si vous installez graphify, décidez quand l'index est reconstruit avant d'en dépendre. Rattachez-le à quelque chose — un changement de branche, un passage quotidien — plutôt qu'à votre mémoire.
Auditez ce qui est connecté. Chaque serveur MCP inutilisé paie un loyer à chaque tour, et aucun des deux outils ne vous le dira.

Ce qui tourne mal (anti-patterns)

Lire un pourcentage par commande comme un pourcentage par session. −90 % sur cargo test est vrai, et ce n'est pas −90 % sur votre facture. Faire confiance à un graphe périmé. L'index de graphify est explicite. Quand il dérive, l'agent donne des réponses fausses avec assurance, ce qui coûte plus cher que pas d'index du tout. Attendre de rtk qu'il couvre les outils propres de l'agent. Le hook est sur bash. Read et Grep passent à côté, et c'est là qu'est le volume sur la plupart des agents. Installer les deux et n'en mesurer aucun. Ils se composent, mais deux outils aux économies non vérifiées ne constituent pas une meilleure preuve qu'un seul.

À lire aussi :