Hasta ahora, cambiar de modelo a mitad de sesión en Claude Code era una decisión libre y silenciosa: se cambiaba y ya está. La versión 2.1.251 introduce dos hooks nuevos, PreModelSwitch y PostModelSwitch, que permiten bloquear, confirmar o anotar ese cambio. Junto a ellos llegan otras dos piezas del mismo ciclo de versiones que apuntan al mismo sitio: el control de qué corre, cuánto cuesta y qué se ve mientras trabaja.
Se trata de una función que a título individual apenas se nota y que en cuanto hay un equipo o un despliegue gestionado de por medio se convierte en algo bastante más serio: la posibilidad de que la elección de modelo deje de depender del criterio de cada persona en cada momento.
Tres respuestas posibles ante un cambio de modelo
Los hooks de Claude Code funcionan como puntos de enganche declarados en la configuración: cuando ocurre el evento al que están asociados, se ejecuta lo que hayas definido y su resultado condiciona lo que pasa después. PreModelSwitch se dispara antes de que el cambio se materialice y admite tres respuestas: bloquearlo, pedir confirmación explícita o dejarlo pasar dejando constancia. PostModelSwitch actúa una vez consumado, que es donde encaja el registro y la notificación.
La diferencia entre las tres opciones no es solo técnica, es de política interna. Bloquear sirve para entornos donde determinado modelo simplemente no debe usarse, por coste o por acuerdos de residencia de datos. Pedir confirmación sirve para el caso mucho más común: no prohibir, sino obligar a que el salto sea una decisión consciente y no un reflejo. Y anotar sirve para lo que casi nadie tiene hoy, que es un registro de qué modelo hizo qué.
La pregunta que estos hooks permiten responder por primera vez es sencilla: ¿qué modelo escribió realmente este código?
Por qué esto importa en un despliegue controlado
El escenario que Anthropic menciona explícitamente es el de los despliegues por fases, y tiene todo el sentido. Cuando una organización decide adoptar un modelo nuevo, lo habitual es hacerlo por etapas: un grupo reducido primero, el resto después. Ese plan se cae en el momento en que cualquiera puede saltar al modelo que quiera desde su terminal. Un PreModelSwitch que bloquee o pida confirmación es lo que convierte una recomendación en una regla efectiva.
Para quien trabaja solo el valor es distinto pero no menor. En un flujo bien montado, cada tipo de tarea tiene un modelo que le corresponde por relación entre calidad y coste; el problema es que en pleno trabajo se cambia de modelo por inercia y luego se olvida volver atrás. Un aviso en el momento del salto cuesta un segundo y evita descubrir a fin de mes que media semana de tareas rutinarias se ejecutó con el modelo más caro del catálogo.
Hay además un efecto secundario poco evidente: cambiar de modelo invalida la caché de prompts de la sesión. Cada salto obliga a reprocesar el contexto acumulado, así que un cambio hecho a la ligera en una sesión larga no solo altera la calidad de la respuesta, también se paga. En esa línea va otro detalle del mismo ciclo de versiones: los hooks de SessionStart al reanudar una sesión reciben ahora la antigüedad de esa sesión y una estimación del coste de volver a cachearla, información con la que se puede decidir automáticamente si merece la pena retomarla o empezar de cero.
cacheTtl: cada agente decide cuánto vive su caché
La versión 2.1.248, publicada un día antes, añadió una pieza que encaja con lo anterior: experimental.cacheTtl en el frontmatter de cada agente, con valores "5m" o "1h". Es decir, la duración de la caché deja de ser una propiedad global y pasa a declararse agente por agente.
- Cinco minutos encaja con agentes que se invocan de forma puntual, terminan su tarea y no vuelven a aparecer en un buen rato.
- Una hora encaja con agentes que se llaman repetidamente durante una misma sesión de trabajo sobre el mismo contexto, donde mantener la caché caliente evita reprocesar lo mismo una y otra vez.
La etiqueta experimental obliga a la cautela habitual: puede cambiar de nombre o de comportamiento sin previo aviso, así que conviene no montar nada crítico encima. Aun así, es un ajuste de una línea en el archivo del agente y el tipo de decisión que se toma bien una vez y se olvida.
🔎 Por dónde empezar
Si nunca has escrito un hook, el más rentable no es el que bloquea: es el que anota. Registrar cada cambio de modelo con marca de tiempo durante una semana te dice cuántas veces cambias, cuándo y con qué tarea entre manos. Con esos datos delante, decidir qué conviene bloquear deja de ser una intuición.
Ver trabajar al subagente desde Remote Control
La tercera pieza del ciclo completa el cuadro por el lado de la visibilidad: las llamadas a herramientas de un subagente en primer plano y sus resultados se transmiten ahora en vivo a los clientes de Remote Control. Antes, quien seguía una sesión desde otro dispositivo veía el turno del agente principal y un hueco mientras un subagente hacía su trabajo; el resultado aparecía al final, sin nada intermedio.
El cambio importa sobre todo en tareas largas lanzadas y desatendidas. Ver en tiempo real qué archivos está tocando un subagente permite cortar a los treinta segundos cuando ha entendido mal el encargo, en lugar de descubrirlo diez minutos después con el trabajo hecho en la dirección equivocada. Es, otra vez, el patrón que recorre toda esta semana de versiones: no hay capacidades nuevas, hay menos cosas ocurriendo a ciegas.
Sumadas, las tres piezas dibujan una intención bastante clara. Quién decide qué modelo corre, cuánto tiempo vive el contexto de cada agente y qué se ve mientras trabaja son exactamente las tres preguntas que aparecen cuando Claude Code deja de ser una herramienta personal y pasa a estar dentro de un proceso con dinero y clientes de por medio. Si tienes agentes definidos en tus proyectos, esta semana toca abrir sus archivos y decidir esas tres cosas de forma explícita.
