Olá a todos!
Nota do autor: uso o Claude. Uso o Claude Code. Já escrevi aqui no blog sobre a Anthropic mais vezes do que provavelmente deveria, e continuo a achar que fazem modelos excelentes. Mas ontem, dia 23 de abril de 2026, a Anthropic publicou um postmortem técnico que, na minha opinião, deveria ser leitura obrigatória para qualquer CTO, arquiteto de soluções, ou engenheiro que tenha modelos de IA em produção. Não pelo que revela sobre a Anthropic em particular — mas pelo que demonstra sobre o risco estrutural de depender de modelos que não controlas.
Vamos a isto.
O que aconteceu, para quem não leu
A Anthropic confirmou que durante quase dois meses — de início de março até 20 de abril — o Claude Code sofreu degradação real de qualidade. Não foi imaginação dos utilizadores. Não foi “variação normal.” Foram três problemas distintos, todos introduzidos pela Anthropic, todos no lado do produto e não no modelo em si.
Primeiro: a 4 de março, mudaram o nível de esforço de raciocínio por defeito de high para medium. A justificação era reduzir latência — o modelo por vezes pensava tanto tempo que a interface parecia congelada. O efeito real foi que o modelo ficou visivelmente menos inteligente para tarefas complexas. Reverteram a 7 de abril, mais de um mês depois.
Segundo: a 26 de março, uma otimização de cache que deveria limpar o histórico de raciocínio apenas uma vez — quando uma sessão estava inativa há mais de uma hora — tinha um bug. Em vez de limpar uma vez, limpava em todos os turnos subsequentes. O Claude perdia a memória do que tinha feito e porquê, tornava-se repetitivo, esquecido, e tomava decisões estranhas. Corrigiram a 10 de abril.
Terceiro: a 16 de abril, adicionaram uma instrução no system prompt para reduzir verbosidade — limitar respostas entre tool calls a 25 palavras e respostas finais a 100 palavras. A combinação com outras alterações de prompt causou uma queda de 3% em qualidade de código nos próprios benchmarks da Anthropic. Reverteram a 20 de abril.
Três mudanças. Nenhuma delas no modelo propriamente dito. Todas na camada de produto — o harness, o scaffolding, a orquestração que envolve o modelo. E os utilizadores sentiram-nas durante semanas antes de a Anthropic as reconhecer.
O elefante na sala: dumbing down silencioso
Há uma palavra que circula nos fóruns e nos threads do GitHub desde março e que merece ser dita sem rodeios: dumbing down. Os utilizadores sentiram que o modelo ficou mais burro. Disseram-no repetidamente. A Anthropic inicialmente respondeu que o modelo estava igual, que o API não tinha sido afectado, que era uma questão de UI.
Tinham razão técnica — o modelo em si não mudou. Mas tinham razão prática? Não. O que o utilizador recebe não é o modelo. É o modelo mais o prompt de sistema, mais a configuração de esforço, mais a gestão de contexto, mais o cache, mais as dezenas de decisões de produto que envolvem cada chamada à API. E quando a Anthropic decide silenciosamente que “medium effort” é bom o suficiente para ti, ou que 25 palavras entre tool calls é aceitável, ou quando um bug limpa o raciocínio anterior sem te dizer — o efeito prático é indistinguível de um modelo que ficou mais burro.
E aqui está o ponto que me interessa particularmente: tu não tens controlo sobre nenhuma destas decisões. Zero. O modelo corre nos servidores da Anthropic. O system prompt é decidido pela Anthropic. O nível de esforço por defeito é decidido pela Anthropic. A gestão de contexto e cache é decidida pela Anthropic. E quando algo corre mal — como correu durante dois meses — tu ficas à espera que eles acreditem nos teus relatórios e decidam investigar.
Os utilizadores tiveram de gritar durante semanas no GitHub e no X antes de a equipa confirmar o problema. E mesmo no postmortem, a Anthropic admite que as suas próprias avaliações internas não reproduziram os problemas que os utilizadores estavam a reportar. As políticas internas de privacidade da Anthropic limitaram o acesso dos engenheiros às interações problemáticas. Os benchmarks falharam em captar a degradação.
Isto não é uma crítica à competência técnica da Anthropic. É uma observação sobre a estrutura: quando dependes integralmente de um fornecedor SaaS para o cérebro do teu produto, estás vulnerável a este tipo de degradação silenciosa, e a tua única ferramenta de diagnóstico é gritar para o vazio até alguém te ouvir.
Open-weight e modelos locais: o argumento que este incidente reforça
Quem segue este blog sabe que não sou fundamentalista de nenhum campo. Uso serviços cloud. Uso modelos proprietários. Também corro modelos locais no meu homelab e em ambientes de produção. A minha posição sempre foi pragmática: usa o que faz sentido para o caso de uso, mas garante que tens controlo sobre o que é crítico.
E este incidente reforça dramaticamente o caso a favor de modelos open-weight e inferência local para cargas de trabalho de produção. Porquê?
Porque o problema não foi o modelo. O modelo da Anthropic não mudou. O que mudou foi tudo à volta dele — a camada que tu, como utilizador, não controlas, não auditas, e sobre a qual não tens sequer visibilidade. Se estivesses a correr um modelo open-weight como o Llama 3, o Mistral, o Qwen, ou o DeepSeek no teu próprio hardware, com o teu próprio system prompt, com a tua própria configuração de esforço e gestão de contexto, nenhum destes três problemas teria acontecido. Não porque os modelos open-weight sejam superiores em capacidade bruta — não são, na maioria dos cenários. Mas porque a camada de produto é tua. O system prompt é teu. A decisão de usar high ou medium effort é tua. O código de gestão de cache é teu. E quando algo parte, tu sabes exactamente onde foi e podes corrigir na hora.
Previsibilidade. Quando corres o mesmo modelo, com os mesmos pesos, com o mesmo prompt, no mesmo hardware, obtens resultados consistentes. Não acordas uma manhã a descobrir que alguém em São Francisco decidiu que 25 palavras entre tool calls era suficiente para o teu caso de uso. Não descobres duas semanas depois que o teu agente está a perder contexto porque alguém partiu a lógica de cache sem querer. A previsibilidade é um requisito de engenharia, não um luxo.
Auditabilidade. Quando tens os pesos do modelo, o código de inferência, o system prompt, e toda a stack de orquestração sob o teu controlo, podes auditar tudo. Podes correr os teus próprios benchmarks, adaptar as tuas próprias avaliações ao teu caso de uso específico, e detectar regressões antes de os teus utilizadores as sentirem. A Anthropic admite no postmortem que os seus benchmarks não captaram o problema. Sabes porque não captaram? Porque foram desenhados para o caso geral, não para o teu caso específico. Se o modelo fosse teu, os benchmarks também seriam.
Independência de fornecedor. Este é o argumento mais fundamental e o que menos se discute. Quando tens toda a tua pipeline de IA dependente de um único fornecedor de API — seja a Anthropic, a OpenAI, ou a Google — estás a aceitar um risco de concentração brutal. Não é só o risco de degradação silenciosa. É o risco de alterações de preço. De mudanças nas políticas de uso. De rate limiting agressivo. De decisões comerciais que não têm nada a ver contigo mas que te afectam directamente. Já escrevi aqui sobre a importância da redundância: se é crítico, tem de ter fallback. E se a IA é crítica para o teu negócio, a pergunta é simples — qual é o teu fallback quando o teu fornecedor de API decide silenciosamente tornar o modelo mais burro?
Mas modelos locais não são tão bons — é isso que vais dizer?
Vou dizer exactamente o contrário do que muita gente espera. Para a esmagadora maioria dos casos de uso em produção — e refiro-me a tarefas como classificação de texto, extracção de entidades, sumarização, triagem de tickets, análise de sentimento, geração de respostas em chatbots internos, assistência a código em pipelines CI/CD — modelos open-weight de 7B a 70B parâmetros são mais do que suficientes. Já escrevi aqui sobre o LiteLLM e como o utilizo para balancear carga entre modelos locais e APIs externas. A arquitectura que defendo é exactamente esta: modelos locais como base de produção, APIs externas como fallback ou para tarefas que genuinamente requerem capacidade de fronteira.
E aqui está o dado que mais me impressiona nos últimos meses: a diferença de qualidade entre modelos open-weight e modelos proprietários tem vindo a diminuir a uma velocidade que ninguém previa. O que o Llama 3 70B faz hoje, o GPT-4 não fazia há dois anos. O que o Qwen 2.5 72B faz em tarefas de código, compete directamente com modelos comerciais que custam ordens de magnitude mais. A fronteira está a democratizar-se, quer os grandes labs queiram quer não.
O que isto significa na prática para a tua empresa
Se tens modelos de IA em produção — ou se estás a planear colocá-los — este postmortem da Anthropic deveria alterar o teu cálculo de risco. Não estou a dizer para cancelares a tua subscrição do Claude. Estou a dizer para deixares de tratar um fornecedor de API como infraestrutura fiável sem plano B.
Concretamente, o que eu recomendo — e o que faço nos ambientes que opero:
Corre modelos open-weight localmente para tudo o que é crítico e previsível. Para tarefas repetitivas, de volume, onde a consistência importa mais do que a capacidade bruta de raciocínio, um modelo local é simplesmente mais fiável. Não porque seja mais inteligente — mas porque é mais teu.
Usa APIs externas para tarefas que genuinamente requerem capacidade de fronteira — raciocínio complexo multi-step, análise de documentos enormes, tarefas criativas de alta complexidade. Mas trata-as como o que são: um serviço externo, com SLA implícito, sujeito a degradação sem aviso.
Implementa fallback real entre fornecedores. O LiteLLM, que já cobri num post anterior, permite exactamente isto: um proxy que distribui carga entre modelos locais e APIs externas, com failover automático. Se a API da Anthropic decide amanhã que “medium effort” é o suficiente, o teu sistema redireciona para o teu modelo local e continua a funcionar.
Monitoriza a qualidade dos outputs da tua IA com os teus próprios benchmarks. Não confies nos benchmarks do fornecedor. A Anthropic tinha benchmarks. Não apanharam o problema. Constrói avaliações adaptadas ao teu caso de uso e corre-as continuamente. Se a qualidade cair, queres saber antes dos teus utilizadores.
A lição de futuro
O postmortem da Anthropic é, paradoxalmente, um dos documentos mais honestos que já vi sair de um grande lab de IA. Descreveram o que partiram, quando partiram, e o que vão mudar. E isso merece respeito. Mas a honestidade do postmortem não elimina o problema fundamental: durante dois meses, utilizadores pagantes receberam um produto degradado, os seus relatórios foram inicialmente tratados como ruído, e a resolução demorou semanas.
Se a IA é crítica para o teu negócio — e em 2026, para muitas empresas já é — não podes depender da boa vontade de um fornecedor para garantir que o teu produto funciona. Os modelos open-weight não são perfeitos. A inferência local tem custos de hardware e operação. Mas dão-te algo que nenhuma API te dá: controlo. Sobre o modelo. Sobre a configuração. Sobre a qualidade. Sobre o destino do teu produto.
E como já sabem, a minha filosofia não muda: se é crítico, tem redundância. Até em IA.
Espero que tenham gostado do post. Como sempre, se acharem alguma coisa fora do sítio, ou que denote reparo, já sabem onde me encontrar.
Um abraço.
Nuno