Skill review: claude-mem, ¿vale la pena darle memoria persistente a Claude Code?

Si llevas más de un mes usando Claude Code intensamente, ya conoces este dolor: cada sesión nueva arrancas desde cero. Explicas otra vez el stack, otra vez las convenciones, otra vez por qué decidiste tal arquitectura hace dos semanas. Es como tener un consultor brillante con amnesia.

claude-mem ataca exactamente ese problema. Es un skill que le da memoria persistente entre sesiones a Claude Code. Llevo cuatro semanas con él activo en cinco proyectos paralelos. Te cuento sin filtro qué cambia, qué cuida tienes que tener, y cuándo lo descartaría.

Qué es claude-mem y qué problema resuelve

claude-mem funciona como un sistema de corpus. Va capturando observaciones, decisiones y patrones de tus sesiones, los indexa, y los recupera en sesiones futuras cuando son relevantes. No guarda todo el chat. Guarda lo que tú o el modelo marcan como significativo.

El cambio concreto en mi flujo:

• Arranco una sesión nueva y Claude ya sabe que en este proyecto uso Next.js App Router, no Pages.
• Cuando le pido refactorizar algo, recuerda decisiones de arquitectura que tomamos hace dos semanas y por qué.
• Si pregunto "¿por qué ese campo es opcional?", saca de memoria la conversación donde lo discutimos.
• Cuando pruebo algo nuevo, puedo decirle "guarda esto como decisión del proyecto" y queda fijado.

Lo que sí cambia tu flujo diario

Tres ganancias reales, medibles, sin marketing:

Arranque más rápido. Los primeros 10-15 minutos de cada sesión que antes gastaba en re-contextualizar ahora son productivos desde el minuto uno. En proyectos donde abro Claude Code dos veces al día, esto suma horas a la semana.

Decisiones consistentes. Antes me pasaba que en una sesión Claude proponía una solución, y dos días después en otra sesión proponía la contraria sin saber que ya habíamos descartado esa vía. Ahora la memoria evita esa esquizofrenia.

Menos explicar lo mismo. Especialmente útil cuando trabajas con varios clientes en paralelo. Cada proyecto tiene su contexto separado y Claude entra al rol del cliente correcto sin que se lo recuerde.

Lo que tienes que cuidar (la parte que no te cuentan)

No es magia. Hay tres fricciones reales:

Qué guardar y qué no. Si dejas que el skill guarde todo, en dos semanas tu corpus está contaminado de decisiones que cambiaste, hipótesis que descartaste, código de prueba que no debe volver. La disciplina de marcar explícitamente "esto sí es decisión" es crítica. Yo aprendí esto mal: dejé que guardara libre y terminé con sugerencias basadas en código viejo durante una semana hasta que entendí qué pasaba.

Memoria contaminada. Cuando cambias de dirección en un proyecto (migración de stack, pivote de feature), tu memoria vieja se vuelve un lastre. Sigue empujándote hacia las decisiones anteriores. Tienes que limpiar o regenerar el corpus, y eso no siempre es un click.

Rebuild ocasional necesario. Cada cuatro o cinco semanas le hago rebuild al corpus para que se reorganice y descarte ruido acumulado. Toma 10 minutos pero hay que hacerlo. Si no, la memoria se vuelve lenta y a veces irrelevante.

Mi experiencia tras 4 semanas de uso continuo

El momento exacto donde valoré claude-mem fue así: cliente me pidió un cambio pequeño en una feature que habíamos trabajado tres semanas antes. Abro Claude Code en el proyecto, le pido "ajusta el flujo de checkout para soportar X". Sin que yo le explicara nada, Claude recordó que ese proyecto usa Stripe en modo test, recordó la estructura del webhook que armamos, y recordó que la feature de cupones la habíamos descartado por decisión del cliente.

En un mundo sin claude-mem, ese contexto me hubiera tomado 20 minutos explicarlo. Con memoria, fue cero. El cambio total se hizo en 40 minutos. Sin memoria hubiera sido una hora bien larga.

Lo que me hubiera ahorrado si lo hubiera instalado antes: muchas reescrituras de instrucciones, muchas decisiones tomadas dos veces con resultados distintos, y bastante frustración de "ya te lo expliqué".

Cuándo NO instalarlo todavía

No es para todos. Casos donde lo descartaría:

• Proyectos puntuales que terminas en una sesión: no compensa el overhead de setup.
• Workstations compartidas donde otra persona también usa Claude Code: la memoria se mezcla y se vuelve ruido.
• Compliance estricto o trabajo con clientes que no permiten que ninguna información se persista fuera del contexto activo. Aunque la memoria sea local, hay políticas que la prohíben de plano.
• Cuando estás aprendiendo Claude Code. Si llevas menos de un mes, primero domina el flujo sin memoria. Después agregas.

Comparado con alternativas que también probé

Antes de claude-mem usé dos alternativas. La primera: mantener un archivo CONTEXT.md gigante en cada repo, que cargaba al inicio de cada sesión. Funciona pero se vuelve inmanejable después de 200 líneas, y Claude no lo lee selectivamente, lo lee todo. Acaba contaminando el contexto activo.

La segunda: una base de notas en Obsidian que copiaba a mano cuando necesitaba contexto histórico. Más limpio que el CONTEXT.md, pero requiere disciplina alta y el modelo no puede consultarla solo. Demasiado trabajo manual.

claude-mem está más cerca de "memoria que se cura sola con un poco de mantenimiento" que de cualquiera de esas dos. No es perfecto pero es la primera solución de las tres que de verdad usé más de un mes seguido sin abandonar.

¿Recomendado? Sí, fuerte. Pero con la advertencia: trátalo como cualquier base de datos. Si no la curas, se llena de basura. La memoria es poder solo si está bien mantenida. Y eso aplica a tu cabeza también, dicho sea de paso.