Como estimar sua cota do Claude quando a Anthropic cortar o acesso

Estou construindo o Tokamak, um app de menu bar para macOS que monitora sua cota do Claude Max. Há algumas semanas, a Anthropic publicou isso nos seus Terms of Service:

“You may not use OAuth or similar authorization mechanisms to allow third-party applications to access Claude on behalf of users.”

E eu, que estou lendo a cota do Claude Max usando os cookies do navegador para chamar um endpoint não documentado, fiquei encarando a tela pensando: “E agora?”

Como funciona hoje (o quebra-galho que funciona)

O Tokamak precisa saber sua porcentagem de cota. Aqueles 42% que você vê no claude.ai quando fica um tempo martelando. O problema é que a Anthropic não tem API pública de cota. Não existe um GET /api/quota documentado com API key.

O que existe é um endpoint interno que a própria web do claude.ai usa:

GET /api/organizations/{org_id}/usage

Retorna algo assim:

1
2
3
4

{
  "five_hour": { "utilization": 42, "resets_at": "2026-02-22T18:00:00Z" },
  "seven_day": { "utilization": 19, "resets_at": "2026-02-28T14:59:59Z" }
}

Para chamar esse endpoint, você precisa dos cookies de sessão de um usuário logado. O Tokamak resolve isso com um WKWebView oculto: o usuário faz login no claude.ai dentro do app, os cookies ficam no WebView, e o app os usa para fazer polling a cada 30 segundos.

Funciona. Está funcionando há meses. Mas é um quebra-galho elegante, não uma solução robusta. Estamos usando uma API interna que a Anthropic pode mudar, quebrar ou bloquear sem aviso prévio.

O limbo jurídico

A proibição do OAuth é clara. Mas aplica a cookies? Tecnicamente não estamos usando OAuth nem “mecanismos de autorização similares”. O usuário faz login diretamente no claude.ai dentro de um WebView padrão. É como abrir o Safari dentro do app.

Mas “similar authorization mechanisms” é uma frase suficientemente ambígua para que um advogado da Anthropic a interprete como bem entender. Hoje estamos num limbo jurídico: não está explicitamente proibido, mas também não explicitamente permitido.

E se um dia a Anthropic decidir que cookies de terceiros também não prestam, ficamos sem dados de cota. Assim, de um dia para o outro.

O plano B: estimar sem API

Aqui é onde fica interessante. A pergunta é: podemos estimar sua porcentagem de cota usando apenas dados locais?

Antes de responder, você precisa entender como funciona a cota do Claude Max. Não é um simples contador de tokens.

A cota é custo equivalente, não tokens

A Anthropic não conta tokens como se fossem amendoins numa tigela. Conta custo equivalente a preços de API. Cada token tem um “preço” diferente segundo seu tipo e modelo:

Em termos simples: uma mensagem curta do Opus onde o Claude pensa muito e escreve uma resposta longa consome muito mais cota que uma mensagem longa sua para o Haiku com resposta curta.

É como a conta de luz. Você não paga por “horas ligado”. Paga por kWh, e o forno gasta 10x mais que a lâmpada do banheiro.

A janela de 5 horas

A cota não se acumula indefinidamente. Funciona como uma janela deslizante de 5 horas. Cada token que você envia “expira” exatamente 5 horas depois. Se às 10:00 você queimou 30% da cota com uma sessão intensa, às 15:00 esses 30% se liberam.

Imagine um balde d’água com um furo. A água que você despeja (suas mensagens) vai saindo por baixo 5 horas depois. O nível da água é sua utilização.

Os três componentes

Certo, sabemos que a cota é custo equivalente e que se move em janelas de 5 horas. Podemos replicar isso localmente?

A resposta honesta: não com precisão cirúrgica, mas sim com precisão útil. Não vamos acertar os 73%. Mas vamos saber que você está “em zona laranja, cuidado”. E acontece que isso é exatamente o que você precisa.

O sistema tem três peças, cada uma com um papel claro:

1. O Estimador (M1): o contador

É quem faz as contas. Lê os arquivos locais de ~/.claude/ (que contêm todos os tokens que você enviou e recebeu, com timestamps e modelo), soma o custo equivalente nas últimas 5 horas, e divide pelo “orçamento total” do tier.

estimação = custo_em_janela_5h / orçamento_tier * 100

É como controlar quanto de energia você gastou este mês: sabe os kWh do forno, da geladeira, do computador. Soma, divide pela sua tarifa, e tem uma estimativa da conta.

O problema: não sabemos o orçamento total exato. A Anthropic não publica. Então precisamos calibrá-lo. Aí entra o segundo componente.

2. O Calibrador (A3): o que aprende observando

Este é o mais elegante. Se chama Decay Estimator e funciona assim:

Quando você para de trabalhar (vai almoçar, numa reunião, dormir), os tokens que você enviou há 5 horas começam a expirar. A cota baixa sozinha. E como nós sabemos exatamente que tokens enviamos e quando (estão nos JSONL locais), podemos observar quanto a cota baixa quando esses tokens específicos expiram.

É como o balde d’água do exemplo anterior: se você despeja um litro de água vermelha e outro de água azul, e vê que quando sai a água vermelha o nível baixa 3 marcas e quando sai a azul baixa 1 marca, agora sabe que a água vermelha pesa 3x mais que a azul. Sem ninguém te contar. Apenas observando.

Atenção para isso: acontece naturalmente. Não consome cota. Não precisa de experimentos. Cada vez que você se levanta para pegar um café, o calibrador está aprendendo os pesos reais de cada tipo de token.

3. O Classificador (A5): o que traduz números em decisões

Aqui há um insight contraintuitivo. A primeira reação é tentar estimar a porcentagem exata: “você está em 73%”. Mas acontece que isso é matematicamente muito difícil de fazer com precisão. A API retorna inteiros de 0 a 100, há fatores ocultos que não podemos medir, e a atividade de outros dispositivos (claude.ai web, mobile) é invisível para nós.

Mas você precisa saber se está em 73% ou 77%? Não. Precisa saber em que zona está:

Classificar em 4 zonas em vez de regredir 100 valores é muito mais fácil e muito mais útil. Se a cota real é 72% e o classificador diz “amarela”, acerta. Se o estimador diz “72% +-20%”, a faixa 52-92% cruza três zonas e não te diz nada.

É a diferença entre um termômetro digital com duas casas decimais e um termômetro de mercúrio com três cores: frio, morno, febre. Para decidir se você toma um ibuprofeno, o de três cores serve igual ou melhor.

O pipeline completo

graph TD
    A["~/.claude/*.jsonl<br/>(tokens locais)"] --> B["Estimador M1<br/>(contador)"]
    B --> |"custo equivalente<br/>em janela 5h"| D["Classificador A5<br/>(semáforo)"]

    C["Calibrador A3<br/>(observa o decay)"] --> |"pesos reais<br/>por tipo de token"| B

    E["API de cota<br/>(enquanto funcionar)"] --> |"ground truth<br/>para calibrar"| F["QuotaCalibrationLog<br/>(dados pareados)"]
    F --> |"calibração<br/>contínua"| C
    F --> |"orçamento<br/>do tier"| B

    D --> G["🟢 Verde"]
    D --> H["🟡 Amarela"]
    D --> I["🟠 Laranja"]
    D --> J["🔴 Vermelha"]

    style E stroke-dasharray: 5 5
    style F stroke-dasharray: 5 5

Enquanto a API funciona, temos o dado real e simultaneamente estamos treinando o estimador com dados pareados: “quando você tinha esses tokens locais, a API dizia 42%”. Acumulamos milhares desses pares. No dia que a API desaparecer, o estimador já sabe quanto “pesa” cada tipo de token porque aprendeu observando.

Como melhora a precisão com o tempo

O truque de todo o sistema é o QuotaCalibrationLog: um registro que se salva a cada 30 segundos com duas coisas:

1. O que a API diz (o dado real, o ground truth).
2. O que calculamos localmente (tokens na janela, custo equivalente, modelo usado).

Cada registro é um ponto de calibração. Com 2.880 pontos por dia (um a cada 30 segundos durante as horas de uso), em duas semanas temos dados suficientes para:

• Calibrar o orçamento do tier: sabemos que quando o custo local chega a $X, a API diz 100%. Agora conhecemos $X.
• Verificar os pesos: se nossos ratios (output 5x input, Opus 1.67x Sonnet) estão errados, os dados pareados revelam.
• Detectar mudanças da Anthropic: se um dia os resíduos do estimador disparam, sabemos que a fórmula mudou. Recalibramos automaticamente.

No primeiro dia, o estimador usa preços públicos de API como aproximação. Em uma semana, já tem pesos empíricos. Em um mês, tem um modelo bastante ajustado do comportamento real.

As limitações honestas

Seria desonesto vender isso como uma bala de prata. Há coisas que nunca poderemos capturar:

• Atividade de outros dispositivos. Se você usa claude.ai do mobile, esses tokens consomem cota mas são invisíveis para o Tokamak. O estimador subestimará.
• Fatores ocultos. Se a Anthropic aplica penalizações por horário, carga do servidor, ou complexidade da tarefa, não podemos medir.
• Precisão pontual. O erro do estimador fica em torno de +-15-25%. Para uma % exata, não é suficiente. Para saber se você está em verde, amarela, laranja ou vermelha, é sim.

Por isso o classificador é o componente que o usuário vê, não o estimador diretamente. Não dizemos “você está em 73%”. Dizemos “você está em zona amarela”. E isso acertamos 85-90% das vezes.

“E por que não mete um modelo de ML?”

Se chegou até aqui, provavelmente está pensando: “Cara, por que não treina um modelo de CoreML com os dados de calibração e pronto?” É a pergunta óbvia. E a resposta é que seria como usar um canhão para matar uma mosquinha que ainda está atrás de um vidro blindado.

O problema é o vidro, não o canhão

Imagine o pote de balas de um bar. Sabe que tem gominhas, alcaçuz e chicletes, cada um com um “preço” diferente. Quer saber que porcentagem do pote você já comeu. Mas só pode olhar o pote de fora e o vidro distorce: só distingue se está “cheio”, “pela metade”, “quase vazio” ou “vazio”. Não vê as balas individuais.

Não importa se você usar óculos de R$ 50.000 ou um microscópio eletrônico. O vidro continua distorcendo igual. Mais potência óptica não te dá mais informação se o sinal que você recebe é borrado na origem.

Isso é exatamente o que acontece aqui:

• Um só observável: a API retorna um inteiro entre 0 e 100. Um número. Essa é toda a informação que recebemos do sistema real.
• Quantização brutal: a maioria das observações consecutivas (a cada 30s) têm delta = 0. Quando há mudança, é de 1% ou mais. Não há informação fina.
• 6+ incógnitas: peso de output, input, cache read, cache write, para cada modelo, mais o orçamento total, mais possíveis fatores ocultos (tempo de GPU, carga do servidor).

Um sistema com 6 incógnitas e 1 equação. Não importa se usar regressão linear, gradient boosting, rede neural ou transformer. É um problema subdeterminado. Não há informação suficiente no sinal para resolver todas as incógnitas, nem com um bilhão de parâmetros.

O que ML ganha vs. o que perde

Se a Anthropic mudar sua fórmula de cota amanhã, com o estimador linear você vê exatamente que resíduo disparou e que peso precisa ajustar. Com um modelo de ML você vê que a métrica baixou e tem que re-treinar às cegas com os dados novos, esperando que convirja.

A analogia do termômetro

Se seu termômetro de mercúrio tem resolução de 1°C, comprar um termômetro digital de 0.001°C não melhora a medição se o que você está medindo é a temperatura de um forno através da mesma parede de vidro grosso. O gargalo é a parede, não o instrumento.

Aqui a “parede” é a quantização inteira + os fatores ocultos + a atividade invisível de outros dispositivos. Nenhum modelo, por mais sofisticado que seja, consegue ver através dela.

O Phase Detector (o semáforo) funciona justamente porque aceita essa limitação: em vez de tentar adivinhar “73.2%”, classifica em 4 zonas. E isso é robusto com a informação disponível.

O que estamos fazendo agora mesmo

O mais urgente é começar a registrar dados. Cada dia sem logging é um dia de calibração perdido. Então a prioridade é:

1. Agora: implementar o QuotaCalibrationLog. Sem mudanças na UI. Só acumular dados pareados em silêncio.
2. Em 2-4 semanas: com dados acumulados, ativar o estimador como fallback automático quando a API falhar.
3. Em 4+ semanas: ativar o calibrador passivo (Decay Estimator) para aprender pesos empíricos.

Se amanhã a Anthropic cortar o acesso, o estimador já estará calibrado e os usuários verão um semáforo em vez de uma porcentagem. Não é perfeito. Mas é útil. E é honesto sobre suas limitações, o que já é mais do que se pode dizer da maioria dos dashboards por aí.

Às vezes o melhor plano B é um que você começa a construir antes de precisar.