Context Mode - el servidor MCP que reduce en 98% el consumo de contexto de Claude Code

• Resuelve el problema de que grandes volúmenes de datos sin procesar consumen rápidamente la ventana de contexto al llamar herramientas externas
• Se ubica entre Claude Code y la salida de las herramientas para comprimir y filtrar datos, reduciendo 315 KB a 5.4 KB (98% menos)
• Mediante una arquitectura de sandbox, aísla cada ejecución e incluye solo stdout en el contexto, bloqueando la filtración de datos originales como logs y snapshots
• Con una base de conocimiento basada en SQLite FTS5, indexa contenido Markdown y aplica ranking BM25 y Porter stemming para permitir búsquedas precisas de bloques de código
• Con el mismo límite de 200K tokens, la duración de la sesión pasa de 30 minutos a 3 horas, lo que permite una gestión de contexto más eficiente para agentes de IA

---

Problema

• Las llamadas a herramientas MCP de Claude Code vuelcan datos sin procesar directamente en la ventana de contexto de 200K en cada llamada
  • Snapshot de Playwright: 56 KB, 20 issues de GitHub: 59 KB, logs de acceso: 45 KB, etc.
  • Tras unos 30 minutos de uso, se consume el 40% del contexto total
• MCP se convirtió en el estándar para usar herramientas externas, pero existe una limitación estructural en la que tanto las definiciones de entrada como los datos de salida llenan el contexto
• Con más de 81 herramientas activadas, ya se había consumido el 72% (143K tokens) incluso antes del primer mensaje

Estructura de Context Mode

• Es un servidor MCP ubicado entre Claude Code y la salida de las herramientas, que entrega los datos minimizando la información sin procesar
  • Una salida de 315 KB se reduce a 5.4 KB (98% menos)
• Cada llamada a execute se ejecuta en un subproceso aislado, por lo que opera de forma independiente sin compartir memoria ni estado
  • Solo stdout se incluye en el contexto, mientras que logs, respuestas de API, snapshots, etc. permanecen dentro del sandbox
• Soporta 10 runtimes de lenguaje: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl y R
  • La detección automática de Bun mejora la velocidad de ejecución de JS/TS entre 3 y 5 veces
• Los CLI autenticados (gh, aws, gcloud, kubectl, docker) transfieren credenciales de forma segura mediante herencia de variables de entorno

Base de conocimiento (knowledge base)

• La herramienta index divide Markdown por encabezados y lo guarda en una tabla virtual SQLite FTS5 manteniendo intactos los bloques de código
• Al buscar, usa el algoritmo de ranking BM25 para calcular relevancia con base en frecuencia de palabras, frecuencia inversa de documento y normalización de longitud del documento
• Aplica Porter stemming, de modo que “running”, “runs” y “ran” coinciden con la misma raíz
• En las llamadas a search, devuelve bloques de código exactos y la jerarquía de encabezados, no resúmenes
• fetch_and_index obtiene una URL, convierte HTML a Markdown y luego lo indexa; la página original no se incluye en el contexto

Métricas de rendimiento

• En 11 escenarios reales (triaje de pruebas, diagnóstico de errores de TypeScript, revisión de git diff, etc.), toda la salida se mantuvo por debajo de 1 KB
  • Snapshot de Playwright: 56 KB → 299 B
  • Issues de GitHub (20): 59 KB → 1.1 KB
  • Logs de acceso (500 entradas): 45 KB → 155 B
  • Análisis de CSV (500 filas): 85 KB → 222 B
  • Log de Git (153 commits): 11.6 KB → 107 B
  • Investigación de repositorio (subagent): 986 KB → 62 KB (5 llamadas vs 37)
• A nivel de sesión completa, se reduce de 315 KB a 5.4 KB, y la duración de la sesión pasa de 30 minutos a 3 horas
• Contexto restante después de 45 minutos: de 60% a 99%

Instalación y uso

• Soporta hooks de enrutamiento automático y comandos slash mediante Plugin Marketplace
• También puede instalarse solo para MCP
• Queda listo para usar inmediatamente después de reiniciar Claude Code

Cambios en la práctica

• Sin cambiar la forma de uso, el hook PreToolUse enruta automáticamente la salida
• Los subagentes usan batch_execute como herramienta predeterminada
• El subagente Bash se actualizó a general-purpose, con acceso a herramientas MCP
• Como resultado, la ventana de contexto deja de llenarse rápidamente, lo que permite sesiones más largas con la misma cantidad de tokens

Antecedentes del desarrollo

• Mientras operaban MCP Directory & Hub, descubrieron un patrón común en el que todos los servidores MCP volcaban datos sin procesar en el contexto
• Inspirado en Code Mode de Cloudflare, que comprimía definiciones de herramientas, se amplió la idea hacia la compresión de datos de salida
• Tras comprobar que permitía trabajar 6 veces más tiempo en sesiones de Claude Code, lo publicaron como open source bajo licencia MIT
• GitHub: mksglu/claude-context-mode

[GN⁺]

Opiniones en Hacker News

• El enfoque de indexación con FTS5 propuesto aquí es correcto, pero creo que hay que ir un paso más allá
  La salida de las herramientas mezcla datos estructurados (JSON, tablas, configuración) y lenguaje natural (comentarios, mensajes de error, docstrings), así que BM25 puro rinde mal
  Para resolver un problema similar, construí un buscador híbrido que combina Model2Vec + sqlite-vec + FTS5. Fusiono ambos resultados con Reciprocal Rank Fusion (RRF), así obtengo al mismo tiempo el emparejamiento exacto por palabras clave de BM25 y el emparejamiento semántico de la búsqueda vectorial
  El indexado incremental también es importante. Mi indexador vuelve a generar embeddings solo para los chunks modificados con la bandera --incremental. Reindexar los 15,800 archivos completos toma 4 minutos, y el incremental diario menos de 10 segundos
  Desde el punto de vista del caché, este enfoque también tiene ventajas. Para la misma consulta, la salida comprimida es determinista, así que el caché de prompts funciona de manera estable
  Algo más que añadiría a la arquitectura de Context Mode es ejecutar el mismo buscador como hook de PostToolUse para que la salida se comprima antes de entrar en la conversación

  • El problema en el enfoque del OP era que las respuestas estructuradas quedaban intactas, pero como yo estoy construyendo un gateway MCP donde no se puede ejecutar sandbox, este método me parece muy útil. Planeo probarlo hoy mismo
  • Definitivamente me gustaría leer un artículo más profundo sobre esto. Creo que a los minuciosos tomadores de notas de HN les encantaría
  • Yo también quiero ver en detalle el contexto y el proceso de implementación de este trabajo de indexación en Obsidian

• Soy el autor del post. Hace unos días compartí el repositorio en GitHub y recibí muy buenos comentarios. Este artículo es la explicación de la arquitectura
  La idea central es que, en vez de meter en la ventana de contexto de 200K los datos en bruto que arrojan las llamadas a herramientas MCP, Context Mode crea un subproceso aislado y solo pasa stdout al contexto. Está basado puramente en algoritmos, sin llamadas a LLM, usando SQLite FTS5 + BM25 + Porter stemming
  Últimamente he conseguido 228 estrellas y datos de uso reales, y me di cuenta de lo importante que es el enrutamiento de subagentes. Si actualizas automáticamente el subagente Bash a uno general y usas batch_execute, ya no hace falta llenar el contexto con salida cruda

  • Estaría bien agregar al post del blog el enlace al post de Cloudflare Code Mode. Está en el README, pero no en el cuerpo del artículo
  • Me parece muy interesante y pienso probarlo yo mismo. Aun así, entiendo que Context Mode no maneja realmente el uso de contexto de MCP en sí, ¿correcto? Uso MCP en varios entornos de Claude, así que solo con CLI hay límites
  • Me pregunto si esto también se podría usar con otros agentes como Zed Agent
  • Quisiera saber si hay alguna razón por la que no se soporte Codex. Por su estructura, parece independiente del agente
  • Me pregunto si esto no rompe el caché

• No entiendo por qué no usan el modo mcp-cli. Yo hice una versión clonada con wener-mcp-cli

• Gran trabajo. Creo que todavía hay mucho margen de mejora en la gestión de la ventana de contexto. Por ejemplo, si el modelo encuentra la respuesta correcta después de varios intentos, un enfoque de backtracking para quitar del contexto los intentos fallidos podría ser útil

  • Yo también estoy de acuerdo. Los logs o registros de fallos que aparecen durante la depuración deberían poder eliminarse una vez corregido el bug. En los IDE actuales hacerlo manualmente es incómodo. Estaría bien que el agente gestionara por sí mismo el contexto y que cosas como los logs se limpiaran automáticamente después de cierto número de veces. El contexto no debería verse como una simple pila, sino como un espacio que se puede manipular libremente
  • Los intentos fallidos al final son ruido. Detectar automáticamente patrones de reintento y dejar solo la última versión exitosa es totalmente factible
  • Ahorita se siente como finales de los 90. En ese entonces era HTML y SQL; ahora son los agentes de programación. Como ya somos ingenieros experimentados, al usar Claude Code encontramos optimizaciones casi de manera natural
  • Aprovechar subagentes también es una opción. Si surge un problema, puedes bifurcar un subagente, resolverlo ahí y traer solo el resultado. También resulta interesante imaginar que el modelo borre su propia memoria y vuelva por sí mismo a un estado anterior
  • Yo de hecho trabajo así. Cada llamada de tarea se ejecuta en un subproceso aparte para no contaminar el contexto padre. Al terminar, le paso al padre cuatro cosas: resultado, resumen del proceso, intentos fallidos y aprendizajes. La salida de las herramientas se guarda en archivos, y el LLM solo lee las partes necesarias. Por ejemplo, si termina con “Success!”, basta con ver la última línea. Si falla, solo lee el mensaje de error. También estoy experimentando con resumir logs con un modelo local y pasarle el resultado a un modelo en la nube. Puede que no sea tecnología de punta, pero en mi entorno funciona bien

• Al ver este post me di cuenta de que no entendía para nada el uso de tokens de Claude Code, así que en la mañana hice un CLI llamado claude-trace
  Analiza ~/.claude/projects/*/*.jsonl para desglosar uso y costo (incluyendo lectura/generación de caché) por sesión, herramienta, proyecto y línea de tiempo
  Si Context Mode resuelve bien la compresión de salida, esto funciona como una capa de medición para visualizar el consumo antes y después de los cambios

  • Como en la pregunta “/context?”, la clave es hacer visible en qué se están gastando realmente los tokens

• Se puede reducir mucho el uso de tokens usando apps CLI en vez de MCP. Por ejemplo, GitHub CLI hace lo mismo con muchos menos tokens que MCP

• Los hooks se sienten demasiado agresivos. Está bien bloquear todo curl/wget/WebFetch y crear snapshots de 56 KB en sandbox, pero para algo tan simple como curl api.example.com/health, donde solo necesitas 200 bytes, es excesivo
  Si comprimes 153 commits de git a 107 bytes, el modelo solo podrá ver los datos si escribe un script de extracción perfecto. Si usa un comando equivocado, la información necesaria desaparece
  El benchmark asume que el modelo siempre escribe el código de resumen correcto, pero en la práctica no es así

  • Yo también estuve de acuerdo, así que quité esa función

• No está mal, pero existe pérdida de precisión y riesgo de alucinación. Por datos incompletos o por una lógica de extracción incorrecta, Claude podría llegar a conclusiones erróneas. Aquí se asume que MCP será lo bastante inteligente como para escribir tanto buenos scripts de extracción como buenas consultas de búsqueda. Creo que la preservación de la información es un problema grande en la práctica

• La tasa de compresión es impresionante, pero me pregunto si, incluso con contexto comprimido, el modelo produce salidas de la misma calidad. Aunque una sesión pase de 30 minutos a 3 horas, solo tiene sentido si la calidad del razonamiento a las 2 horas se mantiene
  La economía del caché que menciona esafak también importa. Si el prompt caching funciona bien, incluso un contexto largo es prácticamente gratis. Pero si la compresión rompe la continuidad del caché, los costos podrían subir en lugar de bajar
  El problema más de fondo es que la mayoría de las herramientas MCP traen todos los datos con SELECT *. Es un problema de diseño de protocolo: deberían soportar resumen y drill-down

  • Aunque el caché parezca gratis, en realidad provoca pérdida de atención y menor velocidad. Aunque reutilices prefijos largos, la carga de cómputo sigue siendo alta

• Dudo que realmente haga falta meter más de 80 herramientas en el contexto. El contexto vale oro, y mientras más cosas no relacionadas con el problema metas, peor será el resultado. Más que compresión de datos, una mejor estrategia es la separación por subagentes

  • Es cierto. Pero la mayoría no administra directamente los servidores MCP por tarea. Con instalar 5 o 6 servidores, ya se cargan por defecto unas 80 herramientas. Context Mode no resuelve el exceso de definiciones de herramientas. En cambio, se enfoca en la salida que se vuelca después de ejecutar una herramienta. Por ejemplo, un solo snapshot de Playwright o un git log puede costar 50 mil tokens, y eso lo procesa dentro del sandbox