Projetando loops com o Fable 5

• Anthropic apresenta self-correction loop e memory como duas técnicas centrais para aproveitar bem o Claude Fable 5 da classe Mythos, que mudou a forma de trabalho interna da empresa
• Com goal e rubric bem projetados, o feedback é injetado no ambiente, permitindo que o Claude execute → colete feedback → faça autocorreção e repita até cumprir o objetivo
• No desafio de engenharia de ML Parameter Golf, o Fable 5 melhorou o pipeline de treinamento em cerca de 6 vezes mais do que o Opus 4.7
• Por meio de memory como outer loop entre sessões, o Claude reutiliza em sessões posteriores o que registrou durante sessões anteriores
• O ponto principal é que, em vez de prompting e controle diretos, projetar loops em que o próprio modelo se corrige e gerencia o contexto é mais eficaz

---

Self-correction loop (loop de autocorreção)

• Uma receita geral para melhorar o desempenho em tarefas é deixar o modelo fazer hillclimb sobre critérios de avaliação
  • bcherny comentou que "seu trabalho é escrever loops"
  • /goal no Claude Code e Outcomes no Claude Managed Agent são primitives que aplicam essa receita a tarefas específicas
• Um goal ou rubric bem projetado adiciona feedback ao ambiente em que o Claude opera, e ele segue executando, coletando feedback e se autocorrigindo até satisfazer o goal/rubric

Teste Parameter Golf

• Parameter Golf é um desafio open source de engenharia de ML para treinar, em até 10 minutos com 8xH100, o modelo de melhor desempenho que caiba em um artifact de 16MB
  • Testa a capacidade de editar um único arquivo train_gpt.py, executar o treinamento, consultar logs, verificar a pontuação e decidir o próximo experimento
  • É semelhante ao projeto autoresearch de karpathy
• Foi usado o Claude Managed Agents (CMA) para comparar Fable 5 e Opus 4.7
  • O CMA fornece agent harness e sandbox hospedado, sendo adequado para tarefas longas do Fable 5
  • Para o Parameter Golf, foi disponibilizado um sandbox self-hosted com GPUs 8xH100

A importância de quem faz a avaliação

• Foi observado que o modelo apresenta problemas em self-critique da própria saída (como descreveu Prithvi Rajasekaran no blog de engenharia)
• Um verifier sub-agent é superior à self-critique porque a avaliação acontece em uma janela de contexto independente
  • Os Outcomes do CMA criam automaticamente um grader sub-agent para isso
• Foi fornecido um rubric com 9 critérios verificáveis (execução do baseline, realização de 20 experimentos etc.), com tempo máximo de 8 horas
  • O grader de Outcomes só permite que o Claude encerre o trabalho depois de confirmar que todos os critérios experimentais foram cumpridos

Comparação de resultados

• O Fable 5 melhorou o pipeline de treinamento em cerca de 6 vezes mais do que o Opus 4.7
  • Ao separar os experimentos entre estruturais (mudanças de arquitetura) e escalares (ajuste de constantes), o Fable 5 apostou em mudanças estruturais maiores e mostrou resiliência (superando uma regressão de quantization para atingir o melhor resultado)
• O Opus 4.7, após um pequeno ganho no primeiro experimento, repetiu quase sempre o mesmo template: ajuste escalar, medição e manutenção se o resultado fosse positivo

Memory (memória)

• Como outer loop entre sessões, permite buscar e reutilizar em sessões futuras a memória escrita durante uma sessão
• A equipe de pgasawa publicou o Continual Learning Bench 1.0
  • É o primeiro benchmark realista para medir o quanto sistemas de IA melhoram em ambientes online
  • Benchmarks anteriores assumiam modelos stateless, tratando cada exemplo de forma independente

Estrutura do teste

• Em uma das tarefas do benchmark, foram comparados Fable 5, Opus 4.7 e Sonnet 4.6
  • A tarefa consiste em responder perguntas sequenciais com acesso a um SQL database; cada pergunta é uma sessão separada de agent, com memory disponível
• Foi usada a memory do CMA, que fornece a cada agent um mounted filesystem compartilhável entre sessões

Etapas do uso eficaz de memory

• O uso eficaz de memory se fortalece ao avançar por fail (registrar o erro) · investigate (identificar a causa) · verify (transformar em fato verificado) · distill (generalizar em regra) · consult (consultar a regra)
• O Sonnet 4.6 tende a parar perto da etapa 1
  • O repositório vira uma lista de notas de falha e suposições não resolvidas ("maybe prc instead of prc_usd?"), quase sem referência às notas anteriores
  • Para melhorar o desempenho, seriam necessárias instruções de memory específicas por tarefa
• O Opus 4.7 tende a parar perto da etapa 3
  • Cria referências de schema com marcações de incerteza ("possibly prc in cents? Verify."), mas a cobertura de verificação é baixa, entre 7% e 33% (mediana de cerca de 17%)
• O Fable 5 tende a completar o processo
  • Na melhor execução, a cobertura de verificação chegou a 73% (22 de 30) e o aprendizado foi destilado em regras gerais úteis para tarefas futuras

Conclusão

• Em vez de fazer prompting e controle diretos do Fable 5, é mais eficaz projetar loops para que ele reaja ao feedback do ambiente (/goal, Outcomes), faça autocorreção e gerencie sozinho o contexto com memory
• Recomenda-se testar diretamente o Fable 5 em tarefas desafiadoras usando loops de autocorreção e memory