Si has llegado buscando cuál de los dos usar para programar, te ahorro el artículo: Opus 5. Fable 5 cuesta el doble y la diferencia que vas a encontrar generando código no compensa ni de lejos.
Pero hay una excepción, y es la parte interesante. Hay una tarea concreta donde Fable 5 me ha dado algo que Opus 5 no me daba, y merece la pena saber cuál es.
Lo que cuesta cada uno
En API, la diferencia es exactamente el doble en ambas direcciones:
Opus 5 | Fable 5 | |
|---|---|---|
Input | 5 $ / millón de tokens | 10 $ / millón de tokens |
Output | 25 $ / millón de tokens | 50 $ / millón de tokens |
Pero si trabajas con suscripción y no con API, lo que importa es otra cosa, y depende de tu plan. Desde el 20 de julio de 2026:
Max, asientos premium de Team y asientos premium de Enterprise por asiento: Fable 5 está incluido en el plan. Puedes dedicarle hasta el 50% de tu límite semanal de uso sin coste extra.
Pro y asientos estándar de Team y Enterprise: Fable 5 no está incluido. Funciona con créditos de uso de pago por consumo.
Enterprise por consumo y API: se factura a tarifas estándar de API.
Antes de eso hubo una promoción que lo incluía en todos los planes de pago, y terminó el 19 de julio.
Requisitos
Fable 5 necesita Claude Code 2.1.170 o superior. Está disponible también en Claude web, móvil, escritorio, Cowork, Design, Claude para Microsoft 365 y Claude Tag. No existe en el plan gratuito.
Por qué Fable 5 no encaja programando
Si estás en Pro, el argumento es el precio y se acaba rápido: cuando programas con un agente generas salida todo el rato —código, tests, refactorizaciones, correcciones sobre correcciones— y la factura la marca el output, que en Fable va a 50 $ el millón.
Si estás en Max, el argumento cambia de forma pero no de fondo. Sí, lo tienes incluido, pero con dos límites: no puedes pasar del 50% de tu cuota semanal con Fable, y consume esa cuota más rápido que cualquier otro modelo. Traducido: dedicar Fable 5 a escribir código te funde media semana de trabajo en una tarde.
Y encima la diferencia de calidad existe pero no es abismal. Ninguna de las dos cosas por separado descartaría a Fable. Juntas, sí: te comes la cuota al doble de velocidad por una mejora que en tareas de implementación apenas se nota.
Y hay un tercer factor que ya expliqué en detalle en ¿necesitas Opus para programar en Laravel?: si tienes un pipeline decente y las convenciones escritas, el margen de mejora que le queda al modelo es estrecho. No importa cuánto pagues por él.
Cómo reparto los tres modelos
Este es mi criterio a día de hoy, con tres niveles bien separados:
Sonnet 5 — implementar. El grueso del trabajo. Tareas acotadas sobre convenciones ya escritas, donde el agente aplica arquitectura en vez de decidirla.
Opus 5 — decidir. Dos casos concretos: cuando el proyecto hace algo por primera vez y ese patrón se va a repetir después, y cuando la tarea exige un razonamiento más complejo que lo habitual. En el primer caso subo de modelo aunque la tarea parezca trivial, porque el error se propaga a todas las que la copien.
Fable 5 — auditar. Y solo auditar. Nunca para escribir.
Esa última asignación no la elegí por teoría. Salió de una prueba.
La prueba: dos modelos auditando el mismo proyecto
Hace unos días audité un proyecto en el que trabajo, todavía sin desplegar a producción, buscando fugas y casos límite. Aproveché para poner los dos modelos a competir en la misma tarea.
Primero se lo pasé a Opus 5. Sacó dos problemas.
Después le pasé exactamente lo mismo a Fable 5. Encontró esos dos, y seis más.
Ocho contra dos es una diferencia que no había visto en ninguna otra tarea. Y no eran hallazgos de relleno: varios eran importantes, y algunos más graves que los dos que había cazado Opus 5.
Cómo sé que no se los inventó
Es la primera pregunta que haría cualquiera, así que la respondo: cogí los ocho hallazgos de Fable 5 y se los pasé a Opus 5 para que los verificara. Los confirmó todos.
Y esta no es la primera vez que hago esta comprobación. La he repetido en otros proyectos y el resultado ha sido el mismo: lo que encuentra Fable, Opus normalmente lo valida sin discutir en cuanto sabe dónde mirar.
Eso deja el hallazgo en un sitio muy concreto, y es la parte que a mí me parece más interesante de todo esto: la diferencia entre los dos modelos no está en entender el problema, está en encontrarlo. Opus 5 comprendía perfectamente los seis casos que se le habían pasado. Simplemente no había buscado lo bastante hondo cuando revisó por su cuenta.
Es una diferencia de profundidad de búsqueda, no de capacidad de razonamiento. Y explica bastante bien por qué en tareas de implementación, donde el problema ya te lo dan definido, la mejora de Fable apenas se nota.
La letra pequeña
Antes de que salgas corriendo a comprar créditos, el dato que matiza todo lo anterior: esos seis casos eran muy difíciles de que se dieran. Casos muy al límite, la mayoría exigiendo que hubiera mala intención por parte del usuario.
Pero los cazó. No eran falsos positivos, no eran avisos genéricos de "podrías validar esto mejor". Eran agujeros reales que Opus 5 no vio.
Lo que significa en la práctica es que el valor de Fable 5 aquí depende por completo de contra qué te estés defendiendo:
Si tu aplicación es interna, con usuarios identificados y sin incentivo para atacarla, esos seis casos probablemente no lleguen a pasar nunca.
Si es pública, con usuarios anónimos y algo que ganar rompiéndola, seis agujeros explotables con mala intención son exactamente lo que buscas antes de desplegar.
En mi caso, el proyecto no está en producción todavía, así que el momento era el bueno: encontrarlos antes de abrir la puerta.
El flujo que uso ahora
De todo esto sale un reparto de tres pasos que ya tengo interiorizado:
Fable 5 busca. Una pasada de auditoría sobre el código, pidiendo fugas y casos límite. Lee mucho, escribe un informe.
Opus 5 confirma. Le paso los hallazgos para que los verifique uno por uno y descarte lo que no se sostenga. Esto entra en tu plan sin dramas.
Sonnet 5 corrige. Con el problema ya identificado y validado, arreglarlo es implementación normal.
El modelo caro solo interviene en el paso donde su ventaja es real. Los otros dos pasos salen baratos porque el trabajo difícil, encontrar el agujero, ya está hecho.
Y el argumento económico se le da la vuelta a sí mismo: lo que descarta a Fable como modelo de trabajo diario es exactamente lo que lo hace asumible como gasto puntual. Programando generas salida sin parar. Auditando, una pasada cuesta una fracción de lo que te llevarías gastado teniéndolo activo una tarde escribiendo código, y si estás en Max, apenas toca tu cuota semanal.
Así que mi recomendación es reservarlo para:
Antes de un despliegue importante, especialmente el primero a producción.
Después de una refactorización grande, cuando has movido mucho y no te fías.
En las piezas donde un fallo es silencioso: concurrencia, transacciones, permisos, límites de cuota. Sitios donde los tests pueden estar verdes y el código estar mal.
Una pasada, un informe, y a corregir con un modelo más barato.
Conclusión
Para escribir código, Opus 5. No por precio, sino porque la diferencia no está donde el precio te dice que debería estar.
Para revisar código escrito, Fable 5 me ha demostrado que encuentra cosas que Opus 5 no encuentra. Cuatro veces más problemas en el mismo proyecto, todos confirmados después por Opus 5, aunque en su mayoría necesiten un usuario con ganas de romper algo.
Y ahí está el resumen de todo: los dos modelos entienden lo mismo, pero uno busca más hondo. Si tu tarea es implementar, el problema ya está encontrado y da igual cuál uses. Si tu tarea es buscar, es lo único que importa.
Si tienes que elegir uno, no hay debate. Si puedes permitirte usar el caro de vez en cuando, gástalo auditando y no programando.
Para seguir
¿Necesitas Opus para programar en Laravel? Lo usé en 3 de 15 tareas
Claude Opus 5: especificaciones, precio y qué cambia respecto a Opus 4.8
Claude Fable 5: el primer modelo clase Mythos para el público
Anthropic suspende Fable 5 y Mythos 5 para todos los usuarios
Y si quieres montar el entorno y el método que hacen que el modelo importe menos, está todo en la ruta Desarrollo Laravel asistido por IA: del setup al Spec-Driven Development.
Rutas de aprendizaje
