fix(usage): consumo do Claude é lazy — evita o 429 do limite agregado#29
Conversation
…regado)
A /api/oauth/usage divide um limite AGREGADO com o /status do próprio Claude
Code. O loop de fundo de 60s consultando esse endpoint alimentava o 429 e a
barra de % do Claude sumia ("parou de contar créditos").
Agora a coleta do Claude é sob demanda (lazy): o loop de fundo não bate mais
na API dele — a chamada só acontece nos gatilhos de UI (abrir/expandir o
overlay, revelar a janela pelo tray/atalho, botão ⟳) e no boot. Entre gatilhos
mostra o último % conhecido ou o plano-só. O cache de 5min evita repetir a
chamada a cada abrir/fechar. GLM/Codex/Antigravity seguem no loop normal.
- usage.js: readClaudeUsage ganha allowFetch (default true); guard devolve
cache/plano-só sem tocar a rede quando false. collectUsage propaga via
claudeAllowFetch. Ordem dos guards (cooldown antes de lazy) mantém o
boot-fetch seguro durante um 429 já ativo.
- main.js: collectAndSendUsage({claudeFetch}); loop=false, boot/expand/reveal/
force=true.
- +2 testes (lazy não bate / segura o último valor bom). Suíte 188 -> 190.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughA coleta do uso do Claude foi alterada para o modo lazy. O app busca dados no boot e quando o uso é visualizado ou atualizado, enquanto coletas periódicas em segundo plano preservam o cache sem acessar a API. ChangesUso lazy do Claude
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Interface
participant MainProcess
participant UsageCollector
participant ClaudeAPI
Interface->>MainProcess: abrir, expandir ou forçar atualização
MainProcess->>UsageCollector: collectUsage com claudeAllowFetch=true
UsageCollector->>ClaudeAPI: consultar /api/oauth/usage
ClaudeAPI-->>UsageCollector: percentual de uso
UsageCollector-->>MainProcess: dados de uso
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problema
"Parou de contar créditos" de novo: a barra de % do Claude some quando a API
/api/oauth/usageretorna 429. Essa API divide um limite agregado com o/statusdo próprio Claude Code — o loop de fundo de 60 s consultando o endpoint alimentava o rate limit (e cada 429 estende o cooldown por backoff exponencial).Investigação confirmou que nenhuma fonte passiva do Claude Code em disco carrega o
utilizationdas janelas 5h/7d (transcript,.claude.json,stats-cache.json,.session-stats.json,policy-limits.json) — o % só existe na chamada ativa. Não dá pra "ler do hook/arquivo deles"; a saída é reduzir a pegada na API.Solução — coleta lazy do Claude
O loop de fundo não bate mais na API do Claude. A chamada só dispara quando o usuário vai olhar o uso:
set-expanded)toggleWin)Entre gatilhos mostra o último % conhecido (ou o plano-só honesto). O cache de 5 min evita gastar chamada a cada abrir/fechar. GLM/Codex/Antigravity seguem no loop normal (não sofrem esse limite).
Detalhes
usage.js:readClaudeUsageganhaallowFetch(defaulttrue); guard devolve cache/plano-só sem tocar a rede quandofalse.collectUsagepropaga viaclaudeAllowFetch. A ordem dos guards (cooldown antes de lazy) mantém o boot-fetch seguro mesmo durante um 429 já ativo.main.js:collectAndSendUsage({claudeFetch}); loopfalse, boot/expand/reveal/forcetrue.Verificação
node --check)collectUsagecomclaudeAllowFetch=false→ 0 chamadas (plano-só);=true→ 1 chamada (% real)Summary by CodeRabbit