Limite do Claude Code caiu 17%: 5 jeitos de recuperar

O limite semanal do Claude Code caiu 17% em meados de setembro de 2026, quando a promoção de verão acabou. Quem está nos maiores planos já relata a semana zerada na quarta-feira. O anúncio da própria Anthropic diz que os limites foram aumentados em 25% de forma permanente, e o post logo em seguida chama a mesma mudança de redução de 17%.

Toda lista de dicas para esticar o limite vem sem um único número. Este artigo dá a cada correção um número medido e ranqueia todas. Dois resultados se destacam: quase metade de um mês de tokens foi para subagents, e uma única pausa longa faz a próxima mensagem reescrever a maior parte da sessão.

As medições aqui vêm de um mês de logs do Claude Code de um único desenvolvedor: 455 sessões e 63.398 requisições, de 3 de setembro a 3 de outubro.

A promoção foi de maio até 13 de setembro e deixou o limite semanal 50% mais alto. O limite de cada janela de cinco horas nunca mudou. No fim de agosto, a conta de desenvolvedores da Anthropic anunciou um aumento permanente de 25%, e um post depois a mesma thread diz que isso dá uma redução de 17%. As duas afirmações são verdadeiras:

Período	Limite semanal (limite antigo = 100)
Antes da promoção	100
Durante a promoção (maio a 13 de setembro)	150
Nível permanente desde 14 de setembro	125

De 150 para 125 são os 17% que as pessoas sentem. Um usuário com dois dos maiores planos escreveu que estar em 100% numa quarta-feira nunca tinha acontecido antes. Outro, no mesmo plano, estava em 86% numa terça de manhã. O corte não é a única causa: um modelo mais faminto foi lançado no início de setembro, então nem toda semana vazia vem dessa mudança.

Do seu lado, você enxerga uma porcentagem. A tela /usage divide o uso recente entre skills, subagents, plugins e cada servidor MCP conectado, e sinaliza os cache misses. Uma tecla alterna entre o último dia e os últimos sete. O que você não vê é o tamanho do limite em tokens: a Anthropic publica porcentagens e multiplicadores, nunca uma contagem de tokens. Por isso, tudo o que foi medido abaixo está em tokens, de uma única carga de trabalho, e não é uma fatia da sua semana.

Contar tokens a partir dos logs tem uma armadilha. O log grava a mesma resposta várias vezes, então somar todas as linhas dá 18,6 bilhões de tokens. Contada uma vez só, são 9,3 bilhões. Uma contagem ingênua quase dobra tudo.

Um subagent é outro Claude que a sua sessão inicia para um trabalho paralelo, e que reporta de volta quando termina. No mês medido, os subagents consumiram 48,1% de todos os tokens, em 2.631 execuções.

Medida	Parcela dos subagents
Todos os tokens	48,1%
Tokens de saída	63,9%
Ponderado como a tabela de preços pública pesa saída e escrita de cache	55,3%

Cada subagent também paga um preço de entrada. Antes de fazer qualquer coisa, a requisição inicial dele já carrega uma mediana de 47.117 tokens: as instruções, a lista de tools e a lista de skills, tudo enviado de novo. Outra pessoa mediu isso em outra máquina e achou de 16.000 a 21.000 tokens por lançamento, para agents cujo próprio prompt é minúsculo. Como esse artigo resume, o arquivo do agent é um erro de arredondamento perto do custo do próprio lançamento.

O modelo é a outra metade. Por padrão, um subagent herda o modelo da conversa principal, então trocar a sessão para o maior modelo coloca todos os ajudantes nele também. Nos logs medidos, o menor modelo atendeu menos de 1% das requisições de subagents. A correção é uma linha no arquivo do agent: um campo model apontando para um modelo menor, para tarefas como rodar testes ou buscar arquivos.

Isso dá dois hábitos. Dispense o subagent em tarefas pequenas que você faria direto, e fixe um modelo pequeno nos que você mantém.

O limite deste resultado: ninguém mediu quanto a fixação economiza como parcela da semana, e um modelo pequeno que precisa de mais turnos pode custar mais. Os 48% vêm de um trabalho que se ramifica bastante. A sua parcela está na tela /usage.

O Claude Code guarda a sua conversa num prompt cache no servidor, e lê-lo de volta custa uma fração do que custa enviar tudo de novo. Para a sessão principal, esse cache vive uma hora. Para um subagent, vive cinco minutos.

A documentação diz isso claramente: subagents ficam com cinco minutos, mesmo numa assinatura, até você escolher mais. O mesmo vale para tudo que fica fora da conversa principal, incluindo trabalho em segundo plano e compactação. Os logs medidos concordam: toda escrita de cache de um subagent caiu na faixa de cinco minutos, e toda escrita de uma sessão principal caiu na faixa de uma hora.

Um desenvolvedor no Reddit percebeu o efeito: um dos subagents dele reescreveu o contexto inteiro oito vezes num único dia. A correção é uma linha no arquivo de configurações, "subagentPromptCacheTtl": "1h".

A medição dele	Antes	Depois
Escritas de cache	12,2 milhões de tokens	3,0 milhões de tokens
Janela de cinco horas com quatro subagents	de 2% a 100%	de 0% a 22%

É um usuário comparando dois dias diferentes, não um teste controlado. Nos logs medidos aqui isso quase não importa: só 95 de 41.790 requisições de continuação de subagents (cerca de duas em mil) vieram depois de uma espera de mais de cinco minutos, embora cada uma tenha reescrito cerca de 75.000 tokens.

Então depende de como os seus subagents trabalham. Se eles esperam um build longo, uma revisão ou você, ative. Se rodam em rajadas curtas, deixe como está, porque um cache que dura uma hora custa mais para escrever.

O cache da sessão principal dura uma hora. Depois de uma pausa maior, ele some, e a próxima mensagem não consegue ler nada de volta. A documentação explica: a mensagem que você manda depois da pausa não acerta o cache e reprocessa o contexto completo.

Pausa antes da mensagem	Requisições	Cache reescrito (mediana)
Menos de 5 minutos	18.029	1.176 tokens
De 5 a 60 minutos	414	1.327 tokens
Mais de 60 minutos	79	130.332 tokens

A sessão típica naquele momento tinha 175.523 tokens, então a maior parte foi escrita de novo. O medidor também não trata uma escrita como uma leitura. Um desenvolvedor colocou um proxy de log na frente do Claude Code e acompanhou a janela de cinco horas dele: pelas proporções dele, um token escrito no cache pesa cerca de quarenta vezes um token lido dele.

O Claude Code sabe disso. Quando você retoma uma sessão grande depois de uma pausa longa, ele oferece retomar a partir de um resumo. Aceite.

O hábito mais barato vem antes. Quando uma tarefa termina, limpe a sessão enquanto o cache ainda está quente. Limpar não custa nada e a próxima tarefa começa pequena. Compactar também funciona, mas compactar uma sessão enorme é, em si, uma requisição enorme.

Uma pausa não é o único jeito de perder o cache. Trocar de modelo no meio da sessão o esvazia, porque cada modelo guarda o seu. Nos modelos mais novos, mudar o esforço não esvazia. O Claude Code pede para você confirmar a troca de modelo enquanto o cache está quente, e esse aviso é o alerta.

Os limites: 79 retornos a frio são uma amostra pequena, e alguns deles vêm depois de uma compactação. Um resumo também perde detalhes, então essa correção custa um pouco de continuidade.

Esforço é por quanto tempo o modelo pode pensar antes de responder. Há cinco níveis, de low a max, e o raciocínio é cobrado como saída. O padrão é high na maioria dos modelos e medium nos dois mais novos.

A documentação diz que o orçamento de raciocínio pode chegar a dezenas de milhares de tokens por requisição e que o nível mais alto tende a pensar demais. Nos modelos mais novos o raciocínio não pode ser desligado, então o nível é o único controle.

Um desenvolvedor rodou as mesmas 29 tarefas reais nos cinco níveis:

Nível de esforço	Custo médio por tarefa	Tarefas aprovadas (de 29)
low	US$ 2,50	23
medium	US$ 3,15	28
high	US$ 5,01	26
xhigh	US$ 6,51	25
max	US$ 8,84	27

A qualidade não acompanhou o custo. O medium aprovou mais tarefas que qualquer nível acima dele e, por dólar, também entregou mais aprovações. Nas palavras dele, a curva parece ter o pico no medium. O time do Claude Code trabalha do mesmo jeito: um dos engenheiros constrói em low ou medium, revisa, e só roda a verificação em high.

O porém é justamente por que essa correção pode custar qualidade. Nos problemas difíceis que ele escolheu, o esforço low passou zero vezes em cinco e o high passou cinco em cinco. Uma tentativa em low levou dois minutos, uma em high levou trinta e três.

Então ajuste o esforço à etapa: medium para construir, high quando um erro sai caro (um bug em código antigo, uma migração, uma checagem final), max quase nunca. Os logs de sessão registram o esforço de cada requisição, então você pode conferir o que realmente usou.

Esses custos são em dólares num modelo mais antigo, não uma fatia da semana; ninguém publicou isso. E uma tentativa barata que falha e roda duas vezes custa mais que uma que funciona.

Algumas correções estão em toda lista e mal mexem o ponteiro. Vale testar, são de graça. Só que não foi ali que a semana foi embora.

O que carrega no início é o item real desse grupo. Um artigo mediu a requisição inicial a partir de uma pasta vazia em 29.061 tokens, e em quase 39.000 dentro de um projeto real. Nos logs medidos aqui, a mediana da requisição inicial é 55.989 tokens, indo de 15.764 a 105.020 conforme o projeto. O comando /context mostra o que está ali dentro (arquivos de memória, skills, listas de tools) e nomeia cada arquivo de memória carregado. Corte o que você nunca usa. O ganho é modesto porque esse bloco é escrito uma vez e lido do cache a cada turno seguinte. Ele pesa numa partida a frio e em todo lançamento de subagent.

Dica popular	Medido
Remover servidores MCP	1.350 tokens para 51 tools em três servidores; 18 tokens para um servidor com uma tool
Desligar as sugestões de prompt	3 a 4% para um usuário; o "até 10%" veio de uma conta com contextos enormes
Filtrar a saída do shell	cerca de 0,1% do volume total, medido por um contribuidor de um desses filtros

As definições de tools agora são adiadas por padrão, e é por isso que os servidores MCP pesam tão pouco. A documentação chama de pequeno o custo das sugestões de prompt. As três crescem com o tamanho do seu contexto, e os servidores custam mais em modelos mais antigos, onde o adiamento está desligado. Desligue se quiser, mas não espere ter a semana de volta.

Ranqueado pelo que foi medido:

Posição	Correção	Medido	Porém
1	Menos subagents, e mais baratos	48,1% dos tokens; 47.117 por lançamento	Menos paralelismo
2	Não retome uma sessão fria	130.332 tokens reescritos contra 1.176	Um resumo perde detalhes
3	Esforço: medium para construir	US$ 3,15 contra US$ 5,01 por tarefa; 28 de 29 aprovadas	Low falha em problemas difíceis
4	Cache de subagent em uma hora	12,2 milhões para 3,0 milhões de tokens de escrita de cache	Só compensa se os subagents esperam
5	Corte o que carrega no início	+9.744 tokens sobre uma base de 29.061	Pago uma vez por sessão

As três dicas populares (servidores MCP, sugestões de prompt, saída do shell) não são onde a semana foi embora.

Os limites, sem rodeios: este ranking está em tokens, de um mês do trabalho de uma pessoa, mais medições de outras pessoas. A Anthropic não publica o tamanho do limite em tokens, então ninguém de fora consegue transformar isso numa fatia da sua semana. A sua ordem pode ser diferente, e a tela /usage vai dizer.

As duas maiores correções são hábitos, não configurações, e são de graça: lance menos subagents e nunca retome uma sessão fria por inteiro.