Cambio de modelo en Claude Code: qué pasa con el contexto, escenario por escenario

Cambiar de modelo a mitad de sesión con /model sigue haciendo hoy lo mismo que hacía hace un año: el historial de mensajes no se borra, sigue ahí, visible. Lo que no es cierto es que el modelo nuevo reciba siempre ese historial completo palabra por palabra: si no cabe en su ventana de contexto, Claude Code lo compacta antes de que el modelo nuevo lo vea, y lo que ese modelo procesa a partir de ahí es un resumen, no el original. Lo que cambió además, de una generación de modelos a otra, es prácticamente todo lo demás — qué modelos hay detrás del selector, qué ventana trae cada uno y qué automatismos se disparan sin que los pidas.

Esta pieza no explica /model desde cero: da por hecho que ya lo usas y organiza el mecanismo por la situación en la que realmente lo tocas — una sesión larga que se degrada, bajar de modelo a mitad de tarea, subir para una decisión difícil, arrancar algo sin relación con lo anterior, o encontrarte con que el modelo cambió sin que tú lo pidieras. Los nombres de modelo que aparecen (Fable 5, Opus 5, Sonnet 5, Haiku 4.5) son la generación vigente al cierre de esta pieza; el protocolo de qué hacer en cada escenario no depende de esa generación y sigue aplicando cuando cambie.

Qué cambia y qué no cambia al ejecutar /model

Ejecutar /model <alias> no borra el historial de mensajes: las mismas líneas siguen ahí. Lo que cambia con certeza es la caché: cada modelo tiene la suya propia, así que según la documentación oficial de caché de prompts de Claude Code, cambiar de modelo con /model hace que el turno siguiente lea toda la conversación sin ningún acierto de caché, aunque el contenido sea idéntico al de un momento antes — de ahí que el selector pida confirmación cuando ya hay conversación previa. Lo que cambia solo condicionalmente es la ventana: si el historial acumulado no entra en la ventana del modelo nuevo, Claude Code intenta compactarlo antes de que ese modelo lo procese, y lo que recibe entonces es un resumen estructurado, no la conversación completa (qué tan garantizado está esto y qué puede fallar, en el Escenario 2).

Dos límites entran en juego además del precio: la ventana de contexto del modelo nuevo (200K tokens en Haiku 4.5 frente a 1M en Fable 5, Opus 5 y Sonnet 5) y su escala de esfuerzo adaptativo, que no es comparable entre modelos — Haiku no ofrece niveles de esfuerzo ajustables, mientras que Fable 5, Opus 5 y Sonnet 5 sí, con low, medium, high, xhigh y max, según la misma documentación. Si el historial acumulado ya supera la ventana del modelo al que bajas, el primer turno con el modelo nuevo puede disparar una compactación automática antes de que llegues a escribir nada.

Referencia para lo que sigue — instantánea al 11 de agosto de 2026, va a quedar desactualizada; lo que no cambia es la mecánica de arriba:

Fuente: tabla oficial de modelos de Anthropic.

Escenario 1: la sesión lleva horas y las respuestas empiezan a fallar

Esto no es (solo) que el modelo se haya "cansado". En cada turno Claude Code reenvía toda la conversación acumulada, y aunque la documentación de gestión de costes explica que ese reenvío se factura a la tarifa de lectura de caché — más barata que un token nuevo —, sigue siendo tráfico real: una pregunta de una línea en una sesión abierta todo el día arrastra el coste de toda la conversación. Dos cosas rompen además esa caché: una pausa más larga que su vida útil (una hora en plan de suscripción, cinco minutos con clave de API o créditos de uso) o una tarea programada que dispara en segundo plano mientras la sesión está inactiva.

Diagnóstico antes de decidir nada: ejecuta /context para ver el desglose real de qué ocupa la ventana (prompt de sistema, memoria, herramientas MCP, mensajes) y /usage para comprobar si Claude Code ya marcó "contexto largo" o "fallos de caché" como el 10% o más del uso reciente. Esa marca es una atribución de coste, no un diagnóstico de causa: dice que el contexto largo pesa en lo que estás pagando, no que sea la razón concreta de que las respuestas hayan empeorado. Sirve para decidir si merece la pena intentar compactar antes de sospechar del modelo en sí, no como prueba de que el contexto sea el culpable.

Decisión: si el desglose confirma que el historial viejo es peso muerto, compacta con foco explícito en vez de dejar que la compactación automática decida qué se pierde:

/compact enfócate en las decisiones de arquitectura y el estado de los tests, descarta la exploración inicial

Con la caché todavía caliente esto sale más barato de lo que sugiere el tamaño de la conversación: según la misma documentación de caché de prompts, la petición de resumen lee el historial previo desde caché y el coste real es generar el resumen nuevo. El turno caro es compactar después de una pausa más larga que la caché, o al reanudar una sesión antigua — ahí sí se reprocesa todo sin descuento.

Verificación: repite /context y confirma que el porcentaje bajó; si configuraste una barra de estado con el uso de contexto, el indicador de porcentaje lo refleja de inmediato, sin esperar al siguiente turno.

Escenario 2: quieres bajar a un modelo más barato a mitad de tarea

El caso típico: terminaste la parte que exigía razonamiento y lo que queda es mecánico (renombrar, aplicar un patrón repetido, generar boilerplate). Bajar de Sonnet a Haiku parece obvio, pero hay una trampa de ventana: Haiku 4.5 solo tiene 200K tokens de contexto frente al 1M nativo de Sonnet 5. Si la sesión ya acumuló más de 200K tokens de historial, Claude Code intenta compactar automáticamente para encajar en la ventana nueva del modelo nuevo — y esa compactación, cuando se dispara, la decide el resumen automático, no tú. No está garantizada: si el umbral de auto-compactación está desactivado, fijado en otro valor, o si ni compactando queda espacio para el resumen, el turno puede fallar directamente con el error Prompt is too long en vez de resolverse solo, según la referencia de errores de Claude Code.

Decisión: si te importa qué se conserva del historial, compacta tú primero, con instrucciones, y luego baja de modelo, no al revés:

/compact conserva los cambios de archivo y el motivo de cada uno, descarta la salida de los tests intermedios
/model haiku

Para trabajo mecánico verdaderamente aislado (un lote de renombres, una extracción de constantes en 40 archivos), suele salir más barato delegarlo a un subagente con model: haiku en su configuración que bajar de modelo la sesión principal entera: el subagente corre en su propia ventana de contexto y no fuerza una compactación de tu conversación principal.

Verificación: /status confirma el modelo activo; /context muestra el nuevo techo de ventana (200000 en vez de 1000000) para saber cuánto margen real queda antes de la próxima compactación.

Escenario 3: necesitas más capacidad para una decisión puntual

Aquí el riesgo es el inverso de bajar: no hay pérdida de ventana (vas de 200K o 1M a 1M), pero sigues pagando la relectura completa sin caché en el turno del cambio, y otra vez al volver. Según la documentación de configuración de modelo, tres alias cubren tres necesidades distintas: opus para razonamiento complejo puntual, fable para "tus tareas más difíciles y de mayor duración" (investigación ambigua, root-cause de una caída, decisiones de arquitectura donde la verificación extra que hace el modelo por su cuenta compensa la latencia), y opusplan como modo híbrido automático: usa Opus en modo plan y cambia solo a Sonnet en modo ejecución, sin que tengas que alternar tú manualmente en cada ciclo de planificar y ejecutar.

Decisión: una sola llamada difícil en medio de una sesión que por lo demás va bien en Sonnet — sube, resuelve, vuelve:

/model opus
(la decisión puntual)
/model sonnet

Una sesión que va a alternar planificación y ejecución varias veces: arráncala directamente en opusplan en vez de hacer ese vaivén a mano. Una investigación abierta y larga, no una pregunta puntual: /model fable, describiendo el resultado que quieres y no los pasos, porque Fable 5 investiga y verifica su propio trabajo con menos necesidad de que se lo pidas explícitamente.

Verificación: /status muestra el modelo activo; si Claude Code habla directamente con la API de Anthropic (no a través de un gateway ni de Bedrock), el selector /model también muestra el precio de cada fila, útil para confirmar que no quedaste en un modelo más caro de lo que pensabas tras el vaivén.

Escenario 4: arrancas una tarea que no tiene nada que ver con la anterior

La confusión habitual es tratar /compact y /clear como intercambiables porque los dos "liberan espacio". No lo son: /compact envía una petición aparte que lee todo lo que va a resumir — con la caché caliente esa lectura sale al precio de caché y el coste real es generar el resumen, pero si la conversación lleva más tiempo inactiva que la vida útil de la caché, o retomas una sesión antigua, esa misma petición reprocesa el historial completo sin ningún descuento. /clear, en cambio, arranca una conversación vacía sin releer nada: no cuesta tokens en ningún caso. Si la tarea nueva no comparte contexto con la anterior, compactar es pagar — poco o mucho, según el estado de la caché — por resumir algo que vas a ignorar de todas formas.

Decisión: sin relación real entre tareas, usa /clear, no /compact. Si crees que vas a querer retomar la sesión anterior más tarde, dale nombre antes de borrarla:

/rename refactor-auth-modulo
/clear

Lo que se carga de cero en cualquier sesión nueva tras /clear es el prompt de sistema, CLAUDE.md, la memoria automática (el MEMORY.md de auto memory, releído desde disco de forma independiente al historial) y el listado de habilidades y de herramientas MCP disponibles. Nada del historial de mensajes ni de los resúmenes de compactaciones previas pasa a la sesión nueva — pero lo que Claude ya había anotado en la memoria automática antes del /clear sí persiste, porque vive en disco y no en la conversación. Esa memoria automática es un mecanismo aparte, con su propia disciplina de curación; para profundizar en qué merece guardarse ahí y qué no, ver memoria persistente en Claude Code.

Verificación: ejecuta /usage en la sesión nueva y confirma que el coste total arrancó en $0 — desde la versión 2.1.211 de Claude Code ese contador se reinicia en cada /clear en vez de acumularse durante toda la vida del proceso, según la documentación de costes. Con /resume puedes volver más tarde a la sesión que renombraste antes de limpiar, pero eso es distinto de persistir en la memoria automática: /rename + /resume te devuelve la transcripción exacta de esa sesión concreta, mientras que la memoria automática es conocimiento que sobrevive aunque nunca vuelvas a abrirla y que comparten todas las sesiones nuevas del mismo repositorio.

Escenario 5: el modelo cambió solo, sin que tocaras /model

Hay dos mecanismos distintos detrás de esto y conviene no confundirlos. El primero es un fallback por disponibilidad: si configuraste una cadena con --fallback-model o el ajuste fallbackModel, Claude Code prueba el siguiente modelo de la lista cuando el principal está saturado o no responde, pero el cambio dura solo ese turno — el siguiente mensaje vuelve a intentarlo con tu modelo principal automáticamente, sin que hagas nada.

El segundo es distinto y persistente: fallback automático por contenido. Fable 5 y Opus 5 corren con clasificadores de seguridad para contenido de ciberseguridad y biología; si una petición activa el clasificador, Claude Code repite esa petición en un modelo de reserva (Opus 5 u Opus 4.8 según el caso, detallado en la documentación de configuración de modelo) y, a diferencia del fallback por disponibilidad, la sesión se queda en ese modelo de reserva hasta que tú la devuelvas manualmente con /model. Puede dispararse en el primer mensaje de la sesión, antes de que escribas nada inusual, porque esa primera petición ya incluye tu CLAUDE.md y el estado de git como contexto.

Diagnóstico: el aviso de cambio aparece en la propia transcripción, nombrando el modelo original y el de reserva. Si sospechas que es tu configuración (CLAUDE.md, una skill, un servidor MCP) la que dispara el clasificador y no el contenido de tu petición, arranca una sesión de control con claude --safe-mode, que desactiva esas personalizaciones mientras mantiene el estado de git.

Decisión y verificación: si el fallback fue por disponibilidad, no hay nada que hacer — se resuelve solo en el turno siguiente. Si fue por contenido y quieres seguir en el modelo original, /model fable (o el alias que corresponda) te devuelve a él explícitamente; /status confirma cuál quedó activo.