Context Mode - Un serveur MCP qui réduit de 98 % la consommation de contexte de Claude Code

 (mksg.lu)
39 points par GN⁺ 2026-03-02 | 1 commentaires | Partager sur WhatsApp
  • Résout le problème des grands volumes de données brutes générés lors des appels à des outils externes, qui épuisent rapidement la fenêtre de contexte
  • Placé entre Claude Code et la sortie des outils, il compresse et filtre les données, réduisant 315 KB à 5,4 KB (98 % de réduction)
  • Grâce à une architecture sandbox, chaque exécution est isolée et seul stdout est inclus dans le contexte, ce qui empêche la fuite de données brutes comme les logs et les snapshots
  • Avec une base de connaissances fondée sur SQLite FTS5, il indexe le contenu Markdown et applique le classement BM25 et le Porter stemming pour permettre une recherche précise dans les blocs de code
  • Avec la même limite de 200K tokens, la durée des sessions passe de 30 minutes à 3 heures, permettant une gestion plus efficace du contexte pour les agents IA

Problème

  • Les appels d’outils MCP de Claude Code déversent directement les données brutes de chaque appel dans la fenêtre de contexte de 200K
    • Snapshot Playwright 56 KB, 20 issues GitHub 59 KB, logs d’accès 45 KB, etc.
    • Après environ 30 minutes d’utilisation, 40 % du contexte total est consommé
  • MCP est devenu le standard pour l’usage d’outils externes, mais il existe une limite structurelle où la définition des entrées comme les données de sortie remplissent toutes deux le contexte
  • Avec plus de 81 outils activés, 72 % (143K tokens) sont déjà consommés avant même le premier message

Architecture de Context Mode

  • Un serveur MCP placé entre Claude Code et la sortie des outils, qui transmet les données en minimisant les données brutes
    • Une sortie de 315 KB est ramenée à 5,4 KB (98 % de réduction)
  • Chaque appel execute s’exécute dans un sous-processus isolé, de manière indépendante, sans partage de mémoire ni d’état
    • Seul stdout est inclus dans le contexte ; les logs, réponses d’API, snapshots, etc. restent à l’intérieur du sandbox
  • Prise en charge de 10 runtimes de langage : JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R
    • Détection automatique de Bun, avec une exécution JS/TS 3 à 5 fois plus rapide
  • Les CLI authentifiés (gh, aws, gcloud, kubectl, docker) transmettent les identifiants de manière sûre via l’héritage des variables d’environnement

Base de connaissances (knowledge base)

  • L’outil index découpe le Markdown par heading et l’enregistre dans une table virtuelle SQLite FTS5, en conservant intact les blocs de code
  • Lors de la recherche, l’algorithme de classement BM25 calcule la pertinence à partir de la fréquence des mots, de la fréquence inverse des documents et de la normalisation de la longueur des documents
  • Grâce au Porter stemming, “running”, “runs” et “ran” sont mis en correspondance avec la même racine
  • Lors d’un appel à search, il renvoie non pas un résumé mais les blocs de code exacts et la hiérarchie des headings
  • fetch_and_index récupère une URL, convertit le HTML en Markdown puis l’indexe ; la page d’origine n’est pas incluse dans le contexte

Chiffres de performance

  • Dans 11 scénarios réels (triage de tests, diagnostic d’erreurs TypeScript, revue de git diff, etc.), la sortie reste dans tous les cas sous 1 KB
    • Snapshot Playwright : 56 KB → 299 B
    • Issues GitHub (20) : 59 KB → 1,1 KB
    • Logs d’accès (500 entrées) : 45 KB → 155 B
    • Analyse CSV (500 lignes) : 85 KB → 222 B
    • Logs Git (153 commits) : 11,6 KB → 107 B
    • Analyse de dépôt (subagent) : 986 KB → 62 KB (5 appels vs 37)
  • À l’échelle de la session complète : 315 KB → 5,4 KB, avec une durée de session passant de 30 minutes à 3 heures
  • Contexte restant après 45 minutes : 60 % auparavant → 99 %

Installation et utilisation

  • Prise en charge du hook d’auto-routing et des commandes slash via le Plugin Marketplace
  • Installation dédiée à MCP également possible
  • Utilisable immédiatement après redémarrage de Claude Code

Changements concrets

  • Sans modifier la manière d’utiliser l’outil, le hook PreToolUse route automatiquement les sorties
  • Les subagents utilisent batch_execute comme outil par défaut
  • Le subagent Bash passe à general-purpose, ce qui lui donne accès aux outils MCP
  • Résultat : la fenêtre de contexte ne se remplit plus rapidement, ce qui permet de conserver des sessions plus longues avec le même volume de tokens

Contexte de développement

  • En exploitant MCP Directory & Hub, l’auteur a constaté un schéma commun : tous les serveurs MCP déversent les données brutes dans le contexte
  • Inspiré par le Code Mode de Cloudflare, qui compressait les définitions d’outils, le projet a étendu cette approche à la compression des données de sortie
  • Après avoir confirmé qu’il permettait de travailler 6 fois plus longtemps dans une session Claude Code, le projet a été publié en open source sous licence MIT
  • GitHub : mksglu/claude-context-mode

À lire aussi

1 commentaires

 
GN⁺ 2026-03-02
Réactions sur Hacker News

  • L’approche d’index FTS5 proposée ici est correcte, mais je pense qu’il faut aller un cran plus loin
    La sortie des outils mélange des données structurées (JSON, tableaux, configuration) et du langage naturel (commentaires, messages d’erreur, docstrings), donc le BM25 pur perd en performance
    J’ai construit un moteur de recherche hybride combinant Model2Vec + sqlite-vec + FTS5 pour résoudre un problème similaire. Je fusionne les deux ensembles de résultats avec Reciprocal Rank Fusion (RRF), ce qui permet d’obtenir à la fois la correspondance exacte par mots-clés de BM25 et la correspondance sémantique de la recherche vectorielle
    L’indexation incrémentale est aussi importante. Mon indexeur ré-embed uniquement les chunks modifiés avec le flag --incremental. Réindexer l’ensemble de 15 800 fichiers prend 4 minutes, et l’incrémental quotidien moins de 10 secondes
    Côté cache aussi, cette approche est avantageuse. Pour une même requête, la sortie compressée est déterministe, donc le cache de prompt fonctionne de manière stable
    Ce que j’ajouterais à l’architecture de Context Mode, c’est d’exécuter ce même moteur de recherche dans un hook PostToolUse afin que la sortie soit compressée avant d’entrer dans la conversation

    • Le problème de l’approche de l’OP, c’est que les réponses structurées restent telles quelles, mais comme je suis en train de construire une passerelle MCP sans exécution en sandbox, cette méthode me semble très utile. Je vais essayer ça aujourd’hui
    • J’aimerais vraiment lire un article approfondi sur ce sujet. J’ai l’impression que les preneurs de notes méticuleux de HN adoreraient ça
    • J’aimerais aussi voir en détail le contexte et l’implémentation de ce travail d’indexation Obsidian

  • C’est l’auteur du post. J’ai partagé le dépôt GitHub il y a quelques jours et j’ai reçu de bons retours. Cet article est une explication de l’architecture
    L’idée clé est qu’au lieu de mettre dans la fenêtre de contexte de 200K les données brutes déversées par les appels d’outils MCP, Context Mode crée un sous-processus isolé et ne transmet que stdout au contexte. C’est purement algorithmique, sans appel LLM, avec SQLite FTS5 + BM25 + Porter stemming
    Récemment, j’ai atteint 228 étoiles et obtenu des données d’usage réelles, et j’ai compris à quel point le routage vers des sous-agents était important. Si on met automatiquement à niveau un sous-agent Bash vers un modèle généraliste pour utiliser batch_execute, on évite de remplir le contexte de sorties brutes

    • Ce serait bien d’ajouter dans l’article de blog un lien vers le post Cloudflare Code Mode. Il est dans le README, mais pas dans le corps du texte
    • C’est très intéressant et je vais essayer moi-même. En revanche, j’ai cru comprendre que Context Mode ne traite pas directement l’usage du contexte MCP lui-même ; j’aimerais confirmer si c’est bien le cas. J’utilise MCP dans plusieurs environnements Claude, donc le CLI seul a ses limites
    • Je me demande si on peut aussi l’utiliser avec d’autres agents comme Zed Agent
    • J’aimerais savoir s’il y a une raison pour laquelle Codex n’est pas pris en charge. Structurellement, ça semble indépendant de l’agent
    • Je me demande si cette approche ne casse pas le cache

  • Je ne comprends pas pourquoi ne pas utiliser le mode mcp-cli. J’en ai fait une version clonée avec wener-mcp-cli

  • Beau travail. Je pense qu’il y a encore beaucoup de marge d’amélioration sur la gestion de la fenêtre de contexte. Par exemple, si le modèle trouve la bonne réponse après plusieurs tentatives, une approche de backtracking qui retire du contexte les tentatives ratées pourrait être utile

    • Je suis d’accord. Les logs ou traces d’échec produits pendant le débogage devraient pouvoir être supprimés une fois le bug corrigé. Dans les IDE actuels, le faire à la main est fastidieux. Ce serait bien que l’agent gère lui-même son contexte, et que des choses comme les logs soient nettoyées automatiquement après un certain nombre d’itérations. Il faut voir le contexte non comme une simple pile, mais comme un espace librement manipulable
    • Les tentatives ratées finissent par n’être que du bruit. Détecter automatiquement les schémas de retry et ne garder que la dernière version réussie est tout à fait faisable
    • En ce moment, on se croirait à la fin des années 1990. À l’époque, c’était HTML et SQL ; aujourd’hui, ce sont les agents de code. Nous sommes déjà des ingénieurs expérimentés, donc en utilisant Claude Code, nous trouvons naturellement des optimisations
    • Utiliser des sous-agents est aussi une option. Quand un problème survient, on peut fork un sous-agent pour le résoudre et ne récupérer que le résultat. L’idée d’un modèle qui efface lui-même sa mémoire et revient à un état antérieur est aussi intéressante
    • C’est d’ailleurs ce que je fais en pratique. Chaque appel de tâche est exécuté dans un sous-processus séparé, ce qui ne pollue pas le contexte parent. Une fois terminé, je transmets au parent quatre éléments : le résultat, le résumé du processus, les tentatives ratées et ce que j’ai appris. La sortie des outils est enregistrée dans des fichiers, et le LLM ne lit que les parties nécessaires. Par exemple, si ça se termine par “Success!”, il suffit de lire la dernière ligne. En cas d’échec, il lit seulement le message d’erreur. J’expérimente aussi la synthèse de logs avec un modèle local avant de les transmettre à un modèle cloud. Ce n’est peut-être pas l’état de l’art, mais dans mon environnement, ça fonctionne bien

  • En lisant cet article, je me suis rendu compte que je ne comprenais pas du tout l’usage des tokens dans Claude Code, donc j’ai créé ce matin un CLI appelé claude-trace
    Il parse ~/.claude/projects/*/*.jsonl pour analyser l’usage et le coût (y compris lecture/génération de cache) par session, outil, projet et timeline
    Si Context Mode résout bien la compression des sorties, ça sert alors de couche de mesure pour visualiser la consommation avant/après les changements

    • Comme avec la question “/context?”, l’essentiel est de rendre visible où les tokens sont réellement dépensés

  • Une grande partie de la consommation de tokens peut être réduite en utilisant des applications CLI au lieu de MCP. Par exemple, GitHub CLI fait la même chose avec bien moins de tokens que MCP

  • Les hooks me semblent trop agressifs. Bloquer tous les curl/wget/WebFetch et créer un snapshot sandboxé de 56 Ko, c’est bien, mais pour un simple curl api.example.com/health où on n’a besoin que de 200 octets, c’est excessif
    Si on compresse 153 commits git en 107 octets, le modèle doit écrire un script d’extraction parfait juste pour voir les données. S’il écrit une mauvaise commande, l’information nécessaire disparaît
    Les benchmarks partent du principe que le modèle écrit toujours le bon code de synthèse, mais dans la réalité, ce n’est pas le cas

    • Je suis d’accord, c’est pourquoi j’ai retiré cette fonctionnalité

  • Ce n’est pas mal, mais il y a un risque de perte de précision et de hallucination. À cause de données incomplètes ou d’une logique d’extraction incorrecte, Claude peut tirer de mauvaises conclusions. Cela suppose que MCP soit assez intelligent pour écrire à la fois de bons scripts d’extraction et de bonnes requêtes de recherche. Je pense que la préservation de l’information est un vrai problème

  • Le taux de compression est impressionnant, mais je me demande si, avec un contexte compressé, le modèle produit toujours des sorties de même qualité. Même si on fait passer une session de 30 minutes à 3 heures, il faut que la qualité du raisonnement au bout de 2 heures reste intacte pour que ce soit pertinent
    L’économie du cache mentionnée par esafak est aussi importante. Si le prompt caching fonctionne bien, même un contexte verbeux devient en pratique quasi gratuit. Mais si la compression casse la continuité du cache, le coût peut au contraire augmenter
    Le problème plus fondamental, c’est que la plupart des outils MCP font des SELECT * et récupèrent toutes les données. C’est un problème de conception du protocole : il faut prendre en charge le résumé et le drill-down

    • Même si le cache paraît gratuit, il provoque en réalité une baisse d’attention et une baisse de vitesse. Même en réutilisant de longs préfixes, la quantité de calcul reste élevée

  • Je me demande s’il est vraiment nécessaire de mettre plus de 80 outils dans le contexte. Le contexte vaut de l’or : plus on y met d’éléments sans rapport avec le problème, plus le résultat se dégrade. Plutôt que la compression des données, une séparation par sous-agents me semble une meilleure approche

    • C’est vrai. Mais la plupart des gens ne gèrent pas directement les serveurs MCP par tâche. Il suffit souvent d’installer 5 ou 6 serveurs pour charger par défaut 80 outils. Context Mode ne résout pas l’excès de définitions d’outils. En revanche, il traite le côté sortie déversé après l’exécution des outils. Par exemple, un snapshot Playwright ou un simple git log peut à lui seul consommer 50 000 tokens, et c’est ça qu’il sandboxe