OpenCode y Graphify: deja de malgastar tokens releyendo tu código
El agente que relee tu proyecto entero cada vez
Imagina que abres una sesión nueva en OpenCode (o en cualquier agente de código) y le sueltas algo simple: “¿qué hace este módulo de pagos? Resúmeme cada archivo”. Pregunta de andar por casa. Y entonces, antes de contestarte, mira lo que hace: abre el README para enterarse de qué proyecto es, luego un archivo de configuración, luego empieza a leerse tus fuentes uno a uno, construyendo una imagen mental desde cero.
Cada una de esas lecturas quema tokens. Y la respuesta que te da al final es solo tan buena como lo que haya conseguido pillar por el camino. Pero lo que de verdad escuece es lo siguiente: cierras esa sesión, vuelves mañana, y empieza otra vez de cero. Sin memoria de nada. Como el protagonista de esas películas que se despierta cada día sin recordar el anterior.
Ese es el problema. Y tiene solución.
Por qué pasa esto: el agente no tiene memoria
Los agentes de código, por defecto, no recuerdan tu proyecto entre sesiones. Cada vez que arrancan, están a oscuras: no saben cómo se estructura tu código, qué depende de qué ni dónde está cada cosa. Así que hacen lo único que pueden: leer archivos sobre la marcha para hacerse una idea.
Esto tiene dos costes. Uno, tokens: releer medio proyecto en cada sesión es carísimo, y te acerca a los límites de uso a toda velocidad. Dos, calidad: el agente solo conoce lo que ha alcanzado a leer en esa sesión, así que se pierde conexiones importantes que están en archivos que no llegó a abrir. Trabaja con una foto parcial.
Qué hace Graphify
Aquí entra Graphify. La idea es elegante: escanea tu base de código una sola vez y construye un grafo de conocimiento de cómo se conecta todo (qué depende de qué, cómo se relacionan los módulos, dónde vive cada pieza). Es, básicamente, un mapa del proyecto.
A partir de ahí, el agente, en vez de releerse los archivos uno a uno cada sesión, lee ese grafo al arrancar. De un vistazo tiene la arquitectura completa: sabe que el módulo de pagos depende de tal otro, que esto conecta con aquello, sin haber abierto cien ficheros. Por lo que se ha mostrado, Graphify hace su trabajo en varias pasadas, lo procesa en local y se integra con OpenCode mediante su instalación (un par de comandos del tipo graphify install y la integración con OpenCode), dejando el grafo disponible para que el asistente lo consulte siempre.
El resultado: respuestas más rápidas, más completas (porque el agente ve el mapa entero, no trozos sueltos) y muchísimo más baratas en tokens, porque deja de releer lo que ya conocía.
Por qué esto importa más de lo que parece
Esto va de algo de fondo: darle memoria y estructura al agente. Es la misma idea que vengo repitiendo con el harness engineering: el modelo rinde mucho mejor cuando le rodeas de un buen entorno. Aquí, ese entorno es un mapa persistente de tu código en lugar de obligarle a redescubrirlo cada mañana.
Y el ahorro no es menor. Si trabajas a diario sobre un proyecto grande, releerlo entero en cada sesión es de lo que más tokens te come. Cambiar eso por “lee el grafo una vez” puede ser la diferencia entre chocar con el límite a mediodía o no tocarlo. Para un equipo, multiplícalo por cada desarrollador y cada día.
Un par de matices honestos
Para no vendértelo como la panacea:
- El grafo hay que mantenerlo. Si tu código cambia mucho, el mapa tiene que actualizarse, o el agente trabajará con una foto vieja. No es “instalar y olvidarse” del todo.
- Es una herramienta más del ecosistema, joven y en evolución. Pruébala en un proyecto y mira si te cuadra antes de montarla en todo.
- No sustituye a entender tú tu propio código. Te ayuda a ti y al agente, pero el criterio sigue siendo tuyo.
Cómo encaja en tu flujo
Lo bueno es que esto no te obliga a cambiar de herramienta ni de forma de trabajar. Montas el grafo una vez, dejas que el agente lo consulte, y sigues pidiéndole lo de siempre, solo que ahora arranca sabiendo cómo está tu proyecto en lugar de a ciegas. La primera pregunta de cada sesión deja de ser un viaje de exploración carísimo y pasa a ser una respuesta directa. Para un proyecto que tocas a diario, esa diferencia se acumula sesión tras sesión, y al final de mes se nota tanto en la factura de tokens como en lo rápido que el agente “entra en materia”.
Lo que me llevo de todo esto
El problema que ataca Graphify es real y caro: agentes sin memoria que se releen el proyecto entero en cada sesión, quemando tokens y trabajando con una foto parcial. Darles un grafo de conocimiento del código, un mapa que leen al arrancar, ataca las dos cosas a la vez: gastas menos y el agente entiende mejor.
Si usas OpenCode (o agentes parecidos) sobre proyectos grandes y notas que se te van los tokens en “déjame que me lea esto otra vez”, échale un ojo. Darle memoria a tu agente es de esas mejoras que se notan en la factura desde el primer día.
Preguntas frecuentes
¿Por qué mi agente de código gasta tantos tokens?
Porque, por defecto, no recuerda tu proyecto entre sesiones: cada vez que arranca lee archivos sobre la marcha para hacerse una idea de cómo está todo, y cada lectura consume tokens. En proyectos grandes, releer medio código en cada sesión es de lo que más cuota gasta, y además da respuestas parciales porque solo conoce lo que alcanzó a leer.
¿Qué es Graphify?
Es una herramienta que escanea tu base de código una sola vez y construye un grafo de conocimiento de cómo se conecta todo: dependencias, relaciones entre módulos y dónde vive cada pieza. El agente lee ese grafo al arrancar, en lugar de releerse los archivos uno a uno cada sesión, lo que ahorra tokens y le da una visión completa de la arquitectura.
¿Graphify le da memoria al agente entre sesiones?
En la práctica, sí: en vez de empezar a oscuras cada vez, el agente dispone de un mapa persistente del proyecto que consulta al arrancar. Eso le da una memoria de la estructura del código que antes no tenía, evitando que redescubra el proyecto desde cero en cada sesión. El grafo, eso sí, conviene mantenerlo actualizado si el código cambia mucho.
¿Merece la pena usar Graphify?
Si trabajas a diario sobre proyectos grandes y notas que se te van los tokens en relecturas, sí: el ahorro y la mejora de calidad son notables. Como matiz, hay que mantener el grafo actualizado cuando el código cambia, y es una herramienta joven, así que conviene probarla en un proyecto antes de adoptarla en todo.
Fuentes
Compártelo si te ha resultado útil, sobre todo con quien vea a su agente releer el mismo proyecto cada mañana.
¿Le has dado alguna forma de memoria a tu agente, o relee todo cada vez? Cuéntame.
Y… darle memoria a la máquina resultó ser lo que más me ahorraba.
Artículos relacionados
Harness engineering: por qué el entorno importa más que el modelo
Habrás notado algo raro usando ChatGPT, Claude o Copilot: a veces hacen cosas increíbles y a veces fallan en lo más tonto. Y resulta que gran parte de los saltos de calidad de los últimos tiempos no han venido de modelos más listos, sino de mejores entornos donde esos modelos se ejecutan. A esos entornos se les llama arneses (harness), y a la disciplina de construirlos bien, harness engineering. Aquí te explico qué es un arnés, por qué importa tanto, y cómo dejar de tratar la Inteligencia Artificial como un simple chatbot para empezar a construir sistemas de verdad encima de los modelos. Porque ahora que generar código es fácil y rápido, el problema ya no es escribirlo, es controlar el caballo desbocado que lo genera.
Las 6 estrategias del creador de Claude Code para tus proyectos
Llevamos meses optimizando prompts, creando reglas y ajustando cada parámetro de Claude Code, y resulta que Boris Cherney, el hombre que creó la herramienta, lo hace de una forma muy distinta a la mayoría. En una entrevista reveló las seis estrategias que usa él, y al leerlas te das cuenta de que casi todos lo estábamos haciendo regular. Van desde empezar siempre en modo plan y mantener un CLAUDE.md minimalista, hasta darle a Claude una forma de verificar su propio trabajo, trabajar con varias sesiones en paralelo, encapsular tus tareas repetidas y, la más filosófica de todas, no apostar nunca contra el modelo. Aquí te las cuento una a una, con ejemplos prácticos de cómo aplicarlas hoy mismo para sacarle de verdad el jugo a Claude Code.
Microsoft Build 2026: las novedades que importan a programadores
Microsoft soltó un montón de bombas en la Build 2026, y por una vez muchas apuntan directas a los que programamos. Lo más llamativo: un mini PC desarrollado con NVIDIA, el Surface RTX Spark Dev Box, capaz de ejecutar en local modelos de hasta 120.000 millones de parámetros sin pagar nube; modelos de Inteligencia Artificial propios de Microsoft entrenados desde cero; y una tanda de mejoras para Windows que llevábamos años pidiendo, como usar comandos de Linux en la terminal o contenedores sin instalar Docker. Yo creo que ha sido la Build más interesante para desarrolladores en años, y aquí te cuento lo que de verdad importa, separando lo confirmado de lo que habrá que ver en la práctica.