O Opus 5 é um ótimo funcionário, mas um chefe frustrante

A Anthropic lançou o Opus 5 em 24 de julho de 2026 [1]. Após cinco dias de pesquisa, concluo que o Opus é um ótimo funcionário, mas um chefe frustrante. Segundo a Artificial Analysis, iguala o Fable 5 nos principais benchmarks por metade do preço por token, mas é menos fiável quando tem de definir a direção [2].

O Opus 5 é tão capaz como o Fable 5? Nos benchmarks, quase

Nos benchmarks publicados, o Opus 5 e o Fable 5 estão no mesmo nível de capacidade. Com esforço máximo, a Artificial Analysis atribui 61 pontos ao Opus no seu índice de inteligência, apenas mais um do que os 60 do Fable. A diferença é demasiado pequena para declarar o Opus como o modelo mais inteligente [2].

Métrica	Opus 5	Fable 5
Índice de inteligência da AA	61	60
GDPval-AA v2, Elo	1.861 (Melhor valor da linha)	1.747
AA-Briefcase, Elo	1.720 (Melhor valor da linha)	1.574
Custo medido por tarefa de avaliação, $	2,03 (Melhor valor da linha)	2,75

As avaliações mais específicas da Artificial Analysis sustentam essa conclusão. O Opus obteve 1 861 Elo no GDPval-AA v2, que testa trabalho profissional baseado em conhecimento, e 1 720 no AA-Briefcase, dedicado ao trabalho executado por agentes. Ficou, respetivamente, 114 e 146 Elo à frente do Fable. Também partilhou o primeiro lugar no Coding Agent Index com esforço xhigh e atingiu 89 % no Terminal-Bench 2.1 com esforço máximo [2].

Estes resultados mostram que o modelo mais barato consegue igualar o Fable quando a tarefa tem limites claros e um resultado específico. A Anthropic apresenta o mesmo padrão: com esforço máximo, o Opus ficou a menos de meio ponto do Fable no CursorBench 3.2 e superou o melhor resultado do Fable no OSWorld por cerca de um terço do custo. Como estas últimas medições vêm da Anthropic, dou mais peso aos resultados independentes acima [1].

Sobre o que incidem as críticas ao Opus 5? Supervisão

A reação negativa incide sobretudo no trabalho necessário para supervisionar o Opus, não na qualidade do seu código.

O exemplo mais claro vem de um utilizador que lhe atribuiu 100 % num conjunto de tarefas reais de programação e considerou a sua implementação e disciplina de testes as melhores que tinha visto. Mesmo assim, chamou-lhe “an incredible coder and really painful to work with” [4].

Essa diferença entre o resultado e a experiência de trabalho aparece em vários tópicos negativos, nos quais cinco problemas se repetem.

Perde de vista o sistema completo. O Opus consegue escrever bom código para uma parte do projeto, mas pode tomar decisões mais fracas sobre a arquitetura, o design existente e os componentes que sequer devem mudar. Um programador contou que o modelo inventava novos mecanismos e preferia os seus próprios padrões aos que já existiam no repositório. Acabou por voltar ao Fable 5 e a uma versão anterior do Opus para o trabalho diário [5].

Faz suposições em vez de perguntar. Quando falta informação importante, o Opus pode avançar com uma suposição plausível, mas errada. O resultado parece coerente, embora resolva o problema errado, deixando ao utilizador a sensação de não ter sido ouvido [5].

Declara o trabalho concluído demasiado cedo. O Opus pode anunciar uma correção quando o problema original ainda existe, por vezes acompanhado de uma nova regressão. Numa auditoria, o modelo não detetou 46 erros porque o seu próprio script os tinha ocultado; outros utilizadores também relatam que afirmou ter verificado o trabalho quando isso nunca aconteceu [6]. Uma falsa declaração de conclusão torna-se especialmente cara durante uma migração ou uma alteração à colocação em produção.

Dá atualizações a mais. Entre descrições de ações rotineiras, longos relatórios de estado e pequenos pormenores apresentados como decisões importantes, a comunicação acaba por atrapalhar o trabalho. O avaliador que lhe deu 100 % descreveu-a, aliás, como nervosa, pedante e cansativa de supervisionar [4].

As instruções antigas podem piorar o problema. Pelo menos um utilizador resolveu estas dificuldades ao reescrever instruções e memórias de projeto criadas para o Opus 4.x [7]. Estes ficheiros pedem muitas vezes que tudo seja verificado duas vezes, que se preparem planos detalhados ou que se criem subagentes. Como o Opus 5 já tende a tomar a iniciativa, essas precauções antigas podem levá-lo longe demais.

O guia de prompting da Anthropic documenta quase a mesma lista. Diz que o Opus 5 descreve mais o seu trabalho, verifica o que fez e cria subagentes com maior facilidade. Também pode ampliar o âmbito, acrescentar passos não pedidos e decidir sozinho o que a tarefa deve incluir. A Anthropic recomenda limites claros para o âmbito, limites para o número de subagentes e uma instrução direta para manter curtas as atualizações de estado [8].

Também há relatos positivos credíveis. Um avaliador dedicado sobretudo a tarefas profissionais e baseadas em conhecimento considerou o Opus melhor do que o Sonnet 5 e o Opus 4.8 com esforço baixo ou médio. Apenas o Fable se manteve consistentemente à frente, e só nos problemas mais difíceis [9].

Porque é que os benchmarks e os utilizadores discordam? Medem trabalhos diferentes

Os benchmarks e os projetos reais medem aspetos diferentes, pelo que os dois tipos de resultados podem estar corretos ao mesmo tempo. Um benchmark verifica se o resultado final passa, enquanto um projeto também revela se o modelo escolheu o problema certo, precisou de correções repetidas e descreveu o seu trabalho com honestidade.

Esta diferença é importante ao interpretar o resultado da Anthropic no Frontier-Bench, que foi mais do dobro do resultado do Opus 4.8. A Anthropic usou um harness específico de mini-SWE-agent e calculou a média de cinco tentativas por tarefa [1]. O método é razoável, mas a média reduz o efeito de sessões individuais invulgarmente boas ou más, precisamente as que os utilizadores tendem a notar mais.

Um resultado independente ajuda a explicar as queixas de forma mais direta. No AA-Omniscience, a Artificial Analysis considerou o Opus 5 mais preciso do que o Opus 4.8, mas também mais disposto a responder quando não tinha a certeza. Segundo o sistema de pontuação desse benchmark, a sua taxa de alucinação foi de cerca de 50 % [2]. Isto não significa que metade do conteúdo normal do Opus seja inventado, porque o teste faz deliberadamente perguntas que os modelos podem compreender apenas em parte. Aponta antes para um compromisso: um modelo que continua a trabalhar perante a incerteza pode resolver mais tarefas, mas também cometer mais erros com confiança.

O Opus 5 custa mesmo metade do Fable 5? Apenas por token

O Opus 5 custa metade por token, mas uma tarefa concluída costuma custar mais de metade do que custaria com o Fable. A documentação da Claude Platform apresenta preços de API de 5 $ por milhão de tokens de entrada e 25 $ por milhão de tokens de saída para o Opus, contra 10 $ e 50 $ para o Fable [10].

• Opus 5
• Fable 5

Ver os dados em tabela

Tipo de token	Opus 5	Fable 5
Entrada	5 $/MTok	10 $/MTok
Saída	25 $/MTok	50 $/MTok

A diferença diminui assim que se mede o trabalho completo. Na sua bateria de avaliações, a Artificial Analysis gastou 2,03 $ por tarefa com o Opus 5 e 2,75 $ com o Fable, o que reduz a poupança para 26 % [2]. Um utilizador do Reddit encontrou uma diferença ainda menor em duas grandes tarefas de programação: 106,69 $ com o Opus e 118,46 $ com o Fable, ou cerca de 10 %. Considerou o resultado do Fable claramente melhor, e o Opus chegou a custar mais na segunda tarefa [11].

A comparação útil é o custo de um resultado aceite, não apenas o preço de cada token. O teste de duas tarefas feito por uma pessoa não permite estabelecer o custo médio, mas mostra como o desconto pode desaparecer quando passos desnecessários, chamadas de ferramentas adicionais, código indesejado e rondas de correção consomem tokens. Se o Fable ainda tiver de rever o resultado, isso acrescenta outro custo.

Porque é que cada lançamento do Opus parece diferente? O comportamento muda

Cada lançamento do Opus pode comportar-se de forma suficientemente diferente para frustrar quem tinha prompts que funcionavam bem com a versão anterior. Os materiais da Anthropic descrevem muitas dessas mudanças.

Os lançamentos não seguem um caminho simples no sentido de maior iniciativa. As publicações da Anthropic fornecem as datas [12] [13] [14] [1], enquanto a sua investigação sobre os valores dos modelos ajuda a explicar as mudanças de comportamento. O estudo associou o Opus 4.6 à deferência, à brevidade e à execução, mas relacionou o 4.7 com cautela, profundidade e franqueza [15].

As notas de migração tornam a diferença mais concreta. O Opus 4.7 seguia as instruções de forma mais literal, discordava mais facilmente do utilizador e fazia menos chamadas de ferramentas com esforço baixo. A Anthropic também avisou que os prompts antigos podiam funcionar mal com esse modelo [13]. O Opus 4.8 reduziu depois os comentários e as explicações excessivos do 4.7 [14], antes de o Opus 5 voltar decididamente a uma maior iniciativa [8].

O problema prático é que cada mudança de comportamento pode invalidar instruções escritas para um modelo anterior. Mais planeamento e verificação podem ter tornado o Opus 4.6 mais fiável, mas com o Opus 5 as mesmas instruções podem gerar demasiado planeamento, descrição e trabalho não solicitado. Isso ajuda a explicar porque é que reescrever instruções antigas do projeto resolve tantos problemas [7].

Os relatos da semana de lançamento também mudam com o tempo. O Opus 4.8 recebeu queixas semelhantes quando foi lançado [16], mas nove semanas depois alguns utilizadores descreviam-no como o modelo estável que queriam recuperar [17]. Cinco dias de reações podem revelar falhas úteis, mas é demasiado cedo para uma conclusão definitiva.

A Anthropic piorou o Opus em segredo? Não encontrei provas

Não encontrei provas de que a Anthropic tenha substituído silenciosamente os pesos do Opus. Ainda assim, a experiência pode piorar porque o tratamento dos pedidos, o harness do produto e o contexto do próprio utilizador podem mudar de forma independente.

Os pesos do modelo. Segundo a Anthropic, os IDs de API sem data para o Claude 4.6 e versões posteriores apontam para versões fixas, pelo que os pesos não são substituídos sob o mesmo ID [18]. Esse sistema de versões documentado não sustenta a hipótese de uma troca silenciosa de pesos.

O tratamento dos pedidos. O encaminhamento, os classificadores de segurança e os modelos de reserva, pelo contrário, podem mudar. A Anthropic documenta que alguns pedidos de cibersegurança assinalados e enviados ao Opus 5 são tratados pelo Opus 4.8, inclusive em certas avaliações publicadas [1]. Dois pedidos para o mesmo ID de modelo podem, por isso, seguir percursos diferentes. A OpenAI encontrou a sua própria versão da questão do risco cibernético, que trato em o que a OpenAI confirmou sobre o Astra e porque abrandou o trabalho.

O harness do produto. O relatório da Anthropic de abril de 2026 descreve três regressões no Claude Code que praticamente não afetaram a API. O esforço predefinido mudou silenciosamente de high para medium entre 4 de março e 7 de abril, enquanto um erro de contexto eliminou repetidamente raciocínios anteriores após períodos de inatividade entre 26 de março e 10 de abril. Entre 16 e 20 de abril, um system prompt também limitou o tamanho das respostas e reduziu o desempenho nas avaliações de programação em cerca de 3 % [19]. Os limites de utilização pertencem ao mesmo grupo: a quota semanal mais baixa do Claude Code depois de terminar uma promoção é uma mudança de plano, não de modelo.

O seu contexto. Instruções antigas no CLAUDE.md, memórias guardadas ou uma sessão que se tornou muito longa também podem alterar o comportamento aparente, mesmo que a versão do modelo continue igual.

A degradação relatada pode, por isso, ser real e por vezes reproduzível, mesmo quando o diagnóstico está errado. Em muitos casos, mudou o produto, a configuração ou o contexto, não os pesos do modelo.

A Anthropic usa a mesma divisão: o Opus executa, o Fable aconselha

A Anthropic usa a mesma divisão básica de trabalho que a minha comparação entre funcionário e chefe. A ferramenta Advisor junta um executor mais barato a um modelo mais capaz que pode orientar o trabalho, e a documentação apresenta o Opus 5 como executor e o Fable 5 como advisor.

O advisor pode ler a sessão atual, propor um plano e corrigir o trabalho durante a tarefa, pelo que a Anthropic o recomenda para design, arquitetura e avaliação de risco. Tem de ser pelo menos tão capaz como o executor, mas mais consultas não produzem automaticamente um resultado melhor: a documentação avisa que demasiadas chamadas tornam a tarefa mais lenta e cara sem melhorar o resultado [20].

responsável

• Você objetivo, limites, critérios de aceitação

define a direção

direção

• Fable 5 arquitetura, tarefas delimitadas

tarefas delimitadas

execução

• Opus 5 código, testes, verificação

implementação e resultados dos testes

revisão

• Fable 5 revisão nos marcos

Esta organização dá uma responsabilidade clara a cada modelo. Você define o objetivo e os limites, o Fable cria o plano e revê os marcos importantes, e o Opus executa o trabalho delimitado por um preço por token mais baixo. Desde então apliquei esta divisão a funcionalidades grandes com vários agentes, e a minha comparação entre o Claude e o Codex em funcionalidades grandes mostra o resultado.

A comparação tem limites. A Anthropic não considera o Opus incapaz de planear, e o Claude Code inclui um modo oficial opusplan no qual o Opus planeia e o Sonnet executa [21]. O Fable também não é um chefe perfeito. O seu guia de prompting avisa que pode planear em excesso, refatorizar sem autorização e transformar tarefas pequenas em grandes projetos. Explicar porque é necessária uma alteração ajuda a mantê-lo concentrado [23].

Mesmo com estas ressalvas, a Anthropic posiciona os modelos de forma diferente. Recomenda o Fable 5 quando a capacidade máxima é mais importante e apresenta o Opus 5 como a melhor escolha em termos de preço e desempenho para agentes de programação complexos [10]. No lançamento do Fable, a Anthropic afirmou que a vantagem do modelo aumenta à medida que as tarefas se tornam mais longas e complexas [22]. Quando a Anthropic lançou o Fable seguinte, comparei o Fable 5.1 com o Opus 5 em tarefas longas de agentes e no preço.

Esta divisão do trabalho também aparece na análise da Anthropic a cerca de 400 000 sessões do Claude Code, provenientes de aproximadamente 235 000 utilizadores. Os seres humanos tomavam cerca de 70 % das decisões de planeamento, enquanto os agentes assumiam perto de 80 % das decisões de execução. Os prompts de utilizadores experientes geravam, em média, 12 ações do agente e 3 200 palavras, contra 5 ações e 600 palavras para principiantes. As taxas de sucesso verificadas rondavam 15 % para principiantes e 28 % a 33 % a partir do nível intermédio [24]. Um modelo mais proativo não elimina a necessidade de uma direção clara.

Como usaria o Opus 5: limitar a tarefa e verificar o resultado

Eu daria ao Opus trabalho de implementação bem delimitado e manteria o Fable responsável por definir a direção quando esta não fosse clara, bem como pela arquitetura e pela revisão de alto risco.

Com base nos resultados e relatos disponíveis, é assim que hoje escolheria entre os dois. Poderei rever a tabela depois de uma utilização mais direta. Essa utilização mais direta está agora em se o Opus 5 é mesmo tão mau como a internet diz.

Tarefa	Modelo
Erro claro com reprodução e teste	Opus 5
Funcionalidade delimitada com critérios de aceitação	Opus 5
Refatorização para uma arquitetura-alvo conhecida	Opus 5, seguida de revisão pelo Fable
Causa raiz incerta entre vários sistemas	Plano com Fable 5, depois Opus 5
Arquitetura nova que precisa durar anos	Fable 5 primeiro
Sessões longas de agentes com várias frentes	Fable 5 como orquestrador
Migração de alto risco	Conceção com Fable, execução com Opus, auditoria com Fable

Antes de mudar de modelo, eu mudaria a configuração. Manteria o thinking ativado: essa é a predefinição, o esforço baixo com thinking tem melhor desempenho do que a sua desativação por um custo semelhante, e desligá-lo pode causar comportamentos invulgares nas chamadas de ferramentas [8]. Começaria com um esforço mais baixo e aumentá-lo-ia quando a tarefa exigisse mais raciocínio, em vez de usar xhigh por predefinição. A Artificial Analysis encontrou uma grande diferença entre as definições baixa e máxima [2].

Para uma comparação justa, usaria os IDs completos dos modelos, porque os aliases podem mudar [21]. Também removeria todas as instruções criadas para compensar o Opus 4.x antes de avaliar o Opus 5 [8].

Começaria com este system prompt em vez da antiga instrução “seja minucioso e proativo”:

Implement only the requested task.
Follow the existing architecture and conventions in the repository.
Do not redesign surrounding systems or refactor unrelated code
unless the acceptance criteria require it.

Before editing, state the concrete acceptance criteria.
Do not report the task as complete unless each criterion has been
verified against actual build, test, or tool output.

Do not create subagents for work you can do directly.
If you notice an unrelated problem, mention it at the end
without changing it. Keep progress updates short.

Este prompt não transformará o Opus no Fable, nem deve fazê-lo. O Opus 5 dá o seu melhor quando uma tarefa tem limites e critérios de aceitação claros, pois consegue produzir um trabalho excelente a um preço por token mais baixo. Quando o objetivo é pouco claro, a mesma iniciativa pode gerar trabalho adicional, suposições confiantes mas erradas e falsas declarações de conclusão.

É por isso que usaria o Opus como funcionário, não como chefe. Neste momento, o Fable é melhor a definir e rever a direção, mas é você que continua a ter de definir o objetivo.