Claude Opus 5 fora do ar de novo: 4 incidentes em 48 horas

Você apontou produção pro Opus 5 na sexta. Hoje ele já quebrou três vezes.

Não é azar. É o preço de ser early adopter de modelo recém-lançado — e dá pra se proteger dele com engenharia, não com torcida.

Claude Opus 5 fora do ar não é manchete: é uma sequência de incidentes de "elevated errors" registrada no feed oficial de status da Anthropic. Este post é a linha do tempo verificada desde o lançamento, com esse feed como única fonte, mais o playbook de resiliência pra quem já tem agente rodando em cima do modelo novo.

TL;DR

• O que aconteceu: 4 incidentes com o Claude Opus 5 nomeado entre 26 e 27 de julho de 2026, três deles só na segunda-feira (27/07).
• Status agora: todos resolvidos. O último fechou às 14:34 UTC (11:34 BRT) de 27/07 — 55 minutos depois de abrir, e atingindo também o Haiku 4.5.
• Não é defeito do Opus 5: em 25/07 caíram Fable 5, Mythos 5, Sonnet 5, Sonnet 4.6 e Haiku 4.5 na mesma janela. É a Anthropic sob carga, não um modelo bichado.
• Fonte: status.claude.com/history.rss — o único lugar onde isso está registrado com carimbo de hora.
• O que fazer: retry com backoff, circuit breaker, fallback em cascata e monitoramento próprio. Detalhes abaixo.

Claude Opus 5 fora do ar: a linha do tempo dos 4 incidentes

O Claude Opus 5 foi lançado em 24/07. Menos de 48 horas depois começou a série. Todos os horários abaixo saem direto do feed de incidentes da Anthropic:

Some as três janelas de segunda-feira: 122 minutos de erro elevado numa faixa de 6h18. Um terço da manhã com o modelo degradado.

Vale ler os updates do último incidente, porque eles contam uma história: abriu às 10:39 BRT como "investigating", teve dois updates seguidos ainda investigando, e só às 11:04 BRT a Anthropic acrescentou que "Haiku 4.5 is also returning errors". Ou seja: o escopo do incidente cresceu 25 minutos depois do começo. Se o seu fallback do Opus 5 era o Haiku 4.5, ele caiu junto — e o status page só te contou isso meia hora depois.

O contexto que evita o alarmismo

Se você olhar só os incidentes do Opus 5, a leitura fácil é "modelo novo saiu quebrado". O feed inteiro conta outra coisa.

No sábado, 25/07, teve três incidentes distintos em pouco mais de quatro horas — e nenhum deles era exclusivo do Opus 5. Caiu Sonnet 4.6 e Sonnet 5 juntos (10 minutos, às 15:03 BRT). Caiu Mythos 5, Fable 5, Opus 5 e Haiku 4.5 juntos. Caiu Fable 5, Sonnet 5, Haiku 4.5 "e outros modelos Claude". No dia 24, dia do lançamento do Opus 5, quem teve erro elevado foi o Opus 4.8 — o modelo antigo, estável, que você provavelmente considerava o porto seguro.

Isso muda o diagnóstico por completo. Não é um modelo com bug. É infraestrutura de inferência sob carga de lançamento, com o modelo mais novo (e mais demandado) pegando a maior parte da pancada. É a mesma coisa que acontece em toda janela de lançamento de fronteira, em todo lab.

O que muda pra você é a conclusão de engenharia: se a causa é carga compartilhada, trocar de modelo não é garantia de nada. Seu fallback precisa ser desenhado sabendo disso.

Esse tipo de decisão — apontar produção pro modelo novo agora ou deixar a poeira baixar — é conversa de engenharia, não de changelog. É o que a gente destrincha toda semana, ao vivo, no Clã Beer and Code. É pago, é assinatura, e é exatamente o ambiente que esse post descreve.

O playbook de resiliência

Agora a parte prática. Cinco coisas, em ordem de retorno sobre esforço.

1. Entenda o que cada código de erro está te dizendo

Você não trata 429 e 529 do mesmo jeito, e tratar errado é a diferença entre se recuperar em 3 segundos e piorar o incidente.

A regra prática: retente 429, 500, 529 e erros de conexão. Nunca retente 4xx fora do 429. O SDK oficial já faz isso — ele retenta automaticamente 408, 409, 429 e 5xx com backoff exponencial, com max_retries=2 por padrão. Se você está com retry desligado ou usando HTTP cru, está jogando essa proteção fora.

import anthropic

# O SDK já retenta 429/5xx com backoff. Suba o teto em janela de incidente.
client = anthropic.Anthropic(max_retries=5, timeout=30.0)

# Ou por requisição, sem mutar o client:
resp = client.with_options(max_retries=1).messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "..."}],
)

2. Retry sozinho não resolve incidente de 55 minutos

Backoff exponencial existe pra atravessar um soluço de 3 segundos. Ele não atravessa uma janela de 47 minutos — e se todo mundo do seu cluster ficar retentando durante quase uma hora, você transforma um erro elevado num pico de latência que derruba a sua própria aplicação por esgotamento de thread pool.

Depois de N falhas consecutivas, pare de tentar. Circuit breaker, aberto por alguns minutos, meio-aberto pra sondar. Enquanto o circuito está aberto, você não espera — você cai pro plano B imediatamente. Latência previsível de degradação vale mais que retry heróico.

3. Cascata de fallback — e o detalhe que quase ninguém sabe

O caminho óbvio é cair pro modelo anterior. Com IDs oficiais da família Claude 5:

claude-opus-5  →  claude-opus-4-8  →  claude-sonnet-5

Três avisos importantes aqui.

Primeiro: o parâmetro fallbacks da API da Anthropic não serve pra isso. Ele existe pra recusa de política (stop_reason: "refusal"), e a documentação é explícita: rate limits, sobrecarga e erros de servidor no modelo pedido são devolvidos como estão, sem nunca acionar o fallback. Se você configurou fallbacks achando que estava coberto contra 529, você não está. Fallback por indisponibilidade é código seu.

Segundo: trocar de modelo invalida o prompt cache. Cache é por modelo. A primeira requisição no modelo de fallback paga escrita de cache cheia. Numa janela de incidente com volume alto, isso é um pico de custo real, não teórico.

Terceiro, e o mais contraintuitivo: o Claude Opus 5 tem bucket de rate limit separado do pool combinado do Opus 4.x. Cair do Opus 5 pro Opus 4.8 não herda a sua folga — você entra num limite que talvez esteja dimensionado pra tráfego residual. Confira os limites do seu tier antes de assumir que a cascata aguenta o redirecionamento inteiro.

E lembre do incidente de segunda: Opus 5 e Haiku 4.5 caíram na mesma janela. Cascata entre modelos do mesmo provedor tem correlação de falha. Se a sua tolerância a indisponibilidade for real, o último degrau da cascata tem que ser outra coisa: resposta em cache, modo degradado, ou fila assíncrona.

4. Nem tudo precisa responder agora

Boa parte do que a gente chama de "agente em produção" não é síncrono de verdade. Classificação, enriquecimento, resumo, extração — isso pode ir pra fila com dead-letter e reprocessar quando o incidente fechar.

Fila com retry assíncrono transforma um incidente de 55 minutos em atraso de 55 minutos, não em erro pro usuário. É a diferença entre um gráfico feio e um ticket de suporte. Se o seu agente devolve 500 pro cliente porque o modelo estava sobrecarregado numa tarefa que ninguém estava esperando em tempo real, o problema é de arquitetura, não da Anthropic.

5. Monitore você mesmo — o status page chega depois

O último incidente abriu às 10:39 BRT e só reconheceu o Haiku 4.5 às 11:04. Vinte e cinco minutos em que quem dependia do Haiku estava quebrado sem confirmação oficial.

Seu alerta tem que ser a sua própria taxa de erro por modelo, não o status page. Instrumente stop_reason, código HTTP e latência com o ID do modelo como dimensão, e alerte em cima disso. O feed oficial vira confirmação e comunicação — não detecção.

Dito isso, assine o feed. É RSS, é público, e é barato:

curl -s https://status.claude.com/history.rss

Um cron de 5 minutos comparando o <pubDate> do primeiro item com o último visto já te dá aviso no Slack antes de alguém abrir chamado.

O que isso significa pra decisão de produção

Não é "não use o Opus 5". O modelo é bom, é o mesmo preço do Opus 4.8 ($5/$25 por milhão de tokens) e a janela em que todo modelo novo fica instável passa — foi assim com todo lançamento de fronteira até hoje. Se você quer o contexto completo do lançamento, com benchmarks e migração, está no post do Claude Opus 5.

É "não aponte produção pro modelo novo sem o playbook acima". A diferença entre um time que sentiu essas cinco janelas de erro e um que não sentiu não é sorte: é retry configurado, circuit breaker, fila pro que é assíncrono e observabilidade por modelo.

Early adopter sem resiliência não é vanguarda. É aposta.

FAQ rápido

Ainda tem incidente aberto agora? Não. O último foi resolvido às 14:34 UTC (11:34 BRT) de 27/07/2026, segundo o status oficial. Este post foi publicado depois disso — se algo novo abrir, o feed é a fonte.

"Elevated errors" quer dizer que o modelo estava fora do ar? Não necessariamente 100% fora. Significa taxa de erro acima da linha de base — parte das requisições volta 529/500, parte passa normal. Por isso retry funciona parcialmente e por isso a sua métrica de erro é mais útil que o status page.

O fallbacks da API cobre sobrecarga? Não. Ele só dispara em recusa de política. Sobrecarga, rate limit e erro de servidor são devolvidos direto. Fallback por indisponibilidade você implementa.

Vale voltar pro Opus 4.8 até estabilizar? Depende da sua tolerância. O Opus 4.8 também teve erro elevado em 24/07, e o bucket de rate limit é separado. Se a sua aplicação aguenta 50 minutos de degradação por dia, fique. Se não aguenta, o problema não é a escolha do modelo — é a falta de fallback.

Quais os IDs corretos dos modelos pra cascata? claude-opus-5, claude-opus-4-8, claude-sonnet-5 e claude-haiku-4-5. Sem sufixo de data. Para escolher o degrau seguinte com critério, o comparativo Fable 5 vs Opus 4.8 ajuda a calibrar custo e capacidade, e o guia de Opus 4.8 em produção tem o resto do checklist de operação.