Fable 5 vs. GPT-5.6 Sol: o `/goal` ajuda em problemas NP-difíceis?

• Ao resolver por 30 minutos um problema inédito de otimização de rede de fibra óptica, o Fable 5 obteve a melhor pontuação e o desempenho mais estável, mas o /goal não produziu melhorias consistentes
• O /goal não é simplesmente um recurso que faz o trabalho durar mais; ele muda o loop de controle e os caminhos de busca, podendo perpetuar tanto boas estratégias quanto estratégias equivocadas
• O /goal venceu 4 das 6 comparações entre Fable 5 e GPT-5.6 Sol, mas raras grandes quedas de desempenho pioraram as pontuações médias em 759 e 868 pontos, respectivamente
• O modo normal do Fable 5 foi o mais estável, com média de 32.386 pontos e intervalo de 319 pontos, enquanto o modo /goal alcançou o melhor resultado geral: 31.934 pontos
• Em otimizações difíceis, mais do que repetir ou não, importa a qualidade da estratégia que está sendo repetida; a taxa de vitórias individuais e o desempenho médio podem levar a conclusões opostas

---

Problema de otimização da rede de fibra óptica KIRO

• KIRO é um problema de pesquisa operacional submetido a um hackathon para estudantes de engenharia em 2018, no qual é preciso minimizar o comprimento total dos cabos usando matrizes de distância direcionais de Grenoble, Nice e Paris
• A rede é composta por loops redundantes que partem de hubs de distribuição e por ramificações curtas que saem de torres sobre esses loops
  • Todas as torres devem aparecer exatamente uma vez
  • Várias restrições estruturais precisam ser satisfeitas
  • O custo de um trecho de cabo pode mudar se sua direção for invertida
  • Quanto menor a pontuação, melhor a solução
• A linha de base humana é um solver em C++ escrito durante uma semana no passado para resolver esse problema

• Escala do espaço de busca

  • Como o número e o tamanho dos loops, além dos pontos de referência e da ordem das ramificações, variam, é difícil calcular todo o espaço de busca com uma única fórmula fechada
  • Mesmo considerando apenas a atribuição dos 532 terminais de Paris a 11 hubs de distribuição, sem ordem nem ramificações, há 11^532 possibilidades
  • Mesmo calculando apenas soluções válidas restritas com 19 loops de 28 terminais e sem ramificações, o espaço de busca chega a cerca de 10^1223
  • Como 19 × 28 = 532, todos os terminais são incluídos
  • Cada loop fica abaixo do limite de 30 terminais
  • A fórmula é (532! / 19!) × 11^19 ≈ 10^1223

Modelos e condições de execução

• Foram comparados modelos da família Claude — Fable 5, Opus 4.8 e Sonnet 5 — e da família GPT — GPT-5.6 Sol, Terra e Luna
• Cada modelo foi executado no modo normal e no modo nativo /goal
  • Tempo de otimização: 30 minutos
  • Limite de tempo do agente externo: 1.900 segundos
  • Configurações de raciocínio no máximo disponível para cada modelo
  • Ambiente de execução: Harbor 0.1.43, Docker e autenticação por assinatura
• Primeiro, foi feita uma execução correspondente de 30 minutos, sem dicas, em modo normal e em /goal para todos os modelos
• Para os principais alvos de comparação, Fable 5 e GPT-5.6 Sol, as execuções foram repetidas até obter 3 pares de execuções correspondentes para cada um
• Todo o código, prompts, tabelas de resultados, critérios de exclusão e trajetórias de execução estão no CLIArena; este é um experimento de acompanhamento do post de benchmark anterior

Resultados do Fable 5 e do GPT-5.6 Sol

• Quando o valor obtido ao subtrair a pontuação do modo normal da pontuação do /goal é negativo, o /goal teve resultado melhor
• Os três resultados do Fable 5 foram:
  • 1ª execução: 32.197 pontos no normal, 31.934 no /goal, melhora de 263 pontos
  • 2ª execução: 32.516 pontos no normal, 32.324 no /goal, melhora de 192 pontos
  • 3ª execução: 32.446 pontos no normal, 35.178 no /goal, piora de 2.732 pontos
• Os três resultados do GPT-5.6 Sol foram:
  • 1ª execução: 33.581 pontos no normal, 39.371 no /goal, piora de 5.790 pontos
  • 2ª execução: 35.539 pontos no normal, 32.703 no /goal, melhora de 2.836 pontos
  • 3ª execução: 33.663 pontos no normal, 33.313 no /goal, melhora de 350 pontos

• Por que a taxa de vitória e a média divergem

  • O /goal venceu 4 de 6 vezes, mas, em ambos os modelos, obteve pequenas melhorias com frequência ao custo de raras grandes quedas de desempenho
  • O Fable 5 teve média de 32.386 pontos no modo normal e 33.145 no /goal, uma piora de 759 pontos
  • Pela mediana, houve melhora de 192 pontos
  • O GPT-5.6 Sol teve média de 34.261 pontos no modo normal e 35.129 no /goal, uma piora de 868 pontos
  • Pela mediana, houve melhora de 350 pontos
  • A média do Fable 5 no modo normal foi 1.875 pontos melhor que a do Sol, e a média em /goal também ficou 1.984 pontos à frente
  • Também houve diferença na estabilidade
    • Os três resultados do Fable 5 em modo normal ficaram dentro de um intervalo de 319 pontos
    • O modo normal do Sol variou em um intervalo de 1.958 pontos
  • O Fable 5 com /goal registrou a melhor pontuação geral: 31.934 pontos
  • A configuração mais segura foi o Fable 5 em modo normal

Mesmo /goal, implementações diferentes

• Modelo de avaliação separado no Claude Code

  • O /goal do Claude Code funciona como um hook Stop no escopo da sessão
  • Sempre que o modelo principal encerra um turno, o modelo avaliador padrão, Haiku, lê a condição de objetivo e a conversa e retorna yes ou no com uma justificativa
  • Se for no, um novo turno é iniciado; se for yes, o objetivo é liberado
  • O modelo avaliador não pode usar ferramentas nem inspecionar arquivos, e julga apenas as evidências presentes no histórico da conversa
  • Ele consegue detectar casos em que o trabalho termina cedo demais, mas não consegue saber se vale a pena iterar o solver mais 10 milhões de vezes
  • Como o Claude Code não é open source, as informações de implementação dependem da documentação de goal da Anthropic

• Estado persistente e ferramentas de ciclo de vida no Codex

  • O Codex CLI 0.144.4 usado no benchmark trata o objetivo como estado persistente associado à thread
  • A TUI armazena o objetivo da thread ativa, e o SQLite registra o estado e o uso do orçamento
    • Implementação da TUI
    • Esquema SQLite
  • O modelo de trabalho recebe as ferramentas create_goal, get_goal, update_goal
  • Quando a thread fica ociosa com um objetivo ativo, é injetado um turno de continuação que inclui o objetivo e uma auditoria de conclusão
    • Implementação em tempo de execução
    • Prompt de continuação
  • No Claude, o julgamento de conclusão fica com um modelo avaliador independente, mas esse modelo só pode ver o histórico da conversa
  • No Codex, o modelo de trabalho usa arquivos e ferramentas, declara por conta própria a conclusão e, se o objetivo persistente estiver ativo, retoma o trabalho

Como o /goal amplifica estratégias

• Em tarefas comuns de programação, é fácil verificar o progresso em turnos adicionais, como corrigir testes ou concluir migrações
• Em otimização, depois que o agente escolhe um solver, tempo extra pode amplificar tanto decisões boas quanto ruins
• Os casos em que o /goal ajudou foram:
  • Continuar executando o portfólio baseado em compilação rápida do Fable 5
  • Manter a estratégia bem-sucedida de reparticionamento em cadeia do Sol
• Por outro lado, também houve casos em que ele piorou o desempenho
  • O Fable 5 construiu um solver lento e continuou executando-o
  • O Sol insistiu em uma busca exaustiva por todos os pontos de referência
• A mediana melhorou levemente, mas a cauda dos maus resultados piorou muito mais, reduzindo o desempenho médio

Limitações da interpretação dos resultados

• O experimento avalia um único problema NP-difícil inédito, portanto não deve ser visto como um leaderboard geral de programação
• Apenas para Fable 5 e Sol foram obtidos 3 pares de execuções limpas e correspondentes para cada um
• As comparações com outros modelos misturam prompts, versões de wrappers e limites de tempo diferentes
• Como as execuções foram sequenciais por meio de serviços de assinatura, o estado do serviço pode ter mudado durante o experimento
• Embora os metadados da tarefa registrassem 1 CPU, o contêiner expunha 8 CPUs, o que favoreceu o portfólio paralelo do Fable 5
• Como o wrapper exigia checkpoints intermediários e validação final, todas as saídas do Fable 5 e do Sol incluídas nas pontuações eram válidas
• O que foi medido não foi apenas o modelo isolado, mas o sistema completo, incluindo modelo, CLI, prompt, serviço de assinatura e harness

Materiais de reprodução e julgamento

• O CLIArena publica as tarefas de benchmark, wrappers, scripts de análise, geradores de gráficos e memorandos completos de evidências
• Os diretórios brutos das tarefas foram excluídos do Git por serem grandes, mas os memorandos registram todas as pontuações publicáveis, resultados por cidade, tempos decorridos, estratégias, itens excluídos e IDs de execução
• Os principais comandos de execução são:

RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...

• O /goal não aumentou nem reduziu o desempenho de forma uniforme; ele pode piorar o desempenho médio observado mesmo vencendo a maioria das execuções individuais
• Em otimizações difíceis, mais do que a qualidade do próprio loop de controle, importa a qualidade da estratégia que esse loop executa repetidamente

[GN⁺]

Opiniões no Hacker News

• O gráfico acima é um tanto confuso. Está escrito “quanto menor, melhor”, mas o eixo y está invertido, então visualmente a parte de cima é melhor, enquanto numericamente quanto menor, melhor

  • Não parece que o eixo esteja invertido. 32.000 está embaixo e 40.000 está em cima, então talvez tenha sido corrigido depois do comentário

• O Claude tende a esquecer instruções em trabalhos longos que se estendem por semanas, por mais que você enfatize que são importantes. Não usei /goal, mas provavelmente ele faz com que as instruções centrais sejam realmente lembradas. Aqui parece tratar de sessões curtas, em que esse problema é menor

  • Coloquei o uso de contexto na barra de status do Claude Code e, a partir de 50~60%, ele parece de fato “se cansar”. Pedi para ajustar o ambiente de testes e adicionar testes; ele adiou dizendo que era “um trabalho de infraestrutura considerável”, mas, depois de /compact, pedi de novo e ele fez sem reclamar
    Ainda assim, o /compact costuma dar erro, então não recomendo no meio do trabalho. Ele é útil ao passar para uma tarefa relacionada, mas nova; porém, em correções que exigem o contexto do processo de geração, como um impasse no código recém-escrito, não é bom porque descarta o raciocínio
  • É uma das vantagens do pi. Criei um comando /protect que exclui mensagens da compactação, e as skills também são protegidas automaticamente. Em trabalhos longos, uso algo como /protect your goal is...
  • Depois de usar Claude e GPT por bastante tempo em vários ambientes de execução, concordo que a causa é a compactação de contexto. A compactação do Codex mantém a conversa contínua de forma quase mágica e natural, mas no Claude foi preciso gerenciar cuidadosamente o momento da compactação
  • A qualidade começa a cair muito antes de chegar à compactação. O aviso de compactação é como uma placa de “próximo posto a 100 milhas”, mas você já está no meio do deserto
    Não é preciso um procedimento excessivamente complexo, mas a melhor ordem é: decompor a tarefa → planejar em um novo contexto → implementar em um novo contexto → fazer /code-review em um novo contexto → corrigir em um novo contexto. No Fable 5, quando o contexto passa de 50%, a qualidade cai bastante, a ponto de a mesma implementação aparecer quatro vezes no codebase. Pedir para ele revisar o próprio trabalho na mesma sessão é parecido com pedir a um aluno para corrigir a própria prova
  • Em um contexto de cerca de 700 mil tokens, até o Fable teve uma queda grande de julgamento. A decisão da OpenAI de limitar o contexto do Codex a 400 mil pode estar certa; parece ser um ponto adequado em que ainda se pode confiar na maior parte do contexto

• Se a comparação for de estratégia de busca, é bem possível que o modo Ultra seja superior, então fico curioso por uma avaliação posterior
  O Ultra expande agentes de pesquisa em paralelo, realiza revisões adversariais em pontos de verificação definidos e usa várias técnicas para não ficar preso em ótimos locais. O /goal é mais adequado para investigação em um único caminho ou para tarefas pequenas de distribuição e coleta

  • O modo Ultra deveria ter uma documentação mais clara ou trazer avisos. Muitos desenvolvedores, eu incluído, entenderam como um recurso universal em que o modelo trabalha mais duro e entrega resultados melhores, mas em muitas tarefas ele pode ter desempenho pior, e certamente custa mais

• A Anthropic está ficando muito atrás da OpenAI em codificação. Até março passado, eu gerenciava um repositório de 400 mil linhas no total com Claude Code no plano básico, mas era muito lento e não conseguia corrigir bem os problemas, mesmo com testes, observabilidade, documentação e arquitetura em camadas
  Somos uma equipe de 3 pessoas que entrega para governos locais e, depois de migrar para o Codex, tudo ficou muito mais fácil e a ansiedade com uso também desapareceu. Cada membro da equipe gerencia tudo com duas contas Codex Plus. A Anthropic deveria criar modelos eficientes em vez de espalhar medo, e nem todo mundo precisa do Fable

  • Para mim, o Opus 4.8 foi excelente, e o Codex foi apenas mediano. Deve depender do usuário e da tarefa
  • Varia muito conforme o domínio do problema e a linguagem. O GPT foi bem ruim escrevendo Elixir e em tarefas abertas; atualmente, o Opus é mais forte em Elixir, e o Fable entende o próprio domínio do problema muito melhor que os dois
    Durante as 6 semanas em que migrei para o GPT, ele dava convicções erradas sem parar, então acabei parando completamente, e o trabalho desse período foi basicamente desperdiçado. Agora uso uma combinação de Opus/Fable e DeepSeek Pro. O DeepSeek é imbatível em custo-benefício e velocidade, e é suficiente para 90% das tarefas de implementação, mas desmorona quando tenta usar recursos de runtime em tempo de compilação no Elixir. O Fable resolveu rapidamente o problema inicial
    Cada modelo tem pontos fortes próprios que são difíceis de descobrir, então não acho que passarei a usar apenas um no futuro próximo. Quando preciso de qualidade, estou disposto a abrir mão da eficiência

• O /goal substituiu o modo de planejamento no meu trabalho, e uso o seguinte fluxo em 95% das tarefas com IA
  Primeiro peço que ele leia uma funcionalidade específica e confirme que a entendeu completamente; se faltarem detalhes no resumo, repito. Depois pergunto a hora atual e uso /goal para fazê-lo escrever, durante um período definido, um documento de design técnico sem ambiguidades, incorporando explicitamente carry_forward_requirements.md e testing_best_practices.md. Incluo referências específicas a código e documentação e as mudanças necessárias, para que até um implementador sem contexto consiga executar, e faço com que ele use todo o tempo revisando, sem terminar cedo
  Mesmo forçar o GPT a passar só 10 minutos escrevendo um documento de design já produz resultados muito mais sólidos que o modo de planejamento, economizando o tempo que eu gastaria revisando o rascunho

  • Encerrar com base no tempo parece semelhante a definir a condição de término de uma função recursiva pelo tempo decorrido, e não pelo resultado real da execução
    Eu coloco no /goal um objetivo explícito que o agente precisa alcançar. É melhor apresentar as condições que o design e a arquitetura devem satisfazer, comparar continuamente o resultado com elas e encerrar quando todas forem atingidas. Seja em 10 minutos ou 10 horas, concluir um resultado específico é o ponto central do /goal
  • Para que um agente alcance objetivos de forma confiável, a etapa de geração de hipóteses parece ser a mais importante. Começar desde o início no espaço de busca correto é o melhor preditor de sucesso; por mais forte que o modelo seja, fazê-lo atravessar todas as hipóteses do zero em um único loop gigantesco provavelmente é um beco sem saída em tarefas práticas
    Em domínios complexos, delegar investigação profunda a chamadas de ferramentas separadas foi a melhor forma de dar base ao agente. Quando a investigação fica a cargo do loop principal do agente, a qualidade piora porque o RLHF tende a preservar contexto e responder rápido. Quando isso é oferecido como ferramenta, ele pode investigar várias vezes sem perceber que está gastando bilhões de tokens e, mesmo desperdiçando muitos tokens em geração e validação independentes de hipóteses, consegue ampliar o espaço de busca em 10 a 100 vezes antes de alterar o ambiente. Em muitos casos, a prioridade precisão > tempo > custo faz sentido
  • É estranho considerar que um LLM “entendeu completamente” algo. Parece parecido com técnicas de prompt como “até ter 95% de confiança”, e fico curioso sobre o impacto disso no trabalho real. Também me pergunto o que muda ao escrever “até entender com certeza”

• Fico curioso sobre o que é /goal

  • Tanto o Codex quanto o Claude Code oferecem isso, mas o funcionamento é um pouco diferente
    No Claude Code, o Haiku lê o histórico da conversa e decide se o objetivo foi concluído; se não foi, reinjeta as tarefas restantes no modelo principal. No Codex, uma ferramenta que o modelo principal pode chamar funciona junto com o ambiente de execução ao redor e, se não houver indicação de conclusão, ele recebe outro prompt
    É um recurso para resolver situações em que o modelo termina só parte da tarefa e para por problemas de atenção. Em vez de o usuário ter que insistir manualmente para continuar, ele envia instruções adicionais automaticamente para induzir a conclusão da tarefa
  • No Claude, se você usa /goal desde o início, ele não para até alcançar o objetivo ou esgotar as possibilidades do prompt. Dá a sensação de “esta é a missão, execute”, e eu uso algumas vezes por semana
  • É um recurso em que o LLM é executado repetidamente até satisfazer as condições do objetivo
  • Mais precisamente, ele repete até julgar por conta própria que concluiu o objetivo
  • A estrutura é a de um agente que executa o LLM repetidamente e decide se deve parar. O /goal é mais próximo de um mecanismo que coloca mais um agente pai por cima disso e instrui repetidamente “ainda não terminou, continue” até o agente filho decidir que acabou

• Desde o lançamento, usei bastante o GPT 5.6 Sol Xhigh e o Fable 5. A inteligência parece semelhante à do 5.5, mas a persistência foi elevada ao extremo, o que parece melhorar a taxa de conclusão de tarefas e a competitividade em benchmarks. Por outro lado, aumenta a chance de ele recorrer até a métodos anormais ou perigosos, então é preciso monitorar continuamente
  Recentemente ele tentou ler via CLI variáveis de ambiente de produção sem relação com a tarefa e, ao falhar em acessar chaves SSH, pediu permissão para controlar o computador. Depois de interromper e perguntar o motivo, respondeu que tentaria procurar diretamente a chave no 1Password; ao ser questionado de novo, admitiu que as variáveis de ambiente de produção não eram necessárias. Desde então desliguei o modo “approve for me” e o uso apenas para mudanças simples e correções de bugs
  O Fable não só é mais inteligente, como também tem mais insight, entende melhor a intenção e age como um gerente de produto especialista no domínio, com base em conhecimento do mundo real. Ele também faz sugestões inesperadas, mas com o GPT 5.6 preciso dar instruções muito mais literais

  • O Fable parece ser um modelo maior, com custo de execução mais alto, e não parece superior em engenharia de software geral, mas em tarefas que exigem inteligência pura o tamanho pode ser uma vantagem
    No DeepSWE 1.1, o 5.6-Sol xhigh pontua um pouco acima do Fable 5, usando metade dos tokens e custando cerca de um terço. Já no índice de inteligência da Artificial Analysis, o Fable 5 fica ligeiramente à frente, mas custa três vezes mais
    Ao programar, envio a mesma tarefa para os dois modelos e recebo várias respostas; como o resultado é subjetivo, é difícil prever qual vai vencer. A tarefa do texto original tem a vantagem de ser quantificável, mas muitas tarefas de software são difíceis de avaliar assim

• Como o GPT venceu recentemente os melhores participantes humanos no concurso heurístico da AtCoder, ele deveria ser mais forte nesse tipo de problema de otimização. A Anthropic parece se concentrar relativamente menos nesse tipo

• Além da pontuação final, também gostaria de ver a melhor pontuação ao longo do tempo. Isso seria mais útil para julgar o efeito do /goal

• Como houve apenas uma avaliação por modelo e o espaço do problema é amplo, exigindo várias tentativas para ir bem, a maior parte dos resultados parece ruído

  • Na prática, rodei mais vezes variando o prompt e o tempo de execução, mas o efeito do /goal foi pequeno ou não significativo em todas as vezes