Cambiar modelo en Claude Code: qué pasa con tu contexto

TL;DR: Cambiar de Sonnet a Opus (o al revés) en mitad de una sesión de Claude Code no traslada igual tu contexto. La transcripción se conserva, pero la ventana efectiva, la caché de prompt y la calidad de los siguientes turnos sí cambian. Antes de cambiar de modelo, conviene pensar si lo que necesitas es otro razonamiento o simplemente una sesión más limpia.

El problema: cambios de modelo en caliente

En Claude Code es trivial alternar modelo dentro de una misma sesión: /model sonnet y luego /model opus cuando una decisión se complica. La fricción aparece después: respuestas más lentas en los primeros turnos, coste por token que sube sin previo aviso y, a veces, una sensación rara de que el agente "ha olvidado" algo que sí estaba escrito un par de turnos atrás.

La duda viene apareciendo en hilos recientes de la comunidad sobre ventanas de 1M de tokens y comportamientos distintos entre Sonnet 4.6 y modelos más capaces como Opus 4.7. La respuesta corta es que el contexto no es un único contenedor que viaja contigo, sino tres capas que reaccionan distinto al cambio de modelo.

¿Qué es la ventana de contexto en Claude Code?

La ventana de contexto es el número máximo de tokens que un modelo puede procesar en una sola llamada, sumando system prompt, transcripción, archivos cargados y la respuesta. En Claude Code esa ventana depende del modelo activo, no de la sesión. Cuando cambias de modelo, la transcripción no se trunca, pero el modelo nuevo aplica su propio límite y descarta lo que sobra desde el extremo más antiguo.

Esto importa porque el descarte no es transparente: el modelo simplemente no ve lo que quedó fuera. Si cargaste tres archivos al principio y luego trabajaste 90 turnos, esos archivos pueden haberse caído del extremo silenciosamente.

Las tres capas que cambian al cambiar de modelo

Para entender qué se conserva y qué no, ayuda separar el contexto en tres capas distintas:

Capa	Qué guarda	Qué pasa al cambiar modelo
Transcripción	Mensajes user/assistant y tool calls	Se conserva entera; la verás igual
Ventana efectiva	Cuántos tokens puede leer el modelo	Cambia: lo viejo se cae si no entra
Caché de prompt	Bloques precomputados para abaratar coste	Se invalida total o parcialmente

La capa que más sorprende es la caché de prompt. Claude Code la usa para reducir coste en sesiones largas: bloques estables (system prompt, CLAUDE.md, archivos cargados al principio) se cobran a precio reducido si se mantienen idénticos entre llamadas. Al cambiar de modelo, esa caché deja de coincidir con el destino y los siguientes turnos pagan tarifa completa hasta que se recompone.

El caso real: Sonnet explora, Opus decide

En sesiones largas un patrón que funciona es usar Sonnet para la fase exploratoria, donde hay muchas lecturas de archivos y poca toma de decisiones, y reservar Opus para los puntos donde una mala elección arquitectónica te cuesta horas. El error frecuente es cambiar a Opus demasiado pronto, cuando la transcripción todavía está cargada de outputs de búsqueda y archivos completos sin filtrar.

Cuando Opus arranca leyendo 80 mil tokens de exploración, dos cosas ocurren: la primera respuesta tarda mucho más y, peor, el razonamiento se diluye en ruido. Si antes de cambiar pides a Sonnet un resumen breve de los hallazgos, Opus llega a una mesa preparada y rinde mejor.

Cuándo /compact ayuda y cuándo no

El comando /compact resume la transcripción para liberar tokens. Es útil en sesiones largas donde la mayor parte del valor ya está condensable: decisiones tomadas, archivos leídos, plan acordado. No funciona bien cuando la sesión está llena de outputs ricos en detalle que tendrías que volver a buscar al expandir.

Reglas prácticas que me funcionan:

• Compacta una sola vez por sesión. Más allá, la pérdida de matices se acumula.
• Si vas a cambiar de modelo a Opus, compacta antes para que la primera llamada al modelo nuevo sea barata y centrada.
• Si llevas tres horas en la misma sesión, abrir una nueva con un CLAUDE.md actualizado suele rendir más que compactar.

Para quien ya viene aplicando higiene de contexto, este patrón conecta con lo que cubrí en setup de memoria, MCPs y mapa de repo en Claude Code: una sesión limpia con un CLAUDE.md bien curado vence a una sesión heroica de doce horas.

Implementación práctica: protocolo de cambio de modelo

Para no improvisar cada vez, conviene tener un mini-protocolo. El que uso al cambiar de Sonnet a Opus dentro de una sesión:

1. Pide cierre de fase a Sonnet: un resumen de lo aprendido, archivos relevantes y decisiones pendientes en menos de 200 palabras.
2. Ejecuta /compact si la transcripción supera el 60% de la ventana.
3. Cambia con /model opus y, en el primer mensaje, indica explícitamente la decisión que toca tomar.
4. Vuelve a Sonnet tras la decisión, con un resumen de la decisión tomada como nuevo punto de anclaje.

Este enfoque encaja con la lógica de separación de responsabilidades aplicada a tu flujo: cada modelo hace lo que mejor sabe, y tu sesión no acumula trabajo de los dos a la vez.

En Producción

Lo que cambia entre el ejemplo de tutorial y un día de trabajo real:

• Coste: cada cambio de modelo invalida parte de la caché de prompt. En sesiones largas con varios cambios, el coste real puede ser un 30-50% mayor que la misma sesión sin cambios. Si trabajas con presupuestos ajustados (10-50€/mes en API), conviene medir antes de adoptar el patrón ping-pong entre modelos.
• Latencia: Opus 4.7 con 80 mil tokens de contexto inicial puede tardar bastante en el primer turno. Si tienes presión de tiempo, compactar primero ahorra más que cambiar de modelo.
• Trazabilidad: el log de la sesión no marca claramente dónde cambiaste de modelo. Si después necesitas reproducir una decisión, perderás trazabilidad. Anota tú mismo el cambio en un mensaje user explícito.
• Límites por hora: alternar modelos no esquiva los límites de uso del plan, así que un cambio de modelo no te regala cuota extra.

Para el dimensionamiento real de costes con MCPs cargados, vale la pena revisar el ángulo del coste oculto que documenté en posts anteriores sobre tokens ocultos por turno con MCP: el cambio de modelo se nota más cuando ya estás cargando muchos servidores MCP de fondo.

Errores comunes y depuración

Los tres síntomas que veo más a menudo cuando alguien lleva mal el cambio de modelo:

• Error: "el modelo olvidó X que estaba arriba" → Causa: X cayó fuera de la ventana efectiva del nuevo modelo. → Solución: reinyecta X explícitamente o lanza /compact antes del cambio para que X entre en el resumen.
• Error: "la respuesta tras cambiar a Opus tarda muchísimo" → Causa: caché invalidada y prompt pesado. → Solución: resume la transcripción antes del cambio; el primer turno bajará de forma clara.
• Error: "el coste se disparó sin razón aparente" → Causa: múltiples cambios de modelo invalidando caché en cadena. → Solución: reduce el ping-pong; planifica fases largas por modelo.

Si quieres profundizar en cómo detectar contexto inflado antes de que cause problemas, el checklist de contexto desperdiciado da herramientas concretas para diagnosticar la sesión antes de cambiar nada.

Preguntas frecuentes

¿Pierdo el historial al cambiar de modelo en Claude Code?

No pierdes el historial visible: la transcripción sigue ahí. Lo que cambia es cómo el nuevo modelo lo procesa, su ventana efectiva y si reaprovecha la caché de prompt. En la práctica, los primeros turnos tras el cambio cuestan más tokens y suelen ir más lentos.

¿Cuándo conviene cambiar a Opus 4.7 a mitad de sesión?

Cuando Sonnet ya hizo el trabajo de exploración y necesitas una decisión arquitectónica concreta sobre poco código. Cambiar antes de tener el contexto curado desperdicia el cambio: Opus pagará por leer ruido que Sonnet podría haber resumido. Si dudas sobre cuándo merece la pena, revisé el flujo en detalle en Claude Opus 4.7 en tu flujo diario.

¿/compact resuelve el problema de la ventana llena?

Ayuda, pero no es magia. /compact resume la transcripción y libera tokens, aunque pierde matices. Si tu sesión lleva muchos archivos cargados con resultados grandes, suele ser más limpio abrir sesión nueva con un CLAUDE.md actualizado que compactar tres veces seguidas.

Cierre

Cambiar de modelo en Claude Code no es un truco gratis. La transcripción viaja, pero la ventana efectiva y la caché de prompt no, y eso se traduce en latencia, coste y, a veces, en respuestas peores que las que tenías antes. La regla simple que me funciona es tratar el cambio como una transición de fase: cierra lo anterior con un resumen, compacta si toca y entra al nuevo modelo con una pregunta concreta. La mayoría de las veces, abrir sesión nueva con buen CLAUDE.md gana al cambio en caliente.

¿Cómo gestionas tú el cambio de modelo en sesiones largas? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el siguiente post quiero entrar en cómo combinar este patrón con subagentes para que el cambio de modelo deje de ser manual y sea parte del flujo.