1M de tokens de contexto. Lo primero que hice fue subir un repositorio Python.
Resultado: el modelo respondio preguntas sobre el codigo. Correcto, pero inutil. Era lo mismo que tenia con Sonnet 4.5 y un repo mediano. El contexto enorme no cambia nada si lo que cargas es solo codigo.
Lo que cambio el juego fue diferente: cargar el vault completo de Obsidian. No el repo. El segundo cerebro.
El problema con “sube tu repo”
Los tutoriales en EN sobre 1M context tienen todos el mismo patron: “sube tu codebase entera, el modelo entiende todo el proyecto”. Tecnico, correcto, util en proyectos grandes.
El problema es que eso asume que el contexto que necesitas es codigo. Para mi, el contexto que mas se pierde entre sesiones no es codigo — es ecosistema: que proyectos existen, que decisiones ya tome, que perfiles son publicos vs privados, que agentes corren y con que reglas.
Cada sesion nueva con un LLM empieza desde cero en ese eje. Los primeros 10-20 minutos de una sesion de orchestration los pasaba re-explicando: que es Geosdata, que es jotive.dev, que perfiles son publicos, que tiene cada HEAD de agente. Tedioso. Y con cada compactacion, se perdia de nuevo.
El vault como contexto persistente
Tengo un vault Obsidian. Son ~150+ archivos Markdown: dashboards, proyectos activos, perfiles de arquitectura, brand kits, notas de agentes, memoria cross-model.
La estructura en alto nivel:
Memory/ → contexto cross-model (perfiles, reglas, estado)
Agents/ → definiciones de agentes (AGENT.md por ejecutor)
Proyectos/ → estado actual por proyecto
Resources/ → brand kits JSON, referencias
Memory/state/ → blackboard (LOCKS, KILLS, HOLDS, SIGNALS)Cuando cargo ese vault completo a Claude Opus 4.7, el modelo tiene acceso simultaneo a:
- Que proyectos existen y en que fase estan
- Que decisiones ya estan cerradas (LOCKS) y cuales descartadas (KILLS)
- Que perfiles son publicos vs privados y por que
- Que agentes existen, que inputs esperan, que outputs generan
- Que reglas de OPSEC aplican por contexto
El resultado practico: la sesion arranca orientada. No re-explico ecosistema. No tengo que recordarle al modelo que cierto proyecto es privado o que cierto perfil no se mezcla con otro.
Como cargo el vault
La forma directa depende de tu cliente Claude. En Claude.ai, usas Projects con Knowledge Files. En Claude Code (el CLI), cargas archivos en el contexto de la sesion o referencias paths en el CLAUDE.md del proyecto.
Mi setup:
1. CLAUDE.md del vault como ancla
El vault tiene un CLAUDE.md en la raiz. Es el indice de todo: estructura, ecosistema, agentes, flujos de trabajo, reglas operacionales. El modelo lo lee primero y tiene un mapa de donde esta todo lo demas.
2. Memory/ como fuente de verdad cross-model
Memory/ tiene ~80+ archivos. Cada uno es una decision, un perfil, una regla. Estan escritos para ser leidos por cualquier LLM, no solo Claude. El modelo los usa como contexto persistente.
3. state/ como blackboard
Memory/state/ tiene cuatro archivos clave: LOCKS.md, KILLS.md, HOLDS.md, SIGNALS.md. Antes de cualquier output, el agente los lee. Si hay conflicto, escribe a CONFLICTS.md. Es protocolo, no magia.
4. Agents/ como instrucciones ejecutables
Cada agente tiene un AGENT.md con inputs, outputs, reglas, boundaries. El modelo no adivina comportamiento — lo lee directo.
Antes y despues: ejemplo concreto
Antes — Sesion orchestration sin vault:
Josse: necesito que el brand-publisher genere un post para jotive.dev
sobre el signal de Claude Opus que esta abierto
Modelo: que es jotive.dev? cual es el signal? que es brand-publisher?
que restricciones aplican al contenido?
Josse: [10-15 minutos explicando ecosistema]
Modelo: [output que igual viola alguna regla OPSEC porque no conocia el contexto]Despues — Sesion con vault cargado:
Josse: brand-publisher, signal SIGNALS-20260502-03, brand dev
Modelo: [lee AGENT.md, LOCKS/KILLS/HOLDS, brand kit dev.json, voz Josse, ESTRATEGIA]
[genera post con frontmatter completo, annotations B-ROLL, sin mencionar DN,
sin banned phrases, con imagen placeholder Pexels]El ramp-up bajo de ~20 minutos a ~2 minutos. Lo que cambio no fue el modelo — fue el contexto disponible desde el primer token.
Lo que no funciona todavia
Honestidad: hay limitaciones reales.
Costo. 150 archivos Markdown son entre 200K y 400K tokens dependiendo de longitud. A precio Opus 4.7, una sesion con vault completo cargado tiene costo de input no trivial. En Projects con cache, el segundo request en adelante es mucho mas barato (cache hit). Sin cache, caro.
Latencia primer token. Con contexto grande, el tiempo hasta primer token sube. En sesiones rapidas de pregunta-respuesta, puede ser molesto. Vale la pena solo para sesiones de orchestration o produccion de contenido donde el resultado justifica el tiempo.
Actualizacion manual. El vault es un directorio local. Obsidian no tiene sync automatico con Claude Projects. Cuando actualizo un archivo, tengo que re-subir manualmente si uso Projects Web. En Claude Code con paths, esto no aplica — lee directo del filesystem.
Organizacion previa obligatoria. Si el vault es un dump de notas sin estructura, cargar 150 archivos genera ruido, no contexto. El modelo puede buscar en el contexto, pero si no hay ancla (CLAUDE.md, indices, estructura clara), las respuestas bajan en calidad. El segundo cerebro funciona porque tiene arquitectura. Un vault desordenado con 1M context es 1M tokens de confusion.
Lo que cambia con 1M context vs 200K
La diferencia no es cuantitativa — es cualitativa. Con 200K context, tenia que elegir que cargar. Vault parcial: cargo Memory/ pero no Agents/. Cargo Proyectos/ pero no Resources/. Siempre habia trade-off de que contexto sacrificar.
Con 1M context, cargo todo el vault de una. El modelo tiene el ecosistema completo simultaneamente. No hay que priorizar porque cabe todo.
Eso habilita workflows que antes no eran practicos: agentes que leen su propio AGENT.md + el blackboard + los brand kits + la estrategia de la submarca + los posts existentes de referencia — todo en el mismo contexto, sin chunks ni recuperacion.
El aprendizaje meta
1M tokens de contexto no es una feature de productividad generica. Es un habilitador especifico para quien ya tiene un sistema de conocimiento estructurado y quiere que el modelo opere dentro de ese sistema, no fuera de el.
Si el sistema no existe, mas contexto solo amplifica el ruido.
El vault esta en Obsidian, estructura libre. El sistema de agentes esta en Agents/ del vault, formato AGENT.md agnostico al LLM. Si construis algo similar, ese es el punto de partida: estructura antes de contexto.