Introdução
Vou ser direto: se você paga Pro ou Max do Claude Code e nunca olhou quanto do seu rate limit já consumiu na sessão, você está voando cego. E se isso nunca te incomodou, provavelmente é porque você nunca bateu num rate limit no meio de um deploy às 15h de uma quinta-feira.
Na última semana de março de 2026, a The Register publicou que a própria Anthropic admitiu que “people are hitting usage limits in Claude Code way faster than expected”. A TechRadar reportou que durante peak hours — entre 5h e 11h PT — cerca de 7% dos usuários Pro começaram a bater em limites que não batiam antes. A PYMNTS chamou isso de “AI rationing” — racionamento de IA.
Na minha experiência com 300+ software houses, o padrão que vejo é previsível: o dev compra o Pro por $20/mês, começa a usar o Claude Code em tudo — refatoração, code review, testes, documentação — e num belo dia descobre que o limit acabou. Não tem aviso prévio. Não tem barra de progresso. Simplesmente para. O dev perde o flow, perde produtividade, e culpa a ferramenta.
O que pouca gente sabe é que desde a v2.1.80, o Claude Code tem um campo rate_limits na statusline que mostra exatamente quanto do seu rate limit já foi consumido — em tempo real, na tela, o tempo todo. E quase ninguém configurou.
O que são os rate limits do Claude Code
Antes de falar da solução, vamos entender o problema.
Dois windows, uma armadilha
O Claude Code para planos Claude.ai (Pro e Max) opera com dois rate limit windows simultâneos:
Window de 5 horas: Um rolling window que conta o consumo das últimas 5 horas. Não tem horário fixo de reset — conforme prompts antigos passam da marca de 5 horas, o espaço vai liberando gradualmente. No Pro, você tem aproximadamente 45 prompts nesse window. No Max 5x, cerca de 225. No Max 20x, cerca de 900.
Window de 7 dias: Um limite semanal que acumula todo o uso da semana. Mesmo que você esteja dentro do window de 5h, se o consumo semanal estourou, você para.
O detalhe maldoso: os dois windows são independentes. Você pode estar com 20% no window de 5h e 95% no de 7 dias. Ou 90% no de 5h e 10% no semanal. Qualquer um que estourar, trava.
Os planos e seus limites
| Plano | Preço/mês | Capacidade 5h (aprox.) | Capacidade semanal |
|---|---|---|---|
| Pro | $20 | ~45 prompts | Limite base |
| Max 5x | $100 | ~225 prompts | 5x o Pro |
| Max 20x | $200 | ~900 prompts | 20x o Pro |
Detalhe importante: Claude.ai e Claude Code compartilham o mesmo bucket de uso. Toda conversa que você tem no chat da Claude conta contra o mesmo rate limit que o Claude Code usa. Se você gastou metade do seu limit conversando com a Claude no browser antes de abrir o terminal, já começa com metade da capacidade.
Peak hours: o agravante
A TechRadar reportou que a Anthropic aplica throttling mais agressivo durante peak hours — entre 5:00 e 11:00 PT (13:00 e 19:00 no horário de Brasília). Nesse período, o sistema é mais conservador com alocação de recursos. Resultado: 7% dos usuários Pro começaram a bater em limites que não existiam antes.
Traduzindo pra realidade de SH brasileira: entre 13h e 19h no Brasil — exatamente o horário mais produtivo da sua equipe — é quando o rate limit fica mais apertado. Se você tem 5 devs usando Claude Code Pro no mesmo período, as chances de pelo menos um bater no limit são altas.
rate_limits na statusline: visibilidade em tempo real
Agora a parte que resolve tudo. A statusline do Claude Code é uma barra customizável na parte inferior da interface que roda qualquer shell script que você configurar. Ela recebe um JSON com dados da sessão via stdin e exibe o que o script printar.
Desde a v2.1.80, esse JSON inclui um objeto rate_limits:
{
"rate_limits": {
"five_hour": {
"used_percentage": 23.5,
"resets_at": 1738425600
},
"seven_day": {
"used_percentage": 41.2,
"resets_at": 1738857600
}
}
}São quatro campos que mudam tudo:
five_hour.used_percentage— Porcentagem do rate limit de 5h consumida (0 a 100)seven_day.used_percentage— Porcentagem do rate limit de 7 dias consumida (0 a 100)five_hour.resets_at— Timestamp Unix de quando o window de 5h resetaseven_day.resets_at— Timestamp Unix de quando o window semanal reseta
Observações técnicas importantes:
- Só aparece para assinantes Claude.ai (Pro/Max) — quem usa API key não tem esse campo
- Aparece após a primeira API response na sessão
- Cada window pode estar independentemente ausente
- A statusline atualiza após cada mensagem do assistant, com debounce de 300ms
Como configurar em 2 minutos
A forma mais rápida: rode /statusline no Claude Code com uma descrição do que você quer.
/statusline show rate limit usage for 5h and 7d windows with color-coded progress barsO Claude gera o script, salva em ~/.claude/, e configura tudo pra você.
Configuração manual (Bash)
Se preferir controle total, crie o arquivo ~/.claude/statusline-rates.sh:
#!/bin/bash
input=$(cat)
MODEL=$(echo "$input" | jq -r '.model.display_name')
FIVE_H=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
WEEK=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
GREEN='\033[32m'
YELLOW='\033[33m'
RED='\033[31m'
RESET='\033[0m'
color_for_pct() {
local pct=$(printf '%.0f' "$1")
if [ "$pct" -ge 80 ]; then echo "$RED"
elif [ "$pct" -ge 50 ]; then echo "$YELLOW"
else echo "$GREEN"; fi
}
LIMITS=""
if [ -n "$FIVE_H" ]; then
COLOR=$(color_for_pct "$FIVE_H")
LIMITS="${COLOR}5h: $(printf '%.0f' "$FIVE_H")%${RESET}"
fi
if [ -n "$WEEK" ]; then
COLOR=$(color_for_pct "$WEEK")
LIMITS="${LIMITS:+$LIMITS }${COLOR}7d: $(printf '%.0f' "$WEEK")%${RESET}"
fi
[ -n "$LIMITS" ] && echo -e "[$MODEL] | $LIMITS" || echo "[$MODEL]"Torne executável e configure:
chmod +x ~/.claude/statusline-rates.shNo ~/.claude/settings.json:
{
"statusLine": {
"type": "command",
"command": "~/.claude/statusline-rates.sh"
}
}Resultado: uma barra persistente mostrando [Opus] | 5h: 23% 7d: 41% — verde abaixo de 50%, amarelo entre 50-80%, vermelho acima de 80%.
Versão avançada: multi-line com context + rates
Se você quer tudo na mesma statusline — git, contexto, custo E rate limits — pode usar um script multi-line:
#!/bin/bash
input=$(cat)
MODEL=$(echo "$input" | jq -r '.model.display_name')
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
COST=$(echo "$input" | jq -r '.cost.total_cost_usd // 0')
FIVE_H=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
WEEK=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
GREEN='\033[32m'; YELLOW='\033[33m'; RED='\033[31m'; CYAN='\033[36m'; RESET='\033[0m'
# Linha 1: modelo + context + custo
COST_FMT=$(printf '$%.2f' "$COST")
echo -e "${CYAN}[$MODEL]${RESET} ctx: ${PCT}% | ${YELLOW}${COST_FMT}${RESET}"
# Linha 2: rate limits
if [ -n "$FIVE_H" ] || [ -n "$WEEK" ]; then
RATES=""
[ -n "$FIVE_H" ] && {
P=$(printf '%.0f' "$FIVE_H")
C=$( [ "$P" -ge 80 ] && echo "$RED" || ( [ "$P" -ge 50 ] && echo "$YELLOW" || echo "$GREEN" ) )
RATES="${C}5h: ${P}%${RESET}"
}
[ -n "$WEEK" ] && {
P=$(printf '%.0f' "$WEEK")
C=$( [ "$P" -ge 80 ] && echo "$RED" || ( [ "$P" -ge 50 ] && echo "$YELLOW" || echo "$GREEN" ) )
RATES="${RATES:+$RATES }${C}7d: ${P}%${RESET}"
}
echo -e "Rate limits: $RATES"
fiDuas linhas na barra inferior. Primeira: modelo, context window, custo. Segunda: rate limits com cores. Tudo em tempo real.
Por que isso importa para sua Software House
O cenário real: 5 devs, 1 plano
Imagina: sua SH tem 5 desenvolvedores no plano Pro. Cada um com $20/mês. Total: $100/mês em Claude Code. Parece razoável.
Agora o cenário real: segunda-feira, 14h (peak hour no Brasil). Os 5 devs estão codando pesado com o Claude Code. O dev que faz code review está no 40º prompt do window de 5h. O dev de backend está no 35º, mas gastou o chat do Claude.ai de manhã e já começou com 30% do bucket consumido. O dev de frontend nem olha pra rate limit porque “nunca bateu”.
Às 15h30, 2 dos 5 devs estão travados. Não sabiam que estavam perto do limit. Não tinham como ver. Agora ficam 2-3 horas sem a ferramenta que mais aumenta a produtividade deles.
Com rate_limits na statusline, cada dev vê em tempo real: “5h: 72%”. Sabe que precisa desacelerar, fazer tarefas menos intensivas, ou esperar o window deslizar. Sem surpresas. Sem interrupção abrupta.
Decisões de upgrade baseadas em dados
Outro cenário que vejo direto: o CEO da SH quer saber se vale fazer upgrade do Pro ($20) para o Max 5x ($100). É 5x o preço. Vale?
Sem a statusline de rate limits, a decisão é baseada em “sentimento”: “ah, acho que os devs batem no limit de vez em quando”. Com a statusline, o dev pode reportar: “Nas últimas duas semanas, bati 80%+ no window de 5h em 3 dos 5 dias úteis, sempre entre 14h e 17h”.
Agora sim: é uma decisão baseada em dados. O custo do upgrade ($80/mês a mais por dev) se paga se a perda de produtividade por rate limit custa mais que isso.
Planejamento de sessão
A informação de resets_at é ouro. Se o window de 5h reseta em 45 minutos e você está com 85%, talvez faça sentido revisar PRs (leitura leve) por 45 minutos e depois voltar pro Claude Code com o window zerado. Sem essa informação, você não sabe se esperar 45 minutos ou 4 horas.
Os números que ninguém te conta
Vamos aos fatos:
Pro a $20/mês com ~45 prompts por 5 horas: Se o dev médio faz 10 prompts por hora em uso intensivo, ele tem 4h30 de trabalho pesado antes de bater no limit. Mas se gastou 15 prompts no Claude.ai antes, são 3 horas. Em peak hours com throttling? Pode ser menos de 2h30.
O impacto financeiro: Um dev senior custa R$25.000-40.000/mês para a SH. Se ele perde 2-3 horas por semana por rate limit (sem poder antecipar), são 8-12 horas/mês. A R$150-250/hora, são R$1.200-3.000/mês desperdiçados. O upgrade para Max 5x custa ~R$500/mês. A conta fecha.
Compartilhamento de bucket: Esse é o detalhe que pega de surpresa. O Claude.ai (chat no browser) e o Claude Code compartilham o mesmo rate limit. Se o dev usa a Claude pra escrever emails, responder dúvidas, brainstorm de manhã — já começa a sessão de código com menos capacidade. A statusline mostra isso desde o primeiro prompt.
Comparação: como era vs. como é
| Aspecto | Antes (sem statusline) | Depois (com rate_limits) |
|---|---|---|
| Visibilidade | Zero — só descobre quando bate | Tempo real — % consumido sempre visível |
| Planejamento | Impossível | “Estou em 70%, vou diminuir o ritmo” |
| Upgrade decision | Baseada em feeling | Baseada em dados de uso real |
| Peak hours | Surpresa desagradável | Previsível: “13h-19h consumo mais rápido” |
| Compartilhamento | Não percebe que chat consome | Vê o impacto do chat no rate limit |
| Reset timing | Não sabe quando libera | `resets_at` mostra exatamente quando |
O que eu penso
Na minha experiência mentorando 300+ software houses, as ferramentas que mais geram valor são as que dão visibilidade. Não é a ferramenta mais poderosa que ganha — é a que você consegue gerenciar.
Rate limits são uma realidade de qualquer plano que não seja API com cartão de crédito ilimitado. A Anthropic está sendo honesta sobre isso — admitiu publicamente que os limits estão apertados. A diferença entre uma SH que reclama e uma que se adapta está na informação.
A statusline do Claude Code com rate_limits é um painel de instrumentos. Nenhum piloto decola sem olhar o combustível. Nenhum dev deveria codar sem saber quanto rate limit tem. São 2 minutos de configuração que economizam horas de frustração.
E se você está olhando pros números e pensando “Max 5x é caro” — faz a conta do custo de ter um dev senior parado 2 horas por semana. A ferramenta mais cara é a que você paga mas não consegue usar.
Conclusão
O campo rate_limits na statusline existe desde a v2.1.80. É uma feature de visibilidade que transforma dados ocultos em informação visual e acionável. Dois campos (five_hour e seven_day) com porcentagem de uso e timestamp de reset. Configuração em 2 minutos. Impacto imediato.
Se você gerencia uma software house onde devs usam Claude Code no Pro ou Max, configure a statusline com rate limits hoje. Não amanhã. São 2 minutos que mudam completamente como sua equipe gerencia a ferramenta que mais impacta a produtividade deles.
Se você quer implementar esse nível de gestão de IA na sua software house e ter clareza sobre custos, produtividade e ferramentas — essa é a conversa que eu mais gosto de ter.
Sou Thulio, mentoro 300+ SHs desde 2016.
