Olá a todos.
Conhecem (e se não conhecem já deviam conhecer) a minha maneira de pensar: Se é critico, então tem redundância. Até em produtos consumidos SaaS. Já escrevi sobre isto várias vezes aqui no blog, mas hoje o tema ganha uma urgência diferente.
Ontem, dia 13 de Maio de 2026, a Anthropic anunciou que a partir de 15 de Junho de 2026, toda a utilização do Claude Agent SDK e do comando claude -p deixa de contar contra os limites da vossa subscrição. Parece bom, não parece? Leiam outra vez. Devagar.
O que eles estão a dizer, embrulhado num papel de presente com um laço bonito, é o seguinte: aquilo que antes estava incluído no vosso plano, agora está separado e limitado a um crédito mensal fixo, ou se preferirem, pay as you go se passarem o que plano vos dá.
Um crédito que, convenientemente, vale exatamente o mesmo que o preço do plano. O plano Pro de $20 dá-vos… $20 de créditos. O Max 20x de $200 dá-vos… $200. Se gastarem mais, pagam a preços de API. Se não gastarem, os créditos expiram. Não acumulam.
Como muito bem disse um utilizador no Reddit: “A ração de chocolate de 30g foi aumentada para 20g.” Puro 1984 em formato de press release corporativo.
O que muda?
Vamos por partes, porque isto está a gerar muita confusão na comunidade:
Uso interativo (Claude Code no terminal, Claude.ai, Claude Cowork) — continua igual. Os vossos limites de subscrição não mudam. Se só usam o Claude para conversar ou programar interativamente, esta mudança não vos afeta diretamente.
Uso programático (Agent SDK, claude -p, GitHub Actions com Claude Code, apps de terceiros via SDK) — sai completamente do pool da subscrição. Passa a consumir de um crédito mensal separado, que tem de ser reclamado, não acumulam tokens não usados para o mês seguinte, e quando se esgota ou se paga a preços de API ou o uso para.
A razão técnica é interessante e revela muito sobre como estes serviços funcionam nos bastidores. Quando usamos o Claude interativamente, sessão após sessão, o sistema de prompt caching da Anthropic funciona em pleno — o contexto mantém-se “quente” entre turnos, e a maioria dos tokens de input são servidos a cerca de 10% do custo normal. Quando um script ou GitHub Action dispara uma chamada isolada, esse cache está frio. A mesma quantidade de trabalho custa à Anthropic várias vezes mais. O plano de subscrição foi sempre calculado assumindo que a maioria do uso seria interativo e com bom cache hit rate. Os utilizadores que corriam agentes autónomos 24/7 estavam essencialmente a fazer arbitragem de compute — a pagar $20 ou $200 por mês por algo que custava centenas ou milhares à Anthropic.
Percebo o racional económico. E é perfeitamente legítimo.
O que não é legítimo é vender um produto com certas capacidades, construir uma base de utilizadores que depende dessas capacidades, e depois cortar o tapete debaixo dos pés com um mês de aviso. Isto tem nome: bait and switch.
Quem vai sofrer
Já vi, só numa thread do Reddit (que em 12 horas acumulou 658 upvotes e 241 comentários — o que vos diz algo sobre o nível de frustração), o seguinte:
Um utilizador que cancelou dois planos Max (dois!) porque 100% do seu uso era via claude -p com ferramentas próprias. Outro que tinha literalmente um script a correr claude -p há semanas num loop até os testes passarem — uma espécie de brute force de qualidade que, admito, é criativo mas obviamente insustentável do ponto de vista do fornecedor. Developers que construíram pipelines de CI/CD inteiros à volta do Agent SDK, com gates de AI que decidiam se um PR passava ou não, se o merge era feito automaticamente, se se enviava notificação. Empresas que integraram o SDK nas suas ferramentas internas para code review automático, para sandboxed sessions, para triage de tickets de suporte via Sentry.
Há quem faça 90% da sua programação a partir do telemóvel, com wrappers à volta do Claude via Telegram ou Discord. Tudo isto são instâncias spawned de claude -p que agora vão cair debaixo do cap de créditos.
Tudo isto vai de funcional a limitado-por-créditos no dia 15 de Junho. E notem: a Anthropic não está a devolver nada. Está a tirar algo que já existia e a reempacotá-lo como se fosse uma oferta. Quando lemos “eligible users can claim a separate monthly credit”, a palavra operativa não é “credit” — é “claim”. Têm que ir ativamente reclamar algo que antes era automático.
A mensagem implícita das “condições” do crédito é ainda mais preocupante: “Subject to terms that will be posted when the claim flow opens. The credit has no cash value, does not roll over, is non-transferable, and — along with eligible plans, amounts, and usage — may be modified or discontinued.” Ou seja, os $200 de hoje podem ser $50 amanhã. Ou zero.
Se isto não é uma red flag para quem constrói produtos em cima deste ecossistema, não sei o que é.
O padrão que mais uma vez se repete e que se escolhe convenientemente não prestar atenção
Isto não é um caso isolado. É um padrão. E se trabalham em IT há mais de cinco anos, já deviam ter visto o filme — só muda o protagonista. Looking at you Google….
Em Abril de 2026, a Anthropic bloqueou ferramentas como o OpenClaw de usar a autenticação de subscrição — com um dia de aviso. Literalmente um dia. Ferramentas que tinham sido construídas legitimamente em cima de uma API que a Anthropic disponibilizava. Agora, em Maio, reabrem o acesso mas com um cap rígido de créditos. Um utilizador acumulou $200.98 em taxas de API inesperadas por causa de um bug na deteção de uso programático — uma string “HERMES.md” num commit de git foi suficiente para o sistema de billing os classificar como uso de terceiros — e a Anthropic inicialmente recusou o reembolso. Só depois do caso viralizar é que devolveram o dinheiro.
Reparem no padrão: funcionalidade gratuita ou incluída → adopção massiva → restrição → nova funcionalidade paga que substitui parcialmente a anterior. É o playbook de todas as plataformas SaaS que já vimos nascer e morrer nesta indústria.
Todos os fornecedores de AI em cloud estão a fazer o mesmo caminho. Os preços subsidiados existem para captar mercado. Quando a base de utilizadores está suficientemente dependente, os preços sobem. É o playbook clássico de lock-in de plataforma. A única diferença é que com AI os custos de compute são tão brutais que a janela de preços subsidiados é muito mais curta do que foi com o cloud computing tradicional. Quem se lembra dos preços iniciais da AWS? Do Heroku gratuito? Do tier free generoso do Firebase? Tudo acabou da mesma maneira.
E para quem está na Europa, há uma camada adicional de preocupação. Estamos a construir dependência crítica de infraestrutura americana de AI para os nossos workflows de desenvolvimento, para os nossos processos de negócio, para os nossos produtos. Quando esta empresa decide mudar os termos — e vai sempre decidir no seu interesse, não no nosso — não temos alternativa europeia de fronteira para onde migrar de um dia para o outro. Já escrevi sobre alternativas europeias aqui no blog, e esta situação reforça tudo o que disse na altura.
A alternativa que ninguém quer ouvir (mas que funciona e muito bem)
Sabem o que não vos faz um bait and switch? O vosso próprio hardware e a vossa própria infraestrutura.
Já aqui falei extensivamente sobre modelos on-premise, sobre o LiteLLM como proxy unificado, sobre o Awesome Local AI, sobre como correr LLMs no nosso datacenter on-prem. E tenho reparado que cada vez que escrevo sobre o tema, alguém nos comentários diz “sim, mas a qualidade dos modelos locais não é a mesma.” Têm razão. Hoje. Mas vejam bem:
Os modelos open-weight estão a melhorar a um ritmo absurdo. O Llama, o Mistral, o Qwen, o DeepSeek — estão cada vez mais próximos dos modelos de fronteira para a esmagadora maioria dos casos de uso empresariais. E mais importante: são vossos. Correm no vosso hardware, com os vossos dados, sem um fornecedor a decidir de um dia para o outro que a vossa pipeline de CI/CD já não está incluída no que pagaram. Ninguém vos vai mandar um email a dizer que o vosso modelo local “já não conta contra os limites” — porque os limites são os vossos, definidos pelo vosso hardware.
Um utilizador meu conhecido resumiu perfeitamente: “Não quero que o meu sustento dependa dos caprichos de uma única empresa.” E depois há o comentário mais prático de todos: alguém que simplesmente fez downgrade para o plano Pro de $20 e abriu uma subscrição de Ollama por $20. Total: $40/mês, com controlo total sobre o uso local. Para quem tem um homelab com uma GPU decente — e hoje encontram-se RTX 3090 em segunda mão a preços muito acessíveis — podem correr modelos de 7B a 70B parâmetros localmente, sem pagar um cêntimo por token.
E não é só para homelabs. Já vi empresas a montarem clusters de inferência com hardware recondicionado a uma fração do custo de um ano de subscrições Max para toda a equipa de desenvolvimento. O investimento inicial é maior, sim. Mas a partir do segundo ou terceiro mês, já estão a poupar. E a partir do sexto mês, estão a rir-se.
Para empresas, a conta é ainda mais clara:
- Custo previsível. Hardware é um CAPEX que se amortiza. Não têm surpresas na fatura. Não precisam de rezar para que o fornecedor não mude os termos de serviço no próximo trimestre.
- Privacidade e compliance. Os vossos dados nunca saem do vosso perímetro. Para quem trabalha com dados sensíveis, regulados, ou sob GDPR, isto não é um nice to have — é um requisito.
- Sem limites artificiais. Não há créditos mensais, não há throttling em horas de pico, não há um algoritmo a decidir que vocês estão a usar “demasiado”.
- Redundância. Podem ter um proxy como o LiteLLM a balancear entre modelos locais e múltiplos fornecedores cloud. Se um falha ou muda as regras, o tráfego redireciona automaticamente.
O que devem fazer agora
Se estão a usar o Claude Agent SDK ou claude -p em produção, têm um mês. Usem-no bem.
Primeiro, façam a conta. Quanto é que gastam realmente em tokens programáticos por mês? Os $20-$200 de crédito chegam? Se a resposta é “nem perto”, vocês estavam na arbitragem de compute e o novo pricing vai doer.
Segundo, avaliem alternativas. O Claude Code interativo continua igual — se podem reformular os vossos workflows para serem interativos em vez de programáticos, façam-no. Mas se isso não é possível, olhem para o API direto (com os vossos próprios API keys e controlo de custos) ou para modelos on-premise.
Terceiro, e mais importante: construam para a portabilidade. Usem o LiteLLM ou um proxy semelhante para abstrair o fornecedor. Façam com que o vosso código funcione com qualquer LLM, não apenas com o Claude. Porque se há uma coisa que este episódio ensina, é que os termos de serviço de qualquer fornecedor SaaS podem mudar de um dia para o outro. Já escrevi um post detalhado sobre como configurar o LiteLLM com Docker para fazer exatamente isto — se ainda não leram, agora é a altura.
Quarto, considerem a abordagem híbrida. Não tem de ser tudo ou nada. Podem manter uma subscrição cloud para os casos onde realmente precisam do modelo de fronteira, e usar modelos locais para as tarefas rotineiras — code review, testes, documentação, triage. Com um proxy bem configurado, o vosso código nem precisa de saber qual é o modelo que está a servir cada request. O routing pode ser automático com base em complexidade, custo, ou simplesmente em disponibilidade.
Conclusão
Não digo isto com prazer. O Claude é, na minha opinião, um dos melhores modelos disponíveis. A Anthropic faz trabalho excelente em safety e em qualidade de resposta. Mas são uma empresa. E como empresa, vão sempre priorizar a sustentabilidade financeira sobre as expectativas dos utilizadores.
O erro não é da Anthropic por mudar os preços — é vosso se construíram toda a vossa infraestrutura em cima de preços subsidiados sem um plano B. Se é crítico, então tem redundância. Ponto.
A era dos tokens subsidiados está a acabar. Quem se preparou, adapta-se. Quem não se preparou, vai aprender da maneira difícil — como sempre.
Espero que tenham gostado do post de hoje. Como sempre, se acharem algo fora do sítio, ou que denote reparo, já sabem onde me encontrar.
Um abraço.
Nuno