Routing de modelos en Claude Code: Fable, Opus y costes

TL;DR: El routing de modelos en Claude Code consiste en usar un modelo distinto para cada fase del trabajo: el más capaz (Claude Fable 5) para planificar y otro más barato (Opus 4.8 o Sonnet 4.6) para ejecutar. Se hace a mano con el comando /model sin perder el contexto de la sesión, y reduce el gasto de tokens porque la planificación consume poco y la ejecución mucho. Aquí tienes el patrón paso a paso, cuándo merece la pena y dónde se rompe.

El problema: un solo modelo para todo te sale caro

Con la llegada de Claude Fable 5 (la familia "Mythos") en la release v2.1.170, mucha gente hizo lo de siempre: poner el modelo nuevo por defecto, subir el effort a max y seguir trabajando igual. El resultado es una factura que se dispara sin que el trabajo final sea mejor.

La razón es de tokenomics básica. Fable 5 cuesta aproximadamente el doble que Opus 4.8 por token. Y aquí está la clave que casi nadie mira: las dos fases de una tarea no consumen igual. Planificar es razonamiento puro, pocos tokens de salida pero mucha "cabeza". Ejecutar (escribir archivos, editar, correr tests, iterar) genera muchísimos más tokens. Si pones tu modelo más caro a hacer la parte que más tokens quema, estás pagando precio premium justo donde menos lo necesitas.

El patrón inteligente invierte esa intuición: el modelo top razona el plan, un modelo más barato lo teclea. Es la misma lógica de separar responsabilidades en arquitectura de software, pero aplicada a qué motor usas en cada etapa.

¿Qué es el routing de modelos en Claude Code?

El routing de modelos es asignar deliberadamente un modelo distinto a cada fase de una tarea según su coste y la capacidad que exige. No es nada nuevo conceptualmente, pero Fable 5 lo vuelve casi obligatorio: la brecha de precio entre tiers ya es grande como para ignorarla.

Claude Code maneja varios alias de modelo que conviene tener claros antes de montar tu flujo:

fable: selecciona Claude Fable 5. No es el modelo por defecto en ninguna cuenta; solo se activa cuando lo eliges tú.
opus: Opus 4.8, el caballo de batalla con razonamiento fuerte a la mitad de precio que Fable.
sonnet: Sonnet 4.6, rápido y económico para el día a día.
opusplan: alias híbrido automático. Usa Opus en modo plan y conmuta a Sonnet al ejecutar.
best: apunta al modelo más capaz disponible en tu cuenta (Fable 5 donde lo tengas).

Si ya conoces el alias opusplan, el patrón de este artículo es su versión manual y un escalón por encima: en lugar de Opus para planificar, usas Fable para los planes realmente complejos, y bajas a Opus o Sonnet para picar código.

¿Por qué no existe un "fableplan" automático?

A junio de 2026 no hay un alias fableplan que combine Fable y Opus de forma automática. El único híbrido integrado es opusplan (Opus en plan, Sonnet en ejecución). Para usar Fable solo en la planificación tienes que cambiar de modelo tú, a mano, dentro de la sesión. No es un fallo: Fable arrastra una retención de datos de 30 días por monitorización de seguridad, así que Anthropic no lo enchufa por defecto en flujos automáticos.

Implementación paso a paso

El flujo cabe en cuatro pasos y no pierdes contexto al cambiar de modelo a mitad de sesión.

1. Arranca en modo plan con el modelo potente. Entra en Claude Code y selecciona Fable para la fase de diseño.

# Cambia el modelo de la sesion a Fable 5 sin reiniciar
/model fable
# Activa el modo plan (tambien con Shift+Tab) para que razone sin tocar archivos

2. Deja que planifique. En modo plan, el modelo analiza el repo y propone un plan sin escribir ni un archivo. Aquí es donde el cerebro de Fable paga: detecta dependencias, edge cases y el orden correcto de los cambios. Salida esperada: un plan estructurado que Claude te pide aprobar antes de tocar nada.

3. Cambia a un modelo más barato para ejecutar. Antes de aprobar el plan, baja de tier. El contexto de la conversación (incluido el plan) se mantiene.

# Conmuta a Opus 4.8 para la fase de implementacion (mitad de coste)
/model opus
# Si la tarea es mecanica y repetitiva, Sonnet aun mas barato:
# /model sonnet

4. Aprueba y ejecuta. Sales de modo plan, Claude implementa el plan ya razonado con el modelo barato. El trabajo de pensar ya está hecho; ejecutar es seguir instrucciones.

Si quieres dejarlo fijo entre sesiones, puedes configurar los modelos por defecto en tu configuración de proyecto mediante variables de entorno:

# Pin de modelos por alias en settings (utiliza IDs concretos)
ANTHROPIC_DEFAULT_OPUS_MODEL="claude-opus-4-8"
ANTHROPIC_DEFAULT_FABLE_MODEL="claude-fable-5"

Cuándo usar cada tier: tabla de decisión

No todo plan necesita Fable. La regla práctica: cuanto más larga y ambigua sea la tarea, más rentable es pagar el plan caro.

Fase / tarea	Modelo recomendado	Por qué
Plan de migración grande o multi-archivo	Fable 5	Razonamiento de largo alcance, pocos tokens
Plan de un fix acotado	Opus 4.8	Fable es excesivo, Opus razona de sobra
Ejecución de código planificado	Opus 4.8	Mitad de coste, calidad sólida
Edición mecánica, boilerplate, renames	Sonnet 4.6	Rápido y barato, no exige razonar
Consultas rápidas sobre el repo	Haiku 4.5	Latencia mínima, coste casi nulo

Esto extiende la lógica de elegir entre Opus y Sonnet según la tarea: ahora añades un tier más arriba (Fable) reservado a lo verdaderamente difícil.

Caso real: una refactorización a un módulo de servicio

En un escenario típico de producto, imagina mover la lógica de validación de un endpoint FastAPI a un servicio reutilizable, tocando 6 o 7 archivos con sus tests. Hecho todo con Fable y effort alto, una tarea así puede comerse una porción notable de tu cuota diaria.

Con routing manual el reparto cambia: arrancas el plan con Fable, que detecta que dos de esos archivos comparten un import circular que hay que romper primero (un detalle que un modelo más flojo pasaría por alto). Apruebas, cambias a Opus, y la ejecución (escribir el servicio, mover métodos, ajustar imports, correr tests) corre a mitad de precio. El plan caro fueron unos pocos miles de tokens; la ejecución barata fueron decenas de miles. Ahí está el ahorro real.

En Producción

Mover esto de un truco puntual a un hábito de equipo tiene aristas que conviene conocer.

Coste y fricción. Cada /model es un cambio manual que se te puede olvidar. El ahorro existe, pero a cambio de más pasos en tu flujo. Si tu sesión es corta, a veces no compensa la gestión.
El fallback de seguridad de Fable. Las consultas que los safeguards de Fable marcan como ciberseguridad o biología se redirigen automáticamente a Opus 4.8. No se te cobra precio Fable por esas peticiones reenviadas, pero tampoco controlas cuándo pasa.
Retención de datos. Usar Fable implica retención de 30 días para monitorización de seguridad (no para entrenamiento). En entornos con requisitos de zero-data-retention, Fable puede estar bloqueado hasta que legal lo apruebe.
Effort, no solo modelo. El tier es media batalla; el nivel de effort multiplica el consumo. Un Opus a effort alto puede salir más caro que un Fable a effort medio. Ajusta ambos ejes, no solo el modelo.
Límites de sesión. Fable consume cuota distinta y más rápido. Vigila tu medidor antes de ponerlo por defecto, porque cruzar ciertos umbrales de tokens vacía el presupuesto de golpe.

Errores comunes y depuración

Error: el cambio a /model fable "se queda pegado" y todas las sesiones futuras arrancan con Fable. Causa: elegir un modelo con /model lo guarda como modelo seleccionado en tus settings de usuario. Solución: vuelve a poner tu default con /model opus (o el alias que prefieras) al cerrar, o usa el flag --model solo para esa sesión.

Error: esperabas el contexto de 1M de tokens al usar el plan con Opus y no aparece. Causa: el contexto extendido a 1M aplica al setting opus, no a la fase de plan de opusplan, que corre con la ventana estándar de 200K. Solución: si necesitas la ventana grande en planificación, fija opus directamente en vez de opusplan.

Error: el routing no ahorra nada pese a cambiar de modelo. Causa: casi siempre el effort sigue en max o haces el plan tan largo que la fase cara domina el gasto. Solución: mide el reparto plan/ejecución con tu dashboard de uso y baja el effort en la fase que no lo necesite.

Preguntas frecuentes

¿Pierdo el contexto al cambiar de modelo a mitad de sesión?

No. El comando /model conmuta el modelo manteniendo la conversación, el plan y los archivos abiertos. Cambias el motor, no la sesión.

¿Merece la pena Fable 5 si solo hago tareas pequeñas?

Normalmente no. Fable brilla en migraciones grandes, trabajo agéntico de varias horas y problemas de razonamiento profundo. Para fixes acotados y edición diaria, Opus 4.8 o Sonnet 4.6 dan mejor relación coste-resultado.

¿Hay forma automática de hacer este routing como con opusplan?

A junio de 2026, no para Fable. El único híbrido integrado es opusplan (Opus en plan, Sonnet en ejecución). El routing Fable/Opus es manual con /model, paso que debes dar tú dentro de la sesión.

Lo que te llevas

Hemos visto que el routing de modelos no va de elegir "el mejor modelo", sino de poner cada tier donde rinde: Fable razonando el plan, Opus o Sonnet tecleando la implementación. La clave está en que planificar consume pocos tokens y ejecutar consume muchos, así que pagar premium por la fase corta y barato por la larga es justo al revés de lo que hace casi todo el mundo. Y recuerda que el modelo es solo un eje: el effort y la longitud del plan pesan tanto como el tier que elijas.

¿Has montado tu propio flujo de routing en Claude Code, o prefieres dejar fijo un solo modelo? Cuéntame qué reparto te funciona en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo desmonto cómo medir el coste real de cada fase con el dashboard de uso, para que decidas el routing con datos y no a ojo.