Anthropic acaba de presentar Claude Fable 5.2 y Claude Mythos 5.2. La noticia puede leerse como otra vuelta de tuerca en la carrera de los modelos frontier: más código, más razonamiento, más capacidad para coordinar agentes y una lista de benchmarks que parece pedir una calculadora antes que una opinión. Pero hay un detalle bastante más interesante que el habitual desfile de porcentajes: Anthropic está separando con más nitidez el modelo disponible para todos del modelo que reserva para entornos verificados.
Fable y Mythos 5.2 comparten el mismo modelo subyacente. Fable incorpora salvaguardas de ciberseguridad y biología para poder distribuirse de forma general; Mythos retira parte de esas barreras y queda limitado a organizaciones evaluadas mediante los programas de verificación de Anthropic. La diferencia, por tanto, no es solo comercial ni una etiqueta de catálogo. Es una decisión sobre dónde termina la capacidad que se ofrece al mercado abierto y dónde empieza la que exige controles adicionales.[2]
La cobertura de The Verge resume bien el anuncio: Anthropic promete avances en código, razonamiento y visión, y sitúa Fable 5.2 como una herramienta para problemas técnicos grandes y prolongados. Conviene añadir la letra pequeña: los resultados y los ejemplos científicos que acompañan el lanzamiento proceden principalmente de la propia Anthropic. Son información relevante, desde luego, pero no equivalen todavía a una auditoría independiente de cada conclusión.[1][2]
La novedad no es que haga más. Es que pretende sostener más trabajo.
Los modelos anteriores ya escribían funciones, analizaban repositorios y respondían sobre documentación. El salto que Anthropic intenta vender con Fable 5.2 está en otra parte: mantener una tarea abierta, usar herramientas, repartir subtareas y volver a comprobar lo que se ha hecho sin que el usuario tenga que reconstruir el contexto cada veinte minutos.
En su anuncio, la empresa describe usos internos muy ambiciosos: una migración de un servicio crítico de Python a Rust, un experimento en el que más de mil subagentes construyeron un prototipo de sistema operativo y la formalización de un teorema en Lean. Son relatos de proveedor, no una garantía de que cualquier equipo vaya a obtener ese resultado con un prompt de tres líneas. Aun así, señalan hacia dónde está cambiando el trabajo: el modelo deja de ser solo quien completa una pieza de código y pasa a ser quien participa en una cadena de investigación, diseño, ejecución y revisión.[2]
Esta diferencia importa porque en los proyectos reales el cuello de botella rara vez es escribir una función aislada. Suele ser entender un sistema viejo, identificar qué datos faltan, probar cambios sin romper lo que funciona, documentar decisiones y saber cuándo detenerse. Un agente puede reducir parte de ese trabajo, pero también puede multiplicar rápidamente un error de diagnóstico. Darle una tarea para ocho horas no convierte ocho horas en valor. Convierte una hipótesis en ocho horas de acciones que necesitan trazabilidad.
Los números son buenos; la comparación exige algo de higiene
Anthropic publica mejoras notables frente a Fable 5.1 en sus tablas. En FrontierCode 2.0 informa de un 49,1% para Fable 5.2 con esfuerzo xhigh, frente al 32,4% de Fable 5.1. En FrontierSWE v2 reporta 69,9% frente a 56,3%; en AutomationBench, 51,4% frente a 31,4%. También atribuye al modelo 74,6% en Terminal-Bench-Science y 89,3% en OSWorld 2.1, una evaluación de uso de computadora fuera de línea y parcial.[2]
Esos datos sirven para una primera orientación, pero hay tres precauciones sensatas. La primera: no todos los modelos de la tabla se ejecutan con el mismo nivel de esfuerzo ni necesariamente con el mismo andamiaje. La segunda: algunos resultados, incluidos varios de seguridad, se refieren específicamente a Mythos, sin las salvaguardas que sí intervienen en Fable. La tercera: un benchmark responde a una definición concreta de éxito; no nos dice por sí solo cuánto costará integrar el modelo en un proceso de negocio, revisar sus salidas o responder cuando una integración falle.
La propia documentación aporta una comparación más útil para un responsable técnico: Fable 5.2 está pensado para razonamiento exigente y trabajo agente de largo alcance, pero Anthropic recomienda empezar con Opus 5.5 para la mayoría de tareas de código y conocimiento. Es una recomendación sensata. Si el modelo caro y más capaz acaba resolviendo correos, resúmenes o transformaciones mecánicas, lo que se ha automatizado es el presupuesto.[3]
La consecuencia práctica es clara. Antes de cambiar de modelo, hay que medir la tarea completa: calidad de la solución, tiempo humano de supervisión, consumo de tokens, número de llamadas a herramientas, tasa de reversión y coste de los errores. Cambiar el nombre del modelo en una variable es la parte más fácil de una migración. La parte cara llega después, cuando alguien descubre que una conversación preservaba un bloque de razonamiento que el nuevo enrutamiento ya no puede leer.
Hay además una diferencia entre medir una respuesta y medir un proceso. Una respuesta puede parecer impecable y aun así haber llegado tarde, haber consultado la fuente equivocada o haber dejado una modificación sin prueba. Por eso los pilotos serios necesitan muestras repetidas, casos con resultados conocidos y una revisión que evalúe el recorrido, no solo el párrafo final. Un agente que entrega una explicación convincente de un cambio fallido sigue siendo un agente que ha fallado, aunque lo haga con una prosa admirable. Esa distinción suele perderse cuando la conversación se limita a comparar capturas de pantalla.
Precio: baja la tarifa, no desaparece la factura
Fable 5.2 y Mythos 5.2 cuestan 8 dólares por millón de tokens de entrada y 40 dólares por millón de tokens de salida. La versión rápida duplica ambas tarifas a 16 y 80 dólares, respectivamente. Frente a los 10 y 50 dólares por millón de tokens de Fable 5.1, la rebaja existe. También hay una lectura de caché a 0,20 dólares por millón de tokens, lo que puede importar mucho en agentes que reutilizan un contexto extenso.[2][3]
Pero el precio por token es solo una parte del coste. Un agente que investiga, delega y verifica puede utilizar más contexto, más herramientas y más iteraciones que un chat ordinario. Si además se activa el modo rápido para reducir tiempos de espera, el ahorro de horas humanas debe compensar una tarifa de tokens que se duplica. No hay una respuesta universal. Hay una cuenta que cada empresa debería hacer con sus propios flujos, sus propios errores y sus propios tiempos de revisión.
Para un caso sencillo, como clasificar documentos con una plantilla estable, quizá baste un modelo menor y una validación bien diseñada. Para depurar una migración compleja, leer un monorepo o coordinar investigación con evidencias, la economía puede inclinarse a favor de un modelo como Fable 5.2. La diferencia no es romántica: hay que comparar el coste de la ejecución con el coste de que un equipo experto haga ese trabajo, incluido el coste de corregir una mala decisión tomada por la automatización.
Fable y Mythos: la frontera de acceso ya forma parte del producto
La arquitectura comercial de Anthropic merece atención. Fable 5.2 se ofrece a usuarios y desarrolladores de forma amplia, aunque sus salvaguardas bloquean o redirigen ciertas peticiones de ciberseguridad y biología. Mythos 5.2 conserva las mismas capacidades de base, pero su acceso se limita a organizaciones evaluadas mediante los programas de verificación de ciberseguridad y ciencias de la vida.[2][5]
Esto tiene una consecuencia incómoda pero saludable: no todos los usuarios recibirán el mismo comportamiento para la misma pregunta. En Fable, Anthropic indica que muchas consultas de ciberseguridad y biología se derivan a modelos Opus mediante mecanismos de reserva. En Mythos, un equipo verificado puede trabajar con capacidades más amplias en esos ámbitos. Para un auditor, un investigador biomédico o una empresa de seguridad, esa distinción no es un detalle técnico. Afecta a las pruebas, los procedimientos internos y la expectativa de resultado.[4]
También obliga a abandonar una costumbre bastante extendida: creer que el nombre de un modelo basta para describir el sistema. No basta. Hay modelo, configuración de esfuerzo, herramientas disponibles, salvaguardas, política de retención, contexto, proveedor cloud y permisos del usuario. Dos equipos pueden decir que usan “Claude Fable 5.2” y estar operando sistemas materialmente distintos. En inteligencia artificial, la etiqueta del motor explica cada vez menos sin el resto del vehículo.
La retención de datos es una conversación que no debe quedarse al final
La documentación de Anthropic establece una retención de 30 días para Fable 5.2 y Mythos 5.2 cuando se usan sus salvaguardas de frontera. La empresa plantea Enterprise Frontier Safeguards como una vía para que la monitorización automatizada se ejecute sobre datos almacenados en la infraestructura del cliente y pueda compatibilizarse con cero retención, pero su disponibilidad depende de elegibilidad y del despliegue correspondiente.[2][3]
Es el tipo de condición que se descubre demasiado tarde, normalmente cuando ya hay un prototipo que funciona y alguien pregunta qué datos viajan, dónde se guardan y durante cuánto tiempo. Si el proyecto toca contratos, expedientes de salud, información financiera o código propietario, la conversación sobre retención debe ocurrir antes de conectar el repositorio. Después suele ser más cara, más lenta y bastante menos elegante.
Tampoco basta con pedir al proveedor una frase tranquilizadora sobre privacidad. El equipo debe documentar qué parte del flujo contiene datos sensibles, qué se minimiza o se anonimiza antes del envío, quién puede ver los resultados y cómo se elimina la evidencia al terminar una prueba. La gobernanza no es un párrafo de la política de compras: es una propiedad del diseño técnico.
Esto no invalida el modelo. Define el perímetro en que conviene usarlo. Las empresas que mejor adopten estas herramientas no serán necesariamente las que pongan el modelo más grande en más procesos. Serán las que diferencien tareas: qué puede hacerse con datos sintéticos, qué requiere un entorno con controles adicionales, qué necesita revisión humana y qué no merece automatizarse todavía.
Hay cambios de API que pueden romper una migración aparentemente menor
Quien use Claude por API no debería tratar Fable 5.2 como una actualización cosmética. La documentación recoge varias incompatibilidades: la comprobación de prefijo se aplica a todas las cuentas, de modo que editar mensajes previos, herramientas o el system prompt antes de un bloque de razonamiento puede provocar un error 400. El antiguo mecanismo computer_20251124 también deja de funcionar fuera de Amazon Bedrock; la ruta admitida es el conjunto de herramientas más reciente.[3]
Hay otra sutileza: Fable 5.2 y Mythos 5.2 pueden leer los bloques de razonamiento del otro, pero otros modelos no conservan necesariamente esos bloques al recibir una conversación. Si un sistema usa un enrutador para alternar modelos por coste o disponibilidad, hay que probar qué pasa con el contexto, no asumir que el historial de mensajes es suficiente.
Mi recomendación sería muy poco cinematográfica y bastante eficaz: crear una batería de conversaciones reales, repetirlas antes y después del cambio, registrar la calidad, el coste, el tiempo, las llamadas a herramientas y los errores. Añadir una prueba específica para conversaciones que editen mensajes, cambien herramientas o hagan fallback. Una migración que sale bien en una demo puede fallar el lunes a las nueve cuando entra la conversación larga que nadie usó para probarla. La informática tiene esa delicadeza.
Qué haría un equipo que quiere probarlo sin convertir el piloto en un salto de fe
Empezaría por elegir un caso de uso de alto valor y un límite claro. Por ejemplo: revisar incidencias complejas de un repositorio, preparar una propuesta técnica a partir de documentación dispersa o investigar discrepancias entre dos fuentes de datos. Evitaría iniciar con un proceso que pueda ejecutar pagos, borrar información o cambiar configuraciones de producción. Si la demostración necesita ser heroica para parecer útil, quizá aún no es una demostración sino una apuesta.
Después definiría una línea base. ¿Cuánto tarda hoy una persona? ¿Qué calidad tiene la solución? ¿Cuántos errores aparecen al revisar? ¿Qué información no puede salir del entorno? Sin esa línea base, cualquier respuesta rápida parece una mejora. Con ella, se puede decidir si el modelo ahorra trabajo o simplemente produce un informe más largo.
El tercer paso sería diseñar controles de parada y evidencia. Un agente que hace cambios debe dejar un registro legible: qué observó, qué supuso, qué archivos modificó, qué pruebas ejecutó y qué queda sin comprobar. Los buenos agentes no son los que parecen más seguros de sí mismos. Son los que hacen visibles sus límites antes de que alguien tenga que descubrirlos en producción.
Finalmente, compararía Fable 5.2 con una opción menos costosa en la misma tarea. Anthropic aconseja precisamente iniciar con Opus 5.5 en la mayoría de los trabajos y escalar cuando las evaluaciones indiquen que hace falta. Es una disciplina sencilla: pagar por capacidad cuando la capacidad cambia la decisión, no cuando mejora la estética de la demo.[2][3]
La noticia de fondo
Fable 5.2 no importa solo por sus cifras. Importa porque hace más visible una transformación que venía formándose: los modelos más potentes ya no se presentan como un asistente que responde, sino como un operador que planifica, delega, usa herramientas y sostiene procesos largos. Eso abre oportunidades concretas en ingeniería, ciencia y análisis. También eleva el precio de equivocarse en el diseño del sistema.
La pregunta útil para una empresa no es si el nuevo modelo “es mejor”. En los resultados publicados por Anthropic, lo es en varias evaluaciones y a menor precio nominal que su predecesor.[2] La pregunta útil es otra: ¿en cuál de nuestros procesos una mayor capacidad, con sus condiciones de datos, sus salvaguardas y su coste, produce una mejora que podamos medir y controlar?
Quien responda bien a esa pregunta tendrá una ventaja. Quien sustituya el análisis por el nombre del modelo tendrá, como mínimo, una factura más interesante que su estrategia.