Resumo
- A ocorrência de Opus 4.8 e Haiku 4.5 foi de 13:37:28Z a 15:23:37Z em 22 de julho.
- Haiku 4.5 se recuperou antes de Opus 4.8 e antes do encerramento do primeiro registro.
- Uma ocorrência independente de Sonnet 5 abriu às 15:24:05Z, 28 segundos depois, e terminou às 16:12:32Z.
- Ambos os registros citaram claude.ai, Console, API, Claude Code e Cowork.
- Anthropic não publicou causa comum, usuários afetados, taxa de erros, perda de dados ou decisão de crédito.
Para uma aplicação que escolhe entre modelos, a passagem de uma ocorrência para a outra cria uma armadilha. Uma fila mantida durante os erros de Opus ou Haiku poderia ser liberada assim que o estado geral ficasse verde. Quase no mesmo instante, Sonnet receberia seu próprio registro. A experiência operacional seria de incerteza contínua, mesmo que o catálogo do provedor mantivesse dois incidentes.
Essa diferença entre experiência e identidade deve permanecer. A proximidade temporal é evidência de uma janela difícil; não prova que um defeito saiu de Opus e entrou em Sonnet, nem que uma correção causou outro problema. O desenho de resiliência pode ser reforçado sem inventar uma raiz técnica.
A recuperação desigual já aparecia no primeiro registro
Anthropic abriu a ocorrência de Opus/Haiku às 13:37:28Z com impacto menor. Depois de identificar o problema, informou que Haiku 4.5 havia se recuperado enquanto Opus 4.8 ainda apresentava erros elevados. O registro passou ao monitoramento às 15:06:53Z e foi resolvido às 15:23:37Z.
Essa ordem oferece uma alternativa a quem pode escolher modelo. Após testes próprios, parte das tarefas poderia voltar a Haiku. As cargas que exigiam Opus deveriam continuar em espera ou usar uma rota compatível. Um único sinal “Claude saudável” esconderia tanto a oportunidade de retorno parcial quanto o risco que ainda restava.
claude.ai, Console, API, Claude Code e Cowork apareceram como superfícies afetadas. A lista não indica que toda solicitação em todas elas falhou. A classificação “menor” também não é contagem de usuários. O registro não informa porcentagem de falhas, região, tamanho de fila nem impacto financeiro.
O relógio separa dois registros, não explica uma causa
A ocorrência de Sonnet 5 começou às 15:24:05Z. Anthropic a marcou como identificada às 15:36:57Z e resolvida às 16:12:32Z, novamente com impacto menor e as mesmas cinco superfícies. A API estruturada preserva os horários com milissegundos e permite calcular os 28 segundos.
Esse limite exato deve ser usado para descrever a sequência, não para extrapolar um mecanismo. Anthropic não declarou que a recuperação de Opus tenha provocado a falha de Sonnet. Também não disse que uma correção moveu o problema entre modelos. IDs, escopos e ciclos de vida separados apontam para duas ocorrências na fonte pública.
Fundir os registros apagaria o escopo por modelo e atribuiria uma causa compartilhada que não foi publicada. A afirmação segura é que clientes de vários modelos enfrentaram registros adjacentes com praticamente nenhum intervalo para reconstruir confiança.
Uma página verde é apenas um sinal de recuperação
Antes de liberar uma fila, o cliente pode exigir uma sequência de requisições sintéticas bem-sucedidas no modelo, interface e região realmente utilizados. Pode reabrir tráfego em etapas, manter chaves de idempotência, limitar tentativas e conservar outro modelo ou fornecedor para tarefas que permitem substituição.
O estado de saúde deveria existir pelo menos no nível de modelo e superfície. Algumas cargas pedem granularidade maior: uso de ferramentas, contexto longo, interação e processamento em lote não se comportam da mesma forma. Uma chamada curta na API não comprova a recuperação de uma tarefa longa no Claude Code ou de um fluxo no Cowork.
Haiku se recuperou primeiro, Opus veio depois e Sonnet ganhou um registro próprio. Um roteador que considerasse todos os modelos um domínio único tomaria decisões mais pobres. Telemetria do cliente — erros, latência, idade da fila e conclusão de negócios — deve acompanhar o status do provedor.
Recorrência não equivale a continuidade técnica
Os dois registros vieram depois do limite de tempo usado pela BTW para os quatro episódios anteriores. São nova recorrência, não evidência retroativa de que tudo pertence a uma só falha prolongada. A repetição pode justificar redundância, orçamento de erro mais conservador e testes mais frequentes, mas não autoriza diagnóstico único.
As mesmas cinco superfícies nas duas páginas também não resolvem a questão. Elas podem refletir canais comuns de consumo, convenções da página de status ou impacto amplo. Sem arquitetura, métricas e causa raiz, não é possível escolher entre essas interpretações.
Os números ausentes limitam a análise
Não há causa compartilhada, usuários afetados, porcentagem de erros, divisão regional, conclusão sobre perda de dados ou tratamento de SLA. Assim, os eventos não sustentam cálculo de disponibilidade contratual, alegação de falta de capacidade ou estimativa agregada de prejuízo.
O que pode ser medido é o encadeamento: cerca de uma hora e 46 minutos no primeiro registro, 28 segundos de intervalo e aproximadamente 48 minutos no segundo. A página de status define a identidade do incidente para o provedor. O cliente precisa definir, com testes próprios, quando o trabalho real está seguro para voltar.