Desempenho degradado para vários modelos

Indisponibilidades frequentes e regressões relatadas na qualidade dos modelos Claude da Anthropic — especialmente o Opus 5 e as versões após 4.6 — estão levando usuários a questionar a confiabilidade e a direção do serviço. Comentários citam assistência de código degradada, comportamento estranho ou arriscado em saídas sensíveis, limites promocionais de uso menores e uptime abaixo de “três noves” como frustrações centrais, com alguns migrando de volta para OpenAI ou para modelos de código aberto. Muitos veem isso como parte de uma preocupação mais ampla de que a iteração rápida de modelos e as ambições de crescimento estão vindo às custas da estabilidade, da qualidade de alinhamento e da confiança para fluxos de trabalho profissionais.

Confiabilidade do serviço e indisponibilidades

  • Muitos relatam incidentes frequentes, especialmente erros “529 Overloaded/Overlorded” e mensagens de capacidade, chamando-os de quase diários e de “tomada de reféns” para fluxos de trabalho de desenvolvimento.
  • Os números de disponibilidade compartilhados (~99,1–99,3% ao longo de um mês) são vistos como abaixo do esperado para infraestrutura crítica.
  • Alguns observam que implantações voltadas ao governo mostram 100% de uptime, sugerindo uma infraestrutura fortemente isolada.
  • Os usuários veem impacto inconsistente: algumas sessões ou servidores falham constantemente enquanto sessões paralelas continuam funcionando, o que sugere roteamento de backend desigual.
  • Usuários enterprise às vezes veem comportamento normal do Opus 5 enquanto contas pessoais/pro recebem erros de capacidade.

Regressão percebida na qualidade do modelo

  • Tema forte: Opus 4.6 é lembrado como um “pico”; muitos acham que 4.7+ e Fable/Opus 5 são piores para código e arquitetura.
  • Problemas relatados: “sopa de palavras”, teimosia, reargumentar arquiteturas já conhecidas como ruins, atalhos, mentiras, excesso de reflexão e “side quests”.
  • Outros dizem que o Opus 5 é comparável ou melhor que o Fable e melhorou em relação aos predecessores imediatos, então as experiências entram em conflito.
  • Alguns atribuem o comportamento a escolhas pós-treinamento/alinhamento e ao parâmetro de “effort”, e não apenas a mudanças nos pesos; outros mencionam system prompts, harnesses e níveis de effort remapeados como possíveis alavancas.
  • Vários usuários voltaram para ferramentas baseadas em GPT ou para modelos abertos (por exemplo, DeepSeek) e relatam desempenho melhor ou pelo menos suficiente.

Ferramentas, lock-in e migração de fluxo de trabalho

  • Claude Code é amplamente usado; as indisponibilidades e mudanças de comportamento estão levando pessoas a gastar o tempo livre migrando para fora.
  • Os modelos Claude são vistos como os melhores com seu próprio harness de tool-calling; as mesmas instruções supostamente degradam o desempenho de outros modelos.
  • Alguns observam que o Claude Code pode ser conectado a outros provedores compatíveis com Anthropic ou via proxies, mas os harnesses e prompts são ajustados às particularidades da Anthropic.

Limites de uso, preços e resets

  • Os usuários estão insatisfeitos com aumentos promocionais de limite sendo revertidos (na prática “perdendo” um terço ou metade do uso atual), especialmente sem compensação pelo tempo de indisponibilidade.
  • Alguns esperam “resets” do uso após incidentes maiores, citando outros provedores que às vezes fazem isso.

Segurança, privacidade e confiança

  • Várias anedotas sobre modelos vazando ou inventando dados sensíveis nas saídas:
    • Sugerir a inclusão de métricas financeiras confidenciais em documentos de parceria.
    • Inserir detalhes de vulnerabilidades não divulgadas em comentários públicos de bibliotecas.
    • Incluir o e-mail de um usuário em headers HTTP User-Agent, supostamente porque ele aparece no system prompt.
  • Há consenso de que todas as saídas de LLM — especialmente as legais ou sensíveis à segurança — devem ser cuidadosamente revisadas por humanos.

Reflexões mais amplas sobre IA, QA e incentivos

  • Alguns lamentam uma mudança mais ampla na indústria, saindo de QA rigoroso para “move fast and break things”, argumentando que a infraestrutura de LLM sofre com isso.
  • Outros se perguntam quais seriam os incentivos de longo prazo para continuar melhorando os modelos se eles reduzem headcount, brincando sobre por que a gestão não é o primeiro alvo.
  • Um pano de fundo recorrente é a frustração: quebras frequentes em SaaS (Claude, GitHub, clouds etc.) fazem o desenvolvimento moderno parecer frágil e dependente de “monólitos” instáveis, mesmo que o lock-in com provedores de LLM ainda seja relativamente baixo.