Économie de tokens : réduire le gaspillage de contexte

Si vous avez utilisé des agents de code IA pour autre chose que des tâches triviales, vous avez vu le problème : chaque nouvelle session repart de zéro. L’agent relit des fichiers qu’il a déjà analysés, oublie des conventions de projet qu’il a apprises hier, et brûle des tokens à reconstruire un contexte qu’il devrait déjà avoir.

J’ai construit loom-memory pour résoudre exactement ça. L’idée est simple : donner aux agents IA une mémoire durable pour qu’ils arrêtent de payer la taxe du démarrage à froid à chaque tâche.

Le problème : des agents amnésiques, des sessions coûteuses

La plupart des outils de code IA sont sans état entre les sessions. Même au sein d’une seule session, une fois la fenêtre de contexte pleine, l’analyse antérieure est perdue. Cela veut dire :

• Scan de fichiers répété L’agent lit les mêmes 50 fichiers pour comprendre la structure du projet à chaque fois.
• Conventions perdues Les patterns propres au projet, les règles de nommage et les décisions d’architecture s’évaporent entre les sessions.
• Gaspillage de tokens Une part importante de chaque session est dépensée juste à rétablir la compréhension de base.
• Sortie incohérente Sans mémoire persistante, l’agent peut contredire des décisions qu’il a prises plus tôt.

Sur une vraie base de code, ce n’est pas théorique. Je voyais 30 à 50 % des tokens de chaque session partir dans la reconstruction de contexte plutôt que dans le vrai travail.

La solution : une base de connaissances vivante

loom-memory transforme un dépôt Git en une base de connaissances persistante et interrogeable. Après l’initialisation, le dépôt contient :

_wiki/
  00-Index.md
  01-Architecture-Stack.md
  02-Fonctionnalites-Actuelles.md
  03-Regles-LLM.md
  04-Code-Map.md
  05-Call-Graph.md
_graph/
  codebase.db          # Graphe SQLite des fichiers, imports, symboles
AGENTS.md              # Instructions d'agent propres au projet
docs/
  decisions.md         # Décisions d'architecture accumulées
  pitfalls.md          # Pièges connus et leçons apprises

Le cœur, c’est une base de données graphe SQLite construite à partir de l’analyse statique :

• Fichiers indexés avec métadonnées de langage
• Symboles exportés et relations d’import
• Graphes d’appels de fonctions (pour TypeScript/JavaScript)
• Arêtes de contrat inter-langages via annotations
• Chunks de recherche sémantique locale pour le code et le wiki

MCP : exposer la mémoire aux agents

Le graphe n’est pas que pour les humains. loom-memory fait tourner un serveur MCP qui expose la connaissance du dépôt directement aux outils IA compatibles :

Outil	Ce qu’il fait
find_symbol	Localiser où un symbole est défini
find_dependencies	Qu’importe ce fichier ?
find_dependents	Qui importe ce fichier ?
find_callers / find_callees	Requêtes de graphe d’appels au niveau fonction
hotspots	Fichiers les plus connectés de la base de code
cross_zone_deps	Analyse des dépendances inter-modules
recent_changes	Ce qui a changé récemment
semantic_search	Recherche en langage naturel sur le code et le wiki
recommend_execution_mode	Comment aborder une tâche Renvoie quels fichiers lire, le niveau de raisonnement et le mode de sortie (patch compact contre code complet)

Ce dernier est la clé de l’économie de tokens. Au lieu que l’agent devine comment aborder une tâche, recommend_execution_mode lui dit :

1. Quels fichiers inspecter en premier fini la lecture de tout le répertoire src/
2. Quel niveau de raisonnement est nécessaire correction rapide ou changement architectural profond ?
3. Quel mode de sortie utiliser patch compact ou implémentation complète ?

Le workflow recommandé

Utilisateur : "Ajouter un flux d'e-mail de réinitialisation de mot de passe"

Agent → recommend_execution_mode("Add password reset email flow")
  → filesToInspect: ["src/auth/", "src/email/", "src/models/user.ts"]
  → reasoning: "medium"
  → outputMode: "compact_patch"

Agent → semantic_search("password reset token")
Agent → find_callers("sendEmail")
Agent → zoneSummary("src/auth/")

[Maintenant l'agent a le contexte et ne lit que 5 fichiers au lieu de 50]

Advise en action

J’ai testé la commande advise sur le dépôt anthropic-cookbook avec une vraie tâche : “Ajouter un nouveau pipeline RAG avec Pinecone”. Voici ce qu’elle a renvoyé :

{
  "task": "Add a new RAG pipeline using Pinecone",
  "taskSize": "medium",
  "risk": "low",
  "recommendedReasoning": "medium",
  "contextStrategy": "memory_first_then_targeted_reads",
  "outputMode": "recipe",
  "filesToInspect": [
    "tool_use/context_engineering/research_corpus.py",
    "tool_use/utils/visualize.py",
    "managed_agents/cma-mcp/src/server-http.ts",
    "claude_agent_sdk/site_reliability_agent/infra_setup.py",
    "managed_agents/self_hosted_sandboxes/modal/modal_sandbox_webhook.py"
  ]
}

Au lieu de scanner tout le dépôt, l’agent obtient 5 fichiers précis à inspecter. La contextStrategy est memory_first_then_targeted_reads : utiliser d’abord le graphe et la recherche sémantique, puis ne lire que les fichiers qui comptent. Le outputMode est recipe, ce qui veut dire que l’agent devrait renvoyer un plan étape par étape plutôt qu’une implémentation complète.

L’économie de tokens en pratique

J’ai lancé le benchmark intégré de loom-memory sur deux vrais projets pour mesurer l’impact réel sur les tokens. Le benchmark construit le graphe SQLite, puis compare la lecture à froid de chaque fichier à la récupération des seuls chunks de mémoire pertinents.

Test 1 : anthropic-cookbook (111 fichiers, Python/TS)

Un dépôt de taille moyenne avec 667 symboles et 378 chunks de recherche sémantique.

Métrique	Démarrage à froid	Avec loom-memory
Tokens pour lire tous les fichiers	223 780	20 598 (top 8 chunks)
Réduction	référence	90,8 %
Précision de recherche de symbole	n/a	100 % (20/20 sondages)
Fichiers indexés	111	111
Chunks de recherche disponibles	n/a	378

Test 2 : next.js (20 685 fichiers, TypeScript)

Une grande base de code de production avec 24 991 symboles et 40 558 chunks de recherche.

Métrique	Démarrage à froid	Avec loom-memory
Tokens pour lire tous les fichiers	18 137 779	1 653 818 (top 8 chunks)
Réduction	référence	90,9 %
Précision de recherche de symbole	n/a	100 % (20/20 sondages)
Fichiers indexés	20 685	20 685
Chunks de recherche disponibles	n/a	40 558

Ce que ça veut dire

Les deux projets montrent le même schéma : loom-memory réduit le coût en tokens de l’acquisition de contexte d’environ 90 %. L’agent dépense ses tokens à faire le travail au lieu de réapprendre le projet.

La métrique clé, c’est le “contrôle de compréhension” : loom-memory sonde l’index de recherche sémantique en choisissant 20 symboles au hasard et en vérifiant qu’une recherche pour chaque symbole renvoie le fichier où il est défini. Les deux projets ont obtenu 100 %. Cela veut dire que la couche mémoire pointe de façon fiable l’agent vers les bons fichiers.

Pour next.js, le coût de lecture à froid est de 18 millions de tokens. Avec loom-memory, l’agent récupère 8 chunks totalisant 1,6 million de tokens et trouve quand même chaque symbole qu’il cherche. C’est une réduction de 11× du coût en contexte tout en maintenant une précision totale sur la résolution des symboles.

Garder la mémoire à jour

La mémoire n’est utile que si elle reste à jour. loom-memory installe un hook post-commit qui :

1. Détecte quelles zones ont changé
2. Met à jour de façon incrémentale seulement les sections de wiki concernées
3. Reconstruit le graphe SQLite pour les fichiers changés
4. Met à jour AGENTS.md avec les nouvelles conventions ou pièges

Le wiki est aussi incrémental au niveau des sections. Si vous changez le module d’authentification, seule la section auth du doc d’architecture est régénérée, pas tout le wiki.

État actuel

loom-memory est un prototype alpha avec une CLI et un serveur MCP fonctionnels. Il prend en charge :

• TypeScript/JavaScript (parsing complet de l’AST)
• Python, PHP, Ruby (Tree-sitter avec repli sur regex)
• Recherche sémantique locale avec embeddings déterministes
• Estimation de coût des fournisseurs payants pour les essais à blanc
• Génération de workflows GitHub Actions

La suite : publication sur npm, tests sur plus de dépôts réels, et cadrage de la feuille de route à partir des usages réels.

Principes de conception

• Local d’abord La connaissance du dépôt vit avec le dépôt, pas dans un service cloud.
• Agnostique à la stack Fonctionne sur JS, Python, PHP, Ruby et les bases de code mixtes.
• Adapté aux petits modèles Compresse le contexte répété en cartes réutilisables et requêtes de graphe.
• Adapté aux agents Expose les faits via MCP au lieu de forcer les agents à deviner.
• Lisible par un humain La mémoire générée est utile dans un éditeur normal, pas seulement via un outil.
• Auto-amélioration Les décisions et les pièges s’accumulent à mesure que la base de code évolue.

Essayez-le

git clone https://github.com/jguillaumesio/loom-memory
cd loom-memory
npm install

# Initialiser un dépôt
node bin/cli.js init ./path/to/your/repo

# Vérifier ce qu'il a généré
node bin/cli.js status ./path/to/your/repo

# Lui demander comment aborder une tâche
node bin/cli.js advise ./path/to/your/repo "Add user notification preferences"

Le projet est open source et sur GitHub : jguillaumesio/loom-memory