Resumo
- O incidente major do Haiku 4.5 foi de 13:04:35 a 16:38:26 UTC em 21 de julho e voltou a “identificado” após o primeiro monitoramento.
- Um registro critical de vários modelos delimitou erros elevados entre 15:28 e 16:26, embora só tenha fechado às 18:18.
- Outro evento critical afetou criação de documentos e ferramentas Claude de 17:40 a 18:03.
- O Opus 4.1 teve um incidente minor separado na API e no Claude Code entre 08:34 e 09:00 do dia 22.
- A Anthropic não divulgou causa comum, número de usuários, taxa de erro, região ou compensação.
O retorno de um incidente do estado de monitoramento para “identificado” vale mais do que uma mensagem genérica de indisponibilidade. No Haiku 4.5, ele mostra que a primeira recuperação percebida pela Anthropic não se sustentou.
Isso justifica cautela do cliente, mas não uma explicação técnica inventada. Os eventos seguintes têm relógios, componentes e níveis de impacto próprios. Somá-los como uma pane única apagaria justamente a informação que a página de status preserva.
O Haiku precisou de uma segunda estabilização
O registro começou às 13:04:35 e listou claude.ai, Console, API, Claude Code e Cowork. A Anthropic identificou o problema, aplicou uma correção e passou a monitorar às 13:22. Às 14:44, voltou ao estado identificado; novo monitoramento começou às 15:30 e a resolução chegou às 16:38.
Não há explicação para a reversão. Portanto, não se pode afirmar se a correção inicial era parcial ou se outro sintoma surgiu. A conclusão comprovada é operacional: o primeiro sinal de melhora não era estável.
Impacto e ciclo do incidente não têm a mesma duração
O evento critical de vários modelos abriu às 15:35. Na nota final, a Anthropic disse que usuários tiveram erros elevados de 15:28 a 16:26. A página ficou ativa até 18:18.
O intervalo de 58 minutos representa o impacto reconstruído. O período maior inclui identificação, correção, monitoramento e confirmação. Tratar tudo como erro contínuo exagera; apagar o tempo de acompanhamento esconde a incerteza de recuperação.
O evento abrangia claude.ai, API, Claude Code e Cowork. Ele se sobrepôs ao Haiku, mas coincidência temporal e componentes compartilhados não provam uma causa comum.
A camada de trabalho falhou separadamente
Às 17:40, outro registro critical citou criação de documentos, Cowork Remote, Claude Code, Claude Code na Web, Claude Tag e Claude Design. O monitoramento começou às 17:51 e a resolução veio às 18:03.
Essa ficha mostra por que uma empresa deve testar mais do que a resposta do modelo. A inferência pode funcionar enquanto ambiente remoto, documento ou orquestração impedem o processo de terminar.
Na manhã seguinte, o Opus 4.1 teve um evento minor na API e no Claude Code: identificado às 08:34, monitorado às 08:45 e resolvido às 09:00.
Um dia ruim não produz uma métrica universal
Rótulos major, critical e minor não podem ser somados. Sem população, percentual de falhas, geografia, perda de dados ou regra de crédito, também não existe cálculo público do impacto total.
O mecanismo prático é claro: interromper filas, sondar a recuperação de forma limitada e decidir se o trabalho migra para outro modelo ou provedor. Uma retomada segura deve combinar estado do fornecedor, sucesso sintético e drenagem do backlog.
Um relatório posterior poderá ligar dependências e explicar a recaída do Haiku. Até lá, a precisão exige dois reconhecimentos ao mesmo tempo: houve concentração de falhas nas superfícies Claude, e não há evidência pública de uma raiz técnica única.