codegraph vs rtk : indexer le code ou filtrer le shell ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Cette page est le face-à-face : deux des outils gratuits les mieux construits de la catégorie, visant deux moitiés différentes de la même facture.

codegraph ou rtk : quel est le meilleur optimiseur de tokens ?

Aucun ne domine — ils couvrent des canaux différents, et c'est la répartition de votre propre trafic qui tranche. codegraph indexe votre code pour que l'agent cesse de lire des fichiers pour trouver quelque chose. rtk filtre ce que renvoient vos commandes shell avant que le modèle ne le voie. Presque rien ne se recoupe. Le seul point commun est un résultat de benchmark : sur mon benchmark ouvert de sessions longues, les deux terminent à peu près à l'équilibre — les sessions coûtent à peu près ce qu'elles coûtent sans aucun outil. Je maintiens ce benchmark et je vends un outil concurrent : lisez le mécanisme plutôt que le classement. Ici, le mécanisme explique l'égalité, et c'est la partie utile.

Que fait codegraph exactement ?

Il remplace la chasse aux fichiers par une requête. tree-sitter parse vos sources vers un graphe de connaissances SQLite FTS5 exposé en MCP, sur plus de vingt langages et quatorze frameworks. Au lieu d'ouvrir quatre fichiers pour trouver où une fonction est utilisée, l'agent interroge l'index et obtient une liste — analyse d'impact, graphe d'appels, recherche de symboles. C'est l'outil le plus facile à installer de la catégorie. Un runtime Node.js embarqué supprime la gestion de versions et les virtualenv, et l'installeur interactif détecte huit agents — Claude Code, Cursor, Codex, opencode, Hermes, Gemini, Antigravity, Kiro — et écrit lui-même leur configuration MCP. Le file watcher est débouncé et affiche une bannière d'obsolescence quand des fichiers attendent d'être réindexés, pour que l'agent sache quand sa réponse peut être en retard sur l'arbre de travail. Il publie aussi un benchmark : −35 % de coût et −71 % d'appels d'outils, en médiane sur sept dépôts. La moitié « appels d'outils » est la plus solide — elle découle mécaniquement du fait d'avoir un index, et se vérifie en une session. La moitié « coût » montre une vraie variance, dont un écart sur quatre runs sur Tokio d'après codegraph lui-même.

Que fait rtk exactement ?

Il réduit les sorties de commandes en limite de shell. Un proxy CLI en Rust avec plus de cent filtres spécifiques par commande — git, cargo, npm, pytest, docker, aws — plus un hook transparent : vous tapez vos commandes comme avant, et rtk compacte ce qui revient. L'ingénierie est serrée : un binaire, moins de 10 ms de surcoût au démarrage, aucun coût en tokens pour l'intégration elle-même, et rtk gain rapporte les économies par commande depuis un stockage SQLite. Sur les outils bavards, la réduction est forte — environ 90 % sur cargo test, environ 80 % sur les opérations git — et un DSL de filtres en TOML permet d'ajouter vos propres règles.

Pourquoi les deux finissent-ils à l'équilibre ?

Chacun couvre un canal réel qui n'est en général pas le plus gros. Pour rtk la raison est précise et documentée : le hook ne fonctionne que sur bash. Il n'intercepte pas les outils intégrés de l'agent — Read, Grep, Glob — et sur la plupart des agents ce sont eux qui portent l'essentiel des tokens. Une coupe de 90 % sur cargo test est donc réelle et porte sur une tranche de la session, tandis que la tranche la plus grosse passe intacte. Pour codegraph, c'est l'image inverse. L'index supprime les lectures de navigation, ce qui est réel, puis laisse tout le reste tranquille : pas de filtrage de sorties, donc les sorties shell bavardes arrivent en taille réelle ; recherche par mots-clés FTS5 seulement, pas de recherche sémantique ; pas de report des manifestes MCP ; pas de compression des fichiers que l'agent ouvre pour éditer. Dit brutalement : rtk possède le shell et ignore le code, codegraph possède le code et ignore le shell. Chacun est à peu près une demi-solution, et une demi-solution mesurée sur une session entière ressemble à l'équilibre.

Se composent-ils ?

Oui, proprement, et c'est la paire où cela a le plus de sens. Ils se placent à des endroits différents et aucun ne réécrit ce que l'autre a produit. Faire tourner le serveur MCP de codegraph à côté du hook shell de rtk ne crée ni interférence ni double comptage. Les coûts sont les coûts ordinaires : deux installations à maintenir, un index à garder frais, et le manifeste MCP de codegraph comme coût d'entrée permanent à chaque tour. Si vos sessions mélangent réellement du travail terminal lourd et de la navigation de code lourde, l'arbitrage est raisonnable.

Que ne fait ni l'un ni l'autre ?

Les lectures de fichiers entiers pour éditer. L'agent ouvre toujours le fichier pour le modifier. Un index lui dit lequel ; un filtre shell ne le voit jamais.
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. codegraph en ajoute un ; rtk ne touche pas à la catégorie.
L'historique de conversation. Aucun ne compresse la fenêtre, qui sur une session longue est la plus grosse accumulation.

Cette liste explique comment un outil peut être bien construit, honnête sur ses chiffres, et ne pas bouger votre facture. Ce n'est pas une critique des deux projets. C'est la différence entre optimiser un canal et optimiser une session.

Lequel choisir ?

Prenez rtk si votre journée est faite de builds, de tests, de conteneurs et de commandes d'infrastructure. L'économie sur ces blocs est immédiate et vérifiable vous-même avec rtk gain en une semaine. Sous Linux et macOS la friction est quasi nulle — il n'y a pas de support PowerShell natif sous Windows. Prenez codegraph si l'agent passe son temps à chercher des choses dans un gros dépôt, ou si vous voulez l'installation la moins friction possible à mettre devant une équipe. Le runtime embarqué et l'installeur huit-agents sont le meilleur parcours d'entrée de la catégorie. Prenez les deux si vos sessions ont réellement les deux formes. Ils se composent sans conflit, ce qui n'est pas vrai de la plupart des paires ici. Ne prenez ni l'un ni l'autre pour l'instant si vous n'avez pas mesuré la répartition. Une semaine avec ccusage ou le panneau d'usage de votre agent répond à cette comparaison mieux que n'importe quel tableau de fonctionnalités.

Comment appliquer ça aujourd'hui

Répartissez une semaine de dépense entre sorties shell et opérations sur fichiers. Ce seul ratio tranche cette page à votre place.
Si vous installez rtk, lisez rtk gain rapporté à votre total, et pas seul. Un gros pourcentage d'un petit canal reste un petit chiffre.
Si vous installez codegraph, comptez les appels d'outils avant et après. C'est la métrique qu'il déplace réellement, et celle que vous pouvez vérifier.
Regardez ce qui est connecté par ailleurs. Chaque serveur MCP inutilisé paie un loyer à chaque tour, et aucun des deux ne le rapporte.

Ce qui tourne mal (anti-patterns)

Attendre de rtk qu'il couvre les outils de fichiers de l'agent. Le hook est sur bash. Read et Grep passent à côté par conception. Attendre de codegraph qu'il aide sur une boucle de build bavarde. Il n'est pas du tout sur ce chemin. Lire un pourcentage par commande ou par dépôt comme un pourcentage par session. Les deux outils publient des chiffres honnêtes à une échelle plus petite que celle que vous payez. Installer les deux et n'en mesurer aucun. Ils se composent, mais deux économies non vérifiées ne font pas une preuve.

À lire aussi :

Réduire l'usage des tokens dans Claude Code — le pilier, indépendant de l'outil
Alternatives à codegraph — le champ autour de codegraph
Benchmark des optimiseurs de tokens — la mesure ouverte derrière les deux résultats
rtk vs graphify — rtk face à un indexeur qui ingère aussi les documents
headroom vs rtk — rtk face à un compresseur de fenêtre