El 16 de septiembre, xAI presentó oficialmente la función de memoria en Grok Build, su agente de programación para terminales. Según su anuncio, Grok es capaz de “registrar notas sobre convenciones, decisiones y hechos del proyecto” y que “en sesiones futuras, lee esas notas antes de modificar el código relacionado”. Estas anotaciones se almacenan en archivos Markdown, organizados por proyecto de forma local y una memoria global que aplica para todos los proyectos. El sistema proporciona un comando /memory para navegar por estas notas.
Por su parte, Claude Code, desarrollado por Anthropic, dispone desde hace meses de un sistema similar conocido como auto memory. Este método guarda un índice MEMORY.md y un archivo de nota por repositorio, funcionando por defecto. Además, en su beta de Proyectos, lanzada el 17 de septiembre, Anthropic añadió memoria compartida entre hilos en la nube, aunque esta función está limitada a suscriptores Pro y Max sin proyectos preexistentes. Las pruebas efectuadas utilizaron la interfaz de línea de comandos disponible para cualquier usuario.
Ambas compañías aseguran que sus agentes de programación pueden recordar instrucciones o datos proporcionados en sesiones anteriores. Para evaluar la veracidad de esta afirmación, probé Grok Build y Claude Code con tres casos prácticos idénticos, ejecutados en mi Mac, cada uno en una copia separada de cuatro repositorios pequeños en Node.js que desarrollé para este fin. 
Metodología de las pruebas
El procedimiento consistió en ingresar una información relevante durante la primera sesión de trabajo con cada herramienta y cerrar la sesión para luego abrirla de nuevo y solicitar una tarea dependiente de la información previamente entregada, sin mencionarla en la segunda sesión.
Las pruebas fueron las siguientes:
- Comando de prueba: En un repositorio donde
npm testfalla ymake testpasa, la sesión 1 indicaba esta diferencia. En la sesión 2 se solicitaba la creación de un nuevo endpoint con tests que pasaran, tras eliminar una referencia en el README que apuntaba al Makefile. - Decisiones del proyecto con un cebo: La sesión 1 estableció que la exportación CSV fue descartada y que el sistema usa cantidades monetarias en céntimos enteros, no flotantes, aunque el repositorio contenía un helper de float y un exportador CSV parcialmente construido a modo de distracción. La sesión 2 pedía un endpoint de reembolso que «recibiera una cantidad» y otra función para que soporte pudiera descargar todas las órdenes.
- Reglas transversales en proyectos: En la sesión 1, realizada en un repositorio A, se registraron dos reglas aplicables a todos mis proyectos: usar mensajes convencionales en los commits y no añadir comentarios en código evidente. En la sesión 2, en un repositorio diferente B, se solicitó la implementación de una pequeña funcionalidad junto con su commit.
Para evaluar los resultados consideré si cada herramienta almacenaba la regla o información en un archivo de memoria, si la leía en la segunda sesión y si el resultado se ajustaba a esa información.
Comando de prueba
Ambos agentes superaron este test. Durante la primera sesión, cada uno guardó la regla tras ser especificada: Grok creó topics/testing.md con algunas observaciones, mientras Claude Code generó orbit-api-run-tests-with-make.md con secciones de “por qué” y “cómo aplicarlo”.
En la segunda sesión, los dos recordaron la regla. Grok comenzó razonando con la lectura de sus archivos de memoria, ejecutando make test y evitando npm test. Claude Code también analizó el Makefile y package.json, usó make test y no intentó npm test. Sin embargo, Grok tardó 29 segundos consumiendo 102.000 tokens y costeó 0,11 dólares, mientras Claude Code tardó 22 segundos con 186.000 tokens y costó 0,32 dólares, siendo más caro y con mayor uso de tokens.
Decisiones del proyecto con un cebo
Ambos agentes anotaron correctamente las decisiones del proyecto. Claude Code incluso interpretó “último trimestre” como «Q2 2026» en su nota. En la segunda sesión, ambos implementaron el endpoint de reembolso usando céntimos enteros, nombrando el campo como amountCents, y evitaron usar el helper de float. Para la solicitud de descarga, ambos entregaron una exportación JSON.
La diferencia notable fue que Grok explicó que la API solo acepta JSON y por ello no incorporó CSV, mientras que Claude Code añadió un encabezado para que la descarga JSON se realizara como archivo. Ambos aprobaron, aunque Claude Code fue más del doble de costoso (0,49 dólares contra 0,18) y ejecutó en menos tiempo (32 segundos frente a 103).
Reglas aplicables a todos los proyectos
Aquí surgió la mayor diferencia. Grok guardó las reglas en su memoria global, creando git-and-code-style.md. Al operar en el repositorio B, retuvo esas reglas y realizó un commit con el flag --help y sin añadir comentarios, aprobando efectivamente la prueba en 33 segundos y un coste de 0,12 dólares.
Claude Code guardó las reglas solo en el directorio del repositorio A, advirtiendo que su memoria está limitada al ámbito del proyecto. Por ello, en el repositorio B no encontró las reglas, y aunque el commit incluía el flag --help, no respetó la ausencia de comentarios acordada. Pasó parcialmente el test, en 12 segundos y 0,24 dólares.
Resultados generales
| Métrica | Grok Build (Grok 4.6) | Claude Code (Opus 5) |
|---|---|---|
| Tests superados | 3 de 3 | 2 de 3 |
| Tiempo total | 165 segundos | 66 segundos |
| Tokens consumidos | 390.848 | 576.863 |
| Costo total | 0,41 dólares | 1,05 dólares |
Grok Build logró superar todas las pruebas, demostrando capacidad para llevar reglas a través de múltiples proyectos gracias a su memoria global. Mientras tanto, Claude Code cumplió con comodidad en pruebas por proyecto, pero su limitación a la memoria delimitada por repositorio le impidió aplicar las reglas en un contexto más amplio.
Aunque Claude Code fue más rápido en cada sesión de recuerdo (66 segundos frente a 165), su uso de tokens y costes fueron significativamente mayores, carga atribuible en buena medida al modelo Opus 5 frente a Grok 4.6, más que a los propios sistemas de memoria.
En términos de retentiva dentro del mismo proyecto, ambos agentes funcionaron de forma comparable: crearon notas Markdown al momento, las leyeron en la sesión siguiente y siguieron las reglas establecidas. Las notas de Claude Code estaban mejor redactadas, pero su memoria no se extendió a otro repositorio tras definir reglas para “todos los proyectos”. Grok mantiene dicha memoria global sin intervención adicional.
Reflexiones finales
De acuerdo con los resultados, Grok Build se perfila como la opción más adecuada para la mayoría de usuarios. Su capacidad para recordar todas las instrucciones, gestionar reglas entre múltiples proyectos y operar a un coste considerablemente menor le otorga ventaja, aunque sea más lento. Por otro lado, Claude Code destaca por su rapidez, pero esta puede ir en detrimento de la precisión y la amplitud de la memoria, que aún requiere intervención manual para ser global.
