Cómo cambiar a GLM-5.3 sin perder la memoria de tu agente (2026)

Comienza con qué es GLM-5.3, porque eso define la respuesta. Z.ai dice: "Escalar el post-entrenamiento es todo lo que hicimos para GLM-5.3"; utiliza el mismo modelo base que GLM-5.2, y cada mejora proviene del post-entrenamiento. Las mejoras reportadas son reales y específicas: Terminal-Bench 3.0 pasa de 4.6 a 28.3, DeepSWE v1.1 de 46.2 a 66.9, Agents' Last Exam (CLI) de 23.8 a 28.5, y Z.ai afirma "una mejora del 50% sobre GLM-5.2 en nuestro Z.ai Code Bench interno". Dos notas honestas sobre este último número: Z.ai Code Bench es el benchmark privado de Z.ai, descrito por la empresa como reductor del "riesgo de contaminación de conjuntos de prueba públicos", y la misma sección dice "GLM-5.3 sigue estando por detrás de Claude Fable 5, que alcanza el 39.5% con el máximo esfuerzo". Los pesos tampoco han salido aún: "Liberaremos los pesos en dos semanas después del lanzamiento, una vez que se completen la evaluación de seguridad y el endurecimiento".

Nada de eso cambia lo que sabe tu agente. Un cambio de modelo cambia lo que realiza el razonamiento; no toca el sustrato del que lee el razonamiento. Y la propia documentación para desarrolladores de Z.ai lo dice, en una página sobre memoria que describe el mecanismo mejor que la mayoría de las documentaciones de proveedores: "La memoria permite a un agente de programación retener el contexto a través de tareas y sesiones, reduciendo la entrada repetida y mejorando la eficiencia de ejecución", y, para la herramienta que utiliza como ejemplo principal, "cada sesión comienza con una ventana de contexto fresca. El conocimiento se transfiere a través de las sesiones principalmente mediante archivos de instrucciones persistentes".

Así que la lista de transferencia se divide claramente.

Se mueve gratis, porque está en tu repositorio o en tu directorio de inicio. Archivos de instrucciones: CLAUDE.md, AGENTS.md, .cursor/rules, o lo que sea que lea tu herramienta. Reglas con alcance de ruta. Habilidades. Configuración del servidor MCP, que es un archivo de configuración que apunta a un servidor, no una capacidad del modelo. Tu historial de git, tu suite de pruebas, tus comandos de compilación. Si el conocimiento de tu agente sobre tu proyecto está escrito en algún lugar que mostraría un diff, el cambio de modelo es invisible para él.

No se mueve, y nada te lo advierte. Cualquier cosa que el modelo anterior haya acumulado dentro de una sesión activa: el plan que construyó, los callejones sin salida que descartó, la corrección que le diste hace una hora. Eso era contexto, y el contexto termina con la sesión, independientemente del modelo que uses a continuación. Cualquier cosa que una herramienta haya escrito en un almacenamiento de memoria local y específico de la herramienta también se queda donde está: sigue en el disco, pero fue escrito por y para una configuración diferente, y si cambiaste de herramientas al mismo tiempo que de modelos, no se leerá en absoluto.

El punto medio incómodo. Los archivos de memoria autogenerados se encuentran en el medio. Son archivos, por lo que sobreviven, pero fueron escritos como una compresión de sesiones con un modelo diferente, y su utilidad depende de si las notas eran hechos duraderos ("las pruebas de la API necesitan una instancia local de Redis") o reacciones a cómo se comportaba un modelo ("recuérdale que no reformatee todo el archivo"). El primer tipo vale la pena conservarlo. El segundo tipo es ruido que estás a punto de llevar a un modelo que nunca tuvo ese hábito.

Dos pasos, en este orden. El primero no es opcional: omítelo y tus solicitudes fallarán por completo.

Paso 1: Corrige la configuración de pensamiento antes de cambiar el ID del modelo

GLM-5.3 cambió un valor predeterminado en la estructura de la solicitud, y Z.ai lo señala como un cambio disruptivo (breaking change). Del anuncio: "GLM-5.3 admite tres niveles de esfuerzo de pensamiento: bajo, alto y máximo. Deshabilitar el pensamiento ya no es compatible con GLM-5.3". La nota de migración documentada es explícita: "Migración requerida: si tu aplicación utiliza actualmente thinking.type: "disabled", cámbialo a enabled y establece reasoning_effort en low antes de actualizar el ID del modelo a glm-5.3. De lo contrario, la solicitud fallará".

Cambia la configuración primero, luego el ID del modelo. Invertir ese orden produce solicitudes fallidas que parecen una caída del servicio, y el reasoning_effort predeterminado es max, que Z.ai recomienda para programar pero que no es un reemplazo directo para un flujo de trabajo que antes funcionaba con el pensamiento desactivado. Si estás integrando esto en una herramienta existente en lugar de en tu propio código, Z.ai documenta que "GLM Coding Plan admite tanto los protocolos de Anthropic como de OpenAI" con URLs base separadas por protocolo (el endpoint de Anthropic Messages es https://api.z.ai/api/anthropic), por lo que el cambio del lado de la herramienta suele ser una URL base más una clave. Los usuarios de Team Plan deben tener en cuenta la restricción documentada de que "La clave de Team Plan no es intercambiable con otras claves de API de Z.AI".

Paso 2: Haz un inventario de lo que vivía fuera de tus archivos

Este es el paso que la gente se salta, y es el que pasa factura una semana después. Antes de cambiar, siéntate con el repositorio y escribe las respuestas a cuatro preguntas. No en tu cabeza: en un archivo.

¿Qué sabía el agente que no está escrito en ningún lado? Cada convención que corregiste en el chat en lugar de hacer un commit. Cada "aquí no lo hacemos de esa manera" que surgió a mitad de la sesión. Si tu único registro es una sesión que está a punto de terminar, se habrá ido.

¿Qué descartaste y por qué? Los enfoques rechazados son el conocimiento de mayor valor y menor durabilidad en cualquier proyecto. Un nuevo modelo no tiene idea de que ya probaste la versión basada en colas y la abandonaste, por lo que la propondrá de nuevo con entusiasmo. Escribe el rechazo y la razón, porque la razón es lo que detiene el bucle.

¿Qué instrucciones eran sobre el modelo antiguo y no sobre tu proyecto? Depúralas ahora. Las instrucciones que existen para solucionar los hábitos de un modelo específico son un lastre en el mejor de los casos y activamente engañosas en el peor: le enseñan a un nuevo modelo a defenderse de un problema que no tiene. La página de memoria de Z.ai incluye una advertencia relevante: el agente "las leerá e intentará seguirlas, pero no puede garantizar el cumplimiento estricto cuando las reglas son vagas, poco claras o conflictivas". Un montón de soluciones temporales obsoletas es exactamente cómo las instrucciones se vuelven conflictivas.

¿Qué está repartido entre máquinas? Si trabajas en una laptop y en una estación de trabajo, verifica si la memoria que generó tu herramienta es local de la máquina. La mayor parte lo es. Un cambio de modelo es un buen momento para notar que la mitad del conocimiento acumulado de tu agente solo existe en una computadora, el mismo problema tratado en por qué Claude Code olvida entre máquinas, y no mejora por sí solo.

Una vez que ese inventario existe como un archivo en el repositorio, el cambio de modelo es genuinamente un cambio de configuración. Sin él, dependes de recordar cosas que has estado delegando en una herramienta durante meses.

El inventario anterior funciona, y deberías hacerlo una vez. Lo que no deberías hacer es hacerlo cada vez, y si el ritmo de lanzamiento de GLM-5.3 es alguna señal, "cada vez" ahora significa cada pocas semanas. La alternativa es dejar de tratar el conocimiento de tu agente como una propiedad de cualquier modelo que estés ejecutando y darle un hogar propio que cualquier modelo pueda leer.

Para eso está MemoryLake: una capa de memoria a la que se conectan tus herramientas, de modo que el conocimiento sobre tu proyecto viva en un solo lugar y el modelo detrás de él se convierta en una pieza intercambiable. Cambia a GLM-5.3 hoy y a otra cosa el próximo mes; la memoria no se mueve, porque nunca estuvo dentro del modelo. La configuración consta de tres pasos.

Paso 1: Crea una clave de API

Inicia sesión en MemoryLake y crea una clave de API. Esta es la credencial que usan tus herramientas para leer y escribir memoria, y es la única parte de la configuración que no es específica de un editor, lo cual es el punto, ya que el objetivo principal es tener una capa que sobreviva a tu elección de herramienta actual.

Paso 2: Sube tus primeras memorias

Sube el inventario que acabas de escribir, además de los documentos que realmente explican tu proyecto: notas de arquitectura, el registro de decisiones, documentos de incorporación, las restricciones de diseño que nadie había escrito hasta ahora. Aquí es donde pertenecen las entradas de "por qué lo rechazamos", porque son las entradas que un modelo nuevo necesita con más urgencia y que es menos probable que infiera. Mantén las entradas cortas y fácticas; una capa de memoria se gana su lugar al ser recuperable, no por ser larga.

Paso 3: Conecta tu IA y agentes

Conecta las herramientas que realmente usas. MemoryLake expone la memoria a través de MCP y de una API, por lo que los agentes con soporte nativo de MCP (como Claude Code, Codex, OpenClaw, entre otros) se conectan apuntando al servidor MCP, y cualquier otra cosa puede leer la misma memoria a través de la API. Si estás ejecutando GLM-5.3 dentro de una de esas herramientas, esta es la parte que hace que el cambio de modelo sea aburrido: el agente sigue leyendo la misma memoria que leía ayer, con un modelo diferente realizando la lectura. Para una guía paso a paso del lado de MCP, consulta cómo configurar la memoria cruzada de IA con MCP.

Un límite honesto: MemoryLake almacena lo que tú o tus agentes ponen en él. No accede a una sesión finalizada de un modelo anterior para recuperar lo que se dijo allí, y no sustituye el escribir tus convenciones. Elimina el tener que volver a explicar, no el decidir.

La diferencia práctica aparece la tercera o cuarta vez que cambias de modelo, no la primera.

La elección del modelo se vuelve reversible. En este momento, la mayoría de los equipos tratan un cambio de modelo como un compromiso porque volver atrás significa reconstruir el contexto dos veces. Cuando el contexto vive fuera del modelo, puedes ejecutar GLM-5.3 en un repositorio durante una semana, compararlo con lo que estabas usando y volver atrás sin pagar un impuesto en ninguna dirección. Dado que los pesos de GLM-5.3 aún tardarán dos semanas en salir tras el lanzamiento, mantener la opción abierta tiene un valor evidente.

Los benchmarks dejan de ser toda la decisión. Los números de Terminal-Bench te dicen algo real sobre la capacidad. No te dicen nada sobre si el modelo sabe que tu módulo de facturación es crítico. Los equipos que separan ambos aspectos toman mejores decisiones de modelo, porque pueden evaluar el modelo por sus propios méritos en lugar de por cuánta información del proyecto perderían.

El gasto de tokens disminuye por una razón aburrida. El propio enfoque de Z.ai sobre la eficiencia de GLM-5.3 es que "ofrece resultados de programación agéntica notablemente más sólidos que GLM-5.2 en cada nivel de esfuerzo, consumiendo al mismo tiempo menos tokens de salida". La memoria recuperada empuja en la misma dirección desde el otro extremo: un agente que puede buscar tus convenciones no necesita que se las pegues en cada prompt. Si has estado volviendo a explicar el contexto a tu asistente, ese hábito tiene un costo medible.

La rotación de olas de modelos deja de ser disruptiva. Este es el cuarto o quinto lanzamiento notable de modelos de programación en este trimestre. Los equipos que experimentan cada uno como una actualización en lugar de una migración son aquellos cuya capa de conocimiento dejó de estar ligada al almacenamiento de sesiones de un proveedor.

Cambia una variable a la vez. Cambia el modelo o cambia la herramienta, no ambos en la misma tarde. Cuando algo empeore, querrás saber qué cambio lo causó.

Vuelve a leer tus archivos de instrucciones después del cambio. Las soluciones temporales específicas del modelo se acumulan de forma invisible. Un nuevo modelo es la oportunidad más barata que tendrás para eliminarlas, y eliminarlas mejora notablemente el cumplimiento de las reglas que quedan.

Verifica qué se cargó, no lo asumas. Cualquiera que sea la herramienta que uses, generalmente hay una manera de listar qué archivos de instrucciones y memoria entraron en la sesión. Compruébalo una vez después del cambio. Un archivo de reglas que no se cargó silenciosamente se ve exactamente como un modelo que dejó de seguir instrucciones.

Mantén separados los hechos duraderos de las reacciones de la sesión. "Usa pnpm, nunca npm" es duradero. "Deja de reescribir todo el archivo" es una reacción al comportamiento de un modelo. Archivarlos en el mismo lugar es la forma en que los archivos de instrucciones se echan a perder.

Establece el nivel de esfuerzo deliberadamente. GLM-5.3 tiene como valor predeterminado max, y Z.ai recomienda max para programar. Si tu carga de trabajo consiste principalmente en búsquedas cortas, low existe por una razón, y si migraste desde una configuración con thinking: disabled, low es el punto de partida documentado equivalente.

Escribe los rechazos como entradas de primera clase. Cada modelo que uses propondrá aquello que ya descartaste a menos que la decisión esté escrita en algún lugar que pueda leer. Este único hábito ahorra más tiempo que cualquier ajuste de configuración.

GLM-5.3 es una prueba inusualmente limpia de si tu configuración es portátil. Nada en tus herramientas tiene que cambiar, por lo que nada oculta la respuesta: si el conocimiento de tu agente sobre tu proyecto sobrevive a un cambio de modelo, estaba escrito en algún lugar duradero, y si no, estuvo viviendo en una sesión todo el tiempo.

Corrige la configuración de pensamiento antes de cambiar el ID del modelo, haz el inventario una vez y coloca los resultados en un lugar que no esté ligado a ningún modelo que actualmente esté ganando benchmarks. Así, el próximo lanzamiento (y habrá uno pronto) será una línea en un archivo de configuración en lugar de una semana de volver a explicar. Si estás evaluando varios de estos cambios a la vez, cambiar entre modelos de IA sin perder el contexto cubre el patrón general, y hay guías paso a paso específicas para modelos como Kimi K3 y GPT-5.6.