Sonnet 5, Opus 5 y Fable 5: cuál uso en cada caso, y lo que cuesta cambiar de idea

TL;DR Mi ruta: Opus 5 en su effort por defecto para casi todo, Fable 5 solo cuando el territorio es nuevo de verdad, y Sonnet 5 viviendo dentro de los subagentes, nunca como modelo principal. Y el dato que no cuenta nadie: cambiar de modelo a mitad de sesión te rompe la caché y ese turno reprocesa la conversación entera a precio completo. Así que la pregunta no es solo cuál eliges, es cuándo cambias.

Anthropic tiene su propia guía y usa una metáfora que funciona: Fable es "un especialista que ha visto problemas que casi nadie más ha visto", Opus es "el experto" para lo genuinamente difícil, y Sonnet es "un generalista muy bueno" para lo rutinario, porque "no hay razón para pagar por capacidad que la tarea no necesita".

Está bien como mapa. Lo que no te dice es lo que pasa cuando cambias de opinión a media tarea, que es la decisión que de verdad tomas varias veces al día. Esto es cómo lo hago yo, con los costes puestos encima de la mesa.

Resultado (mi ruta, tal cual):

Tarea nueva              →  Opus 5, effort por defecto
Territorio desconocido   →  Fable 5 para arrancar y acotar
   ...y al bajar         →  /compact  y DESPUÉS  /model opus
Trabajo mecánico         →  subagente con model: sonnet

1. Opus 5 en su default, y el effort no se toca

Mi modelo diario es Opus 5 con el effort donde viene. No lo bajo ni lo subo salvo emergencia, y resulta que eso es exactamente lo que recomienda Anthropic para Claude Code: "para la mayoría de tareas deberías usar el effort por defecto del modelo", tratándolo como una preferencia general y no como una decisión tarea a tarea.

Súbelo cuando tengas una razón concreta, y la doc nombra las tres: Claude se saltó un archivo, no ejecutó los tests, o abandonó un refactor a medias. Para mí el effort es un extintor, no un mando que toqueteo.

Ojo con un detalle: Opus 5 no te resetea el effort al estrenarlo, a diferencia de Fable 5 y los Opus anteriores. Si en su día lo bajaste, sigue bajado. Compruébalo una vez con /effort y olvídate (las tres formas de fijarlo).

2. Fable solo cuando el territorio es nuevo de verdad

A Fable 5 entro cuando el área es completamente nueva para mí, o cuando combino áreas que conozco de una forma que no he usado nunca. Le pido que acote el problema y arranque, y luego bajo a Opus para el grueso.

Eso coincide con lo que dice su documentación: navegar la ambigüedad es su punto fuerte, y recomiendan empezar por el techo de tu rango de dificultad, dándole una tarea más difícil de las que le darías a un modelo anterior para que la acote y ejecute.

Lo que no hago es usar Fable para trabajo delegable a un modelo inferior perfectamente capaz. Es ir con un Lamborghini a comprar el pan, y además te come el cupo: Fable consume tus límites unas 2 veces más rápido que Opus. Dicho esto, la propia doc avisa de lo contrario también, así que no lo tomes como regla ciega: en trabajo complejo, un modelo pequeño puede quemar iteraciones y salirte más costoso que el grande acertando a la primera.

3. Sonnet vive dentro de los subagentes

Sonnet 5 no es mi modelo principal, es mi modelo delegado. Opus orquesta con el contexto fresco y reparte lo mecánico a subagentes que corren en Sonnet.

La teoría es esta: si las macrodecisiones de dominio ya están resueltas arriba, las microdecisiones técnicas tienen suficiente contexto en el propio código para que las infiera un modelo inferior. Lo que no es inferible del codebase es lo que decide el humano, y eso pasa antes.

No es solo mi manía: la doc de effort describe el nivel low para "tareas simples que necesitan la mejor velocidad y el menor coste, como los subagentes".

Y esto no se hace a mano cada vez, se declara en el agente:

---
name: refactor-worker
description: Cambios mecánicos con el diseño ya decidido
model: sonnet
memory: project
---

Sobre la memoria, que confundí en su día. Los subagentes tienen memoria persistente (user, project o local) y las siguientes ejecuciones llegan sabiendo lo que aprendieron. Pero eso no es caché: la doc dice que un subagente tiene caché separada de tu sesión, y al activar memoria le inyecta las primeras 200 líneas o 25 KB de su MEMORY.md dentro del system prompt. O sea, el arranque en frío queda mejor informado y más grande, no más económico. Dos trampas de propina: activar memoria le devuelve Read, Write y Edit aunque tú se los hubieras restringido, y todo esto muere si tienes autoMemoryEnabled en falso o CLAUDE_CODE_DISABLE_AUTO_MEMORY puesto.

4. Lo que cuesta cambiar de idea

Aquí está la parte que casi nadie tiene en cuenta. El modelo y el effort forman parte de la clave de caché, no son solo texto. Cambiar cualquiera de los dos arranca una caché nueva desde cero, y ese turno reprocesa toda la conversación a precio completo, del orden de 10 veces más en input (el detalle completo).

Por eso, cuando bajo de Fable a Opus, el orden importa:

/compact          # invalida solo la capa de conversación
/model opus       # ahora el reproceso cae sobre un historial ya corto

Al revés pagas el reproceso completo del historial largo. Es el mismo movimiento, y uno de los dos órdenes sale bastante más económico.

Referencia

Si estás en una nube, el "Sonnet" que comparas no es el mío.

Dónde encaja

Esto no sustituye a cómo elegir el modelo adecuado, que va del reparto por fase con opusplan (Opus planifica, Sonnet ejecuta) y sigue siendo válido. Aquel responde "qué modelo para qué fase"; este, "cuál de los tres de arriba y en qué orden". Y si vienes de Sonnet 5, verás que lo que allí era el modelo equilibrado aquí es el trabajador delegado, porque Opus 5 bajó el coste por tarea y movió la frontera.

Documentación oficial: Choosing a Claude model and effort level in Claude Code · Model configuration

Requisitos

• Comprobado en Claude Code v2.1.220. Fable 5 pide v2.1.170, Sonnet 5 pide v2.1.197 y Opus 5 pide v2.1.219.