Context Mode - Serveur MCP qui économise 98 % de la fenêtre de contexte des agents de codage IA
(github.com/mksglu)- Économise les données brutes que les appels d’outils MCP déversent dans la fenêtre de contexte, et prolonge la durée des sessions d’environ 30 minutes à ~3 heures
- Économie de contexte : isole les données brutes dans un sandbox pour les faire passer de 315 KB à 5,4 KB, soit une réduction de 98 %
- Continuité de session : enregistre et indexe tous les événements — modifications de fichiers, opérations git, tâches, erreurs, décisions utilisateur, etc. — dans SQLite+FTS5, puis les recherche avec BM25 pour assurer le suivi des événements de session et la récupération après compaction
- Penser en code : au lieu que le LLM lise directement les données, il écrit des scripts et ne renvoie que les résultats (par exemple pour compter des fonctions, il écrit le code pertinent sans consommer de contexte, puis récupère uniquement le résultat réel)
- Compression de sortie : réduction d’environ 65 à 75 % des tokens de sortie, tout en conservant la précision technique
- Prise en charge de 14 plateformes : Claude Code (marketplace de plugins), Codex CLI, Gemini CLI, Cursor, OpenCode, OpenClaw, Antigravity, etc.
- Selon le niveau des hooks propres à chaque plateforme (PreToolUse, PostToolUse, SessionStart, PreCompact), prise en charge différenciée des niveaux de continuité de session
- 11 outils MCP fournis :
ctx_execute(11 runtimes de langage),ctx_batch_execute(exécution groupée de plusieurs commandes + recherches),ctx_execute_file(traitement de fichiers en sandbox),ctx_index/ctx_search(indexation et recherche de base de connaissances via FTS5+BM25),ctx_fetch_and_index(récupération d’URL, indexation et cache TTL de 24 heures),ctx_stats/ctx_doctor/ctx_upgrade/ctx_purge/ctx_insight - Sécurité : applique à l’identique dans le sandbox MCP les paramètres
permissionsde Claude Code (patterns deny/allow), avec vérification séparée de chaque commande même lorsqu’elles sont chaînées - Exécution entièrement locale : aucune télémétrie, aucune synchronisation cloud, aucun suivi d’usage ; la base SQLite est stockée dans le répertoire personnel
- Déjà utilisé par des équipes de grandes entreprises comme Microsoft, Google, Meta, Amazon, NVIDIA, Stripe et Datadog
- Elastic License 2.0 (code source publié, fourniture d’un service hébergé interdite)
8 commentaires
J’ai l’impression que c’est effectivement perceptible. Je n’utilise que MCP et j’exclus les hooks pour l’instant.
Ça marche bien..?
Ça donne l’impression d’un mélange entre Claude mem et caveman.
On dirait qu’en ce moment, les produits et les prompts qui prétendent économiser les tokens sont à la mode. Je ne sais pas si c’est réellement efficace, cela dit.
Je pense que l’économie de tokens et l’économie de fenêtre de contexte se recoupent, sans pour autant désigner exactement la même chose.
L’économie de tokens relève d’une question de coût, tandis que l’économie de fenêtre de contexte relève de la qualité de la mémoire de travail du modèle. Si l’on injecte tels quels de gros volumes de logs ou des snapshots de DOM, non seulement le coût augmente, mais le plus gros problème est surtout que le modèle risque davantage de manquer des indices importants dans le bruit ou de s’y référer de travers.
Il semble plus juste de comprendre context-mode comme un outil qui vise moins à « utiliser moins » qu’à « contrôler ce que l’on place dans le contexte ».
Il faut distinguer l’économie de tokens de l’économie de fenêtre de contexte.
Comme ces deux notions sont souvent traitées ensemble, il est facile de les confondre.
C’est vrai, je ne sais pas si c’est vraiment concret… J’ai l’impression qu’en l’utilisant une ou deux fois de plus, ça risque plutôt de consommer encore plus de tokens…
Vrai ?