Diseñando loops con Fable 5

• Se presentan dos técnicas clave para aprovechar bien Claude Fable 5, un modelo de clase Mythos que cambió la forma de trabajo interna en Anthropic: self-correction loop y memory
• Un goal o rubric bien diseñado inyecta retroalimentación en el entorno, para que Claude repita la estructura de ejecución → recolección de feedback → autocorrección hasta cumplir el objetivo
• En el reto de ingeniería de ML Parameter Golf, Fable 5 mejoró el pipeline de entrenamiento aproximadamente 6 veces más que Opus 4.7
• A través de memory, un outer loop que atraviesa sesiones, Claude reutiliza en sesiones posteriores lo registrado durante una sesión
• La idea central es que resulta más efectivo diseñar loops para que el modelo se corrija y gestione el contexto por sí mismo, en lugar de depender de prompting o control directo

---

Self-correction loop (loop de autocorrección)

• Una receta general para mejorar el desempeño en tareas es dejar que el modelo haga hillclimb sobre criterios de evaluación
  • bcherny menciona que "su trabajo consiste en escribir loops"
  • /goal de Claude Code y Outcomes de Claude Managed Agent son primitives que aplican esta receta a tareas específicas
• Un goal o rubric bien diseñado agrega feedback al entorno en el que corre Claude, y luego avanza mediante ejecución, recolección de feedback y autocorrección hasta satisfacer el goal/rubric

Prueba de Parameter Golf

• Parameter Golf es un desafío open source de ingeniería de ML para entrenar, en menos de 10 minutos y con 8xH100, el modelo de mayor rendimiento que quepa dentro de un artifact de 16MB
  • Evalúa la capacidad de editar un único archivo train_gpt.py, ejecutar entrenamiento, consultar logs, revisar puntajes y decidir el siguiente experimento
  • Es similar al proyecto autoresearch de karpathy
• Se comparó Fable 5 con Opus 4.7 usando Claude Managed Agents (CMA)
  • CMA ofrece un agent harness y un sandbox alojado, adecuado para tareas largas de Fable 5
  • Para Parameter Golf se proporcionó un sandbox self-hosted con GPUs 8xH100

La importancia de quién califica

• Se confirmó que el modelo muestra problemas al hacer self-critique sobre su propia salida (como describió Prithvi Rajasekaran en el blog de ingeniería)
• Un verifier sub-agent supera a la self-critique, porque la calificación se realiza en una ventana de contexto independiente
  • Outcomes de CMA maneja esto creando automáticamente un grader sub-agent
• Se proporcionó un rubric con 9 criterios verificables (como ejecutar el baseline o realizar 20 experimentos), con un tiempo máximo de ejecución de 8 horas
  • El grader de Outcomes solo permite que Claude termine su trabajo después de confirmar que se cumplieron todos los criterios del experimento

Comparación de resultados

• Fable 5 mejoró el pipeline de entrenamiento aproximadamente 6 veces más que Opus 4.7
  • Al dividir los experimentos entre estructurales (cambios de arquitectura) y escalares (ajustes de constantes), Fable 5 apostó por cambios estructurales más grandes y mostró resiliencia (superó una regresión por quantization y alcanzó el máximo resultado)
• Opus 4.7, tras un pequeño avance en el primer experimento, repitió en su mayoría la misma plantilla: ajuste escalar, medición y mantenimiento si el resultado era positivo

Memory (memoria)

• Como outer loop que atraviesa sesiones, permite buscar y reutilizar en sesiones posteriores la memoria escrita durante una sesión
• El equipo de pgasawa publicó Continual Learning Bench 1.0
  • Es el primer benchmark realista para medir cuánto mejora un sistema de IA en un entorno online
  • Los benchmarks anteriores asumían modelos stateless, procesando cada ejemplo de forma independiente

Configuración de la prueba

• En una de las tareas del benchmark se compararon Fable 5, Opus 4.7 y Sonnet 4.6
  • Era una tarea de responder preguntas secuenciales con acceso a una base de datos SQL; cada pregunta era una sesión separada de agent, con memory disponible
• Se usó la memory de CMA, que proporciona a cada agent un filesystem montado compartible entre sesiones

Etapas del uso efectivo de memory

• El uso efectivo de memory se fortalece avanzando por fail (registrar errores) · investigate (identificar la causa) · verify (convertirlo en hechos verificados) · distill (generalizarlo como regla) · consult (consultar la regla)
• Sonnet 4.6 se queda cerca de la etapa 1
  • Su repositorio contiene notas de fallos y conjeturas sin resolver ("maybe prc instead of prc_usd?"), y casi no consulta notas anteriores
  • Para mejorar su desempeño necesita instrucciones de memory específicas por tarea
• Opus 4.7 se queda cerca de la etapa 3
  • Genera referencias de esquema marcando incertidumbre ("possibly prc in cents? Verify."), pero la cobertura de verificación es baja, entre 7% y 33% (mediana de aproximadamente 17%)
• Fable 5 tiende a completar el proceso
  • En su mejor ejecución alcanzó una cobertura de verificación de hasta 73% (22 de 30) y destiló lo aprendido en reglas generales útiles para tareas futuras

Resumen general

• Más que hacer prompting o controlar directamente a Fable 5, es más efectivo diseñar loops para que responda al feedback del entorno (/goal, Outcomes), se autocorrija y gestione por sí mismo el contexto con memory
• Se recomienda probar directamente a Fable 5 en tareas desafiantes usando loops de autocorrección y memory