Fable 5.1 vs GPT-6 Astra: os níveis de esforço de raciocínio fazem a mesma coisa?

Fala aí, beleza? Cinco níveis de um lado, cinco níveis do outro, com os mesmos rótulos: low, medium, high, xhigh e max

Parece que é só copiar o valor de uma config pra outra e seguir a vida… só que não

Se você está portando uma configuração de Fable 5.1 pro GPT-6 Astra (ou fazendo o caminho inverso) e esperava paridade, esse post é pra você

O nome do parâmetro muda, o que o nível governa muda, o jeito de trocar no meio da conversa muda, e o cache de prompt reage de formas diferentes em cada plataforma

Bora destrinchar isso? 🙂

Fable 5.1 vs GPT-6 Astra: comparativo dos controles de esforço

Olhando assim, a linha dos níveis é idêntica e todo o resto é diferente

É exatamente essa a armadilha

O que cada nível controla na prática em cada modelo:

Vamos separar por casa, porque a definição de "esforço" não é a mesma dos dois lados

No Fable 5.1: profundidade por passo, e não orçamento

A documentação de effort da Anthropic é bem clara no ponto que mais confunde: effort controla o quanto o Claude raciocina por passo

E é orientação suave, não limite estrito

Ou seja, você não está cortando um orçamento rígido de tokens, está dando um sinal de comportamento

Outra coisa que pega gente desprevenida: o effort vale pra todo token de saída, com ou sem thinking ligado

Então mesmo com thinking desativado o nível continua fazendo diferença, o que muda a leitura de quem vinha tratando raciocínio e resposta como coisas separadas (e se esse ponto te interessa, vale ver como funcionam os thinking blocks no Fable 5.1)

E tem o efeito colateral que quase ninguém prevê ao baixar o nível: effort mais baixo gera chamadas de ferramenta menos numerosas e mais curtas, além de explicações mais enxutas em volta delas

Ou seja, você não mexeu só no "tamanho do pensamento"

Você mexeu em quantas vezes o modelo resolve ir buscar informação antes de responder

Em fluxo agêntico isso é ENORME

No Astra: velocidade e tokens de raciocínio, por tipo de tarefa

Do lado da OpenAI, a régua é outra: o reasoning effort governa quanto raciocínio o modelo gera antes de responder, e nível menor é mais rápido e usa menos tokens de raciocínio

A orientação oficial vem por tipo de tarefa, o que ajuda bastante na hora de escolher:

• low: extração, roteamento, classificação e reescrita simples
• medium ou high: diagnosticar problema, comparar opções, planejar ou raciocinar sobre código

E tem o detalhe que quebra migração de quem vinha de configuração antiga: o nível none não é suportado no Astra

Se o seu código manda none hoje, ele não tem pra onde ir nesse formato

Outro ponto de atenção pra quem escreve integração: o parâmetro tem nome diferente conforme a API usada, reasoning.effort na Responses API e reasoning_effort na Chat Completions

Parece bobo, mas é o tipo de coisa que faz o valor ser silenciosamente ignorado quando você copia trecho de código de um lugar pro outro

Trocar o nível no meio da conversa: cache de prompt e o custo de errar

Aqui é onde a diferença dói de verdade no bolso

Na Anthropic, o valor de output_config.effort é renderizado no prompt

"E daí?" Daí que mudar esse valor no nível superior da requisição quebra o prefixo em cache

Você troca de high pra max achando que só aumentou a profundidade, e na real reescreveu o começo do prompt e perdeu o cache inteiro

A alternativa documentada é trocar por mensagem: uma mensagem role: "system" com conteúdo vazio, carregando o novo nível em output_config.effort

{
  "role": "system",
  "content": "",
  "output_config": { "effort": "max" }
}

Tome cuidado com três detalhes desse recurso:

1. ele está em beta e exige o header mid-conversation-output-config-2026-07-01
2. vale pra Fable 5.1, Mythos 5.1 e Opus 5
3. o novo nível passa a valer no turno de usuário seguinte, não no turno atual

Esse terceiro item derruba muita expectativa: se você troca e espera o efeito imediato na mesma resposta, vai achar que o ajuste "não funcionou"

Ele funcionou, só chegou no turno seguinte (o assunto rende, e dá pra ir mais fundo em trocar o effort por mensagem)

No Astra o desenho é outro: a troca acontece por um item configuration_update que entra na conversa, e não como campo da requisição

Como ele não mexe no começo do prompt, o prefixo em cache continua valendo byte a byte, e o novo nível vale até outro configuration_update sobrescrever

Bonito no papel, né? Só que especificação e implementação são coisas diferentes

Existe uma issue aberta no repositório do Codex relatando justamente que a troca de reasoning effort não usa configuration_update, o que anula a preservação de cache

Moral: se você depende de cache, não confie no comportamento por dedução

Confira no que está saindo do seu cliente

Limites e tetos: o que o esforço não controla

Tem três controles que vivem sendo confundidos com effort, e vale separar

max_tokens é o limite duro. Na API da Anthropic ele soma thinking mais resposta, e a documentação orienta um teto alto quando o esforço é elevado: em xhigh ou max, defina max_tokens de pelo menos 64k

Faz sentido, né? Se você pede profundidade e mantém teto curto, o corte vem no meio

Task budgets são outra camada. Enquanto o effort controla a profundidade por passo, os task budgets limitam o trabalho total ao longo do loop agêntico

São perguntas diferentes: "quanto o modelo pensa em cada passo" não é "quanto ele pode trabalhar no total"

Quem tenta segurar custo de agente só baixando o effort está mexendo na alavanca errada

E tem a restrição prática do Astra: ele funciona em Chat Completions, mas chamada de ferramentas exige a Responses API

Então se o seu plano era portar a config mantendo a Chat Completions e o fluxo com ferramentas, esse pedaço não vai junto

Veredito: dá para portar a configuração de um para o outro?

Veredito honesto: mapear nível por nível é o erro

Os rótulos coincidem, o comportamento não, e o que cada plataforma promete com o nível é diferente na origem

O caminho que sobra é o chato e o certo: escolher pelo tipo de tarefa e validar comparando resultado

A própria orientação de migração da OpenAI vai nessa linha: quem usava none ou minimal começa em low e compara resultados, e quem já usava outro nível preserva o esforço efetivo atual, subindo só com ganho comprovado

Do lado do Fable 5.1 o ponto de partida já é alto: o padrão da API é high

Então "subir tudo pra xhigh porque no outro modelo estava alto" costuma ser decisão sem evidência, e ainda te obriga ao teto de pelo menos 64k de max_tokens

Se você trabalha no Claude Code, o ajuste sai por um comando de barra próprio, /effort seguido do nível, conforme o changelog do Claude Code

E fica um contexto pra não confundir velocidade com esforço configurado: a OpenAI divulgou que, na simulação de latência do OSWorld 2.0 em uso de computador, o Astra fez 72,6% com cerca de 40 minutos por tarefa, contra 65,7% com cerca de 75 minutos do GPT-5.6 Sol, cerca de 47% menos tempo por tarefa

Menos tempo por tarefa não quer dizer "menos esforço configurado"

São eixos separados, e tratar um como proxy do outro é justamente o vício que faz a config portada dar resultado estranho

Vídeo: comparativo de modelos na prática

Pra começar do zero na comparação entre modelos, esse vídeo do canal coloca Kimi K3, GPT-5.6 Sol e Fable 5 lado a lado em teste prático

Conclusão

Nome igual não é comportamento igual

Os dois têm cinco níveis, os dois chamam de esforço, e as semelhanças param aí: no Fable 5.1 o effort é orientação suave por passo, vale com thinking desligado e encurta chamadas de ferramenta; no Astra ele é quanto raciocínio sai antes da resposta, sem nível none, com nome de parâmetro variando por API

O próximo passo é bem direto:

1. defina o nível pelo tipo de tarefa em cada plataforma, não por espelhamento
2. valide com comparação de resultados antes de subir
3. confira se a troca no meio da conversa está usando o mecanismo que preserva o cache

Faça o teste no seu fluxo real e compare, é o único jeito de saber onde o esforço extra vira ganho e onde vira só conta maior

Até o próximo post! 😀