Clase 8 • Junio 2026 • Basado en documentación oficial, papers académicos y análisis multiplataforma
La memoria en agentes de IA no es un repositorio monolítico. Es un sistema en capas donde cada nivel tiene distinto alcance temporal, sustrato de representación y política de control. El paper arXiv:2603.07670 formaliza este modelo como un loop write–manage–read que atraviesa tres capas fundamentales.
El modelo es stateless entre llamadas. El context window es la memoria de trabajo: todo lo que el modelo "ve" en una interacción. Se pierde al terminar la sesión si no se persiste.
Compaction, checkpointing, resume entre sesiones. Mecanismos que extienden la vida útil del contexto más allá de una sola conversación sin llegar a ser persistente.
RAG, LLM Wiki, plugins de memoria persistente, MCP servers. Conocimiento que trasciende sesiones individuales y se acumula con el tiempo.
Cada plataforma implementa estas tres capas de forma distinta. Esta clase analiza cómo OpenCode, Codex CLI y Claude Code gestionan la memoria y el contexto, qué mecanismos ofrecen y dónde están sus limitaciones.
OpenCode usa SQLite persistente vía Drizzle ORM para la gestión de sesiones. Las sesiones forman una estructura de árbol padre-hijo, donde cada sesión hija (fork) preserva la transcripción de la sesión padre. El estado se guarda continuamente en SQLite.
El session sharing está disponible vía /share, que genera un link público opncd.ai/s/<id>. No hay documentación oficial de sessions en opencode.ai — la referencia está en Mintlify (opencode-ai-opencode.mintlify.app).
La compactación es el mecanismo que evita que el context window se desborde. OpenCode implementa dos estrategias:
| Parámetro | Default | Descripción |
|---|---|---|
compaction.auto | true | Compactación automática al detectar overflow |
compaction.prune | false | Estrategia prune (borrado de mensajes viejos) |
compaction.reserved | 20,000 tokens | Buffer de tokens reservados para respuesta |
Cuando el uso del context window alcanza ~80% del límite (model.limit.context), prune recorre los mensajes del más reciente al más viejo. Protege los últimos ~40K tokens de tool outputs. Los tool outputs antiguos se reemplazan con "[output truncated by compaction]". Los skill outputs nunca se limpian.
Si prune no libera suficiente espacio, OpenCode usa un LLM (agente compaction interno) para generar un resumen que reemplaza el historial. Usa un prompt template con anchored summaries para preservar información crítica.
token_threshold, context_threshold, min_messages. Si necesitas control granular, es posible que debas implementarlo manualmente.El contexto de proyecto se carga en este orden:
~/.config/opencode/AGENTS.mdinstructions en opencode.jsonskill() toolAdemás, OpenCode soporta expansión de {file:path} (incluye archivos) y {env:VAR} (variables de entorno) dentro de las instrucciones.
| Feature | Estado | Notas |
|---|---|---|
| Memoria entre sesiones (built-in) | ❌ No | No hay memoria persistente por defecto |
| Plugins de memoria | ✅ 10+ | opencode-memory, opencode-working-memory, opencode-graphiti, opencode-memsearch, opencode-lcm (FTS5), opencode-acm (pins/knowledge packages), opencode-momo, opencode-lore, opencode-mempalace |
| Memstate MCP | ✅ | Memoria persistente vía MCP. Docs en memstate.ai/docs/setup/opencode |
| ai-memex-cli (LLM Wiki) | ✅ Instalado | Vault en /root/.llmwiki/. Slash commands: ingest, distill, search, fetch, watch, lint |
| RAG built-in | ❌ No | Ni vector store ni knowledge base integrados |
| Prompt Caching | Provider-managed | Manejado por Anthropic/OpenAI subyacente |
OpenCode no implementa prompt caching propio. La gestión de caché se delega al provider subyacente (Anthropic, OpenAI, etc.). La página opencode.ai/docs/prompt-caching/ devuelve 404 — no hay documentación propia sobre el tema.
Fuentes para esta sección:
Codex CLI persiste sesiones en ~/.codex/sessions/ como archivos history.jsonl. Ofrece tres modos de reanudación:
codex resume — picker interactivo de sesionescodex resume --last — reanuda la última sesión directamentecodex resume <SESSION_ID> — reanuda por UUIDcodex fork <SESSION_ID> — bifurca una sesión preservando la transcripción originalclaude -n <name>.Codex CLI ofrece dos parámetros configurables para el context window:
| Parámetro | Descripción |
|---|---|
model_context_window | Configurable en config.toml. Define el tamaño del context window del modelo. |
model_auto_compact_token_limit | Threshold para activar compactación automática. |
Server-side — Configurado via context_management = [{ type = "compaction", compact_threshold = 200000 }]. La Responses API compacta automáticamente al cruzar el threshold.
Standalone — Via endpoint /responses/compact. Envías el contexto completo y recibes una versión compactada con un item cifrado opaco. Soporta compact_prompt inline y experimental_compact_prompt_file para prompts de compactación personalizados.
Codex CLI incluye un sistema de Memories persistente que debe activarse explícitamente con features.memories = true. Almacena preferencias, convenciones, tech stacks y pitfalls.
| Aspecto | Detalle |
|---|---|
| Storage | ~/.codex/memories/ — archivos markdown, NO encriptados |
| Control por thread | /memories para gestionar qué se recuerda |
| Config | memories.generate_memories, memories.use_memories, memories.extract_model, memories.consolidation_model |
| Rate-limit aware | memories.min_rate_limit_remaining_percent (default 25%) |
| Límites | max_rollout_age_days (30), min_rollout_idle_hours (6), max_raw_memories_for_consolidation (256) |
Chronicle es una feature de captura de pantalla para contexto visual. Exclusivo para macOS + ChatGPT Pro. Las capturas se almacenan efímeramente en $TMPDIR/chronicle/.
.codex/rules/. Soporta --cd <path> para working root y --add-dir <path> para directorios extra con write access. Fuzzy search con @ en composer.Fuentes:
Claude Code ofrece el sistema de gestión de sesiones más completo de las tres plataformas:
| Feature | Comando | Notas |
|---|---|---|
| Session naming | claude -n <name>, /rename <name> | Aceptar un plan en plan mode nombra automáticamente |
| Resume | --continue (última), --resume (picker), --resume <name>, --resume <session-id> | Múltiples modos de reanudación |
| Fork | /branch [name] (en sesión), --continue --fork-session (CLI) | Sesiones forked agrupadas bajo root session. Permisos "allow for this session" NO se transfieren |
| Session picker | Ctrl+W (worktrees), Ctrl+A (proyectos), Ctrl+B (branch), Ctrl+R (rename), Space (preview) | Navegación avanzada con atajos de teclado |
| Auto-cleanup | cleanupPeriodDays (default 30) | Transcripts en ~/.claude/projects/<project>/<session-id>.jsonl |
| Clear | /clear | Vacía contexto (conversación guardada, resumible) |
| Compact | /compact [instructions] | Reemplaza historial con resumen |
| Context inspection | /context | Muestra qué consume contexto |
Claude Code tiene un context window estándar de 200K tokens, con soporte para modelos de 1M tokens. La composición aproximada es:
| Componente | Tokens aprox. |
|---|---|
| System prompt | 4,200 |
| Auto memory (MEMORY.md) | 680 (primeras 200 líneas o 25KB) |
| Environment info | 280 |
| MCP tools (deferred) | 120 (solo nombres) |
| Skill descriptions | 450 (solo descripciones) |
| CLAUDE.md (project) | 1,800 |
Los subagentes ejecutan con su propio context window aislado: ~6,100 tokens de lecturas + 970 de MCP/skills. Solo el resumen final (~420 tokens) regresa al contexto principal. Esto evita la contaminación del contexto padre.
Claude Code captura automáticamente el estado del código antes de cada file edit. El sistema ofrece:
/rewind o Esc+Esc → menú interactivo de restauraciónArchivo automático que captura preferencias, tech stack y decisiones del proyecto:
Claude Code Agent SDK ofrece una arquitectura de sesiones programáticas:
SessionStore interface — métodos obligatorios: append(key, entries) y load(key)S3SessionStore, RedisSessionStore, PostgresSessionStoreappend()append() falla, emite mirror_error pero la query continúasubpath: "subagents/agent-<id>"Anthropic mantiene un servidor MCP de memoria oficial en @modelcontextprotocol/server-memory. Características:
create_entities, create_relations, add_observations, delete_entities, read_graph, search_nodes, open_nodesmemory.jsonl), configurable via MEMORY_FILE_PATHClaude Code deliberadamente NO usa RAG. Prefiere agentic search puro (Glob → Grep → Read) sobre embeddings. Razones:
🔹 Precisión: grep es exacto; embeddings dan falsos positivos y resultados probabilísticos.
🔹 Simplicidad: no requiere infraestructura de índices, vectores ni actualizaciones.
🔹 Frescura: un índice se desvía en cuanto editas el código; agentic search siempre busca en el estado actual.
🔹 Privacidad: no envía tu código a servicios externos de embeddings.
— Boris Cherny, creador de Claude Code
Fuentes:
| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Session persistence | ✅ SQLite (Drizzle) | ✅ JSONL files | ✅ JSONL transcripts |
| Session resume | ❌ (no doc) | ✅ codex resume | ✅ --continue / --resume |
| Session fork | ❌ | ✅ codex fork | ✅ /branch, --fork-session |
| Session naming | ❌ | ❌ (UUID) | ✅ --name, /rename |
| Compaction auto | ✅ prune + full | ✅ server-side + standalone | ✅ /compact + auto |
| Compaction config | ✅ thresholds + reserved | ✅ model_auto_compact_token_limit | via Anthropic API |
| Checkpointing | ❌ | ❌ | ✅ /rewind |
| Cross-session memory | plugins (10+) | ✅ Memories feature | ✅ Auto memory (MEMORY.md) |
| RAG / Codebase index | plugins | ❌ (web search only) | ❌ (agentic search) |
| LLM Wiki support | ✅ via memex | ❌ | ✅ via plugins/MCP |
| MCP Memory Server | ✅ via any MCP | ❌ (no MCP) | ✅ official server-memory |
| Agent SDK SessionStore | ❌ | ❌ | ✅ S3/Redis/Postgres |
| Prompt caching | provider-managed | provider-managed | ✅ 90% off cache reads |
| Context window | Según modelo | Configurable | 200K / 1M |
| Subagent isolation | ✅ per task tool | ✅ per subagent | ✅ own context window |
En lugar de RAG que re-deriva conocimiento en cada query, Karpathy propone que el LLM compile un wiki persistente. El patrón cambia el paradigma: de "buscar y sintetizar cada vez" a "acumular y referenciar".
El material fuente se almacena en raw/ como referencia inmutable. Pueden ser URLs, documentos, transcripciones de sesiones.
El LLM lee el material, lo resume, cross-referencia y escribe páginas estructuradas en wiki/ con enlaces internos ([[wikilinks]]).
Antes de responder, el agente busca en el wiki primero. Las respuestas incluyen referencias a las páginas fuente mediante [[wikilinks]].
Detección automática de contradicciones, stale claims (información desactualizada) y orphans (páginas sin enlaces entrantes).
| Plain RAG | LLM Wiki |
|---|---|
| Re-derives knowledge each query | Knowledge accumulates |
| Cross-references re-computed | Cross-references pre-written |
| Contradictions surface only if asked | Contradictions flagged during ingest |
| Exploration disappears | Good answers re-filed as pages |
| Scales by embeddings infrastructure | Scales by markdown + index.md |
ai-memex-cli: Herramienta CLI que implementa el patrón LLM Wiki para OpenCode. Instalado en este proyecto con vault en /root/.llmwiki/. Ofrece 6 slash commands: ingest, distill, search, fetch, watch, lint.
Obsidian: Puede funcionar como LLM Wiki si se combina con plugins de IA. Los wikilinks nativos de Obsidian ([[nota]]) son compatibles con el patrón.
Los servidores MCP de memoria permiten persistencia externa a través del protocolo Model Context Protocol. Aquí los principales disponibles:
| Servidor | Storage | Tools | Features clave |
|---|---|---|---|
| @modelcontextprotocol/server-memory | Key-value simple (JSONL local) | Básico | Referencia oficial de Anthropic. Integración directa con Claude Code. |
| Mem0 MCP | Cloud (vector + graph) | 9 tools | add/search/get/update/delete, graph mode. Plug & play. |
| Mem0 self-hosted | Qdrant + Neo4j + Ollama | 6 tools | Hybrid read/write, graph. Control total de datos. |
| Graph-Mem MCP | SQLite + embeddings | 28 tools | Multi-graph, hybrid search, BFS, shortest paths. El más completo en tools. |
| Memgraph MCP | Memgraph (graph DB) | 9 tools | Cypher queries, PageRank, centrality analysis. Para análisis de grafos avanzado. |
El prompt caching es el mecanismo que permite reutilizar representaciones de tokens cacheadas entre requests, reduciendo drásticamente costos y latencia. Cada proveedor lo implementa de forma distinta.
| Parámetro | Valor |
|---|---|
| Activación | Explícita vía cache_control breakpoints (máx 4 por request) |
| Descuento cache hit | 90% off (0.1x del input price) |
| Write premium (5min) | 1.25x |
| Write premium (1h) | 2x |
| TTL | 5 min default, 1 hora opcional |
| Mínimo | 1024 tokens (Sonnet/Opus), 2048 (Haiku) |
| Ejemplo Sonnet 4.6 | Input $3/M → Cache write $3.75/M → Cache read $0.30/M |
| Parámetro | Valor |
|---|---|
| Activación | Automática (prefix matching) |
| Descuento cache hit | 50% off en modelos recientes |
| TTL | ~5-10 min, hasta 24h en extended retention (GPT-5.5+) |
| Mínimo | 1024 tokens |
| Ejemplo GPT-5.5 | Input $5/M → Cache read $0.50/M (90% descuento actualizado) |
DeepSeek ofrece el cache más agresivo del mercado: cache read a $0.0028/M, que representa un 98% de descuento sobre el input price de $0.14/M. Sin write premium — todo el ahorro va al usuario.
El paper "Prompt Cache: Cost-Effective LLM Serving" (arXiv:2601.06007) demuestra:
🔹 Coloca el contenido estático (system prompt, tool definitions, reglas) al principio del prompt.
🔹 Coloca el contenido dinámico (query del usuario, contexto variable) al final.
🔹 En Anthropic, usa cache_control breakpoints para marcar explícitamente secciones cacheadas (máx 4).
🔹 En OpenAI, el prefix matching es automático — asegúrate de que los prefijos sean consistentes entre requests.
🔹 En DeepSeek, el cache hit rate depende de la repetición de inputs compartidos entre usuarios.
OpenCode no tiene RAG built-in. En su lugar, ofrece plugins que implementan codebase indexing:
.opencode/context/*.md. Enfoque más ligero que un vector index completo.Claude Code deliberadamente NO indexa. Boris Cherny, su creador, ha explicado extensamente por qué:
Precisión > embeddings: "grep es exacto, embeddings dan probabilidades. Cuando buscas una definición de función, quieres la definición exacta, no algo que 'se parece'."
Simplicidad: "No necesitas infraestructura de índices, actualizaciones periódicas, ni preocuparte por drift."
Frescura: "Un índice de embeddings se desvía en cuanto editas un archivo. Agentic search siempre opera sobre el estado actual del código."
Privacidad: "No envías tu código a servicios externos de embeddings. Todo es local."
— Boris Cherny, creador de Claude Code
Similar a Claude Code — no hay codebase index persistente documentado. La búsqueda se realiza mediante herramientas de file search y retrieval locales, sin infraestructura de vectores.
✅ Fortalezas: Ecosistema de 10+ plugins de memoria, MCP nativo, ai-memex-cli integrable, compaction configurable.
❌ Debilidades: Sin memoria cross-session built-in, sin checkpointing, sin session naming, sin SDK programático.
✅ Fortalezas: Memories feature persistente, compaction server-side + standalone, código abierto.
❌ Debilidades: Sin MCP, sin checkpointing, sin session naming, sin LLM wiki, sin RAG.
✅ Fortalezas: Checkpointing nativo, auto memory persistente, SDK con SessionStore, forking, naming, prompt caching 90% off.
❌ Debilidades: Sin RAG (por diseño), auto memory limitada a 200 líneas/25KB, cleanup a 30 días, sin persistencia infinita.
OpenCode + ai-memex-cli + plugin de memoria. Combinación de LLM Wiki + MCP server para memoria infinita.
Claude Code. Única plataforma con /rewind nativo. Esencial para desarrollo iterativo riesgoso.
Claude Code con agentic search + servidor MCP local. Sin datos fuera del dispositivo.
LLM Wiki (ai-memex-cli) sobre cualquier plataforma. Markdown versionable + wikilinks. No requiere infraestructura de vectores.
OpenCode con MCP. Acceso a 5+ servidores de memoria, plugins de terceros, y personalización total.
Claude Code Agent SDK con SessionStore (S3/Redis/Postgres). Única plataforma con API de sesiones para integración enterprise.
OpenCode + compaction optimizado. Aprovecha el caching del provider y los plugins open-source. Sin costo adicional de suscripción.
Graph-Mem MCP + Memgraph. 28 tools para análisis de grafos de conocimiento. Ideal para experimentar con memoria asociativa.
Claude Code con auto memory + checkpointing. La mejor experiencia para desarrollo diario gracias al contexto persistente y la capacidad de deshacer.
🔹 Corto plazo: Compaction automático + context window amplio (1M si el modelo lo soporta).
🔹 Medio plazo: Session naming + forking + auto memory (MEMORY.md o similar). Checkpointing si es posible.
🔹 Largo plazo: LLM Wiki (ai-memex-cli) + MCP Memory Server. La combinación de markdown versionable + graph knowledge base cubre todos los casos de uso de memoria persistente.
Ahorro estimado vs RAG tradicional: 60-80% en costos de infraestructura (no necesitas vectores, embeddings, ni actualizaciones de índice).
Todas las afirmaciones en esta clase están respaldadas por documentación oficial, papers académicos y análisis técnicos verificados a Junio 2026.
Última verificación: Junio 2026. Las URLs y políticas pueden cambiar; consulte las fuentes oficiales para información actualizada.