Claude Fable 5.2 en Devin logra un 49,1 % en FrontierCode 2.0, frente al 32,4 % de la 5.1

Una historia conocida: el agente informa de que la tarea está resuelta y los tests están en verde, pero en la revisión resulta que el código no se puede fusionar. No sigue las convenciones del repositorio, rompe un módulo vecino o arrastra cambios innecesarios. Esa diferencia entre «funciona» y «se puede integrar en main» es justo lo que intenta medir el benchmark FrontierCode 2.0 del equipo de Windsurf. Ahora tiene un nuevo líder: Claude Fable 5.2, que ya está disponible en Devin.

Qué muestran las cifras

Según Windsurf, Fable 5.2 obtuvo un 49,1 % en FrontierCode 2.0. A modo de comparación:

• Fable 5.1 — 32,4 %.
• Opus 5.5 — 45,5 %.

La mejora respecto a la versión anterior es de casi 17 puntos porcentuales. No es una actualización cosmética, sino un salto notable en la calidad del código. La diferencia con Opus 5.5 es más modesta, de unos 3,6 puntos, pero el modelo aun así quedó en primer lugar.

La segunda parte de la afirmación es más interesante para quien cuenta el dinero. Según los autores, incluso con un nivel bajo de reasoning effort, Fable 5.2 supera el mejor resultado de Fable 5.1 y cuesta menos de un tercio del precio por tarea. Si esto se confirma con sus datos, la actualización aporta dos efectos a la vez: el código mejora y la factura de la API baja. Normalmente hay que sacrificar una cosa por la otra.

Cómo funciona la evaluación y por qué importa

FrontierCode 2.0 evalúa los modelos en tareas de ingeniería reales según criterios de calidad y «mergeabilidad». La puntuación final es una suma ponderada de los puntos de una rúbrica. Además hay una regla estricta: una solución que no pasa los criterios bloqueantes recibe cero. Esto es radicalmente distinto de las pruebas habituales del tipo «pasó los tests unitarios o no». Aquí no cuenta el código que funciona formalmente pero incumple los estándares del proyecto.

En su gráfico, Windsurf calcula el coste como el importe medio en dólares por ejecución a precios públicos de la API, teniendo en cuenta los descuentos abiertos. Es decir, no es el coste interno, sino lo que pagaría usted. Estas cifras al menos permiten extrapolar de forma aproximada a su propio presupuesto.

Limitaciones y qué hacer en la práctica

La salvedad principal es evidente: el benchmark lo ha ideado y lo mantiene la propia Windsurf, que además vende Devin. Eso no significa que las cifras no sean fiables. Pero sí significa que no hay verificación independiente. Tampoco hay detalles que convendría conocer antes de sacar conclusiones: cuántas tareas tiene el conjunto, qué lenguajes y stacks abarca, cuán estable es el resultado entre ejecuciones. La diferencia de 3,6 puntos entre Fable 5.2 y Opus 5.5 puede estar dentro del margen de ruido, o puede que no; la publicación no permite saberlo.

Por eso, la conclusión práctica es la siguiente.

• Si ya usa Devin, pruebe Fable 5.2 con varias de sus tareas habituales, incluidas las incómodas: refactorización, corrección de bugs en código ajeno, cambios que deban respetar las convenciones.
• Empiece con reasoning bajo. El ahorro declarado, un tercio del coste del mejor resultado de la versión anterior, es potencialmente la parte más valiosa de la versión. Compruebe si este modo le basta antes de pagar por el alto.
• Mida la métrica que le importa. El porcentaje de PR aceptados sin cambios y el tiempo de revisión dirán más que cualquier leaderboard público.

En resumen: Fable 5.2 parece una actualización sólida para el desarrollo con agentes, sobre todo por la combinación «mejor y más barato». Pero por ahora es una afirmación del fabricante sobre su propio benchmark, y la decisión de cambiar debe basarse en los resultados sobre su propia base de código.