Claude Fable 5 vs Opus 4.8 vs Sonnet 5: Cuándo Usar Cada Uno

Ya escribí sobre el apagón de Fable 5 y sobre su vuelta. Lo que faltaba era la pregunta que en realidad importa cuando tenés los tres modelos disponibles: ¿cuál usás, y cuándo?

No es una pregunta de benchmarks. Es una pregunta de costo, latencia y compliance — y en cada uno de esos ejes, el modelo "mejor" cambia.

El punto de partida: precio y comportamiento por defecto

Antes de los casos, la base técnica que define todo lo demás:

Fable 5 / Mythos 5: $10 / $50 por millón de tokens (input/output). Thinking siempre activo, no se puede desactivar — solo controlás la profundidad con effort (low/medium/high/xhigh/max). Contexto de 1M tokens, hasta 128K de output por request.
Opus 4.8: $5 / $25 por MTok. La mitad del costo de Fable 5, thinking opcional.
Sonnet 5: $3 / $15 por MTok ($2 / $10 de precio intro hasta el 31 de agosto de 2026). El más barato de los tres.

Con thinking obligatorio, tareas difíciles en Fable 5 pueden tardar varios minutos por request — no es raro ver 15 minutos en effort alto. Eso no es un detalle menor: es la variable que más rápido descarta a Fable 5 en casos donde la latencia importa.

Anthropic mismo lo dice: Opus 4.8 es el default recomendado. Fable 5 es para cuando la dificultad de la tarea justifica pagar el doble y esperar más.

Caso 1: agente desatendido de largo horizonte → Fable 5

Si tenés un agente corriendo solo durante horas — una migración de código grande, un refactor que toca decenas de archivos, una tarea que no tiene a nadie mirando cada paso — Fable 5 es la opción correcta.

Está entrenado específicamente para no sobre-planificar y sostener coherencia en sesiones largas. Sonnet 5 y Opus 4.8 tienden a perder el hilo o repetir trabajo ya hecho cuando la sesión se estira. Acá el costo por token importa menos que la probabilidad de que el agente termine el trabajo sin que tengas que intervenir.

La pregunta que te tenés que hacer: si este agente falla a mitad de camino, ¿cuánto tiempo tuyo cuesta detectarlo y arrancar de nuevo? Si la respuesta es "mucho", pagá el 2x.

Caso 2: debugging de un incidente en producción → Fable 5, pero escalando

Acá la recomendación tiene un matiz importante: no arranques con Fable 5. Arrancá con Sonnet 5 o Opus 4.8. Si el bug es real y esos modelos no lo encuentran en dos o tres intentos, ahí escalás.

Fable 5 tiene mejor recall de bugs reales en código complejo — pero ese beneficio solo se paga cuando el problema efectivamente lo necesita. Usarlo de entrada en cada incidente es pagar 2x de costo y minutos de latencia por bugs que Sonnet 5 hubiera resuelto en segundos.

El patrón correcto es de escalada, no de default: Sonnet 5 → Opus 4.8 → Fable 5, subiendo solo cuando el nivel anterior no resuelve.

Caso 3: chat interactivo o soporte en vivo → Sonnet 5

Este es el contrapeso necesario. Si Fable 5 ganara siempre, no habría nada que decidir.

En cualquier caso donde hay una persona esperando una respuesta en tiempo real — chat de soporte, asistente conversacional, cualquier interacción donde el usuario ve el cursor parpadear — el thinking obligatorio de Fable 5 es un problema, no una ventaja. Esperar 15 minutos por una respuesta en un chat es UX inaceptable, sin importar qué tan buena sea la respuesta.

Sonnet 5 rinde cerca de Opus 4.8 en la mayoría de tareas agénticas, a mejor costo y sin la carga de thinking forzado. Para interacción en vivo, es la opción por descarte: los otros dos no están diseñados para esto.

Caso 4: empresa regulada con Zero Data Retention estricto → Fable 5 queda bloqueado

Este caso no es de conveniencia, es un bloqueo técnico duro. Fable 5 y Mythos 5 requieren una retención de datos mínima de 30 días — es incompatible con Zero Data Retention (ZDR). Si tu organización tiene ZDR configurado, todos los requests a Fable 5 devuelven error 400. No hay forma de sortear esto a nivel de configuración.

Para salud, finanzas o legal — sectores donde ZDR suele ser un requisito de compliance, no una preferencia — Fable 5 queda descartado de entrada, sin importar cuánto mejor sea en la tarea específica.

Caso 5: empresa regulada que necesita capacidad frontera + ZDR → Opus 4.8

Acá está el otro lado del caso 4. Si tu organización necesita ZDR pero también necesita la mayor capacidad posible — análisis complejo, razonamiento profundo, tareas donde Sonnet 5 se queda corto — Opus 4.8 es la respuesta: es el modelo más potente de los tres que sigue siendo compatible con ZDR.

Es el caso que cierra el círculo: mismo dealbreaker regulatorio que el caso 4, pero con una salida real en vez de un bloqueo total.

Tabla resumen

Caso	Modelo	Por qué
Agente desatendido de largo horizonte	Fable 5	Coherencia en sesiones largas, no sobre-planifica
Debugging de incidente (escalando)	Fable 5	Mejor recall de bugs reales, pero como segundo/tercer intento
Chat interactivo / soporte en vivo	Sonnet 5	Sin thinking forzado, mejor costo, latencia aceptable
Empresa regulada con ZDR estricto	— (Fable 5 bloqueado)	Incompatibilidad técnica dura con ZDR
Empresa regulada + capacidad frontera + ZDR	Opus 4.8	El más potente que sigue siendo compatible con ZDR

Preguntas frecuentes

¿Vale la pena usar Fable 5 para todo, ya que es el modelo más nuevo?

No. Es 2x más caro que Opus 4.8 y tiene thinking obligatorio, lo que agrega latencia incluso en tareas triviales. Anthropic recomienda Opus 4.8 como default y reserva Fable 5 para casos de máxima dificultad o sesiones largas desatendidas.

¿Puedo desactivar el thinking de Fable 5 para reducir la latencia?

No. El thinking está siempre activo en Fable 5 y Mythos 5 — intentar desactivarlo (disabled) devuelve error 400. Solo podés ajustar la profundidad con el parámetro effort (low a max).

¿Mythos 5 es una alternativa a Fable 5 para estos casos?

En la práctica, no para la mayoría. Mythos 5 comparte capacidades, pricing y API con Fable 5, pero solo es accesible vía Project Glasswing — reservado a ciberdefensores e infraestructura crítica. Para el resto de los casos de este artículo, el modelo relevante es Fable 5.

¿Por qué Fable 5 es incompatible con Zero Data Retention?

Porque requiere un mínimo de 30 días de retención de datos por diseño. Cualquier organización con ZDR configurado recibe error 400 en todos los requests a Fable 5 o Mythos 5 — es una limitación técnica, no ajustable por configuración.

Esta es la decisión que uso yo mismo para enrutar tareas entre modelos en mi propio sistema de agentes. Si estás armando algo similar y no sabés por dónde empezar a decidir qué modelo usar en cada punto de tu arquitectura, hablemos.