Escolher um modelo para trabalhar com ferramentas não é o mesmo que escolher o melhor modelo para conversar, programar ou responder perguntas. Em um fluxo real, ele precisa acertar três coisas diferentes: quando usar uma ferramenta e qual usar, quais argumentos enviar e o que fazer quando a execução não sai como esperado.
Em agosto de 2026, a evidência pública mais útil aponta para uma resposta clara, mas não absoluta: Claude Opus 5 é hoje o ponto de partida mais forte para fluxos empresariais com ferramentas. No AutomationBench oficial, executado sobre tarefas privadas e avaliadas pelo estado final do ambiente, ele lidera com margem relevante. GPT-5.6 Sol e Gemini 3.6 Flash continuam sendo alternativas importantes, especialmente quando arquitetura, custo ou características específicas da plataforma pesam mais que a taxa bruta de conclusão.
O ponto que muda a decisão é outro: nenhum desses números autoriza colocar um agente em produção confiando apenas no modelo. Pesquisas recentes sobre ferramentas defeituosas mostram que diagnosticar corretamente a falha ainda é um gargalo separado da capacidade de fazer a chamada inicial.
Quem está completando melhor o fluxo inteiro?
O AutomationBench é particularmente interessante porque não dá nota à resposta textual do modelo. Cada tarefa inicializa um pequeno ambiente empresarial com CRM, e-mail, calendário, planilhas e outros sistemas simulados. Depois que o agente termina, asserções determinísticas verificam se o estado final ficou correto. O placar oficial usa mais de 600 tarefas privadas e não depende de outro LLM como juiz.
Na versão 1.0.5 do leaderboard consultada em 7 de agosto de 2026:
| Modelo e configuração | Score oficial | Custo medido por tarefa |
|---|---|---|
| Claude Opus 5 — Max | 26,2% | US$ 1,27 |
| Claude Opus 5 — Medium | 23,6% | US$ 0,89 |
| Gemini 3.6 Flash — High | 19,8% | US$ 0,58 |
| GPT-5.6 Sol — Max | 18,1% | US$ 1,00 |
| Claude Fable 5 — Max | 17,4% | US$ 2,03 |
Os scores parecem baixos porque o critério é severo: cumprir cinco de seis requisitos não basta para considerar a tarefa concluída. O benchmark informa ainda que a variação típica entre execuções fica dentro de aproximadamente um ponto percentual.
Há dois achados práticos aqui. O primeiro é a vantagem do Opus 5 neste tipo de trabalho. O segundo é que a configuração do mesmo modelo pode importar quase tanto quanto trocar de fornecedor: Opus 5 em Medium continua acima dos melhores resultados mostrados para Gemini 3.6 Flash e GPT-5.6 Sol nesse leaderboard, enquanto reduz o custo medido da tarefa em relação ao próprio Max.
Isso não significa que o AutomationBench meça isoladamente “qual modelo gera o JSON mais correto”. Nesse teste, o agente precisa pesquisar schemas e executar endpoints, encontrar registros, distinguir dados desatualizados, obedecer políticas e alterar o estado certo. Portanto, a nota combina seleção de ferramentas, planejamento, leitura de resultados e persistência até a conclusão. É justamente por isso que ela é útil para quem está escolhendo um modelo para fluxos, e não apenas para uma demonstração de function calling.
E quem escolhe a função e os argumentos corretamente?
Para observar a chamada em si, o Berkeley Function Calling Leaderboard continua sendo uma referência melhor. O BFCL V4 inclui chamadas single-turn e multi-turn, funções e parâmetros ausentes, casos paralelos, medição de alucinação e tarefas agentic. Sua avaliação usa mecanismos como AST e transições de estado para verificar a chamada de forma mais determinística.
Há, porém, um problema temporal: o leaderboard consultado foi atualizado pela última vez em 12 de abril de 2026 e ainda traz uma geração anterior de vários modelos. Claude Opus 4.5 aparecia em primeiro lugar geral, com 77,47%, seguido por Claude Sonnet 4.5 com 73,24%. Os atuais Opus 5, GPT-5.6 Sol e Gemini 3.6 Flash não estão todos representados nesse recorte.
Por isso, o BFCL ajuda mais a entender quais famílias já demonstravam bons fundamentos de function calling do que a decretar o vencedor atual. Para uma compra ou migração feita agora, o resultado end-to-end mais recente deve pesar mais.
Argumento válido não significa argumento certo
As APIs atuais oferecem mecanismos que reduzem uma classe importante de falhas: argumentos que não obedecem ao schema.
Na OpenAI, Structured Outputs em chamadas de função com strict: true faz os argumentos aderirem ao JSON Schema definido para aquela função. Os modelos GPT-5.6 também suportam function calling e structured outputs; a plataforma acrescenta tool search e Programmatic Tool Calling para determinados fluxos com muitas operações.
A Anthropic também oferece ferramentas estritas com strict: true, além de controles de tool_choice para deixar a decisão automática, exigir alguma ferramenta ou forçar uma ferramenta específica. Resultados de ferramentas podem ser devolvidos ao Claude com is_error: true, permitindo que a falha faça parte explicitamente do próximo turno do agente.
No Gemini, a API disponibiliza modos auto, any e none, além do modo validated, ainda marcado como preview, para aderência ao schema. Gemini 3.6 Flash suporta function calling, structured outputs e ferramentas como execução de código, pesquisa de arquivos e computer use em preview.
Essas proteções são valiosas, mas têm um limite simples: um campo customer_id pode ser perfeitamente válido como string e ainda apontar para o cliente errado. Validação estrutural reduz chamadas malformadas; não garante seleção semanticamente correta da ferramenta, da entidade ou da ação.
O teste mais difícil começa quando a ferramenta falha
O ToolBench-X, publicado em junho de 2026, foi construído justamente para preencher uma lacuna dos benchmarks tradicionais. Em vez de presumir ferramentas estáveis, ele introduz cinco classes de problemas recuperáveis: mudança na especificação, erro de invocação, falha de execução, mudança no formato ou significado da saída e conflito entre fontes. As tarefas permanecem solucionáveis por caminhos como nova tentativa, fallback, verificação ou cruzamento de evidências.
Os modelos avaliados no artigo já não são todos os flagships atuais, então seria incorreto usar seus números para comparar diretamente Opus 5 com GPT-5.6 ou Gemini 3.6. O resultado mais importante é estrutural: todos os modelos testados ficaram abaixo de 60% de acerto quando as ferramentas receberam essas falhas recuperáveis. GPT-5.4 marcou 45,3%, Claude Sonnet 4.6 ficou em 41,0% e o melhor resultado do conjunto, Doubao-Seed-2.0-Lite, atingiu 51,3%.
O estudo encontrou ainda algo mais útil para quem está projetando o agente. Dar apenas mais tempo de inferência ajudou pouco em comparação com informar ao modelo que tipo de anomalia estava enfrentando. Em um subconjunto de 200 tarefas, dicas direcionadas de diagnóstico elevaram o resultado de base em 25,5 a 35,5 pontos percentuais, recuperando grande parte dos casos perdidos. Os autores identificam diagnóstico da falha, e não simplesmente falta de computação, como gargalo central.
Isso muda a pergunta de engenharia. Não basta perguntar “qual modelo tenta de novo?”. Um agente robusto precisa reconhecer se deve repetir a mesma chamada, trocar de ferramenta, corrigir argumentos, desconfiar da resposta ou parar com uma falha explícita.
Qual modelo eu escolheria para cada cenário?
Se a prioridade é maximizar a chance de concluir corretamente um fluxo empresarial complexo hoje, Claude Opus 5 é a escolha mais sustentada pelos dados públicos disponíveis. Ele lidera o conjunto privado do AutomationBench e a própria Anthropic o posiciona para trabalho empresarial e tarefas agentic complexas.
Se o sistema terá um catálogo grande de ferramentas ou etapas previsíveis que podem ser filtradas, agregadas e encadeadas programaticamente, GPT-5.6 Sol merece um teste lado a lado mesmo sem liderar o AutomationBench. A OpenAI oferece tool search e Programmatic Tool Calling no GPT-5.6, permitindo que determinadas sequências de chamadas sejam processadas em um runtime programático em vez de exigir um novo julgamento do modelo entre todas as operações. A própria documentação recomenda manter chamadas diretas quando cada resultado pode alterar semanticamente a próxima decisão.
Para um fluxo mais sensível a custo e latência, Gemini 3.6 Flash é o challenger mais interessante entre os três nessa medição: marcou 19,8% no conjunto privado do AutomationBench a US$ 0,58 por tarefa, contra 18,1% e US$ 1,00 do GPT-5.6 Sol Max naquele mesmo teste. Seu preço padrão de API é de US$ 1,50 por milhão de tokens de entrada e US$ 7,50 por milhão de saída, incluindo os tokens de pensamento na cobrança de saída.
Claude Opus 5 também merece ser testado abaixo do esforço máximo. No próprio AutomationBench, Medium ficou em 23,6% por US$ 0,89 por tarefa. Se essa relação se reproduzir no seu domínio, diminuir o esforço pode gerar uma economia mais interessante do que trocar imediatamente para um modelo menor.
O teste que deve decidir a produção
Antes da escolha definitiva, o benchmark público deve servir para montar a shortlist. A decisão final deveria vir de um conjunto pequeno de avaliações que reproduza suas próprias ferramentas.
- Separe de 50 a 100 tarefas representativas, incluindo casos fáceis, ambíguos e com múltiplas etapas.
- Registre a ferramenta correta, os argumentos esperados, ações proibidas e o estado final necessário.
- Injete falhas controladas: parâmetro rejeitado, 401 ou 403, entidade inexistente, timeout ou 429, erro 500, resultado vazio, dado desatualizado e conflito entre duas fontes.
- Meça separadamente acerto na seleção da ferramenta, correção dos argumentos, conclusão end-to-end, recuperação após falha, chamadas desnecessárias, efeitos colaterais incorretos, latência e custo.
- Rode os mesmos casos nas duas ou três configurações finalistas e fixe versões ou snapshots quando a plataforma permitir.
Esse procedimento evita um erro frequente: escolher o modelo que funciona melhor quando tudo dá certo. Em produção, o candidato realmente útil é o que falha de maneira detectável, tenta a recuperação adequada e não transforma um erro parcial em uma ação incorreta irreversível.
Hoje, os dados colocam Claude Opus 5 na frente para esse shortlist. Mas o ganho informacional mais importante dos benchmarks de 2026 é menos confortável: o modelo ainda é apenas uma parte da confiabilidade. Schema estrito, descrições inequívocas de ferramentas, respostas de erro estruturadas, limites de retry, idempotência, validação do estado final e testes com falhas reais continuam fazendo parte do produto.
