graphify vs token-optimizer : le projet ou le fichier ?

Fait partie du pilier réduire l'usage des tokens dans Claude Code. Les deux remplacent du contenu par une carte de ce contenu ; ils diffèrent par l'échelle, le moment et l'entretien.

graphify ou token-optimizer : lequel choisir ?

token-optimizer si vos tokens partent dans la lecture de fichiers ; graphify s'ils partent dans la recherche à travers un projet qui n'est pas que du code — et la licence décide si le premier vous est seulement accessible. graphify indexe tout le projet une fois — code, documentation, PDF, images, vidéo — dans un graphe interrogeable que vous relancez à mesure que les choses changent. token-optimizer produit une carte de structure d'un seul fichier au moment où l'agent en a besoin : 180K tokens deviennent environ 250. token-optimizer est en PolyForm Noncommercial : gratuit à titre personnel et en petite équipe, licence payante pour l'usage commercial. graphify est en MIT. Réglez cela d'abord s'il s'agit de travail d'entreprise. Aucun des deux n'a de résultat positif sur mon benchmark ouvert de sessions longues — graphify n'y montre aucune économie de session mesurable, token-optimizer n'y est pas passé du tout. Je maintiens ce benchmark et je vends un outil concurrent.

Que fait graphify exactement ?

Une carte de tout, construite à l'avance. Python, licence MIT, depuis PyPI, invoqué par /graphify sur Claude Code, Codex, opencode, Cursor, Copilot, Aider, OpenClaw et d'autres. Son différenciateur, c'est la portée : documentation, PDF, images et vidéo à côté des sources. Rien d'autre dans la catégorie n'ingère les actifs non-code, et dans les projets où un document de conception ou une passation enregistrée détient la réponse, c'est un vrai manque comblé. Il laisse un artefact persistant et inspectable — graph.json, une vue HTML, un rapport Markdown — donc le graphe est interrogeable plus tard sans relire le dépôt, et un humain peut l'auditer au lieu de lui faire confiance à l'aveugle. Ses coûts : l'indexation est explicite et doit être relancée à mesure que le projet bouge, un graphe périmé induit en erreur en silence plutôt que d'échouer bruyamment, il exige un runtime Python, et il est opt-in : il n'est consulté que si quelque chose y conduit la session.

Que fait token-optimizer exactement ?

Une petite carte d'un fichier, construite au moment de l'usage — plus trois autres couches :

Les cartes de structure AST. 180K tokens vers environ 250 : signatures, symboles, forme. 95–99 % de compression sur la charge qui fait le plus mal, et ça marche parce que l'agent a en général besoin de savoir ce qu'il y a dans un fichier plutôt que de le lire.
La compaction intelligente à checkpoints progressifs, qui condense l'état de session à mesure qu'il grossit.
Un score de qualité à 7 signaux, qui guette la dégradation du contexte en cours de session. Presque rien d'autre ici ne modélise cela.
Un tableau de bord HTML complet : coûts par tour, mix de modèles, analyse du cache, répartition par sous-agent, détection de dérive.

Il tourne sur Claude Code, OpenCode, OpenClaw et Codex, avec une installation plus lourde ailleurs, une forte dépendance Python locale, et aucune API transparente pour des intégrations tierces.

À l'avance contre au moment de l'usage

C'est le vrai axe, et il décide de la charge d'entretien. Un graphe de projet est construit une fois et consommé plusieurs fois, ce qui est efficace — jusqu'à ce que le projet bouge. Il est alors faux, et faux en silence. Tout utilisateur de graphify doit finir par répondre à « quand est-ce reconstruit », et la réponse honnête doit être un événement plutôt qu'une intention. Une carte de structure par fichier n'a pas ce problème. Elle est générée depuis le fichier tel qu'il existe à cet instant : elle ne peut pas être périmée. Le compromis, c'est qu'elle est recalculée plutôt que réutilisée, et qu'elle ne dit rien à l'agent des fichiers qu'il n'a pas ouverts. Cette différence correspond directement à leurs usages. graphify répond à « où est-ce et pourquoi », sur du matériel qui n'est pas que du code. token-optimizer répond à « qu'y a-t-il dans ce fichier », à bas coût, à chaque fois.

Se composent-ils ?

Oui, et l'association est cohérente : l'un trouve, l'autre réduit. graphify ramène un gros projet au bon fichier ou au bon document ; token-optimizer rend la lecture de ce fichier bon marché. Aucun ne fait l'étape de l'autre et il n'y a pas d'interférence. Les coûts sont les coûts ordinaires plus un propre à cette paire : deux installations Python. Les deux portent une dépendance Python locale, ce qui vaut la peine d'être su si vous en choisissiez un en partie pour éviter la gestion de runtime — aucun ne vous aide là-dessus.

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

Les sorties de commandes en limite d'outil. graphify n'est pas sur ce chemin ; la compaction de token-optimizer est au niveau session, pas un filtre par commande.
Les manifestes MCP. Aucun ne les diffère.
Les relectures. Une carte de structure rend chaque lecture plus petite ; un graphe réduit la probabilité d'une lecture. Aucun ne déduplique.
L'historique de conversation. Aucun ne compresse la fenêtre à mesure qu'elle s'accumule.

Lequel choisir ?

Réglez la licence en premier s'il s'agit de travail commercial. PolyForm Noncommercial implique une licence payante, et c'est la seule décision irréversible de cette page. Prenez token-optimizer si vous êtes un individu ou une petite équipe sous Claude Code et que les lectures de gros fichiers dominent. La carte de structure est le mécanisme unique le plus fort d'ici, et elle ne périme jamais. Prenez graphify si la connaissance de votre projet est répartie dans des documents que l'agent ne peut pas atteindre autrement, et que vous êtes prêt à rattacher la réindexation à un événement. Prenez les deux si la licence le permet et que vos sessions cherchent autant qu'elles lisent.

Comment appliquer ça aujourd'hui

Réglez la question de licence. Deux minutes, et irréversible si vous vous trompez à l'échelle.
Demandez-vous où partent vos tokens : chercher, ou lire ? Cette seule question sépare nettement les deux.
Si vous prenez graphify, décidez du déclencheur de réindexation avant d'en dépendre — un changement de branche, un passage quotidien.
Trouvez vos plus grosses lectures de fichiers. Si une poignée de gros fichiers domine, la carte de structure est le changement le plus rentable disponible.

Ce qui tourne mal (anti-patterns)

Déployer en entreprise un outil sous licence non commerciale. L'erreur la plus coûteuse ici, et sans rapport avec les tokens. Faire confiance à un graphe périmé. Une réponse fausse mais assurée coûte plus cher que pas de réponse, et graphify ne prévient pas. Installer un graphe opt-in et ne jamais l'invoquer. Indexation gaspillée, qui ressemble en tout point à un outil cassé. Lire 180K vers 250 comme une réduction de facture. Compression honnête sur une charge, à un périmètre plus petit que votre facture.

À lire aussi :