Anthropic lanza Fable 5.2: resultados cercanos a Opus por casi la mitad del coste por tarea

Un agente de IA puede pasar horas corrigiendo un error, ejecutando pruebas y reescribiendo su propio parche. Para el equipo, la cuestión pronto se vuelve económica: ¿cuánto cuesta producir un cambio que un desarrollador esté realmente dispuesto a aceptar? Anthropic ha lanzado Fable 5.2 y afirma que, en una prueba de programación, el modelo se acercó al resultado de Opus 5.5 con casi la mitad del coste por tarea. Es un motivo para poner a prueba la configuración de tu agente, sobre todo si el gasto en razonamientos prolongados ya se nota en el presupuesto.

De dónde sale el ahorro

En FrontierCode 2.0, Fable 5.2 con el nivel High obtuvo un 45,3%, mientras que Opus 5.5 con Max alcanzó un 45,5%. La prueba evalúa si los responsables de mantener repositorios de código abierto aceptarían los cambios propuestos por el modelo. Según la compañía, el coste por tarea de Fable en esta comparación fue aproximadamente la mitad. La API del nuevo modelo cuesta $8 por millón de tokens de entrada y $40 por millón de tokens de salida. Las cifras proceden del anuncio de Anthropic.

Aquí conviene distinguir entre el precio de un token y el coste de un resultado. El primero figura en la tarifa. El segundo depende de cuántas veces intente el agente corregir el error, cuánto contexto lea y cuánto trabajo deje para una persona. Una ejecución más barata puede acabar saliendo más cara si después un ingeniero dedica media jornada a restablecer el funcionamiento que se ha roto.

El nivel de razonamiento también pasa a formar parte de la elección. Comparar modelos solo con sus ajustes máximos resulta cómodo para una clasificación de récords. Para un producto, es más útil encontrar un nivel que ofrezca una calidad aceptable con un presupuesto asumible. El resultado de Anthropic muestra por qué merece la pena hacer ese experimento, aunque no permite prometer de antemano el mismo ahorro a un equipo concreto.

Cómo comprobarlo con un error conocido

Imaginemos un servicio de suscripciones: tras repetirse una solicitud, un cliente recibe a veces dos cargos idénticos. El agente debe investigar cómo se gestionan los reintentos, corregir el código y añadir una comprobación. Una explicación impecablemente redactada no resuelve nada si los cargos duplicados siguen apareciendo.

Para comparar modelos, prepara la misma instantánea del repositorio, la misma descripción del error y las mismas herramientas disponibles. Establece límites idénticos de tiempo y gasto. Después, comprueba si el parche resuelve el problema original, si pasan las pruebas existentes y si cambia el comportamiento de los casos relacionados. Conviene que quien revise los cambios los evalúe primero sin conocer el nombre del modelo: así habrá menos tentación de perdonarle un fallo a su favorito.

Un solo error no basta. Reúne un pequeño conjunto de tareas ya resueltas: corregir una regresión, ampliar una API, modificar un esquema de datos y localizar la causa de una consulta lenta. Para cada una, registra el coste de las ejecuciones, el número de reintentos y el tiempo de revisión humana. La métrica principal es el gasto por corrección aceptada. Conviene observar también la proporción de tareas resueltas y el tiempo de ejecución; de lo contrario, el ahorro podría ocultar una pérdida de calidad o velocidad.

Para un responsable de producto, es una forma de comprobar una hipótesis concreta: si es posible atender más solicitudes complejas con el mismo presupuesto. Para un fundador, es una oportunidad de evaluar el coste de una función antes de prometer a los usuarios un asistente ilimitado.

Hasta dónde llegan las conclusiones del anuncio

La comparación publicada tiene una limitación importante: los resultados los presentó el propio proveedor. Tus repositorios, herramientas, instrucciones y criterios de aceptación pueden diferir considerablemente de los utilizados en la prueba. La diferencia entre el 45,3% y el 45,5% tampoco demuestra por sí sola que los modelos sean equivalentes en todas las tareas de ingeniería.

Por tanto, sería prematuro cambiar de modelo de inmediato en todo el producto. Un primer paso razonable es ejecutar las tareas guardadas y después asignar a la nueva configuración una pequeña parte del trabajo real, con la revisión habitual. Si se confirma la ventaja, su uso puede ampliarse de forma gradual, manteniendo la posibilidad de volver a la configuración anterior.

El valor práctico del lanzamiento reside en una promesa verificable de reducir el coste del trabajo complejo. Cada equipo necesita su propia respuesta a una pregunta sencilla: cuánto dinero y tiempo requiere una corrección que supera la revisión y se incorpora al código principal.