context-mem
Optimización de contexto para asistentes de codificación de IA — 99% de ahorro de tokens mediante 14 resumidores conscientes del contenido, búsqueda de 3 capas y divulgación progresiva. Sin dependencia de LLM.
Documentación
Context Mem
Infraestructura de memoria + contexto para agentes de IA. Recuerda todo. Comprime todo. Totalmente local.
El Problema
Dos problemas con las herramientas de IA actuales que nadie ha resuelto juntos en un solo paquete.
Tu IA olvida. Cada nueva sesión comienza desde cero. Las decisiones de arquitectura que tomaste el jueves pasado, el error que pasaste cuatro horas rastreando hasta una variable de entorno mal configurada, las preferencias que declaraste tres veces — nada de eso se transfiere. Pasas los primeros diez minutos de cada sesión reexplicando contexto que ya existía. Multiplica esto por cada desarrollador en tu equipo, cada proyecto, cada día.
Tu contexto explota. Las sesiones largas de codificación superan la ventana de contexto. Una sesión típica con 50 salidas de herramientas acumula 365 KB de texto crudo — rastros de pila, salida de pruebas, lecturas de archivos, comandos de shell. Cada token cuesta dinero o ralentiza el modelo. La truncación ingenua descarta la evidencia exacta que el modelo necesita. Mantener todo hace que las respuestas sean más lentas y el costo de inferencia suba rápido.
Estos dos problemas se agravan mutuamente. La solución para olvidar (mantener todo) es lo opuesto a la solución para la explosión de contexto (descartar todo). El resultado es un falso trade-off que la mayoría de las herramientas te imponen: o tu IA olvida todo, o tus costos se disparan. context-mem resuelve ambos simultáneamente construyendo un almacén de memoria indexado, comprimido y recuperable en lugar de volcar el historial crudo en la ventana de contexto.
La Solución — una herramienta, dos pilares
Pilar 1: Memoria (LLM Wiki)
Cada llamada de herramienta se ingiere, resume y escribe automáticamente en un vault de markdown navegable — una wiki viva que tu IA mantiene sobre tu proyecto. Las entidades obtienen sus propias páginas con backlinks. Los temas obtienen páginas de síntesis. Las sesiones se convierten en documentos fuente navegables. Las decisiones se acumulan en un rastro reconstruible.
El vault vive en .context-mem/vault/ y se sincroniza continuamente desde el almacén SQLite subyacente. Léelo en Obsidian, haz grep desde la terminal, o consúltalo a través de 45+ herramientas MCP usando búsqueda híbrida BM25 + vectorial + juez LLM opcional. El almacén SQLite crudo es el registro autoritativo; el vault de markdown es la capa derivada y legible por humanos.
Esta es una implementación de referencia del patrón LLM Wiki de Andrej Karpathy — tres capas (fuentes crudas / wiki / esquema), con ingesta automática desde llamadas de herramientas que ningún otro sistema proporciona.
Pilar 2: Compresión (14 resumidores)
Cada observación pasa por un resumidor consciente del contenido antes de almacenarse. Un rastro de pila no se trata igual que un archivo de configuración JSON. La salida de shell de una compilación se comprime de manera diferente a los errores del compilador de TypeScript. El sistema aplica la compresión correcta para el tipo de contenido.
El resultado: una sesión completa de codificación con 50 salidas de herramientas pasa de 365 KB a 3.2 KB — 99.1% de ahorro de tokens, verificado. La compresión es adaptativa: las observaciones recientes de alta importancia permanecen verbatim; las más antiguas de baja importancia se comprimen progresivamente. Las entradas fijadas nunca se comprimen independientemente de su antigüedad.
Un Comando
npm i context-mem && npx context-mem init
init auto-detecta tu editor y escribe los archivos de configuración correctos:
| Editor | Configuración escrita |
|---|---|
| Claude Code | .mcp.json + 8 hooks + CLAUDE.md |
| Cursor | .cursor/mcp.json + .cursor/rules/context-mem.mdc |
| Windsurf | .windsurf/mcp.json + .windsurf/rules/context-mem.md |
| VS Code / Copilot | .vscode/mcp.json + .github/copilot-instructions.md |
| Cline | .cline/mcp_settings.json + .clinerules/context-mem.md |
| Roo Code | .roo-code/mcp_settings.json + .roo/rules/context-mem.md |
| Aider | .aider.conf.yml (bloque MCP) |
| Continue | .continue/config.json (bloque MCP) |
| JetBrains AI | .idea/mcp.json |
Sin claves API. Sin cuenta en la nube. Ningún dato sale de tu máquina.
Doble pilar en 60 segundos
[ placeholder: GIF o video — sesión de Claude Code con vista dividida mostrando el gráfico de Obsidian actualizándose en tiempo real junto con el gráfico de ahorro de tokens del dashboard de context-mem ]
Arquitectura (implementación de referencia del patrón LLM Wiki de Karpathy)
┌─────────────────────────────────────────┐
│ Raw Sources (immutable) │
│ tool calls · observations · file reads │
└──────────────────┬──────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Observation Pipeline │
│ │
│ PrivacyEngine (9 detectors) │
│ → 14 content-aware summarizers │
│ → entity extraction (100+ aliases) │
│ → topic detection │
│ → importance scoring (0.0–1.0) │
│ → adaptive compression tier │
└────────────────┬────────────────────────┘
│
┌─────────────────┴───────────────────┐
│ │
▼ ▼
┌──────────────────────────┐ ┌─────────────────────────────┐
│ SQLite (primary) │ │ Markdown Vault (derived) │
│ │ │ │
│ observations │──────▶│ .context-mem/vault/ │
│ entities + graph │ sync │ index.md │
│ knowledge │ │ log.md │
│ events │ │ sources/<session>.md │
│ FTS5 index │ │ entities/<name>.md │
│ vector embeddings │ │ topics/<name>.md │
└──────────────────────────┘ │ knowledge/<id>.md │
│ └─────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Hybrid Retrieval │
│ │
│ BM25 (8 strategies + synonym expansion) │
│ + Vector (nomic-embed-text-v1.5, 768-dim) │
│ + Trigram + Levenshtein │
│ → Fusion (intent-adaptive weights, IDF reranker) │
│ → Optional LLM judge (Haiku, 50/50 blend, 100% R@5) │
└──────────────────────────────────────────────────────────────┘
Tres capas (según Karpathy):
- Fuentes crudas — tus salidas de llamadas de herramientas, lecturas de archivos, comandos de shell, observaciones. Escritas una vez, nunca modificadas. El registro permanente.
- La wiki — vault de markdown mantenido por LLM (
.context-mem/vault/). Auto-sincronizado desde SQLite. Legible por humanos, compatible con Obsidian, apto para grep. Páginas de entidades, páginas de temas, páginas de sesiones, páginas de conocimiento, índice, registro de eventos. - Esquema —
docs/llm-wiki-schema.mdgobierna la estructura de páginas, convenciones de enlace, recetas de flujo de trabajo de agentes y el contrato de interoperabilidad. Especificación pública — otras herramientas pueden emitir wikis conformes.
La distinción de la mayoría de los sistemas de memoria: context-mem no reemplaza SQLite con markdown. SQLite es autoritativo — es donde se almacenan, buscan e indexan las observaciones. El vault es la superficie navegable, enlazable y diferenciable encima — la capa que un humano o LLM puede navegar sin un cliente de base de datos. Si eliminas el directorio del vault, no pierdes nada que importe. Si editas una página del vault manualmente, esas ediciones se conservan y no se sobrescriben en la siguiente sincronización.
Este es el modelo de tres capas de Karpathy aplicado a un entorno de desarrollo de IA en ejecución: entradas inmutables, una capa de síntesis mantenida y un esquema público que gobierna la síntesis. El vault se puede usar independientemente de las herramientas MCP — es solo un directorio de archivos markdown. Ábrelo en cualquier editor. Ponlo en git. Haz diff entre commits. Úsalo como contexto de formato largo copiando y pegando páginas en una nueva conversación. Las herramientas MCP son la ruta automatizada; el vault de markdown es la ruta portátil, duradera y legible por humanos.
Benchmarks de recuperación (metodología honesta)
Todas las puntuaciones son recall de recuperación a nivel de sesión: ¿apareció alguna evidencia correcta de la sesión en los resultados top-k? Esto es diferente de la precisión de QA de extremo a extremo (recuperar + generar + juzgar), que es más difícil y más baja para todos los sistemas. Ambas mediciones se publican aquí.
Puramente local (cero llamadas API, totalmente gratis)
| Benchmark | Recall de Recuperación | Precisión QA E2E | Preguntas | Sesiones |
|---|---|---|---|---|
| LongMemEval | 97.8% R@5 | publicado post-v3.4 | 500 | ~53/conv |
| LoCoMo | 98.1% R@10 | publicado post-v3.4 | 1,977 | 19-35/conv |
| MemBench | 98.0% R@5 | — | 500 | — |
| ConvoMem | 97.7% R@10 | — | 250 | — |
Con reranking LLM opcional (~$1 por 500 consultas)
| Benchmark | Recall de Recuperación |
|---|---|
| LongMemEval | 100.0% R@5 (500/500) |
El juez LLM (Claude Haiku) puntúa los candidatos top-N de BM25+vectorial de 0 a 10 y combina 50/50 con la puntuación de recuperación. Se activa cuando ai_curation.enabled = true. Añade ~$0.002 por consulta al precio de Haiku.
Notas de metodología:
- Un "acierto" se puntúa si aparece alguna evidencia correcta de la sesión en top-k. No es QA de extremo a extremo.
- El benchmark LoCoMo añade metadatos proporcionados por el conjunto de datos (session_summary, observation, event_summary) a los documentos de sesión — el sistema de producción aplica un enriquecimiento equivalente mediante resumidores y extracción de entidades.
- Expansiones de sinónimos: el constructor de consultas central incluye sinónimos de vocabulario general (película → film, hermano → brother). Los resultados sin ninguna expansión de sinónimos son ~1-2% más bajos.
- Todo el código de benchmark es abierto y ejecutable:
npm run bench. Verbenchmarks/.
Metodología completa: docs/benchmarks/methodology.md (publicada con v3.4).
Benchmarks de compresión (verificados)
| Escenario | Crudo | Comprimido | Ahorro |
|---|---|---|---|
| Sesión típica de codificación (50 salidas de herramientas) | 365 KB | 3.2 KB | 99.1% |
Desglose por resumidor:
| Resumidor | Ratio de compresión |
|---|---|
| Salida de logs | 97% |
| Errores | 95% |
| Shell / CLI | ~95% |
| Código | 92% |
| JSON | 89% |
| Errores del compilador TS | ~88% |
| Pruebas | ~85% |
| Salida de compilación | ~94% |
| Logs de git | ~90% |
| HTML | ~92% |
| Markdown | ~75% |
| CSV | ~80% |
| Respuestas de red | ~88% |
| Binario (volcados hex) | ~98% |
La compresión es sin pérdidas a nivel semántico para observaciones de alta importancia (banderas DECISION, MILESTONE, PROBLEM) — esas permanecen verbatim independientemente de su antigüedad. La compresión se aplica a la salida de herramientas rutinaria.
Características principales
Memoria
- Sustrato LLM Wiki — vault de markdown en
.context-mem/vault/, auto-sincronizado desde SQLite. Páginas de entidades, páginas de temas, páginas fuente de sesiones, páginas de conocimiento, index.md, log.md. Compatible con Obsidian, apto para grep. - 14 resumidores conscientes del contenido — JSON, shell, código, logs, errores, errores TS, pruebas, compilaciones, logs de git, HTML, markdown, CSV, binario, red. Cada uno ajustado para su tipo de contenido.
- Compresión adaptativa de 4 niveles — verbatim (0–7 días) → ligera (7–30 días) → media (30–90 días) → destilada (90 días+). Las entradas fijadas permanecen verbatim para siempre.
- Grafo de conocimiento — modelo de relaciones entidad-tipo: archivos, módulos, patrones, decisiones, errores, personas, bibliotecas, servicios, APIs, configuraciones. Recorrible mediante
graph_query,graph_neighbors,add_relationship. - Hechos temporales —
valid_from/valid_toen todas las entradas de conocimiento. Cadenas de supersesión.temporal_queryresponde "¿qué era verdad sobre X en el tiempo T?" - Reconstrucción del rastro de decisiones —
explain_decisionrecorre la cadena de evidencia hacia atrás: lecturas de archivos → errores → búsquedas → la decisión. Proveniencia completa. - Inteligencia de entidades — detecta automáticamente tecnologías, personas, rutas de archivos, identificadores CamelCase, constantes ALL_CAPS. Más de 100 alias canónicos (React.js → React, Node → Node.js, etc.).
- Narrativas de sesión — 4 plantillas listas: descripción de PR, actualización de standup, ADR, guía de incorporación.
context-mem story --format pr. - Préambulo de despertar — inyección de contexto con presupuesto de tokens al inicio de la sesión. 4 capas: perfil del proyecto (15%), conocimiento crítico (40%), decisiones recientes (30%), entidades principales (15%).
- Inyección por prompt — el hook UserPromptSubmit inyecta automáticamente memorias relevantes en cada mensaje. Con límite de velocidad, deduplicación por tema. Cero comandos manuales.
Compresión
- 14 resumidores conscientes del contenido — no es una talla única. Un rastro de pila recibe un tratamiento diferente que una respuesta JSON.
- Preservación verbatim fijada — las decisiones, hitos y observaciones fijadas manualmente nunca se comprimen.
- Cascada de truncación por prioridad — si se excede el presupuesto de contexto, los elementos de menor importancia se comprimen primero. Los de alta importancia sobreviven.
- Presupuesto de tokens configurable — tres estrategias de desbordamiento: comprimir los más antiguos, comprimir los de menor importancia, o truncar duro.
- 365 KB → 3.2 KB — verificado en una sesión típica de codificación con 50 salidas de herramientas.
Ambos
- Búsqueda híbrida — BM25 (8 estrategias + expansión de sinónimos) + vectorial (nomic-embed-text-v1.5, 768-dim) + trigrama + Levenshtein se ejecutan en paralelo, fusionados mediante pesos adaptativos por intención con reranking de contenido ponderado por IDF. Reranker juez LLM opcional.
- Resolvedor temporal — análisis determinista para consultas de fechas relativas ("hace 3 días", "el sábado pasado", "la semana pasada"). Cero costo LLM. Devuelve rango de fechas absoluto con nivel de confianza.
- 45+ herramientas MCP — observar, buscar, recordar, preguntar, línea de tiempo, grafo de conocimiento, detección de entidades, consulta temporal, traspaso de sesión, coordinación multi-agente, presupuesto de tokens, dashboard, diagnósticos, y más.
- Totalmente local, cero nube — SQLite en tu máquina. Sin telemetría. Sin claves API requeridas para la funcionalidad central.
- Motor de privacidad de 9 detectores — elimina etiquetas
<private>, aplica redacciones regex personalizadas, detecta claves API, tokens, contraseñas, patrones PII. Nada sensible sale de tu máquina. - Operaciones sub-milisegundo — clasificación de importancia a 556K ops/s, extracción de entidades a 179K ops/s, búsqueda BM25 a 3.3K ops/s, todo local.
Cómo se compara
El espacio de memoria tiene múltiples actores establecidos. El espacio de compresión de contexto tiene algunos más. Ninguna otra herramienta aborda ambos ejes juntos.
| context-mem v4 | Mem0 | Graphiti | Zep | Letta | |
|---|---|---|---|---|---|
| LLM Wiki / bóveda markdown | ✅ | ❌ | ❌ | ❌ | ❌ |
| Auto-ingesta desde llamadas a herramientas | ✅ | ❌ | ❌ | ❌ | ❌ |
| Recall de recuperación (local) | 97.8–98.1% R@k | no publicado | no publicado | no publicado | no publicado |
| Compresión de tokens | 99.1% | ❌ | ❌ | ❌ | parcial |
| Grafo de conocimiento tipado | ✅ | ✅ | ✅ | parcial | parcial |
| Consultas temporales de grafos | ✅ | ✅ | ✅ | ❌ | ❌ |
| Híbrido BM25 + vector + reordenamiento LLM | ✅ | parcial | ❌ | parcial | ❌ |
| Totalmente local (sin nube requerida) | ✅ | ❌ | ❌ | ❌ | ❌ |
| Reconstrucción de rastro de decisiones | ✅ | ❌ | ❌ | ❌ | ❌ |
| Salida compatible con Obsidian | ✅ | ❌ | ❌ | ❌ | ❌ |
| Herramientas MCP | 45+ | algunos | algunos | algunos | algunos |
| Licencia | MIT | Apache/cloud | Apache | Apache | Apache |
Notas sobre esta tabla: Las cifras de recall de recuperación para Mem0, Graphiti, Zep y Letta no están publicadas con los mismos benchmarks (LongMemEval, LoCoMo, MemBench, ConvoMem) a nivel de sesión con una metodología comparable a la nuestra. Si existen números publicados en su documentación, son para conjuntos de datos diferentes, granularidad diferente (nivel de fragmento vs. nivel de sesión), o con infraestructura no revelada. No los compares directamente. Los números de QA E2E para context-mem se publicarán con v3.4. Todas las demás comparaciones se basan en documentación pública a partir de abril de 2026.
La fila de "compresión de tokens" merece una nota: Mem0, Graphiti y Zep son principalmente sistemas de recuperación — no pretenden resolver el problema del costo de la ventana de contexto. Letta tiene compresión parcial mediante resumen. La cifra del 99.1% de context-mem se mide en una sesión de codificación real (50 salidas de herramientas, 365 KB → 3.2 KB). La medición es reproducible: puedes ejecutarla tú mismo contra tu propio proyecto comparando context-mem stats --raw vs context-mem stats --compressed.
Ejemplos del mundo real
You: "Why did we choose Postgres over MySQL?"
→ recall returns the exact verbatim quote from March 15 (importance 0.95)
with the full evidence chain: error → file_read → search → decision
You: "What did Sarah work on last sprint?"
→ browse by person shows 14 observations mentioning Sarah,
grouped by topic (auth, database, deployment)
You: "What are we about to forget?"
→ predict_loss shows 8 entries at risk: low importance, 45+ days old,
never accessed. Pin the critical ones before they decay.
You: "Generate a PR description for this branch"
→ context-mem story --format pr assembles changes, decisions,
resolved issues, and test plan from the current session
You: "What was our database schema in January?"
→ temporal_query returns what was true about the schema at that point
in time, including since-superseded knowledge
Primeros pasos
1. Instalación
npm i context-mem && npx context-mem init
init crea la configuración MCP correcta para tu editor. No se requiere reiniciar el IDE para Claude Code. Para Cursor, Windsurf y VS Code, reinicia el IDE después de init.
2. Configurar MCP (opción manual)
Si prefieres configurar manualmente, añade a tu configuración MCP:
{
"mcpServers": {
"context-mem": {
"command": "npx",
"args": ["context-mem", "serve"],
"env": {}
}
}
}
Para Claude Code específicamente, init también escribe 8 hooks en .claude/settings.json que auto-inyectan recuerdos relevantes en cada envío de prompt — no se necesitan llamadas manuales a observe durante el desarrollo normal.
3. Habilitar la bóveda LLM Wiki (opt-in v3.4+)
Añade a tu configuración context-mem (.context-mem/config.json):
{
"vault": {
"enabled": true,
"vaultDir": ".context-mem/vault"
}
}
El directorio de la bóveda se auto-poblará en la próxima ingesta de observaciones. Abre .context-mem/vault/ en Obsidian para explorar la vista de grafo del conocimiento de tu proyecto.
La bóveda es opt-in en v3.4 y estará activada por defecto en v4.0.
4. Panel de control
context-mem dashboard
Abre una interfaz web local en http://localhost:3141 con 6 páginas: Resumen de inteligencia, Grafo de conocimiento, Temas, Línea de tiempo, Entidades y Diagnósticos.
5. Benchmarks (ejecútalos tú mismo)
npm run bench # quick mode (all 4 benchmarks, sample sizes)
npm run bench:full # full benchmarks
npm run bench:e2e-qa # E2E QA: retrieve → Haiku answer → Haiku judge
Todo el código de benchmarks es abierto. No hay adaptadores ocultos que inflen los números. Ver benchmarks/ y docs/benchmarks/methodology.md.
Referencia de herramientas MCP (45+)
context-mem expone toda su superficie como herramientas MCP — sin SDK propietario, sin biblioteca envolvente, sin bloqueo. Cualquier host compatible con MCP (Claude Code, Cursor, Windsurf, VS Code, Cline, Roo Code, Aider, Continue, JetBrains AI, CrewAI, LangChain, AutoGen) puede usar estas herramientas directamente. No hay herramientas 'premium' detrás de un muro de pago ni funciones que requieran suscripción a la nube. Cada capacidad listada en este README está disponible a través de la interfaz MCP abierta.
Herramientas de memoria principales:
| Tool | Purpose |
|---|---|
observe | Almacenar observación con auto-resumen, puntuación de importancia, extracción de entidades, detección de temas |
recall | Recuperar contenido verbatim por filtro (importancia, tipo, bandera, tiempo) |
search | Búsqueda híbrida (BM25 + vector + juez LLM opcional) |
ask | Preguntas y respuestas en lenguaje natural sobre el almacén de memoria completo |
timeline | Observaciones en orden cronológico inverso con insignias de importancia y banderas |
stats | Economía de tokens para la sesión actual (crudo vs. comprimido) |
Herramientas de grafo de conocimiento:
| Tool | Purpose |
|---|---|
save_knowledge | Guardar una entrada de conocimiento con detección de contradicciones + ventanas de validez temporal |
search_knowledge | Buscar (entradas superadas filtradas por defecto) |
promote_knowledge | Promover al almacén global entre proyectos |
global_search | Buscar en todos los proyectos simultáneamente |
resolve_contradiction | Resolver conflictos de conocimiento (superar / fusionar / mantener / archivar) |
merge_suggestions | Ver sugerencias de duplicados entre proyectos |
graph_query | Recorrer relaciones de entidades |
add_relationship | Enlazar entidades con relaciones tipadas |
graph_neighbors | Encontrar entidades conectadas (profundidad configurable) |
Herramientas temporales y de inteligencia:
| Tool | Purpose |
|---|---|
temporal_query | Consultar qué era verdad en un punto específico en el tiempo |
time_travel | Comparar el estado del proyecto en dos marcas de tiempo arbitrarias |
explain_decision | Recorrer la cadena de evidencia hacia atrás para reconstruir por qué se tomó una decisión |
predict_loss | Identificar observaciones en riesgo de compresión/eliminación |
generate_story | Generar descripción de PR, actualización de standup, ADR o guía de incorporación |
entity_detect | Detectar entidades en texto arbitrario |
find_tunnels | Encontrar conexiones de temas entre proyectos |
Herramientas de sesión y agente:
| Tool | Purpose |
|---|---|
wake_up | Preparación de contexto con presupuesto de tokens para el inicio de sesión |
restore_session | Restaurar sesión desde punto de control |
handoff_session | Paquete de continuidad entre sesiones |
agent_register | Registrar un agente con rol y capacidades |
agent_status | Verificar todos los agentes activos y sus recursos reclamados |
claim_files | Reclamar archivos para prevenir conflictos entre agentes paralelos |
agent_broadcast | Transmitir un hallazgo a todos los agentes del proyecto |
Herramientas del sistema:
| Tool | Purpose |
|---|---|
configure | Actualizar configuración en tiempo de ejecución |
budget_status / budget_configure | Gestión del presupuesto de tokens |
summarize | Resumir contenido sin almacenar (de una sola vez) |
execute | Ejecutar código (JS, TS, Python, Shell, Ruby, Go, Rust, PHP, Perl, R, Elixir) |
index_content | Indexar con fragmentación consciente del código |
search_content | Buscar fragmentos indexados |
list_people / list_topics | Explorar entidades y temas |
import_conversations | Importar historial de conversación |
browse | Recuperar observaciones por persona, entidad o tema |
diagnostics | Registro de errores, estadísticas de pipeline, salud del almacenamiento |
API de diagnóstico
Si necesitas inspeccionar lo que el sistema está haciendo:
# MCP tool
mcp__context-mem__diagnostics
# HTTP (when dashboard is running)
curl http://localhost:3141/api/diagnostics
Devuelve registro de errores, estadísticas de pipeline, sesión activa, salud del almacenamiento, estado del índice de búsqueda.
Soporte multi-agente
context-mem soporta agentes de IA paralelos trabajando en el mismo proyecto sin colisiones:
// Agent A registers and claims a file
mcp__context-mem__agent_register({ agent_id: "agent-a", role: "backend" })
mcp__context-mem__claim_files({ files: ["src/api.ts"] })
// Agent B sees Agent A's claim and avoids the conflict
mcp__context-mem__agent_status({})
// → { "agent-a": { files: ["src/api.ts"], status: "active" } }
// Broadcast a finding to all agents
mcp__context-mem__agent_broadcast({ message: "auth module has a race condition on token refresh" })
La memoria compartida previene trabajo duplicado. Los archivos reclamados previenen conflictos de fusión. La transmisión mantiene a todos los agentes sincronizados en los descubrimientos.
Referencia de arquitectura: pipeline de búsqueda
La pila de recuperación ejecuta 8 estrategias BM25 en paralelo, cada una con diferente peso y compensación de precisión/recall:
| Strategy | Weight | Purpose |
|---|---|---|
| AND-mode | 2.0 | Alta precisión, todos los términos requeridos |
| Phrase matching | 1.9 | Pares de palabras clave consecutivas |
| Entity-focused | 1.8 | Nombres propios, fechas, identificadores |
| Sanitized FTS5 | 1.5 | Tokenización por defecto |
| Relaxed AND | 1.2 | Entidad + palabras clave principales |
| OR-mode + synonyms | 1.0 | Recall amplio con expansión semántica |
| Individual keywords | 0.5 | Captura de cola larga |
| Individual synonyms | 0.2 | Puente de brecha semántica (sibling → brother) |
Además, resolución temporal (peso 1.6): las consultas de fechas relativas ("el sábado pasado") se resuelven a rangos de fechas absolutos de forma determinista antes de la búsqueda — costo cero de LLM.
La búsqueda vectorial (nomic-embed-text-v1.5, 768-dim) se ejecuta en paralelo con BM25 sobre los 30 mejores candidatos, no en cascada. Los resultados se fusionan mediante pesos adaptativos a la intención (BM25: 0.45, trigrama: 0.15, Levenshtein: 0.05, vector: 0.35) con reordenamiento de contenido ponderado por IDF. El juez LLM opcional combina 50/50 con la puntuación de recuperación en el top-N final.
Esquema de LLM Wiki
La bóveda sigue un esquema documentado en docs/llm-wiki-schema.md. Especifica:
- Estructura de directorios (
sources/,entities/,topics/,knowledge/) - Tipos de página y convenciones de frontmatter
- Sintaxis de enlace (
[[entity-name]]resuelve aentities/entity-name.md) - Operaciones: ingesta / consulta / lint
- Recetas de flujo de trabajo para agentes en CLAUDE.md / AGENTS.md
- Contrato de interoperabilidad — otras herramientas pueden emitir wikis conformes que context-mem puede importar
Esta es una especificación pública. RFCs de la comunidad en github.com/JubaKitiashvili/context-mem/discussions.
Características de rendimiento
Todas las operaciones principales son síncronas y de submilisegundo. No se requiere LLM para ninguna operación por defecto.
| Operation | Throughput | Latency |
|---|---|---|
| Clasificación de importancia | 556K ops/s | 0.002ms |
| Extracción de entidades | 179K ops/s | 0.006ms |
| Detección de temas | 162K ops/s | 0.006ms |
| Cálculo de nivel de compresión | 3M ops/s | <0.001ms |
| Búsqueda verbatim FTS5 | 50K ops/s | 0.020ms |
| Búsqueda híbrida BM25 | 3.3K ops/s | 0.3ms |
| Ensamblaje de preparación de despertar | 9K ops/s | 0.111ms |
| Generación de narrativa | 6K ops/s | 0.164ms |
La incrustación vectorial (nomic-embed-text-v1.5) añade ~5–15ms por consulta cuando la búsqueda vectorial está habilitada — aún más rápido que cualquier llamada de red. El juez LLM opcional añade una llamada a la API de Haiku (~100ms) y solo se invoca cuando ai_curation.enabled = true.
Destacados del changelog
- v4.0.0 — Lanzamiento completo de LLM Wiki. Páginas de síntesis, plugin de Obsidian, 8 integraciones de IDE, RFC de Protocolo de Contexto, pulido de compresión. Objetivo 2026-05-22.
- v3.4.0 — Vista previa de LLM Wiki. Capa de bóveda Markdown, especificación de esquema v1, benchmark de QA E2E, issue #6 cerrado (divulgación de metodología de benchmark).
- v3.3.0 — Fundamentos. CI, registro de errores, diagnósticos. Parche silencioso.
- v3.2.0 — Búsqueda híbrida paralela. BM25 + vector en paralelo, fusión adaptativa a la intención.
- v2.5.0 — Panel de control. Interfaz web en tiempo real, visualización de grafo de conocimiento.
Licencia: MIT
Construido por Juba Kitiashvili.
Crédito: Andrej Karpathy por el marco de LLM Wiki (2026-04-04). Vannevar Bush por Memex (1945).