Claude Code 2.1.251 agrega hooks para controlar cambios de modelo antes y después de que ocurran, y eso convierte el cambio de modelo en una decisión auditable del workflow.
La frase corta del changelog oficial, publicado el 28 de agosto de 2026, es: “Added PreModelSwitch and PostModelSwitch hook events”.
Pero la lectura útil para equipos no es “Claude Code sumó dos hooks más”. La lectura útil es que el modelo dejó de ser solamente una preferencia individual del desarrollador. En una sesión larga, con prompt cache, subagentes, permisos, Remote Control, SDKs y posibles gateways de modelos, cambiar de modelo puede tener impacto en costo, política, rendimiento, trazabilidad y datos enviados al proveedor correcto.
Ahí es donde PreModelSwitch y PostModelSwitch importan.
El primero permite intervenir antes de que Claude Code aplique un cambio de modelo solicitado por una persona o por un cliente. Puede bloquear el cambio, pedir confirmación o mostrar información de costo antes de seguir. El segundo corre después de que la sesión ya cambió de modelo y sirve para auditar, registrar o inyectar orientación específica para el modelo nuevo.
Para equipos que ya usan Claude Code en serio, esto no es cosmética. Es gobernanza.
Y para equipos en Iberoamerica, donde muchas organizaciones combinan cuentas cloud, restricciones de seguridad, presupuestos por proyecto y herramientas de desarrollo heterogéneas, esa gobernanza empieza a ser una ventaja operativa concreta.
¿Cómo controlar cambios de modelo en Claude Code?
Para controlar cambios de modelo en Claude Code, usas PreModelSwitch como punto de decisión antes del cambio y PostModelSwitch como punto de auditoría o adaptación después del cambio.
La documentación oficial ubica PreModelSwitch antes de que Claude Code aplique un cambio de modelo solicitado. Ese evento puede bloquear el cambio. También puede devolver una decisión de permisos equivalente a permitir, denegar o preguntar al usuario.
PostModelSwitch, en cambio, corre después de que la sesión ya cambió. No puede impedir nada porque el cambio ya ocurrió, pero sí puede agregar contexto para la siguiente solicitud, registrar evidencia o aplicar instrucciones específicas para el modelo actual.
La diferencia parece pequeña, pero define dos responsabilidades distintas:
PreModelSwitches política preventiva.PostModelSwitches observabilidad y adaptación.
Si un equipo quiere impedir que ciertos proyectos usen un modelo retirado, caro o no aprobado, el control pertenece a PreModelSwitch. Si quiere registrar que una sesión pasó de un modelo económico a uno más fuerte, o darle instrucciones operativas al modelo nuevo, el lugar natural es PostModelSwitch.
Ese patrón se parece mucho a lo que ya está ocurriendo con herramientas, comandos y MCP: los agentes necesitan puntos de intervención alrededor de sus acciones, no solo prompts generales al comienzo de la sesión.
¿Qué es Claude Code y por qué importa este cambio?
Claude Code es el agente de desarrollo de Anthropic para trabajar sobre repositorios, ejecutar herramientas y sostener sesiones de programación desde CLI, IDEs, SDKs y flujos remotos.
En yoDEV ya venimos siguiendo ese movimiento en varias capas: sesiones que se hablan entre máquinas con ListAgents y SendMessage, runners self-hosted para correr sesiones en tu infraestructura, plugins locales, workflows dinámicos y SDKs para construir copilotos propios.
Ese contexto importa porque PreModelSwitch no llega a un producto simple. Llega a una superficie donde el agente puede trabajar durante mucho tiempo, mover contexto entre herramientas, delegar a subagentes, recibir instrucciones de clientes externos y operar sobre repositorios reales.
Cuando el agente trabaja cinco minutos en una tarea trivial, cambiar de modelo puede sentirse como una comodidad. Cuando trabaja dentro de un flujo de equipo, el cambio de modelo toca preguntas más serias:
- ¿Este modelo está aprobado para este repositorio?
- ¿El cambio rompe una política de costo?
- ¿Se pierde una cache caliente que ya tenía contexto cargado?
- ¿El nuevo modelo necesita instrucciones distintas?
- ¿Quién pidió el cambio: la persona, el picker,
/config, fast mode, el SDK o Remote Control? - ¿La transición quedó registrada para auditoría?
Claude Code 2.1.251 pone esas preguntas dentro del ciclo de hooks.
¿Por qué cambiar de modelo puede costar más de lo que parece?
Cambiar de modelo puede costar más de lo que parece porque una sesión larga puede tener mucho contexto y una prompt cache caliente que se pierde al cambiar de destino.
La documentación de PreModelSwitch expone campos diseñados justamente para que el hook pueda mostrar el costo antes de que el cambio ocurra. Entre ellos aparecen context_tokens, prompt_cache_warm, cache_ttl, estimated_cache_write_usd y pricing.
Esa lista cuenta una historia clara.
Claude Code no solo informa “vas de un modelo a otro”. También le da al hook datos sobre cuántos tokens podrían reenviarse, si la cache actual probablemente sigue caliente, cuánto tiempo de vida tiene esa cache y cómo se estimó el costo en dólares de escribir ese contexto en la cache del modelo destino.
La documentación aclara que ese costo es una estimación, porque el servidor quizá no necesite volver a cachear todo el contexto. Aun así, para un equipo es una señal suficiente para tomar mejores decisiones.
Un caso típico: una sesión lleva horas de conversación, lectura de archivos y resultados de herramientas. Alguien cambia de un modelo más económico a uno más fuerte justo antes de una pregunta pequeña. Sin control, esa transición puede reemitir una masa de contexto que no era necesaria para la tarea. Con PreModelSwitch, el equipo puede pedir confirmación cuando el costo estimado cruza un umbral, bloquear cambios desde superficies no interactivas o simplemente mostrar una advertencia.
Esto convierte el costo en parte del diseño del workflow.
No se trata de regañar al desarrollador por elegir un modelo fuerte. Se trata de distinguir cuándo el modelo fuerte aporta valor y cuándo el cambio ocurre por inercia, hábito o una automatización demasiado generosa.
¿Qué políticas de modelos puede aplicar un equipo?
Un equipo puede usar hooks de cambio de modelo para aplicar listas de modelos aprobados, retirar modelos obsoletos, pedir confirmación ante costos altos y registrar cambios hechos desde SDKs o Remote Control.
La documentación oficial muestra que PreModelSwitch se dispara para cambios pedidos desde /model, desde el picker de modelos, desde la configuración, al activar fast mode cuando eso cambia el modelo, o desde solicitudes set_model y cambios de modelo enviados por hosts del Agent SDK o Remote Control.
Ese abanico es importante. Si el control solo cubriera la UI interactiva, sería una comodidad local. Al cubrir SDK y Remote Control, se vuelve una pieza para entornos donde Claude Code está integrado en flujos más amplios.
Algunas políticas razonables:
- Bloquear modelos retirados o no aprobados por el equipo.
- Pedir confirmación cuando
estimated_cache_write_usdsupere un umbral. - Permitir cambios a modelos baratos sin fricción y pedir aprobación para modelos premium.
- Denegar cambios de modelo desde automatizaciones no interactivas.
- Registrar
from_model,to_model,sourceypricingen un sistema interno. - Mostrar una advertencia cuando
prompt_cache_warmsea verdadero y el cambio implique perder esa ventaja.
La parte fina está en no codificar políticas demasiado frágiles.
Claude Code compara matchers contra nombres canónicos de modelos. La documentación también advierte que, si no puede determinar un nombre canónico para el destino, por ejemplo detrás de un gateway que usa IDs propios, corre todos los hooks de PreModelSwitch sin depender del matcher. Por eso una política robusta debería revisar el campo to_model recibido por el hook, no confiar solamente en el matcher.
Ese detalle es exactamente el tipo de borde que vuelve a estos hooks relevantes para equipos, no solo para usuarios avanzados.
¿Qué diferencia hay entre bloquear, preguntar y anotar?
Bloquear, preguntar y anotar son tres niveles distintos de control operativo sobre el cambio de modelo.
Bloquear es la decisión fuerte. En Claude Code, un hook puede cancelar el cambio con una decisión de bloqueo o con el código de salida documentado para acciones bloqueantes. Es la opción correcta cuando el modelo no está aprobado, la ruta viola una política o la automatización intenta un cambio que el equipo no quiere permitir.
Preguntar es útil cuando el cambio puede ser razonable, pero merece una confirmación humana. Por ejemplo, subir a un modelo más caro con 180.000 tokens de contexto puede estar bien si la sesión está resolviendo una migración compleja. También puede ser innecesario si la persona solo quiere una respuesta corta. La confirmación le devuelve contexto al humano antes de gastar.
Anotar es el modo menos intrusivo. Un hook puede mostrar o agregar información sin impedir la transición. Aquí entran advertencias de costo, notas de auditoría o instrucciones posteriores para el modelo nuevo.
El matiz operativo: ask solo tiene sentido donde Claude Code puede mostrar una confirmación interactiva. La documentación indica que, en superficies no interactivas como -p, /config o solicitudes set_model, esa decisión se trata como una negativa. Para flujos automatizados, conviene diseñar políticas explícitas: permitir o denegar, no depender de una pregunta que nadie verá.
¿Por qué PostModelSwitch también importa si no puede bloquear?
PostModelSwitch importa porque muchos cambios de modelo no son solicitados por la persona y aun así deberían quedar visibles para el equipo.
La documentación dice que PostModelSwitch corre después de cambios solicitados, cambios automáticos como fallbacks, entradas o salidas de ciertos modos y restauraciones de modelo al resumir una sesión. También aclara que no corre cuando una cadena de fallback sustituye el modelo solo por un turno sin cambiar el modelo de la sesión.
Ese comportamiento lo vuelve útil para auditoría.
Si una sesión cambió de modelo por fallback automático, el equipo tal vez no podía bloquearlo con PreModelSwitch, porque no fue un cambio pedido por el usuario o el cliente. Pero sí puede registrarlo después. En entornos con compliance, facturación interna o análisis de calidad, esa diferencia entre “modelo solicitado” y “modelo efectivamente usado por la sesión” no es menor.
También sirve para instrucciones operativas. Un equipo puede querer que ciertos modelos reciban contexto adicional: delegar implementación a subagentes, limitarse a planificación, evitar llamadas a herramientas costosas o dejar una nota de revisión más estricta. PostModelSwitch puede agregar ese contexto al siguiente request después del cambio.
No reemplaza a CLAUDE.md ni a reglas de proyecto. Funciona como una capa dinámica que depende del modelo activo.
¿Qué tiene que ver esto con permisos y seguridad?
Tiene que ver con permisos y seguridad porque la misma versión que agrega hooks de cambio de modelo también corrige varios bordes de permisos, rutas y settings.
Claude Code 2.1.251 no llegó solo con PreModelSwitch y PostModelSwitch. El changelog también menciona fixes para casos donde herramientas de archivo podían seguir un symlink cambiado dentro del working directory después del chequeo de permisos, comandos de plugins podían apuntar fuera del directorio del plugin, workflows podían leer rutas antes del chequeo de permisos, y Grep/Glob no aplicaban ciertas reglas de denegación sobre rutas alcanzadas por symlinks.
También aparecen ajustes alrededor de tracing, logging crudo de cuerpos de API y comportamientos de settings bajo scopes más altos.
La señal de fondo es clara: Claude Code se está moviendo en una zona donde los bordes importan. No basta con que el agente sea capaz. Tiene que ser operable bajo restricciones.
Esto encaja con una conversación más amplia que también vimos en otras herramientas: los agentes de código necesitan sandboxing, no solo buenos prompts, y la aprobación de comandos debería modelar capacidades, no hacer matching superficial.
Los hooks de modelo son otra parte de la misma arquitectura.
El modelo decide cómo razona el agente. Las herramientas deciden qué puede tocar. Los permisos deciden qué se le permite ejecutar. La cache y el gateway deciden cuánto cuesta y por dónde viaja el contexto. Si cualquiera de esas capas cambia sin visibilidad, el equipo pierde control.
¿Cómo debería empezar un equipo con estos hooks?
Un equipo debería empezar con una política pequeña: registrar todos los cambios de modelo, pedir confirmación cuando el contexto sea grande y bloquear solo los modelos explícitamente no aprobados.
Ese enfoque evita dos extremos malos. Por un lado, dejar que cada sesión cambie de modelo sin trazabilidad. Por el otro, crear una política tan rígida que los desarrolladores apaguen los controles para poder trabajar.
Una primera iteración práctica podría separar tres objetivos:
- Visibilidad: registrar
from_model,to_model,source,context_tokens,prompt_cache_warm,estimated_cache_write_usdypricing. - Costo: pedir confirmación cuando el costo estimado de re-cachear contexto sea alto o cuando la cache esté caliente.
- Política: bloquear modelos retirados, no aprobados o incompatibles con un repositorio específico.
Después de una semana de uso real, el equipo puede mirar evidencia en lugar de discutir preferencias:
- Qué modelos se usan de verdad.
- Desde qué superficies se piden los cambios.
- Cuántos cambios ocurren con cache caliente.
- Cuántas confirmaciones fueron útiles.
- Qué automatizaciones intentan cambiar de modelo.
- Qué repositorios necesitan reglas distintas.
La gobernanza buena no empieza con una matriz perfecta. Empieza haciendo visible el comportamiento real.
¿Cuál es la advertencia con Claude Code 2.1.251?
La advertencia es que estos detalles tienen alto riesgo de decay: nombres de modelos, campos de status line, semántica de hooks, gateways y rutas de configuración pueden cambiar rápido.
Al momento de publicar esta nota, 1 de septiembre de 2026, la documentación oficial marca PreModelSwitch y PostModelSwitch como disponibles desde Claude Code v2.1.251. El changelog ya muestra una versión posterior, 2.1.252, publicada el 31 de agosto de 2026, con fixes adicionales. Eso no invalida el cambio de 2.1.251, pero sí confirma que el tren de releases se mueve rápido.
Por eso conviene tratar esta nota como una guía de criterio, no como una receta congelada. Antes de copiar una política a producción, revisa la documentación oficial de hooks y el changelog actual.
La parte duradera es el patrón.
Los agentes de código ya no son una caja de chat que sugiere funciones. Son runtimes que ejecutan herramientas, consumen contexto, usan cache, delegan trabajo, se conectan por SDK y pueden cambiar de modelo dentro de una sesión viva.
En ese mundo, “qué modelo usamos” no es una preferencia estética.
Es una decisión de operación.
Y Claude Code 2.1.251 acaba de darle a los equipos un lugar explícito para controlarla.