Claude Code: como ver o uso por sessão e descobrir qual sessão está consumindo o seu plano

Rode várias sessões do Claude Code em paralelo e o seu limite semanal esvazia mais rápido do que você espera. Você quer saber qual sessão está consumindo, mas abrir o /usage não responde isso.

A resposta curta: em setembro de 2026, não existe nenhuma tela oficial que mostre qual parcela do uso cada sessão levou. O /usage traz os números da sessão atual, mais o consumo do plano inteiro dividido em percentuais por Skill, subagente, plugin e servidor MCP. Se você quer ver isso por sessão, precisa agregar os logs de conversa guardados na sua própria máquina.

Só que, se você contar esses logs sem cuidado, vai errar. Quando medi os logs dos últimos 7 dias na minha máquina, somar as linhas como estavam deu um total 2,06 vezes maior que o valor correto. Pior: mesmo entre as 12 sessões mais pesadas, o tamanho desse erro variou de 1,30× a 3,02×, e a ordem entre elas mudou. Este artigo percorre o que as telas oficiais mostram, o jeito certo de contar, um script de agregação de cerca de 50 linhas e o que eu medi.

1. O que as telas oficiais mostram e o que não mostram

Estes são os principais lugares oficiais que informam o uso (em setembro de 2026). Nenhum deles mostra a parcela de cada sessão. O mais próximo é o detalhamento do plano no /usage, mas o eixo dele é para qual recurso o uso foi, e não qual sessão o consumiu.

Fonte: documentação do Claude Code, "Manage costs effectively" (/usage, /insights, painéis da organização), documentação do Claude Code, "Desktop" (anel de uso), Central de Ajuda do Claude, "Usage limit best practices" (a página de uso em Settings), documentação do Claude Code, "Monitoring" (OpenTelemetry)

Sobre o detalhamento do plano no /usage, a documentação diz mais uma coisa importante: "Os valores são aproximados e calculados a partir do histórico local de sessões nesta máquina, então o uso em outros dispositivos ou no claude.ai não está incluído." Ou seja, até o detalhamento oficial vem, no fim das contas, dos seus logs locais. Lendo esses mesmos logs por conta própria, dá para agregá-los no eixo que as telas oficiais deixam de fora: a sessão. Se você já bateu no limite e quer ver quanto resta, veja Claude Code "usage limit reached": limites de 5 horas e semanal.

2. A resposta está nos seus logs de conversa locais

O Claude Code salva o registro completo de cada conversa em JSONL (um objeto JSON por linha), com um arquivo por sessão. A documentação diz onde eles ficam.

Fonte: documentação do Claude Code, "Explore the .claude directory"

Na minha máquina, o nome da pasta <projeto> era o caminho absoluto da pasta de trabalho com os símbolos trocados por - (D:\work\site-a vira D--work-site-a). As sessões executadas na aba Code do app desktop eram gravadas no mesmo lugar, com "entrypoint":"claude-desktop" registrado em todas as linhas.

O que você agrega é o usage presente nas linhas que registram as respostas do Claude ("type":"assistant"). Aqui está uma linha real, reduzida apenas aos campos que a agregação usa (IDs ocultados).

{"type":"assistant","requestId":"req_…","timestamp":"2026-07-25T00:16:37.822Z",
 "message":{"id":"msg_…","model":"claude-opus-5",
  "content":[{"type":"text","text":"…"}],
  "usage":{"input_tokens":2,"output_tokens":255,
           "cache_read_input_tokens":33775,"cache_creation_input_tokens":17265,
           "cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":17265}}}}

Os quatro números do usage (entrada, saída, leitura de cache e escrita de cache) são campos oficiais das respostas da API do Claude. Já o formato do arquivo de log em si, ou seja, o que é gravado em cada linha, não tem documentação oficial. O método de contagem deste artigo foi conferido nos meus próprios logs da v2.1.197 à v2.1.260 e pode deixar de funcionar em versões futuras.

A documentação deixa explícita mais uma precaução: "Transcrições e histórico não são criptografados em repouso. As permissões de arquivo do sistema operacional são a única proteção." Se uma ferramenta lê um arquivo .env, o conteúdo dele também vai parar no log. Compartilhar os resultados agregados com outras pessoas não tem problema, mas tome cuidado ao entregar os próprios logs a alguém ou ao deixar que uma ferramenta que você não conhece bem os leia.

3. Some tudo direto e o total quase dobra: quatro armadilhas

Encontre as linhas com usage e some todas. É o caminho mais óbvio, mas nos meus logs o total saiu em cerca do dobro do valor correto. Há quatro motivos.

Armadilha 1: uma resposta é gravada em várias linhas

Uma resposta do Claude (uma requisição à API) não corresponde necessariamente a uma linha do log. Na minha máquina, cada bloco de conteúdo, como raciocínio, texto ou chamada de ferramenta, era gravado em uma linha própria (mais de 99,9% das linhas tinham exatamente um bloco), e todas essas linhas traziam usage. O que identifica uma resposta é o par message.id e requestId.

Das 142.345 respostas gravadas em duas ou mais linhas, 76% tinham exatamente o mesmo usage em todas as linhas. Nos 24% restantes, o valor de tokens de saída variava de uma linha para outra. Então, para cada resposta, fique só com a linha que tem a maior contagem de tokens de saída. À parte disso, 1.903 respostas também apareciam em outro arquivo (0,95% de todos os tokens). Não investiguei a causa, mas agrupar tudo pela mesma chave evita que essas também sejam contadas duas vezes.

Armadilha 2: os registros dos subagentes ficam em arquivos separados

Leia só os arquivos .jsonl principais e os subagentes somem por completo. Nos meus logs, esta foi a parcela dos totais corretos que veio dos subagentes.

• Entrada (sem cache): 42,9%
• Saída: 23,2%
• Escrita de cache: 10,8%
• Leitura de cache: 6,9%

Por sessão, a variação é ainda maior: nos últimos 7 dias, ponderando pelo preço, ela ia de sessões com 0% até uma sessão com 54%. Quanto mais uma sessão distribui trabalho para subagentes, menor ela parece quando você conta só o arquivo principal.

Armadilha 3: os dois erros se compensam em parte, mas de um jeito diferente em cada sessão

Somando as linhas dos arquivos principais como estão, a armadilha 1 infla a contagem enquanto a armadilha 2 a encolhe. Nos últimos 7 dias, o total chegou a 2,06 vezes o valor correto. Se todas as sessões errassem pelo mesmo fator, os percentuais continuariam certos. Na prática, não foi o que aconteceu.

Fonte: minhas próprias medições (últimos 7 dias em 15 de setembro de 2026. Para facilitar a comparação, só esta tabela usa contagens de tokens sem ponderação, inclusive na parcela de subagentes. As letras das sessões são as mesmas da figura do início)

A 2ª e a 3ª posições trocaram de lugar, assim como a 4ª e a 5ª, e G, que na verdade é a 9ª, subiu para 6ª. D sair pequena por depender de subagentes é exatamente a armadilha 2, mas E, com a mesma parcela de 39% de subagentes que D, foi no sentido oposto, com 2,60×. Em quantas linhas cada resposta se divide (quanto raciocínio e quantas chamadas de ferramentas ela contém) também pesa, então não dá para prever o fator de antemão. "É só dividir por dois" não funciona.

Armadilha 4: 97% dos tokens são leituras de cache

Mesmo contando corretamente, comparar contagens brutas de tokens leva a julgar mal o peso de cada sessão. Veja do que foram feitos os últimos 7 dias.

Os preços unitários, porém, estão longe de ser iguais. Na página oficial de preços da Anthropic, a leitura de cache custa 0,1× o preço base de entrada (0,025× no Claude Fable 5.1 e no Claude Mythos 5.1), a escrita de cache de 5 minutos custa 1,25× e a de 1 hora, 2×, e a saída custa 5× o preço de entrada em todos os modelos atuais. A sessão C, que tinha 12,7% dos tokens, caiu para 10,4% depois de ponderada por esses preços.

O próprio tamanho dos números também diz algo. Das 12 sessões do topo, as 10 que não são D nem E leram em média cerca de 410 mil a 480 mil tokens de contexto por resposta (D e E, que dependem de subagentes, ficaram em cerca de 240 mil e 310 mil). "O Claude Code envia a conversa inteira a cada requisição", então quanto mais tempo uma sessão fica aberta, mais pesada fica cada requisição. Claude Code: o que está consumindo o seu contexto? explica em detalhe como isso funciona.

4. O script de agregação

Este script de agregação leva em conta as quatro armadilhas. Ele roda só com a biblioteca padrão do Python 3 (testei no 3.11). Ele apenas lê os logs e nunca modifica nem envia nada. Se você mudou o diretório de configuração com a variável de ambiente CLAUDE_CONFIG_DIR, ele lê de lá.

import json, os, sys
from collections import defaultdict
from datetime import datetime, timedelta, timezone
from pathlib import Path

DAYS = float(sys.argv[1]) if len(sys.argv) > 1 else 7
ROOT = Path(os.environ.get("CLAUDE_CONFIG_DIR") or Path.home() / ".claude") / "projects"
SINCE = datetime.now(timezone.utc) - timedelta(days=DAYS)
# USD per 1M input tokens (output = 5x). First match wins.
PRICES = [("sonnet-5", 2), ("sonnet", 3), ("haiku", 1), ("opus-4-1", 15),
          ("opus-4-2025", 15), ("opus", 5), ("fable", 10), ("mythos", 10)]

best = {}  # one API response = one (message.id, requestId)
for path in ROOT.rglob("*.jsonl"):  # also reads <session>/subagents/*.jsonl
    project = path.relative_to(ROOT).parts[0]
    with path.open(encoding="utf-8", errors="replace") as f:
        for line in f:
            if '"usage"' not in line:
                continue
            try:
                row = json.loads(line)
            except ValueError:
                continue
            msg = row.get("message") or {}
            usage = msg.get("usage")
            ts = row.get("timestamp")
            if row.get("type") != "assistant" or not usage or not ts:
                continue
            if datetime.fromisoformat(ts.replace("Z", "+00:00")) < SINCE:
                continue
            key = (msg.get("id"), row.get("requestId"))
            old = best.get(key)
            if old is None or usage.get("output_tokens", 0) >= old[2].get("output_tokens", 0):
                best[key] = (project, msg.get("model") or "", usage)

totals = defaultdict(lambda: [0, 0.0])  # [tokens, weight]
for project, model, u in best.values():
    p = next((v for name, v in PRICES if name in model), 5)
    read_rate = 0.025 if "5-1" in model and ("fable" in model or "mythos" in model) else 0.1
    inp, out = u.get("input_tokens", 0), u.get("output_tokens", 0)
    read, write = u.get("cache_read_input_tokens", 0), u.get("cache_creation_input_tokens", 0)
    write_1h = (u.get("cache_creation") or {}).get("ephemeral_1h_input_tokens", 0)
    totals[project][0] += inp + out + read + write
    totals[project][1] += p * (inp + out * 5 + read * read_rate
                               + (write - write_1h) * 1.25 + write_1h * 2)

all_tokens = sum(t for t, _ in totals.values()) or 1
all_weight = sum(w for _, w in totals.values()) or 1
print(f"last {DAYS:g} days: {len(best):,} responses")
print(f"{'weight':>7} {'tokens':>7}  project")
for project, (t, w) in sorted(totals.items(), key=lambda kv: -kv[1][1]):
    print(f"{w / all_weight:7.1%} {t / all_tokens:7.1%}  {project}")

Salve com um nome como usage_by_session.py e passe o número de dias como argumento. Sem argumento, ele usa os últimos 7 dias.

python usage_by_session.py        # últimos 7 dias
python usage_by_session.py 1      # últimas 24 horas
python usage_by_session.py 30     # últimos 30 dias

A saída fica assim (nomes de pastas ocultados). weight é a parcela ponderada pelo preço e tokens é a parcela pela contagem bruta de tokens.

last 7 days: 19,991 responses
 weight  tokens  project
  32.3%   31.7%  D--work-project-a
  11.1%   11.4%  D--work-project-b
  10.4%   12.7%  D--work-project-c
   7.7%    8.6%  D--work-project-d
   6.4%    5.4%  D--work-project-e

5. Medição: uma de 29 sessões usou quase um terço

Nos últimos 7 dias, 29 sessões estiveram ativas na minha máquina. Como mostra a figura do início, o uso estava concentrado em apenas algumas delas.

Colocar os números lado a lado mostrou três coisas.

Primeiro, as sessões do topo são pesadas em cada requisição. As 3 do topo leram em média cerca de 410 mil a 480 mil tokens por resposta. Não é só que fizeram mais requisições: elas ficaram abertas o dia inteiro enquanto o contexto não parava de crescer. A documentação também aponta que, em uma sessão deixada aberta por muito tempo, até uma pergunta de uma linha gera uso equivalente à conversa inteira.

Segundo, sessões que dependem de subagentes parecem pequenas vistas pela conversa principal. Em D e E, os subagentes responderam por 44% e 54% do uso ponderado pelo preço, respectivamente. Olhando a conversa principal na barra lateral, você nunca vê essa parte.

Terceiro, mais da metade das sessões quase não usou nada. O seu limite não esvazia mais rápido porque você tem muitas sessões abertas; são poucas sessões pesadas que o esvaziam. Se for agir, começar por essas poucas já basta. O que cortar primeiro está em Dicas para economizar tokens no Claude Code e o custo extra ao atingir o limite.

6. Como ler os números, e até onde eles valem

7. Para acompanhar daqui em diante, use o OpenTelemetry

A vantagem de agregar os logs é que você vê os últimos 30 dias na hora. Se, em vez disso, você quer acompanhar daqui para a frente, o OpenTelemetry, o recurso oficial de monitoramento, é a opção mais adequada.

Quando ele está ativado, o Claude Code exporta uma métrica de tokens, claude_code.token.usage (com os tipos input, output, cacheRead e cacheCreation), e uma métrica de custo, claude_code.cost.usage. As duas trazem session.id por padrão (OTEL_METRICS_INCLUDE_SESSION_ID, padrão true). Como isso não lê os arquivos de log, as linhas duplicadas da armadilha 1 nunca entram na conta, e o uso dos subagentes é registrado à parte em query_source (main, subagent, auxiliary).

Para testar localmente primeiro, inicie o Claude Code com o exportador configurado para imprimir no terminal, como mostra a documentação.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000
claude

Para agregar de forma contínua, defina OTEL_METRICS_EXPORTER=otlp e envie os dados para um destino que você mesmo mantém (um backend de monitoramento que aceite OTLP). Você precisa montar esse destino, e nada do que aconteceu antes da ativação fica registrado: essas são as diferenças em relação a agregar os logs.

Fonte: documentação do Claude Code, "Monitoring" (nomes das métricas, atributos, variáveis de ambiente)

FAQ

Q1. O detalhamento do plano no /usage não basta?
Ele mede em outro eixo. O detalhamento do plano mostra, em percentuais, para quais Skills, subagentes, plugins e servidores MCP o uso foi, e não mostra qual sessão o consumiu. Para rastrear o que está esvaziando o seu limite pelo lado dos recursos, use o /usage; pelo lado das sessões, use a agregação deste artigo.

Q2. Posso usar uma ferramenta de agregação pronta?
Pode. A ferramenta não oficial ccusage, por exemplo, gera relatórios por sessão a partir dos mesmos logs. Antes de usar uma, confira duas coisas. Primeiro, se todo o processamento fica na sua máquina: os logs contêm resultados de ferramentas, sem criptografia. Segundo, como ela conta: para ter certeza de que ela trata linhas duplicadas e subagentes do mesmo jeito, compare uma vez a saída dela com a do script deste artigo.

Q3. Quero incluir o uso de outras máquinas e do claude.ai.
Os logs só ficam guardados em cada máquina, então você agrega em cada uma e soma os resultados. Os chats no claude.ai não são registrados nos logs do Claude Code. Para saber quanto do plano resta no geral, o lugar confiável para olhar são as barras de progresso em Settings > Usage no claude.ai.

Q4. Quero guardar os logs para poder agregar usos mais antigos também.
Para sessões usadas no terminal, aumente cleanupPeriodDays no settings.json e elas ficam guardadas por mais tempo. Sessões que você iniciou ou continuou por último no app desktop (ou no Cowork) já são mantidas sem limite de idade a partir da v2.1.248 (para definir um limite, use desktopSessionCleanupPeriodDays). Note, porém, que a documentação cita reduzir esses valores como forma de diminuir a exposição dos logs. Quanto mais tempo você os guarda, mais tempo registros sem criptografia ficam na sua máquina, então leve isso em conta.

Fontes

• Claude Code Docs — Manage costs effectively (o bloco Session e o detalhamento do uso do plano no /usage, a observação de que os valores são calculados a partir do histórico desta máquina, /insights, painéis da organização, por que o uso cresce em sessões longas)
• Claude Code Docs — Explore the .claude directory (onde os logs ficam, subagents/, o padrão de 30 dias do cleanupPeriodDays e o tratamento das sessões do app desktop, a falta de criptografia)
• Claude Code Docs — Desktop (o anel de uso)
• Claude Help Center — Usage limit best practices (o que Settings > Usage mostra)
• Claude Code Docs — Monitoring (nomes das métricas do OpenTelemetry, session.id, variáveis de ambiente)
• Claude Platform Docs — Pricing (preços por modelo, multiplicadores de cache)

Artigos relacionados

• Claude Code: o que está consumindo o seu contexto? — por que cada resposta fica pesada
• Claude Code "usage limit reached": limites de 5 horas e semanal — quando você bate no limite
• Dicas para economizar tokens no Claude Code e o custo extra ao atingir o limite — o que cortar primeiro
• O limite semanal do Claude Code e os resets antecipados — como funciona o limite semanal