Anthropic redujo un 20% las tarifas de Fable 5.2, pero el coste por tarea subió un 31% en una prueba

Si su agente de IA pasa horas corrigiendo código, una rebaja de las tarifas por token no garantiza un ahorro. Anthropic ha lanzado Fable 5.2 con precios un 20% inferiores a los de la versión anterior, pero en una prueba independiente de tareas profesionales la factura media por intento aumentó un 31%. La razón es clara: el modelo comprueba su propio trabajo con mayor rigor. Para los equipos, es un motivo para revisar los ajustes de razonamiento y calcular el coste de un resultado que haya superado la revisión.

Fable 5.2 se lanzó junto con Mythos 5.2. Anthropic presenta los nuevos modelos como herramientas para proyectos técnicos complejos en los que la definición de la tarea sigue cambiando durante el trabajo. El lanzamiento coincidió con el inicio de las presentaciones de la empresa a inversores de cara a su salida a bolsa, pero a los desarrolladores les interesa más otra cuestión: cuántas comprobaciones adicionales merece la pena pagar al modelo.

Por qué unos tokens más baratos encarecieron la tarea

Un millón de tokens de entrada de Fable 5.2 cuesta $8, y un millón de tokens de salida, $40. En Fable 5.1 costaban $10 y $50, respectivamente. Sin embargo, la factura final también depende del volumen de trabajo: cuánto razona el modelo, cuántas veces recurre a herramientas y cuánto revisa las soluciones intermedias.

Según el análisis de SemiAnalysis, en la prueba GDPx la nueva versión llegó a generar cientos o miles de comprobaciones donde los modelos anteriores se limitaban a unas veinte. También recurría con más frecuencia a agentes adicionales para que verificaran la solución de forma independiente. El coste medio por tarea pasó de $67,16 a $88,15. Fable obtuvo un 16,4%, el mejor resultado de esta prueba, pero ese porcentaje no se puede extrapolar al desarrollo cotidiano.

Imagine la migración de un servicio a una nueva biblioteca. El agente modifica las llamadas a la API, ejecuta las pruebas y después empieza a comprobar combinaciones poco habituales de parámetros y pide a otro agente que vuelva a revisar el parche. Ese trabajo puede detectar un error grave antes del lanzamiento. Si el cambio afecta a un prototipo interno para una sola tarde, el coste de ese mismo rigor ya resulta más discutible. Es un ejemplo hipotético de cómo se acumulan los gastos, no un experimento publicado.

El máximo razonamiento no garantiza la máxima utilidad

Fable ofrece cinco niveles de esfuerzo: Low, Medium, High, Xhigh y Max. Las aplicaciones Claude y Claude Code utilizan Medium de forma predeterminada. Este ajuste determina cuántos recursos puede dedicar el modelo a resolver una tarea.

Un detalle importante del lanzamiento: varias evaluaciones mostraron que aumentar el esfuerzo no siempre mejora el resultado. En Vals, High superó a Xhigh y Max. Según Anthropic, en FrontierCode 2.0, Fable en High igualó a Opus 5.5 en Max con aproximadamente la mitad del coste por tarea. Esta última es una afirmación del fabricante que conviene comprobar por separado con código propio.

Tampoco existe una superioridad universal. En las mediciones independientes citadas, Fable quedó por detrás de algunos competidores en tareas de terminal y automatización. Por eso, el primer puesto en una clasificación general dice poco sobre si un proceso concreto saldrá más barato: corregir regresiones, preparar documentos financieros o trabajar con el navegador.

El anuncio oficial explica el posicionamiento de Fable y Mythos, mientras que la documentación de Cursor permite consultar las particularidades del uso del modelo en el editor. Al migrar, es importante volver a evaluar los ajustes: que un modo tenga el mismo nombre en distintas versiones no garantiza el mismo consumo.

Qué comprobar antes de cambiar

Seleccione unas decenas de tareas completadas de su propio proyecto y ejecútelas con el modelo actual, Fable Medium y Fable High. Defina de antemano los criterios de aceptación: si pasan las pruebas, si se cumplen los requisitos y cuántas correcciones solicita una persona. Compare los gastos junto con el tiempo de espera y el trabajo manual de revisión.

Una métrica útil es el coste total de todos los intentos dividido entre el número de resultados aceptados. Así se tienen en cuenta tanto los fallos baratos como las ejecuciones satisfactorias costosas. Para las ejecuciones prolongadas, fije un presupuesto, un límite de tiempo y condiciones de parada; de lo contrario, una comprobación adicional puede convertirse fácilmente en un gasto imprevisto.

Fable 5.2 merece una prueba en migraciones complejas y tareas con requisitos incompletos. El traslado masivo de las solicitudes cotidianas debería justificarse con mediciones propias. Si High ya ofrece una solución válida, el siguiente nivel de esfuerzo debe demostrar su utilidad.