Claude Fable 5.2: una frase sube el refactor al 50%

Una frase que cambia el comportamiento del modelo

En las pruebas de Anthropic con tareas pequeñas de código, Claude Fable 5.2 fusionó código repetido en cerca de la mitad de los intentos cuando el prompt decía que el código era suyo, y en menos de una décima parte cuando no lo decía. La diferencia entre esos dos escenarios no fue un cambio de modelo, ni de temperatura, ni de esfuerzo de razonamiento: fue una sola frase en el prompt.

Para un equipo que ya tiene agentes de código escribiendo en su repositorio, eso es una palanca de calidad con costo cero. Y también es una advertencia: si nunca le dices al modelo quién es dueño del código, el comportamiento por defecto es el conservador.

¿Qué dice la documentación de Anthropic sobre la propiedad del código?

Simon Willison citó el 10 de noviembre de 2026 la sección de la documentación de Anthropic que trata este punto. Según ese texto, el modelo responde con bastante fidelidad a lo que el prompt dice sobre quién es dueño del código con el que trabaja.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

En las pruebas de Anthropic sobre tareas pequeñas de código, cuando el prompt no decía nada sobre la propiedad o presentaba el código base como de otra persona, el modelo tendía a sumar a la estructura existente, incluso cuando eso repetía código que ya estaba ahí.

La instrucción que la documentación propone para el caso contrario es literal:

«This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.»

En español: este código base es tuyo, para qué sirve y cómo está construido es decisión tuya, y vas a seguir construyendo sobre él. Con esa frase, el modelo fusionó código repetido en cerca de la mitad de los intentos. Sin ella, en menos de una décima parte.

El detalle importa porque no se trata de una instrucción de estilo ni de un formato de salida. Es una instrucción sobre permiso. El modelo no está decidiendo si el código está bien o mal: está decidiendo si tiene autoridad para reorganizarlo.

¿Por qué el modelo repite código cuando no le dices que es suyo?

La lectura más razonable —y conviene marcarla como interpretación nuestra, no como dato de la documentación— es que el modelo trata el código base como un artefacto ajeno. Ante la duda, el comportamiento seguro es agregar sin tocar: escribir una función nueva al lado de la existente en lugar de unificarlas.

Eso explica por qué el efecto aparece en tareas pequeñas. En un cambio acotado, el modelo tiene menos margen para justificar una reestructuración. Si el código es de otro, agregar es lo menos invasivo. Si el código es suyo y va a seguir construyendo sobre él, la duplicación se vuelve un problema propio.

Para un founder, el costo de ese comportamiento por defecto es acumulativo. Un agente que agrega en vez de consolidar no rompe nada el primer día. Al mes tienes tres versiones de la misma validación, dos helpers que hacen lo mismo y un módulo que nadie se anima a tocar. La deuda no la genera un error: la genera el sesgo por defecto.

¿Qué más trae Claude Fable 5.2 además de esta técnica de prompting?

El modelo no llega solo con esta recomendación. Según Brave New Coin, Anthropic lanzó Claude Fable 5.2 y Claude Mythos 5.2 con una reducción del 20% en los precios estándar de la API: US$8 por millón de tokens de entrada y US$40 por millón de salida, frente a los US$10 y US$50 de la generación 5.1. El mismo medio reporta una ventana de contexto de un millón de tokens y hasta 128.000 tokens de salida, y que Anthropic afirma una velocidad de generación hasta un 30% mayor que la versión 5.1.

En la evaluación interna FrontierCode 2.0 de Anthropic, el modelo obtiene 49,1% con esfuerzo Xhigh, frente a 32,4% de Fable 5.1 en ese mismo ajuste, según la misma cobertura. Brave New Coin señala además un detalle que conviene leer con cuidado: el ajuste Max, más caro, puntúa por debajo de Xhigh en esa evaluación. Más gasto no garantiza mejor resultado.

Fable y Mythos comparten el mismo modelo de base, con salvaguardas y requisitos de acceso distintos. Mythos queda restringido a organizaciones admitidas mediante los programas de verificación de Anthropic, según Brave New Coin. Fable está disponible en la API de Claude y en plataformas cloud como Amazon Bedrock, Google Cloud y Microsoft Foundry.

¿Cuánto cuesta dejar que el modelo trabaje solo?

El precio por token cuenta una parte de la historia. La otra es cuántos tokens consume una tarea cuando el modelo trabaja de forma autónoma. Decrypt reporta las pruebas de Matthew Berman, que describió a Fable 5.2 como el mejor modelo que ha usado: un nivel inspirado en Gears of War le tomó 43 horas y 48 minutos de construcción y 8.630 millones de tokens, con un costo estimado de API de US$14.710. Un clon de Excel en el navegador llegó a unos US$11.700 con descuentos por entradas en caché, y un juego estilo Fall Guys consumió más de 9.000 millones de tokens en 71 horas, equivalente a unos US$13.000.

Son estimaciones de costos de API, y los proyectos no salieron perfectos: Berman reportó animaciones torpes, bugs y funciones que aún necesitaban pruebas, según Decrypt. El mismo medio señala que el precio por token de Fable es el doble del de Claude Opus 5.5, que Anthropic recomienda para trabajo diario, y compara con Kimi 3.1 Pro (US$2 y US$10 por millón de tokens) y el último modelo de Deepseek (US$0,6 y US$1,98 fuera de horas pico).

La conclusión práctica: la frase de propiedad del código no solo mejora el refactor. También reduce el número de intentos que el agente necesita para llegar a un resultado limpio. En un modelo con este perfil de costo, cada intento evitado se paga solo.

¿Qué significa esto para tu startup?

Primero: deja de asumir que el modelo sabe de quién es el código. Si tu prompt de sistema o el archivo de instrucciones de tu agente no dice nada sobre la propiedad, el modelo está operando en el modo conservador. No es un bug: es el comportamiento documentado.

Segundo: la frase va en el prompt de sistema, no en el prompt de cada tarea. Es una instrucción de contexto permanente, no una instrucción puntual. Escríbela una vez, en el lugar donde tu agente lee las reglas del proyecto.

Tercero: mide el refactor, no solo el resultado. Que el código compile no te dice si el agente consolidó o duplicó. Cuenta cuántos bloques repetidos quedaron en el diff. Es la métrica que la propia documentación usa para reportar el efecto.

Cuarto: presupuesta el costo por tarea, no por token. Con agentes que trabajan durante horas, el costo por token es una mala unidad de decisión. La unidad útil es cuánto cuesta una tarea terminada y aceptada.

¿Cómo lo pruebas en tu repositorio esta semana?

No necesitas un benchmark. Necesitas un experimento pequeño y honesto:

Elige 10 tareas de refactor acotadas y comparables entre sí: consolidar una validación, unificar dos helpers, eliminar un bloque duplicado.
Corre las 10 con tu prompt actual y anota en cuántas el agente fusionó el código repetido en lugar de agregar una variante nueva.
Corre las mismas 10 con la frase de propiedad incluida y compara los resultados.
Revisa también el costo: tokens consumidos y tiempo hasta el diff aceptado.

La referencia que da la documentación es amplia: menos de una décima parte de los intentos sin la frase, cerca de la mitad con ella. Tu número va a ser distinto, porque depende de tu código, de tus tareas y de tu configuración. Pero si el salto aparece, tienes una mejora de calidad que no cuesta nada implementar.

Un detalle de gobernanza: si trabajas en un entorno regulado, el prompt no es el lugar para las reglas que deben cumplirse siempre. Un análisis publicado en Hacker Noon sobre el despliegue de asistentes de código agénticos en una empresa regulada lo resume así: las instrucciones en un prompt son orientación; lo que debe cumplirse siempre va en configuración gestionada o en hooks deterministas. La frase de propiedad es una instrucción de calidad, no un control de seguridad.

Conclusión

La noticia no es que un modelo nuevo escriba mejor. Es que Anthropic documentó un comportamiento que cualquier equipo puede aprovechar hoy, con una frase y sin cambiar de herramienta: el modelo trata el código como ajeno salvo que le digas lo contrario, y ese sesgo por defecto se acumula en forma de duplicación.

Si tu agente de código lleva meses agregando en lugar de consolidar, la causa puede estar en una omisión de tu prompt y no en el modelo. Revísalo esta semana. Es de las pocas mejoras de calidad que se implementan en un minuto y se miden en el siguiente diff.