Claude Fable 5 para agentes: recusas em tool calls e custo vs GLM 5.2

No nosso eval, o Claude Fable 5 recusou 11 de 44 turnos de um agente de código durante uma tool call, inclusive em tarefas triviais como corrigir o valor padrão de uma configuração. A recusa aparece como stop_reason: "refusal" no meio da geração dos argumentos da ferramenta. Mesmo truncados, os argumentos continuam sendo JSON válido. Assim, um loop de agente que executa tool calls sem verificar o motivo da interrupção pode gravar tranquilamente um arquivo pela metade no disco. Ao usar o Fable 5 em um agente, esse comportamento precisa ser tratado antes mesmo do preço.

TL;DR

• O Claude Fable 5 retornou stop_reason: "refusal" no meio de tool calls em tarefas comuns de agentes, como corrigir um valor padrão de configuração e reservar uma sala de reunião. Os argumentos truncados de write_file continuaram válidos, então um loop que não verifica o motivo da interrupção executa a gravação de arquivos incompletos.
• O pensamento do Fable 5 é adaptativo e não pode ser desativado: tanto enabled quanto disabled são rejeitados; o controle disponível é output_config.effort.
• O custo adicional do Fable 5 depende do formato da carga: uma tarefa de código com quatro turnos custou $0.045, contra $0.003 no glm-5.2, uma diferença de 15x. Já em processamento em lote com cache aquecido, o custo foi apenas 5x maior que o sonnet-5.
• O Fable 5 exige retenção dos dados por 30 dias.

Todas as medições abaixo foram feitas em 2026-07-05 pelo gateway da Synthorai, com um pequeno harness de cenários. Testamos cinco formatos de carga para agentes: um loop de código com ferramentas, perguntas e respostas com RAG, orquestração intensiva de ferramentas, classificação em lote e uma conversa de 15 turnos. Executamos os testes com claude-fable-5, claude-opus-4-8, claude-sonnet-5 e glm-5.2, repetindo três vezes as tarefas em que a variância é relevante. As tarefas são intencionalmente triviais; a taxa de sucesso serve como verificação básica, não como benchmark de capacidade. Os custos correspondem ao usage.cost faturado pelo gateway.

Verifique stop_reason antes de executar tool calls

A documentação não alerta sobre essa falha, que pode corromper o estado. O agente lê app.py, decide gravar a correção e começa a emitir uma chamada write_file. No meio do conteúdo do arquivo, o stream para:

{
  "stop_reason": "refusal",
  "content": [{
    "type": "tool_use",
    "name": "write_file",
    "input": {
      "path": "app.py",
      "content": "DEFAULTS = {\n    \"timeout_s\": 30,\n    "
    }
  }]
}

O objeto input é um JSON completo e válido. Nada nele indica que a geração foi interrompida. Se o contrato do seu loop for “recebeu tool calls, execute”, você acabou de sobrescrever app.py com um fragmento de 38 caracteres que termina no meio de um dicionário e já não é um Python válido. O turno seguinte também é recusado, e o loop termina com o workspace corrompido.

Os dados permitem concluir três coisas:

• Acontece em tarefas comuns. As recusas ocorreram ao corrigir um KeyError na leitura de uma configuração, implementar uma função de slugify, reservar uma sala de reunião e criar um rascunho de fatura. Nenhuma dessas tarefas envolve uso dual ou conteúdo sensível.
• É reproduzível, não aleatório. Uma das tarefas de código foi recusada nas três execuções, tanto com streaming quanto sem streaming. Outras nunca foram recusadas. Dependendo da condição, entre 58-75% dos nossos episódios triviais de código passaram no Fable 5, contra 100% no claude-opus-4-8, claude-sonnet-5 e glm-5.2. Todas as falhas foram causadas por recusas, não por código incorreto.
• Depois que a recusa entra na conversa, o episódio termina. Os turnos seguintes retornaram stop_reason: "refusal" sem conteúdo. Repetir a tentativa no mesmo contexto não resolveu.

O conteúdo da tarefa não é o gatilho, e os dados deixam isso claro. A tarefa recusada em todas as execuções era uma correção de KeyError em um dicionário de configuração com nove linhas, sem credenciais ou exploits. Ao mesmo tempo, o cenário em lote classificou tickets de suporte sobre cryptomining, chaves da Stripe vazadas e páginas de phishing sem nenhuma recusa. O cenário de RAG também respondeu normalmente usando documentos cheios de segredos AES-256-GCM e procedimentos de resposta a incidentes. Todas as recusas ocorreram nos dois cenários com vários turnos e execução de ferramentas. Os três cenários single-shot não tiveram nenhuma recusa, mesmo com conteúdo mais sensível. O padrão está no formato do loop do agente, não nas palavras. Higienizar as entradas não evita o problema.

A correção exige uma linha antes da etapa que executa as ferramentas:

if response.stop_reason == "refusal":
    # do NOT execute tool calls from this turn: arguments may be truncated
    raise AgentInterrupted("model refused; restart episode or escalate")

A Anthropic documenta o funcionamento: quando a recusa ocorre antes de qualquer saída, a resposta traz um array content vazio e não há cobrança. Se acontecer durante o stream, a saída já transmitida é cobrada, e a orientação é descartar o conteúdo parcial. A resposta também inclui um objeto stop_details com uma categoria, como cyber, bio ou null, permitindo distinguir bloqueios do classificador de recusas comuns. A documentação não explica a interação com o uso de ferramentas que encontramos acima: a recusa pode acontecer durante a geração dos argumentos, e não há como diferenciar os argumentos parciais dos completos.

Também existe um caminho oficial de recuperação. Na API do Claude, o parâmetro beta fallbacks (betas: ["server-side-fallback-2026-06-01"], fallbacks: [{"model": "claude-opus-4-8"}]) repete uma requisição recusada em um modelo de fallback dentro da mesma chamada. Se a recusa ocorrer antes da saída, ela não é cobrada. Esse recurso não está disponível no Amazon Bedrock, Vertex AI ou Microsoft Foundry; nesses serviços, os SDKs oferecem um middleware de fallback no cliente. Independentemente da opção usada, a verificação acima continua sendo obrigatória: nunca execute tool calls de um turno cujo motivo de interrupção seja uma recusa.

Quanto custam cinco formatos de agentes

Custo mediano por unidade concluída, seja tarefa, consulta, item ou conversa, com os mesmos prompts e no mesmo dia:

Duas conclusões dessa tabela importam mais que qualquer célula isolada:

• O modelo mais barato muda conforme o formato da carga. O glm-5.2 vence nos loops e na conversa longa, mas o claude-sonnet-5 é o classificador em lote mais barato do grupo, abaixo do glm-5.2. Isso acontece porque seu preço inicial se beneficia de uma taxa de 97% de leituras do cache depois que o prompt-base está aquecido.
• O custo adicional do Fable 5 também depende do formato da carga: 15x o glm-5.2 no loop de código e 11x na conversa, mas apenas 5x o sonnet-5 nos itens em lote com cache aquecido, em que o cache absorve a maior parte do prompt.

O restante da análise de custos trata de como controlar esses números e de dois fatores que podem aumentá-los silenciosamente.

Como reduzir a conta de um agente

O cache é a principal alavanca. No Fable 5, seu contrato não mudou. Os dados dos agentes mostram o impacto: sem os marcadores de cache_control, a mesma tarefa de código custou 2.0x mais, e os itens em lote com cache aquecido, 6.8x mais. No opus-4-8, os mesmos números foram 3.8x e 6.9x. Em um loop, o padrão de marcadores deslizantes não é uma simples otimização; ele determina se a conta é viável.

A segunda alavanca é a ordem do prompt, e o resultado se manteve em todos os modelos testados. Colocar as regras estáveis antes do contexto específico de cada consulta, em vez de depois, deixou as consultas RAG entre 26-37% mais baratas nos quatro modelos. Na linha Claude, a ordem errada ainda gera o adicional de 1.25x da gravação em cache em todas as chamadas. O funcionamento está explicado no artigo sobre cache com LangChain; os números daqui apenas confirmam que ele continua valendo para o Fable 5.

O Fable 5 também oferece duas alavancas próprias. A primeira é que o mínimo necessário para entrar no cache caiu para 2,048 tokens, metade dos 4,096 do Opus 4.8. Parece um detalhe, mas a economia de um agente vem justamente do trecho repetido: system prompt, definições de ferramentas e prefixo deslizante da conversa. Esse trecho só entra no cache quando ultrapassa o mínimo. Um agente com muitas ferramentas cujo prefixo por turno ficava entre 2,048 e 4,096 tokens não tinha cache no Opus 4.8, mas passa a ter no Fable 5. Com isso, um prefixo cobrado integralmente vira uma leitura do cache por cerca de 10% do preço em cada turno seguinte. O inverso também vale: um prefixo inflado para passar do antigo limite de 4,096 pode estar carregando conteúdo inútil. Consulte cache_read_input_tokens em uma resposta real em vez de presumir o comportamento, pois no Fable 5 o desconto começa mais cedo.

A segunda alavanca são os task budgets (beta, header task-budgets-2026-03-13), que atacam exatamente o problema recorrente nesta comparação: um loop com Fable 5 acumula custos rapidamente, e max_tokens não resolve. Esse parâmetro é um limite rígido por resposta que o modelo não conhece. O modelo planeja como se tivesse espaço ilimitado e acaba interrompido no meio do raciocínio. Um task budget funciona de outro modo. Você define para o loop um teto de tokens, com mínimo de 20,000, que o modelo acompanha como uma contagem regressiva. Assim, ele ajusta o ritmo e conclui o trabalho sem ser truncado. A contagem inclui o que o modelo gera e os resultados de ferramentas que lê no turno, mas não todo o histórico reenviado em cada requisição. Em um modelo cujo turno do loop de código custa 15x mais que o glm-5.2, um orçamento que o próprio modelo administra é a proteção de custo mais barata que se pode adicionar.

Duas surpresas de custo que a documentação não aponta

Mesmo com essas alavancas configuradas, dois fatores menores ainda alteraram nossa conta em direções que a documentação não antecipa.

O effort “Low” não saiu mais barato. A profundidade de pensamento do Fable 5 é controlada por output_config.effort, e a expectativa é que low custe menos. Não foi o que aconteceu. Com effort: "low", nosso loop de código custou $0.0478 por tarefa, contra $0.0451 na configuração padrão, e gerou mais tokens de saída, não menos. Observamos o mesmo padrão no GLM 5.2, em que os nomes dos níveis de effort não correspondem à contagem de tokens. Nas duas famílias de modelos, meça esse controle na sua própria carga antes de presumir que “low” significa “menos”. Um dos motivos para o número ser difícil de prever é que a participação do pensamento adaptativo nos tokens de saída variou de 2% no loop de código para 30% nas respostas RAG e 52% na classificação em lote, no mesmo modelo e no mesmo dia. Defina o orçamento de tokens de saída por formato de carga, não por modelo.

Nunca reenvie reasoning_content. Nos modelos compatíveis com OpenAI, o campo de reasoning não faz parte do histórico da conversa. A API da DeepSeek exige que ele seja removido; no GLM 5.2, reenviá-lo é permitido, mas gera cobrança. Incluir esse campo novamente no histórico aumentou o custo do nosso loop com GLM em cerca de 28%, até começarmos a removê-lo. Os blocos de pensamento da própria Anthropic funcionam de outra forma: no mesmo modelo, eles precisam ser reenviados sem alterações. Porém, se um bloco de pensamento do Fable 5 for direcionado a um modelo diferente, como em um fallback para o Opus, ele é removido automaticamente do prompt e não é cobrado. Não há nada para remover manualmente.

O que mudou na interface de requisição

O Fable 5 compartilha a maior parte da interface de requisição com o Opus 4.7/4.8 e o Sonnet 5. Segundo a documentação, os seguintes recursos foram removidos:

• thinking: {type: "enabled", budget_tokens: N} retorna 400. O pensamento estendido com orçamento de tokens, usado do Claude 3.7 Sonnet até a família 4.5, foi descontinuado em toda a linha 4.7+ em favor do pensamento adaptativo.
• thinking: {type: "disabled"} retorna 400, e essa restrição é exclusiva do Fable 5. O Opus 4.7/4.8 e o Sonnet 5 ainda permitem desativar o pensamento; o Fable 5 não.
• temperature, top_p e top_k são rejeitados com qualquer valor diferente do padrão.
• Prefills de mensagem do assistant, ou seja, um turno final assistant, retornam 400.

As remoções de temperature/top_p/top_k e de prefill são as que mais costumam quebrar requisições migradas. As mudanças de pensamento e retenção foram abordadas acima e no artigo sobre retenção por 30 dias.

Conclusão

Usar o Fable 5 em um agente exige resolver primeiro um problema de engenharia, depois um problema de orçamento. Trate stop_reason: "refusal" antes de executar tool calls; caso contrário, uma gravação truncada pode corromper o estado em uma tarefa tão simples quanto corrigir uma configuração. Depois, molde o custo. O cache é a principal alavanca. O mínimo para entrar no cache agora é de 2,048 tokens, então reavalie seu prefixo. Um task budget impede que o loop acumule o maior custo por turno desta comparação. E effort: "low" não oferece o desconto sugerido pelo nome. O orçamento também precisa considerar o formato da carga: o mesmo modelo custa 15x o glm-5.2 em um loop de código e 5x o sonnet-5 em processamento em lote com cache aquecido. Nada disso determina se você deve ou não usá-lo. O ponto é que os padrões não são neutros: tanto a conta quanto os modos de falha dependem do formato do agente.

Perguntas frequentes

O Fable 5 recusa tool calls com frequência? As recusas ficaram concentradas em tarefas específicas: uma correção de configuração foi recusada em todas as execuções, enquanto outras nunca foram. As mesmas tarefas reproduziram o comportamento em chamadas com e sem streaming. Portanto, não se trata de uma falha rara que desaparece ao repetir a tentativa. As taxas serão diferentes na sua carga, mas a medida de engenharia é sempre a mesma: verifique stop_reason antes de executar tool calls.

Posso desativar o pensamento do Fable 5? Não. Tanto thinking.type.disabled quanto enabled são rejeitados. O pensamento é adaptativo por padrão, e output_config.effort é o único controle disponível. No nosso loop, o effort low não reduziu o custo.

O Fable 5 chega a ser a opção barata? Não neste conjunto. A menor diferença aparece no processamento em lote com cache aquecido, cerca de 5x o sonnet-5, porque o cache absorve a maior parte do prompt. Nos loops e na conversa longa, foi o modelo mais caro entre os testados.

Verificação: todos os valores foram medidos em 2026-07-05 usando https://synthorai.io/ (/v1/messages nativo da Anthropic para a linha Claude e /v1/chat/completions para o glm-5.2), em 505 episódios e 1,022 chamadas distribuídos por cinco formatos de cenário, com três execuções por tarefa quando a variância era relevante. Os custos são o usage.cost informado pelo gateway; mostramos as medianas. As tarefas são intencionalmente simples, portanto as taxas de sucesso servem como verificação básica, não como benchmark de capacidade; não publicamos afirmações de capacidade que não medimos. O comportamento de recusa foi reproduzido com e sem streaming. Seus números variarão conforme os prompts, a região e a carga.

← Voltar ao blog