Problema no plano Claude Code Pro Max 5x: cota se esgota em 1,5 hora mesmo com uso moderado

• No plano Pro Max 5x (contexto de 1M), mesmo apenas com um nível moderado de perguntas e respostas e trabalho de desenvolvimento, ocorre estouro do limite de tokens em 1,5 hora
• Aponta-se como causa um erro em que os tokens de cache_read são contabilizados pela proporção total (1.0x), eliminando o efeito do cache e provocando consumo acelerado
• Chamadas automáticas de sessões em segundo plano, compactação automática (auto-compact) e entrada de contexto grande elevam em conjunto a velocidade de consumo
• A comunidade analisa como causas centrais o encurtamento do TTL do cache (1 hora→5 minutos) e o fenômeno de invalidação de cache (cache busting)
• A Anthropic está trabalhando em redução do contexto padrão (400k), melhorias de UX e otimização de chamadas inativas, além de coletar feedback dos usuários

---

Problema de esgotamento rápido da cota no plano Pro Max 5x

• Foi relatado no plano Pro Max 5x (claude-opus-4-6, contexto de 1M) um fenômeno em que a cota se esgota em 1,5 hora mesmo com perguntas e respostas em nível intermediário e desenvolvimento leve
  • Em 5 horas anteriores de desenvolvimento intenso, o consumo foi normal, mas após a redefinição ocorreu consumo acelerado
  • O ambiente era Claude Code CLI no WSL2, em uma única sessão (com 2 compactações automáticas)
• O principal suspeito é um erro em que os tokens cache_read são calculados pela proporção total (1.0x)
  • Em condições normais, cache_read deveria ser calculado na proporção de 1/10; caso contrário, o efeito do cache desaparece
  • O uso de tokens foi analisado por meio do objeto usage nos logs da sessão (~/.claude/projects/.../*.jsonl)
• Chamadas automáticas de sessões em segundo plano, processamento caro da compactação automática (auto-compact) e entradas grandes na janela de contexto de 1M atuam em conjunto para acelerar o consumo
• Segundo a análise da comunidade, alguns usuários apontam como causa principal o encurtamento do TTL do cache (1 hora→5 minutos) e a invalidação de cache (cache busting)
• A equipe da Anthropic está trabalhando em redução do contexto padrão (400k), melhorias de UX e otimização de chamadas inativas, e pediu mais dados por meio do feedback dos usuários

Consumo de tokens medido

• Janela 1 (15:00–20:00, 5 horas, desenvolvimento intenso)

  • 2.715 chamadas de API, Cache read 1.044M, Cache create 16.8M, saída de 1.15M tokens
  • Entrada efetiva (com proporção de 1/10 aplicada): 121.8M tokens
  • Foi realizado servidor Express + app iOS, pipeline graphify e coordenação multiagente baseada em SPEC

• Janela 2 (20:00–21:30, 1,5 hora, uso moderado)

  • Sessão principal (vibehq): 222 chamadas de API, Cache read 23.2M, Cache create 1.4M, saída 91k
  • Sessões em segundo plano (incluindo token-analysis e career-ops): total de 691 chamadas, Cache read 103.9M, saída 387k
  • Total de 13.1M tokens efetivos (com proporção de 1/10 aplicada) → em condições normais, não haveria estouro da cota
  • Na prática, foram 105.7M tokens (com cálculo 1.0x) → cerca de 70.5M por hora, compatível com o esgotamento da cota

Resumo dos principais problemas

• 1. Erro no cálculo do limite de cobrança dos tokens de cache read

  • Esperado: cache_read calculado na proporção de 1/10
  • Real: calculado na proporção total, anulando o efeito do cache
  • Em um ambiente com contexto de 1M, são enviados de 100~960k tokens por chamada, o que pode esgotar a cota em minutos após mais de 200 chamadas

• 2. Consumo da cota compartilhada por sessões em segundo plano

  • Sessões inativas (como token-analysis e career-ops) também continuam consumindo a cota compartilhada por chamadas automáticas de compactação e pós-processamento

• 3. Chamadas caras da compactação automática (auto-compact)

  • Antes da compactação, todo o contexto (~966k tokens) é enviado como cache_creation, fazendo com que a chamada mais cara ocorra automaticamente

• 4. Efeitos colaterais da janela de contexto de 1M

  • O contexto grande aumenta drasticamente o número de tokens por chamada, acelerando a velocidade de consumo da cota

Etapas de reprodução

1. Executar o Claude Code com o modelo Opus no plano Pro Max 5x
2. Incluir cerca de 30 arquivos de regras em ~/.claude/rules/ (sobrecarga de 19k tokens)
3. Realizar tarefas centradas em ferramentas, como leitura de arquivos, build e testes
4. Confirmar o aumento do contexto com o comando /context
5. Verificar a queda brusca da cota após 200~300 chamadas
6. Manter de 2 a 3 sessões em outro terminal
7. Confirmar que a cota volta a se esgotar em pouco tempo mesmo após a redefinição

Comparação entre comportamento esperado e comportamento real

• Esperado:

  • cache_read calculado na proporção de 1/10
  • Sessões inativas com consumo mínimo
  • A compactação automática não provoca consumo excessivo
  • Com uso moderado, a sessão pode durar de 2 a 3 horas

• Real:

  • Esgotamento em 1,5 hora
  • Sessões em segundo plano respondem por 78% do consumo
  • Supõe-se que cache_read esteja sendo calculado na proporção total devido ao envio de 105.7M tokens no total

Sugestões de melhoria

1. Esclarecer o método de cálculo de cache_read — explicitar na documentação a proporção real usada para calcular o limite de cobrança
2. Limite com base em tokens efetivos — ajustar para que cache_read seja calculado na proporção de 1/10
3. Detecção de sessão ociosa — impedir chamadas automáticas de sessões inativas ou exibir aviso
4. Visualização em tempo real do consumo de tokens — mostrar o uso de cache_read, cache_create, entrada e saída
5. Previsão de custo com base no contexto — exibir o custo estimado em tokens antes da tarefa

Análise e discussão da comunidade

• cnighswonger

  • Coletou dados de 1.500 chamadas ao longo de 24 horas com o interceptador claude-code-cache-fix
  • Ao validar três hipóteses (cache_read 0.0x, 0.1x, 1.0x), apenas o modelo 0.0x apresentou resultado consistente na janela de 5 horas (CV 34.4%)
  • Conclusão: cache_read praticamente não afeta a cota na prática, e o cache está funcionando normalmente
  • Ainda assim, é necessária validação adicional, pois os dados são de uma única conta

• henu-wang

  • Após uma regressão que reduziu o TTL do cache de 1 hora para 5 minutos, sempre que a sessão era pausada ocorria cache_create, gerando custo 12,5 vezes maior
  • Quanto mais longo o contexto, mais o custo aumenta de forma não linear
  • Como solução temporária, sugeriu manter sessões curtas, usar ativamente o comando /compact e pré-carregar o contexto essencial em CLAUDE.md

• bcherny (equipe Anthropic)

  • Reconheceu que, ao usar a janela de contexto de 1M, falhas no cache de prompt têm alto custo
  • Está testando melhorias de UX (induzir /clear ao retomar sessões longas) e uma medida para reduzir o contexto padrão para 400k
  • Também identificou casos em que tarefas inativas consomem tokens em excesso ao usar multiagentes e plugins, e está avançando em limpeza automática e melhorias no agendamento

• wadabum

  • Apontou um bug em que novas sessões não acertam o cache de forma alguma (#47098, #47107)
  • O prompt de sistema baseado em git status e os blocos CLAUDE.md mudam a cada sessão, causando invalidação de cache (cache busting)
  • cnighswonger respondeu que o interceptador faz alguma estabilização da ordenação, mas o problema de git-status exige correção separada

Resumo das sugestões da comunidade

• RockyMM: quando a sessão atingir o limite, induzir retomada após resumo automático e reduzir o TTL para 10 minutos
• mikebutash: relatou que no plano Pro só era possível fazer 2 prompts a cada 5 horas e confirmou melhora de 3 a 4 vezes ao fazer rollback para a versão v2.1.81 e instalar o cache-fix
• wutlu: mitigou o problema reinicializando a sessão por tarefa
• dprkh: ajudou na identificação da causa ao compartilhar habilidades do modo de depuração (Skill.md)

Conclusão

• O problema de esgotamento rápido da cota no plano Pro Max 5x foi confirmado como resultado do efeito combinado de comportamento do cache, regressão de TTL, expansão do contexto e chamadas em segundo plano
• A comunidade avalia que, mais do que um erro no cálculo de cache_read, as causas centrais são a invalidação de cache e o encurtamento do TTL
• A equipe da Anthropic está trabalhando em reduzir o contexto padrão, melhorar a UX do cache e otimizar chamadas inativas, e pediu mais dados por meio do feedback dos usuários (/feedback)

[kimjoin2]

Em termos de qualidade, não há nem o que substitua isso
Tomara que, com um patch simples, dê para usar mais.

[GN⁺]

Comentários do Hacker News

• Aqui é o Boris, da equipe do Claude Code. Após investigar os problemas relatados recentemente, concluímos que há duas causas principais

  1. Ao usar a janela de contexto de 1M tokens, falhas no cache de prompt saem caras. No momento, o TTL do cache é de 1 hora, então, se você ficar ausente por mais de uma hora, a sessão expira e todo o cache precisa ser recarregado. Já lançamos melhorias de UX para isso e estamos avaliando reduzir o padrão para 400k. Se quiser testar agora, use o comando CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude
  2. Quando muitos plugins ou agentes rodam ao mesmo tempo, há desperdício de tokens. Para resolver isso, estamos trabalhando em melhorias de UX e também em limpeza e agendamento automáticos de tarefas não principais
     Se você estiver enfrentando esse problema, envie feedback com o comando /feedback, pois isso ajuda no debugging
  • Boris, os relatos de experiência dos usuários que estão aparecendo na comunidade não são simples exceções. Como Jeff Bezos disse, há momentos em que as anedotas dizem a verdade, e não os dados. Vocês precisam considerar seriamente a possibilidade de as métricas estarem erradas
  • Eu estava me perguntando por que esse problema surgiu de repente, e ao investigar descobri que a causa foi a redução do TTL do cache de prompt de 1 hora para 5 minutos. Mesmo iniciando uma nova sessão, no fim das contas é preciso reconstruir tudo de novo, então isso é ineficiente. Uma estrutura em que é preciso monitorar a expiração do cache vai contra a filosofia do CC
  • No meu caso, a regressão mais grave foi a parte em que o prompt do sistema tentava fazer varredura de malware nos arquivos toda vez. Isso fazia os tokens serem consumidos rapidamente, e a resposta “not a malware” continuava aparecendo. Esse design foi uma decisão errada. No fim, abandonei o projeto e migrei para o Qwen, que tem sido bem bom
  • O aviso do /clear não é uma solução. Se você limpa o cache, no fim precisa reconstruí-lo de novo, então o custo é o mesmo. Levar o usuário via UX a usar contextos menores é uma piora na qualidade do serviço. Se o problema é custo, então precisam corrigir o preço ou a arquitetura
  • A OpenAI costumava resetar o limite de uso quando havia problemas, mas a Anthropic não toma esse tipo de medida. Isso dá a impressão de que foi intencional

• Ultimamente o Claude estava visivelmente mais lento e ineficiente. Mesmo indicando os arquivos, ele entrava num loop de exploração por mais de 5 minutos e logo atingia o limite da sessão. Usando só três vezes por dia, 25% do limite semanal ia embora. Então migrei para o plano Codex de $100, que é muito melhor em precisão e generosidade. Só acho o jeito de falar do Codex irritante, então adicionei instruções separadas no Agents.md. O senso de UI do antigo Claude Code era melhor, mas para debug de backend e resolução de problemas complexos o Codex leva vantagem. No momento, eu recomendaria comparar o Codex com o plano de $20 do Cursor

  • Tive uma experiência parecida. Há alguns dias o Claude parecia travado, só “pensando”, e no dia seguinte voltou ao normal
  • Estou usando o plano Codex Business (30 euros) e sinto que recentemente a cota diminuiu. Mesmo assim, as condições ainda são bem melhores que no Claude Code
  • No momento estou comparando o comportamento do confidence score dos modelos Opus, Haiku e Sonnet. O Opus é o mais eficiente para tarefas de dificuldade intermediária
  • Já usei CC, Gemini-cli e Codex, e o CC ainda é o melhor. Fico curioso se uma combinação com Cursor ou Aider seria melhor
  • Como coding com IA desperdiça muito contexto, limitar o escopo com um sandbox customizado aumenta a eficiência

• Ao passar pelos issues, entendi por que a Anthropic fecha tickets tão rápido. A maioria parece ser ruído gerado por IA. A solução que encontrei foi a seguinte

  1. Ativar max thinking em todas as sessões para reduzir exploração de caminhos desnecessários
  2. Manter a sessão continuamente ativa. Se o cache expira em 5 minutos, os tokens precisam ser reconstruídos
  3. Executar compact imediatamente após 200k tokens
     O que mais me incomoda é a Anthropic ter forçado o uso do modelo de 1M
  • Eu também ri ao ver o issue. Provavelmente mandaram o Claude Code “investigar por que todos os tokens foram gastos”
  • Tem gente dizendo para ligar o thinking, e outros dizendo para desligar. É irônico que ambos digam que isso economiza tokens
  • O problema central é um bug em que o cache é invalidado aleatoriamente. Parece que o cliente da API encerra cedo demais o cache dos assinantes. Além disso, ainda aumentaram discretamente o custo dos tokens de entrada
  • Eu também confirmei isso. max effort ajuda. O importante é manter o contexto abaixo de 25%. Queria saber se existe alguma forma de verificar o estado de expiração do cache
  • É possível desativar o modelo de 1M com os comandos /model opus ou /model sonnet

• Dá a sensação de que o fim da era dos subsídios está chegando. Na comunidade do Google Gemini também estão explodindo reclamações recentes sobre redução de cota (link do issue). No fim, eu também migrei para a combinação Kiro IDE + Codex CLI e estou satisfeito

  • Essa mudança já era previsível. Na época dos tokens gratuitos, a estratégia inteligente era construir com antecedência as bibliotecas necessárias
  • A Anthropic agora parece estar mudando o foco para clientes corporativos, e a OpenAI segue por um caminho parecido. No Reddit e no Discord há movimentos em busca de modelos abertos ou alternativas chinesas, mas ainda não existe um substituto completo
  • O antigravity consome rapidamente a cota Pro, mas o modo flash é muito mais generoso. Em um projeto com STM32, consegui produtividade 3x maior
  • No fim, talvez esse caminho termine em uma era em que as respostas venham com anúncios
  • Isso me lembra o Uber de $3 de antigamente

• É preocupante que o issue que apontou a causa raiz do problema tenha sido fechado como “Not planned”

  • A resposta parece artificial, como se tivesse sido escrita por IA. A lógica de que “TTL de 1 hora é mais caro” também soa estranha. Dizer que não fornecem um toggle por custo é difícil de aceitar
  • Não precisa ter tanto medo. Se a qualidade piorar, é só parar de usar
  • Vejo a Anthropic como uma empresa que vende tokens como um cassino, sem se importar se o usuário perde dinheiro. Se você não gosta desse modelo, acho melhor usar um LLM local

• Fiz rollback para a versão 2.1.34 e a maior parte dos problemas de cota e cache foi resolvida.
  Adicionei "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1 etc. em ~/.claude/settings.json, e removi as outras versões.
  O adaptive thinking ainda está incompleto, mas talvez ajude quando melhorar no futuro. Mesmo assim, estou pensando em migrar para o Codex

  • Eu também defini CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1 etc. no ~/.bashrc

• Também houve problemas parecidos nos modelos inferiores. Acho que uma relação justa começa com medição transparente. Vou cancelar a assinatura deste mês

  • Houve casos em que a sessão era iniciada enquanto o computador estava em modo de suspensão, consumindo tokens. Até perguntas simples como “que horas são?” chegaram a gastar 10%

• Este ano experimentei fazer a declaração de impostos com agentes de IA. Usei Opus 4.6, Codex 5.4 e Antigravity 3.1, cada um no plano de $20.
  O Codex concluiu tudo perfeitamente em 12 minutos, o Antigravity deixou uma página passar mas foi corrigido rapidamente. Já o Claude Code parou por exceder o limite de uso, e mesmo após tentar de novo ainda houve erros. Ficou abaixo das expectativas

  • Também fiz um experimento parecido, mas no meu caso o Claude foi tão preciso quanto um contador. É interessante como os resultados variam entre sessões, mesmo na mesma tarefa. A experiência de suporte ao cliente na era do software não determinístico é realmente estranha

• Depois do anúncio de atualização no Reddit, o Claude mudou a ponto de ficar inutilizável para programação do dia a dia. Os créditos da conta Pro acabaram em uma hora, então voltei para Gemini ou ChatGPT

• No fim das contas, a estrutura de cobrança por tokens da Anthropic parece ter sido desenhada de forma desfavorável para usuários comuns. Na prática, ao usar, dá para sentir imediatamente quanto dinheiro eles queriam tirar disso