Claude Opus 4.6 lida com tarefas de 12 horas — mas com apenas 50% de confiabilidade

O Google News destacou uma afirmação chamativa: o Claude Opus 4.6 consegue realizar trabalho de IA equivalente a quase 12 horas de esforço humano. No entanto, o modelo atinge essa marca com apenas 50% de probabilidade prevista de sucesso.

Em um limite de sucesso de 80%, seu horizonte medido cai para cerca de 70 minutos. Essa diferença transforma uma manchete triunfalista em uma história mais relevante sobre a confiabilidade de agentes de IA. Um agente que conclui metade de suas atribuições não é um colega autônomo. É um gerador de rascunhos incerto, cujas falhas ainda exigem detecção humana.

Os números vêm da METR, uma organização independente de pesquisa que avalia se agentes de IA conseguem concluir tarefas de software de diferentes durações. A Anthropic lançou o Claude Opus 4.6 em fevereiro de 2026, descrevendo melhor desempenho em trabalho agentivo sustentado. Os resultados da METR corroboram essa direção, ao mesmo tempo que expõem os limites ocultos no número mais chamativo da manchete.

O conflito, portanto, não é entre Claude e outro modelo. É entre a autonomia como é vendida e a autonomia que uma equipe pode usar com segurança. Para desenvolvedores e compradores corporativos, 70 minutos confiáveis importam mais do que 12 horas especulativas.

O que o resultado de 12 horas do Claude realmente mede

O número da manchete descreve a dificuldade da tarefa, não 12 horas de operação autônoma ininterrupta.

A METR define um horizonte de tempo para conclusão de tarefas como a duração de que um especialista humano precisa para realizar um trabalho que um agente de IA consegue concluir com determinada taxa de sucesso. Um horizonte de 12 horas não significa que o Claude permanece ativo por 12 horas. Significa que as tarefas testadas levariam aproximadamente esse tempo para um humano qualificado.

A distinção importa porque agentes de IA muitas vezes executam tarefas bem-sucedidas mais rápido do que suas referências humanas. Eles podem escrever vários blocos de código de uma vez, pesquisar documentação rapidamente e evitar parte da navegação manual. A duração humana funciona como uma escala de dificuldade, não como um cronômetro para o modelo.

O painel de horizontes de tempo da METR estima o sucesso ajustando uma curva estatística aos resultados dos agentes. Seu conjunto de tarefas contém mais de 100 atribuições voltadas a software. Os pesquisadores executam cada tarefa várias vezes e comparam os resultados com estimativas de tempo de conclusão humano.

O trabalho avaliado abrange principalmente engenharia de software, aprendizado de máquina e cibersegurança. As tarefas são projetadas para serem autocontidas, claramente especificadas e avaliadas automaticamente. Essas condições tornam o teste sistemático possível, mas diferem do trabalho diário dentro de uma empresa.

Segundo relatos, o Claude Opus 4.6 alcançou um horizonte de 50% de cerca de 719 minutos, ou quase 12 horas. Seu horizonte de 80% foi de aproximadamente 70 minutos. O primeiro número rende uma manchete marcante, enquanto o segundo fornece um sinal mais prático para implantação.

Um horizonte de 50% prevê sucesso em apenas metade das tarefas comparáveis. Essa taxa de falha ainda pode ser útil quando a verificação é rápida e os erros têm baixo custo. Um desenvolvedor poderia pedir a um agente que tentasse uma refatoração difícil, inspecionar o resultado e descartá-lo se os testes falhassem.

A mesma confiabilidade seria inaceitável para uma migração de produção sem monitoramento. Também seria inadequada para mudanças de segurança cujos erros permanecem invisíveis até que ocorra um incidente. Uma capacidade maior para tarefas longas tem pouco valor operacional quando uma equipe não consegue reconhecer falhas com eficiência.

O limite de 80% também não é perfeito. Ele implica que uma em cada cinco tentativas comparáveis ainda falha no modelo ajustado. Ainda assim, aproxima o sistema de um tipo de trabalho que pode receber revisões periódicas em vez de supervisão contínua.

É por isso que o enquadramento do Google News precisa de contexto. Doze horas capturam o limite externo da capacidade do Claude com confiabilidade de cara ou coroa. Setenta minutos descrevem melhor a duração em que um usuário pode começar a considerar uma delegação limitada.

Mesmo essa interpretação exige cautela. O resultado não mostra que o Claude consegue concluir 80% de todas as tarefas de 70 minutos. A METR explica que algumas tarefas são consistentemente fáceis para um modelo, enquanto outras o derrotam de forma consistente. A porcentagem representa uma expectativa ajustada em todo o conjunto de avaliação.

A questão prática não é se o modelo ultrapassou uma duração impressionante. É se os usuários conseguem identificar quais atribuições estão dentro de sua faixa confiável antes de delegá-las.

Por que leitores do Google News devem se concentrar na confiabilidade

A confiabilidade de agentes de IA determina se horizontes mais longos economizam tempo humano ou apenas o transferem para revisão e recuperação.

Uma resposta malsucedida em um chat custa segundos. Uma execução malsucedida de um agente pode alterar arquivos, escolher a dependência errada, interpretar requisitos de forma equivocada e construir trabalho adicional sobre um erro inicial. Os custos dos erros aumentam à medida que um agente recebe mais ferramentas e mais liberdade.

Isso cria um problema assimétrico. Execuções longas bem-sucedidas são fáceis de celebrar porque produzem resultados visíveis. Execuções malsucedidas podem ocultar seus defeitos em código plausível, testes incompletos ou um resumo confiante. O supervisor pode gastar mais tempo auditando um erro bem apresentado do que concluir a tarefa original.

O Claude Opus 4.6 importa porque a Anthropic o posicionou explicitamente para fluxos de trabalho agentivos mais longos. O anúncio do modelo da empresa afirma que ele planeja com mais cuidado, trabalha com mais confiabilidade em bases de código maiores e detecta mais dos próprios erros. A Anthropic também introduziu uma janela de contexto de um milhão de tokens em beta.

Uma janela de contexto é a quantidade de informação que um modelo consegue processar durante uma interação. Mais contexto permite que um agente inspecione repositórios maiores e retenha históricos mais longos. Isso não garante que o modelo raciocinará corretamente sobre tudo que for colocado nessa janela.

Contexto longo e horizontes de tarefas longos resolvem restrições diferentes. O primeiro diz respeito à quantidade de material que o modelo consegue acessar. O segundo estima o quão difícil é uma tarefa que ele consegue concluir em um nível de confiabilidade especificado. Combiná-los amplia o espaço de trabalho disponível, mas não elimina o risco de execução.

A lacuna de confiança fica mais clara em um cenário real de desenvolvimento. Imagine atribuir a um agente uma migração de banco de dados que um engenheiro humano precisaria da maior parte de um dia para concluir. O agente escreve scripts de migração, atualiza o código da aplicação e modifica testes.

Com 50% de confiabilidade, a equipe não pode tratar o resultado como trabalho concluído. Um engenheiro precisa inspecionar premissas de esquema, comportamento de reversão, preservação de dados e ordem de implantação. Essa revisão pode se aproximar do custo de realizar a tarefa diretamente.

Agora considere uma atribuição menor, com uma referência humana de 70 minutos. O agente atualiza um componente definido, executa testes e produz um conjunto compacto de alterações. Uma taxa esperada de sucesso de 80% ainda exige revisão, mas a superfície de revisão é menor e as falhas são mais fáceis de isolar.

A diferença afeta o design de produto tanto quanto a escolha do modelo. Sistemas de agentes úteis precisam de pontos de controle, testes, limites de permissão e registros completos do que o modelo alterou. Também precisam de um caminho de escalonamento quando a incerteza aumenta.

Isso torna o contexto rastreável especialmente importante para o trabalho do conhecimento. Uma base de conhecimento de IA pesquisável pode preservar requisitos, decisões de reuniões e material-fonte. Ela não pode garantir um raciocínio correto, mas fornece às pessoas evidências para revisar as conclusões de um agente.

O benchmark atual também pressiona equipes que anunciam agentes como substitutos de funções completas. A medição da METR não sustenta essa interpretação. Uma função combina solicitações ambíguas, contexto organizacional, negociação, julgamento e responsabilidade em muitas tarefas conectadas.

Em vez disso, o conjunto se assemelha a atribuições claramente delimitadas dadas a um trabalhador com pouco contexto. A METR alerta especificamente que seus horizontes não devem ser equiparados ao trabalho realizado por um funcionário experiente que entende a história de uma empresa.

Esse alerta muda a forma como compradores devem interpretar manchetes sobre IA. A unidade relevante não é o número de horas de trabalho nominal. É o trabalho verificado concluído por hora de atenção humana.

A verdadeira disputa é entre autonomia de IA e verificação humana

A limitação central já não é saber se um agente de IA consegue tentar um trabalho longo, mas se as pessoas conseguem verificar esse trabalho sem recriá-lo.

Horizontes de tarefas mais longos ainda representam progresso significativo. A pesquisa original da METR constatou que os horizontes dos modelos de fronteira aumentaram exponencialmente ao longo de vários anos. Os pesquisadores atribuíram a melhora, em parte, a melhor raciocínio, uso de ferramentas, confiabilidade e recuperação de erros.

Seu estudo sobre tarefas longas relatou um período histórico de duplicação de aproximadamente sete meses desde 2019. A análise TH1.1 mais recente da METR encontrou um intervalo de duplicação mais curto, de 89 dias, ao ajustar apenas modelos lançados desde 2024.

Esses dois números descrevem janelas de tempo diferentes. A estimativa recente mais rápida não elimina a tendência histórica mais longa. Ela sugere aceleração sob um ajuste, mas deixa em aberto se esse ritmo persistirá.

A atualização TH1.1 também expandiu o conjunto de 170 para 228 tarefas. Ela mais que dobrou o número de atribuições que duram pelo menos oito horas humanas, de 14 para 31. As adições melhoraram a cobertura na extremidade longa, onde os modelos mais novos estavam esgotando o benchmark anterior.

O Claude Opus 4.6 avançou diretamente contra esse limite. Quando um modelo é bem-sucedido em quase todas as tarefas mais curtas, a curva ajustada depende fortemente do grupo menor de atribuições longas. As estimativas então se tornam mais sensíveis à seleção de tarefas e às premissas estatísticas.

A METR reconheceu essa questão em uma análise de março sobre premissas de modelagem. A organização afirmou que seu conjunto estava se aproximando da saturação e que os resultados recentes se tornaram mais sensíveis às escolhas analíticas.

Isso não torna o resultado de 12 horas sem sentido. Torna a confiança em uma duração precisa de manchete mais fraca do que a manchete sugere. A tendência ampla em direção a trabalhos bem-sucedidos mais longos permanece mais clara do que a posição exata de um modelo.

A tensão também explica por que 80% merece mais atenção. Um horizonte de 50% reage fortemente à fronteira incerta, onde sucessos e falhas estão equilibrados. O horizonte de 80% permanece mais próximo da região em que o modelo acumulou mais evidências de sucesso.

Ainda assim, 80% não é um limite universal de confiança. A taxa aceitável depende da tarefa e de seu custo de verificação.

Um agente de programação pode tentar implementar um recurso bem testado porque verificações automatizadas detectam muitos erros. Um agente de pesquisa que resume documentos privados precisa de citações porque omissões sutis podem escapar de um teste simples. Um agente que altera controles de acesso exige revisão mais rigorosa porque um único erro não percebido pode expor sistemas sensíveis.

Essas diferenças criam três categorias práticas de delegação.

Trabalho reversível e de baixo custo pode tolerar falhas frequentes. Entre os exemplos estão elaborar casos de teste, explorar opções de implementação ou produzir um protótipo descartável. Uma pessoa pode executar o agente novamente ou rejeitar o resultado.

Trabalho de produção verificável precisa de evidências mais fortes. Exemplos incluem corrigir um bug localizado ou atualizar um cliente de API documentado. Testes, análise estática e revisão de código podem limitar o risco.

Trabalho de alto impacto e difícil verificação precisa de confiabilidade muito maior. Recomendações estratégicas, decisões de segurança, análises jurídicas e operações irreversíveis de dados não se tornam seguras apenas porque o agente trabalhou por mais tempo.

A indústria frequentemente resume as três categorias na palavra "autonomia". Esse enquadramento esconde o mecanismo que determina o valor real. Um agente é útil quando é mais fácil verificar sua produção do que produzi-la.

O marco de 12 horas, portanto, representa capacidade sem certeza suficiente. O marco de 70 minutos representa uma faixa operacional mais crível, embora continue inadequada para trabalhos de alto risco sem supervisão.

Essa é a inversão por trás da manchete. O número maior mede ambição. O número menor mede confiança.

O que os números do Claude Opus 4.6 não comprovam

O resultado da METR não comprova que Claude possa automatizar um dia de trabalho, substituir um desenvolvedor ou ter o mesmo desempenho fora de tarefas de software.

A primeira limitação é a cobertura de domínio. O conjunto atual da METR concentra-se em engenharia de software, aprendizado de máquina e cibersegurança. Essas áreas oferecem ambientes executáveis e avaliação objetiva, o que as torna excepcionalmente adequadas para avaliar agentes.

Muitas tarefas empresariais não têm essas características. Uma análise de mercado pode parecer persuasiva e ainda assim ignorar uma fonte decisiva. Um plano de vendas pode seguir todas as etapas solicitadas e, mesmo assim, interpretar mal o cliente. Um memorando de políticas pode exigir um julgamento que nenhum teste automatizado consegue pontuar.

A segunda limitação é a definição da tarefa. As atribuições de benchmark são autocontidas e, em geral, possuem critérios claros de conclusão. Projetos reais começam com requisitos incompletos, expectativas conflitantes de partes interessadas e restrições não documentadas.

Um modelo que tem sucesso após receber uma especificação precisa não demonstrou que consegue descobrir a especificação correta. Profissionais humanos dedicam muito tempo a resolver essa incerteza antes do início da implementação.

A terceira limitação diz respeito ao contexto. A METR compara agentes com especialistas humanos que abordam as tarefas sem a familiaridade organizacional de um funcionário estabelecido. Isso torna o benchmark mais comparável, mas limita a conclusão econômica.

Um engenheiro experiente sabe por que existe uma solução alternativa estranha. Um gerente de produto se lembra de qual promessa ao cliente restringiu um recurso. Um líder de segurança entende qual risco teórico a empresa já aceitou. Esses fatos raramente cabem em um ticket.

Grandes janelas de contexto podem fornecer mais documentos, mas selecionar o contexto certo continua difícil. Decisões antigas podem entrar em conflito com as mais recentes. Exceções informais podem estar em reuniões ou mensagens privadas. Mais entradas podem introduzir mais evidências irrelevantes junto ao material útil.

A quarta limitação é a própria estimativa ajustada. Um horizonte temporal resume tarefas variadas em um único eixo de duração. A extensão da tarefa se correlaciona com a dificuldade, mas duas atribuições que exigem o mesmo tempo humano podem desafiar um modelo de formas completamente diferentes.

Uma pode exigir alterações repetitivas de código que um agente lida bem. Outra pode depender do reconhecimento de uma restrição arquitetural sutil. A mesma duração não cria a mesma probabilidade de falha para ambas.

A METR também alerta que medições acima de 16 horas são pouco confiáveis com seu conjunto atual. A estimativa de 12 horas de Claude está próxima desse limite, e seu intervalo de confiança é amplo. Leitores devem tratar a estimativa pontual como uma região de incerteza, não como uma garantia de serviço calibrada.

A quinta limitação é a dependência do modelo e da estrutura de suporte. Uma estrutura de suporte é o sistema de software que fornece a um modelo ferramentas, instruções, memória e um ciclo para executar ações. Claude Code, Codex e outros sistemas de agentes podem produzir resultados diferentes com o mesmo modelo subjacente.

Mudanças em prompts, permissões de ferramentas, orçamentos de tokens e políticas de repetição podem afetar materialmente o desempenho. Um resultado de benchmark para um agente configurado de determinada forma não se transfere automaticamente para todos os produtos que carregam o mesmo nome de modelo.

Por fim, as taxas de sucesso não revelam o custo humano da supervisão. Um resultado de 50% pode ter valor comercial se as falhas forem imediatas e óbvias. Um resultado de 80% ainda pode ser pouco atraente se cada produção exigir uma auditoria especializada.

A METR foi incomumente direta sobre essas ressalvas. Sua nota sobre limitações afirma que um horizonte de 50% não significa que os usuários possam simplesmente delegar todas as tarefas mais curtas. Algumas atribuições exigem taxas de sucesso acima de 98% antes que a automação se torne vantajosa.

Essa afirmação é o contraponto mais importante à manchete do Google News. O benchmark mede uma fronteira em expansão, mas não certifica a prontidão para implantação.

A documentação de segurança da própria Anthropic fornece outro limite necessário. Seus cartões de sistema apresentam avaliações de capacidade e segurança sob condições específicas de teste. São divulgações valiosas, mas continuam sendo avaliações de um modelo, não garantias para todos os fluxos de trabalho posteriores.

Compradores empresariais devem pedir evidências no nível do sistema. Isso inclui o modelo, a estrutura do agente, as ferramentas conectadas, os dados organizacionais, as permissões e o processo de revisão. A confiabilidade emerge da configuração completa.

O que observar após a manchete do Google News

A próxima fase será definida por melhores testes de tarefas longas, resultados de maior confiabilidade e evidências de implantações supervisionadas no ambiente de trabalho.

O primeiro sinal é a próxima expansão do conjunto de tarefas da METR. Claude Opus 4.6 já está perto de saturar partes do benchmark atual, especialmente em durações menores. Mais tarefas longas com fortes referências humanas reduziriam a incerteza em torno das estimativas de fronteira.

A qualidade dessas adições importa mais do que o número bruto de tarefas. Pesquisadores precisam de atribuições que permaneçam autocontidas e avaliáveis, ao mesmo tempo que se assemelhem a trabalhos consequentes. Também precisam de tentativas humanas suficientes para estimar os tempos de conclusão sem depender excessivamente de estimativas de especialistas.

Se avaliações mais recentes preservarem o horizonte de 12 horas em um conjunto maior, a confiança na tendência de capacidade aumentará. Se a estimativa cair acentuadamente, a manchete atual parecerá mais um artefato de medição próximo ao teto do benchmark.

O segundo sinal é o avanço em limites de sucesso mais rigorosos. Um modelo que estende seu horizonte de 50% pode tentar trabalhos mais difíceis, mas não necessariamente reduz o risco operacional. O crescimento do horizonte de 80% mostraria que tarefas mais longas estão se tornando solucionáveis de forma confiável.

Um sinal ainda mais forte seria o desempenho publicado com confiabilidade de 90%, 95% ou mais. Esses limites se alinham mais de perto aos fluxos de trabalho de produção, nos quais falhas repetidas criam custos de revisão. Eles também revelariam se as curvas de confiabilidade melhoram de maneira uniforme ou continuam acentuadas.

Por essa razão, a diferença entre 50% e 80% merece atenção contínua. Claude Opus 4.6 mostra uma grande separação entre quase 12 horas e 70 minutos. Se modelos futuros reduzirem essa diferença, a autonomia se tornará mais fácil de implantar.

Se ambos os horizontes aumentarem enquanto sua separação permanecer ampla, a capacidade de manchete continuará superando a capacidade confiável. As plataformas de agentes então dependerão mais de verificação, tentativas repetidas e pontos de controle humanos.

O terceiro sinal são evidências do ambiente de trabalho que meçam resultados concluídos, e não apenas produção gerada. As organizações devem acompanhar alterações aceitas, defeitos que escaparam, tempo de revisão, frequência de reversão e a porcentagem de trabalho do agente que exige revisão substancial.

Essas medidas respondem à questão econômica que os benchmarks não conseguem resolver. O agente reduz o esforço total dos especialistas após a supervisão ou desloca esse esforço para depuração e validação?

Implantações controladas também podem identificar quais categorias de tarefas se transferem para além do benchmark. Um modelo pode ter bom desempenho em atribuições isoladas de programação, mas enfrentar dificuldades com mudanças em todo o repositório. Pode elaborar análises financeiras de forma eficaz, mas falhar ao localizar a premissa interna decisiva.

Os melhores relatórios separarão a duração da tarefa de seu tipo. Também divulgarão a estrutura de suporte, as permissões, o processo de revisão e a definição de falha. Sem esses detalhes, afirmações sobre horas autônomas continuam difíceis de comparar.

Resultados competitivos fornecerão contexto útil, mas os rankings de modelos não devem se tornar a história principal. O painel da METR mediu sistemas da Anthropic, OpenAI, Google e outros desenvolvedores. A liderança pode mudar a cada lançamento e configuração de avaliação.

A disputa mais profunda continua sendo entre delegação mais longa e verificação acessível. Um modelo não se torna um trabalhador autônomo quando lidera um gráfico. Ele se torna operacionalmente útil quando uma equipe pode confiar em sua produção a um custo total de atenção menor.

Para desenvolvedores, a resposta imediata deve ser uma delegação calibrada. Atribua aos agentes trabalhos delimitados com testes de aceitação explícitos. Preserve logs, exija resumos dos arquivos alterados e restrinja o acesso a sistemas de que a tarefa não precisa.

Para compradores empresariais, as perguntas de aquisição devem ir além da inteligência do modelo. Pergunte o que acontece após uma falha parcial. Determine se o sistema pode reverter alterações, citar evidências, expor incertezas e encaminhar o caso a uma pessoa.

Para trabalhadores do conhecimento, o número de 70 minutos oferece uma expectativa mais realista. A IA consegue cada vez mais conduzir uma atribuição definida por várias etapas. Ainda precisa de uma pessoa para enquadrar a atribuição, verificar o resultado e assumir as consequências.

Essa divisão de responsabilidades mudará à medida que a confiabilidade melhorar. As evidências não apoiam abandoná-la agora.

A manchete do Google News capturou um marco genuíno, mas seu número mais dramático não é o mais útil. Doze horas mostram até onde Claude pode chegar quando sucesso e falha estão equilibrados. Setenta minutos mostram onde a confiança começa a se tornar prática.

Antes de entregar a um agente um dia inteiro de trabalho, escolha uma tarefa com evidências claras e um resultado reversível. Registre o tempo humano gasto para especificá-la, monitorá-la e revisá-la. Em seguida, compare esse total com o fluxo de trabalho original.

Se o agente economizar atenção após a verificação, amplie o limite com cuidado. Se a revisão consumir o ganho, um horizonte de modelo mais longo não resolverá o processo. A próxima notícia importante sobre IA não será apenas mais um recorde. Será a prova de que o trabalho confiável está alcançando as tentativas impressionantes.