El 8 de julio Fable 5 —el modelo más capaz de Anthropic— sale de los planes Pro y Max y pasa a créditos de uso. Antes de que se fuera le pedí una cosa: que escribiera su propio manual de razonamiento. Ese manual, iterado con pruebas A/B contra salidas reales de Fable, es ahora fable-mode: un skill open source de Claude Code que convierte a Opus 4.8 en algo que jueces ciegos no pudieron distinguir del original. Acá cuento cómo lo hice, con los números y la letra chica.

Lo que hace especial a un modelo como Fable no es solo capacidad bruta: es un conjunto de hábitos. Planifica antes de escribir, verifica antes de afirmar, se refuta a sí mismo antes de entregarte nada, y no reporta “listo” sin haberlo comprobado. La capacidad no se copia. Los hábitos sí.

La idea: que el modelo se documente a sí mismo

En vez de escribir yo un prompt gigante tratando de imitar a Fable, invertí el problema: le pedí a Fable que documentara en primera persona su propia forma de trabajar, como instrucciones directas para el modelo que lo lea. El resultado fue un SKILL.md para Claude Code con su protocolo de seis fases (encuadre → plan → ejecución → auto-refutación → loop de verificación → entrega), checklists por tipo de tarea, criterios explícitos de “terminado” y una lista de anti-patrones prohibidos — el “listo” falso, el dato inventado de memoria, el scope creep.

Hasta ahí, nada que no pueda hacer cualquiera con un buen prompt. Lo que cambió el resultado fue lo que vino después.

El loop: no confiar en el primer borrador

Un playbook autoescrito es una hipótesis, no una respuesta. Así que lo puse a prueba con el método más directo posible: pruebas A/B contra el original. Cada tarea de prueba la corrieron dos agentes en contextos independientes, con las mismas herramientas — Opus 4.8 con el skill como instrucciones obligatorias, y Fable 5 nativo sin instrucciones. Después comparé las salidas con una rúbrica de ocho criterios de comportamiento: ¿abre con el resultado?, ¿verificó con evidencia?, ¿respetó el alcance?, ¿se comprometió con una recomendación o tiró un menú?

La primera ronda fue reveladora. La sustancia ya convergía —mismo bug encontrado, mismo fix, misma recomendación— pero Opus no sonaba a Fable en cuatro cosas concretas: narraba el protocolo en la respuesta (títulos tipo “Verificado vs. asumido”), sobre-formateaba respuestas cortas, respondía en abstracto sin buscar los archivos reales del proyecto, y era más tímido con los defectos vecinos al bug reportado. Cada brecha se convirtió en una regla nueva del skill. Tres rondas de iteración después, la brecha desapareció.

Los números

Con la versión final corrí dos tandas de validación: 20 tareas distintas —debugging en Python, JavaScript, SQL y bash, decisiones de arquitectura, review de seguridad, premisas falsas, estimaciones bajo presión, escritura ejecutiva— y las 20 comparaciones convergieron según la rúbrica.

Pero esa evaluación la hacía yo mismo, y un examen donde el alumno se corrige a sí mismo vale poco. Así que agregué la prueba dura: evaluación ciega. Diez jueces independientes (Claude Sonnet, un modelo de otro tier sin interés en el resultado) recibieron cada par de respuestas sin etiquetas y en orden aleatorio, y tenían que elegir la mejor y adivinar cuál venía del modelo frontier.

El resultado: preferencia 4 a favor del clon, 3 a favor de Fable, 3 empates — una moneda al aire. Y en la identificación, los jueces acertaron 3 de 10 — peor que el azar, con cero adivinanzas de confianza alta. Mi momento favorito: en una de las tareas el juez prefirió al clon específicamente por su disciplina de alcance — una regla del skill ganándole al original en evaluación ciega.

Los límites, dichos sin vueltas

Todo lo anterior aplica al trabajo diario: bugs, decisiones técnicas, reviews, escritura. Ahí la ventaja de Fable eran mayormente hábitos, y los hábitos se copiaron. Pero hay una zona donde ningún skill llega: el techo de capacidad. En cadenas de razonamiento muy largas, trabajo agéntico de horas y problemas de frontera, el clon rinde al techo de Opus — estimo un 70-80% del original, y eso es una estimación, no una medición.

La cuenta rápida para tu caso: tu % ≈ (proporción de trabajo diario × 0.95) + (proporción de trabajo de frontera × 0.75). Un dev de producto típico queda cerca del 93%. Y la regla de escalada que dejé documentada en el repo: por defecto el clon; créditos de Fable solo cuando el clon falló dos veces en el mismo problema, o cuando un error cuesta claramente más que los créditos.

También vale decirlo: la evaluación ciega usó jueces IA, no humanos, sobre 10 pares. Es mucho mejor que autoevaluarse, y no es un benchmark académico. Todo el método, las tablas y las limitaciones están publicados en el repo, con la evaluación completa, para que nadie tenga que creerme nada.

Cómo instalar el skill en Claude Code

Todo el proyecto es open source: github.com/fabdelgado/fable-mode. La instalación completa (skill + reglas siempre activas) es una línea:

curl -fsSL https://raw.githubusercontent.com/fabdelgado/fable-mode/main/install.sh | bash

O como plugin nativo de Claude Code:

/plugin marketplace add fabdelgado/fable-mode
/plugin install fable-mode@fable-mode

Después abrí una sesión nueva y listo: las seis reglas núcleo corren solas en cada sesión, y el protocolo completo se activa con /fable-mode o solo, cuando la tarea lo amerita.

Lo que me queda de todo esto

Fable vuelve a los planes cuando Anthropic tenga capacidad, o no vuelve — nadie publicó fecha. En cualquiera de los dos escenarios, el clon gana: si vuelve, queda como piso elevado permanente; si no, es la diferencia entre pagar o no pagar por el trabajo diario.

Pero el aprendizaje de fondo es otro. Los modelos son alquilados: los cambian, los sacan de los planes, les suben el precio. Los hábitos que les extraés y sabés codificar son tuyos, y viajan intactos al modelo que venga después. Escribir reglas, skills y loops de verificación es la habilidad que sigue valiendo cuando cambie el modelo de moda — y ese es el mejor argumento para empezar a hacerlo hoy.

¿Tenés un flujo de trabajo con IA que querés llevar a este nivel de sistematización? Hablemos.