Después de varias semanas de bloqueo, por fin tenemos Fable 5 disponible como modelo en anthropic, y lo que vamos a hacer es evaluarlo, en comparación al resto de modelos de anthropic y luego ponerlo en un gráfico general en conjunto con los otros modelos que hemos analizado.
Para ello utilizo mi proyecto de Github - Coding evals donde puedes ver todos los puntajes y donde cuadra cada uno de ellos.
Table of Contents
1 - Cuándo usar Fable 5?
La gran diferencia entre Fable 5 (o Sonnet 5) no es en el nivel de código que te va a generar, sino en la autonomía. La idea de Fable es darle un objetivo y debería estar iterando hasta conseguir dicho objetivo.
Estos modelos no están pensados para que los lleves de la mano sino para esos objetivos globales. Piensa en tu día a día como programador, tienes una epic, la cual está dividida en tareas y cada tarea tiene su implementación.
Con Sonnet 4.6 tienes que investigar a mano, pensar tú, discurrir, mirar el código y comprenderlo. para finalmente indicarle a Sonnet donde hacer cada cambio y como, para que todo tenga sentido.
Con Opus 4.8 puedes delegar la investigación y tener una conversación sobre lo que va saliendo que al final, sin escribir código, llega al objetivo final. En muchos casos requiere varias iteraciones con el modelo, ya sea en la parte de conversación o personalmente tener que iterar en el código a mano. Como puedes imaginar saca muchos mejores resultados que sonnet, pero también es mucho más caro.
Con Fable 5 es distinto, le das un objetivo, y es Fable quien opera e itera hasta conseguir el objetivo. Volviendo al caso del programador, podría ser la epic, Fable investiga la tarea, la entiende, la divide e implementa, todo automáticamente. Y si opus utilizaba tokens, fable ya no te cuento, no solo eso, sino que además cuesta el doble por token. Así que si lo pones a hacer tareas muy pesadas o que sabes que son largas, va a tardar mucho tiempo y costará una fortuna, una fortuna de verdad, no de forma retórica.
2 - Evaluación de los modelos de Anthropic
Al final este post de lo que se trata es de evaluar como es el nuevo modelo y en este caso vamos a evaluar todos ellos.
En nuestro caso vamos a continuar con la prueba 2026.06 el cual consiste en dos pruebas, ambas utilizando el código de Distribt el cual es una simulación de un sistema distribuido, escrito en C#.
A - Code review
La primera tarea es una code review, donde presentamos una PR al modelo para que la evalúe, esta PR tiene problemas (muchos) y la idea es ver cuantos es capaz de encontrar.
La idea general del cambio del código es un sistema que nos permita poner descuentos en los precios de los productos.
B - Implementación de una funcionalidad
La segunda tarea es implementar una funcionalidad end to end siguiendo los ejemplos de otras funcionalidades que tenemos en el código, como de bien está implementado y que sea correcto. En este caso la implementación del código es una funcionalidad para cancelar pedidos.
Para que no quede un post enorme, voy a poner unos resúmenes en cada uno de los apartados, pero estará todo en detalle tanto en github, como en el vídeo de youtube.
Obviamente, para realizar esto bien tengo que eliminar la memoria, etc, entre cada una de las tareas.
Una nota a mencionar es que he notado que han tardado muchísimo, en otras pruebas que he hecho, tanto GLM 5.2, GPT-5.5, etc, el resultado era relativamente rápido, con los modelos de antropic ha tardado mucho más tiempo.
2.1 - Análisis de Claude Sonnet 4.6 para desarrollo
El primer modelo que vamos a empezar es sonnet 4.6 y la idea de empezar con este modelo es porque así podemos tratarlo como un baseline para ver de dónde venimos.
Obviamente podríamos compararlo con otro modelo, ya sea open source como GLM 5.2 o de otras empresas pero pienso que partir de sonnet 4.6 como baseline es ideal.
A - ¿Cómo es sonnet 4.6 para hacer code reviews?
Sonnet 4.6 ha encontrado 10 problemas donde la gran mayoría son correctos: la división entera que siempre da cero, el publicar el evento antes de confirmar la escritura, el diccionario estático que simula una caché (aunque a medias, porque no mencionó el problema de memoria hasta un finding posterior), el Math.Round con double en vez de decimal, el test que no valida absolutamente nada, etc.
Lo que se ha dejado: que el endpoint siempre devuelve 200 porque el método siempre devuelve true, el cancellation token que no se está pasando, el try/catch que se traga todas las excepciones y la validación del ID en el handler. Tampoco cayó en ninguna de las dos trampas, pero como no indico qel finding asociado, no hay penalización.
Resultado: 64/100. Que os digo una cosa: 64 sobre 100, una marca aceptable.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-4.6/task1_code_review_evaluation.md
B - ¿Cómo es sonnet 4.6 para programar funcionalidades completas?
Aquí la cosa empieza regulerea ya que no ha escrito tests, que si bien no es un requisito, ningún software tendría que salir sin tests.
A partir de ahí, el endpoint existe pero no sigue el estilo del resto del proyecto (el cancel va en la URL en vez de seguir la convención de los demás endpoints), aunque sí utiliza el result pattern sin excepciones, controla que un pedido cancelado no se pueda volver a cancelar, sigue los principios DDD con su Apply, respeta la idempotencia (no genera otro evento si ya está cancelado) y pasa los cancellation tokens por todos lados.
Resultado: 70/100, muy aceptable.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-4.6/task2_feature_implementation.md
Total Sonnet 4.6: 134 puntos, lo que lo deja por encima de GPT-5.5 en la clasificación. Oye, no está mal.
NOTA: Todos estos puntajes los hice "en directo" durante el vídeo, y por algún motivo Sonnet 4.6 tarda mucho más que el resto, e incluso gasta más tokens, cosa que ni después de editar el vídeo comprendo. El effort estaba igual que en el resto, así que no sé qué ha pasado ahí.
2.2 - Análisis de Claude Sonnet 5 para desarrollo
Una vez ya tenemos la base, podemos ir a los modelos que son mejores, pero obviamente más caros. La teoría dice que el funcionamiento de Sonnet 5 para la code review debería ser similar, algo mejor pero similar, mientras que en la implementación de la funcionalidad es donde debería notarse la diferencia, ya que estos modelos están evolucionando hacia la autonomía en tareas largas.
A - ¿Cómo es Sonnet 5 para hacer revisiones de código?
Sonnet 5 ha sido bastante más rápido y más barato que Sonnet 4.6, lo cual ya es una alegría. Ha encontrado prácticamente lo mismo: la división entera, el diccionario estático (esta vez sí, mencionando que crece sin límites, así que puntos completos), la key de la caché con el precio equivocado, el double en vez de decimal, la publicación del evento sin garantías, la falta de validación del input, el test que no valida nada y el cancellation token que no se pasa.
Se ha dejado el try/catch (menciona que puede causar errores, pero no que siempre devuelve verdadero, que es lo que quiero que me diga) y la validación del ID en el handler.
Resultado: 72/100. Un poquitín mejor que Sonnet 4.6, pero muchísimo más rápido.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-5/task1_code_review_evaluation.md
B - ¿Cómo es Sonnet 5 para programar funcionalidades completas?
Aquí es donde ha pinchado. El endpoint y el result pattern están perfectos, controla que un pedido cancelado no se pueda volver a cancelar, sigue DDD con el Apply, y pasa los cancellation tokens.
Pero por algún motivo no ha generado el evento de dominio, por lo que no hay handler, no hay idempotencia real vía eventos y se cae todo ese bloque de puntos. Y además, una penalización de 10 puntos por poner los tests en el proyecto que no tocaba.
Resultado: 60/100.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-5/task2_feature_implementation.md
Total Sonnet 5: 132 puntos. Como puedes imaginar, que Sonnet 4.6 haya ganado a Sonnet 5 en esta puntuación es chocante, pero también es cierto que el motivo es no hacer el evento de dominio ni el handler, eso por si solo son 20 puntos.
2.3 - Análisis de Opus 4.8 para desarrollo
Personalmente es el modelo que utilizó en el trabajo y espero un resultado similar a lo que nos dio GLM 5.2, el cual me hizo plantearme si tendría que cambiar el test.
A - ¿Cómo es Opus 4.8 para hacer revisiones de código?
En cuanto a encontrar los problemas, Opus 4.8 ha cumplido ya que ha encontrado prácticamente todos los problemas, incluyendo alguno que los Sonnet se dejaron, como que el método siempre devuelve verdadero y por lo tanto el endpoint siempre responde 200.
¿El problema? Las trampas. Opus encontró el problema del try/catch pero no mencionó que el test asociado valida un comportamiento erróneo, y eso son -20 puntos directos. Y puedes decir "oh, macho, qué duro", pero es lo que hay: hay que ser serios, y 20 puntos de descuento son 20 puntos de descuento. Es la misma penalización que se llevó Composer 2.5 en su día por lo mismo.
Resultado: 60/100.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Opus-4.8/task1_code_review_evaluation.md
B - ¿Cómo es Opus 4.8 para programar funcionalidades completas?
Ha tardado 7 minutos en implementar la funcionalidad. Los tests los ha puesto en el proyecto correcto (no como Sonnet 5) y pasan, el endpoint con sus response types está muy bien, utiliza el Result pattern con el binding de errores, que me parece maravilloso...
Pero luego el CanBeCancelled comprueba que el estado sea created o paid en vez de comprobar los estados en los que NO se puede cancelar, no genera el evento de dominio (con lo cual, adiós idempotencia, adiós handler), y de infraestructura, evento de integración y outbox pattern, nada de nada.
Resultado: 50/100. Decepción total y no me lo esperaba.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Opus-4.8/task2_feature_implementation.md
Total Opus 4.8: 110 puntos. Desgraciadamente el resultado no ha sido tan bueno como esperaba, aunque también es verdad que es en gran parte por la penalización de no encontrar la trampa de la code review. Cosa que, bueno, solo penalizo si encuentran el bug como tal, y eso ha perjudicado a Opus 4.8 mientras que no ha perjudicado a los Sonnet, que tampoco flaguearon la trampa. Algo a tener en cuenta.
2.4 - Análisis de Fable 5 para desarrollo
Finalmente llegamos a Fable, el nuevo modelo, y ahora vamos a ver si de verdad hay un cambio importante y si merece la pena pagar el doble por token comparado con Opus 4.8.
Sin haber probado nada aún, la propia definición del modelo nos da a entender que la review debería ser de un nivel similar, o sea, casi perfecta, mientras que donde debería mejorar es en la implementación de la funcionalidad, que es la tarea abstracta con un objetivo. Mi apuesta antes de ejecutar nada: entre 180 y 200 puntos en total.
A - ¿Cómo es Fable 5 para hacer revisiones de código?
Lo ha encontrado prácticamente todo, la división entera, la key de la caché, el diccionario estático con su problema de memoria (grows unbounded), la publicación del evento antes de confirmar la escritura, el try/catch silencioso junto con el "siempre devuelve 200", la validación del input, el test que no valida nada, el double vs decimal, el cancellation token... Y lo más importante: haidentificado la trampa del test que valida un comportamiento erróneo, que es exactamente por lo que le quitamos 20 puntazos a Opus y que a Fable no le vamos a quitar.
Lo único que no ha flagueado es que el handler debería validar que el ID existe, que podríamos entrar en una discusión sobre si de verdad hace falta (en mi opinión sí, pero es discutible).
Resultado: 92/100. Es de lejos el mayor puntaje en una code review; el anterior récord era GLM 5.2 con un 80. Mismo prompt, exactamente todo igual.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Fable-5/task1_code_review_evaluation.md
B - ¿Cómo es Fable 5 para programar funcionalidades completas?
Ha escrito tests (un montón, de hecho), compilan y pasan. El endpoint HTTP PUT de cancelación con sus diferentes response types, correcto. Result pattern, correcto (ha simplificado y no usa el binding como otros, pero está bien). Un pedido cancelado no se puede volver a cancelar, correcto. Sigue DDD con el Apply, genera el evento de dominio, respeta la idempotencia, controla que no se pueda cancelar un pedido enviado o completado, y tiene su domain handler con un TODO para liberar el stock reservado.
¿Fallos? El publish del evento no lleva cancellation token, así que ese punto a medias. Y de los bonus points, ninguno: ni fake API para devolver el stock, ni infraestructura, ni mención al outbox pattern. Quizá el prompt sea demasiado vago para eso, pero oye, se supone que pagamos un dineral por estos modelos precisamente para eso.
Resultado: 90/100.
Enlace al resultado: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Fable-5/task2_feature_implementation.md
Total Fable 5: 182 puntos. Sinceramente, sin palabras.
3 - Conclusión
Ya hemos terminado, y los resultados son por un lado esperados y por otro no: tenemos a Sonnet 4.6, que lo iba a usar de baseline y ha terminado siendo la gran sorpresa. No sé muy bien por qué ha sucedido, pero la realidad es que ha sacado una gran puntuación (134), por delante incluso de Sonnet 5 (132) y de Opus 4.8 (110), aunque a Opus la penalización de la trampa le ha hecho un roto considerable.
Al caso que concierne al post, que es Fable 5: 182 puntos sobre 200 (240 si contamos los 40 puntos de bonus, que no ha hecho ninguno).
Es la primera posición de la clasificación con muchísima diferencia, un 92 en la code review que es récord absoluto y un 90 en la implementación donde prácticamente lo ha hecho todo bien a la primera, sin llevarlo de la mano. La diferencia entre GPT-5, Opus o Sonnet y Fable 5 es brutal.
¿Merece la pena? Depende. Ahora mismo, en cuenta personal, el uso está medio subvencionado y tira que te va; pero cuando pagues por la API el doble por token que Opus, y con la cantidad de tokens que consume, la factura se va de madre.
Para el día a día yo seguiré con Opus 4.8 en el trabajo (aunque a partir del lunes le voy a empezar a dar bola a Sonnet 5), y reservaría Fable 5 para esos objetivos globales tipo epic donde su autonomía de verdad marca la diferencia o para hacer el plan.
Y así es como lucen dentro de la clasificación global dentro de nuestra herramienta para testear:
Si te fijas, esto confirma lo que me temía cuando GLM 5.2 sacó tan buenos resultados: me va a tocar hacer un test nuevo, porque con Fable 5 rozando la puntuación perfecta, la prueba 2026.06 se ha quedado pequeña.
