Usage draining fast? Find which session used it

Why it happens

Over the last two weeks there's been a run of reports of limits filling faster than expected: a Team plan's weekly limit at 100% about 30 hours after reset (#107390), the same workload draining much faster since mid-October (#105621), and one 5-hour session taking half the weekly limit (#106274). Only Anthropic can say whether plan accounting changed.

But some causes you can check on your own Mac. Two background subagents told to open 93 images once each made 19,099 Read calls and used up the plan limit twice (#106556); a subagent waiting on its own background work kept waking the parent with "Waiting." notifications, each costing a full turn (#105928); a one-minute /loop ran 1,200 times overnight for about 400M tokens (#106522). A Mac that sleeps and wakes mid-run, rewriting its context each time, adds to it too.

Finding it yourself

1. See what's running now: in a session, /usage (aliases /cost, /stats) shows plan usage and this session's cost, and /tasks lets you view and manage the subagents and shells running in the background (as of Claude Code 2.1.317). With several sessions you have to check each one. If you see a runaway loop, press Esc in that session.

2. Total the last 24 hours by session: Claude Code writes each conversation to ~/.claude/projects/<project>/<session>.jsonl, subagents separately under <session>/subagents/, and records token counts in message.usage for each response. The command below adds up responses, output, input (including cache writes) and cache reads per file and lists the biggest first (needs jq: brew install jq). One response can be logged on several lines, so it counts each message.id once.

since=$(date -u -v-24H +%Y-%m-%dT%H:%M)
find ~/.claude/projects -name '*.jsonl' -mtime -1 -print0 |
while IFS= read -r -d '' f; do
  jq -r --arg s "$since" 'select(.message.usage and .timestamp >= $s)
    | [.message.id, .message.usage.output_tokens,
       (.message.usage.input_tokens + (.message.usage.cache_creation_input_tokens // 0)),
       (.message.usage.cache_read_input_tokens // 0)] | @tsv' "$f" 2>/dev/null |
  sort -u -k1,1 | awk -v f="${f#$HOME/.claude/projects/}" \
    '{o+=$2; w+=$3; r+=$4} END {if (NR) printf "%6d %10d %12d %14d  %s\n", NR, o, w, r, f}'
done | sort -k3,3nr | head -15

Reading it: a line with an unusually high response count usually means a loop, a path containing subagents is a subagent, and large input relative to responses often means a session that kept rewriting its context (after sleep or compaction, for example).

Limits: limits aren't a plain sum of tokens and the formula isn't published, so use these numbers only to compare where usage went. The log format isn't an official interface and can change with an update. With several GB of logs it takes about 30 seconds (checked on Claude Code 2.1.317, M1 Pro). You only see this Mac's logs, not usage from other devices or the web.

With Lidnight

Lidnight shows Claude's and Codex's 5-hour and weekly limits in the menu bar with when each will run out at the current pace, and breaks tokens down by AI, model and project (CSV export). The service map unfolds the subagents each session started, with their CPU and memory. Limits, today's usage and the service map are free; 7- and 30-day stats and an early warning when a limit drops fast are Pro. Costs are estimates at API prices, not your subscription bill, and it won't stop a loop for you. Why overnight Claude Code runs eat your limit

Checked 2026-11-11 against Claude Code 2.1.317 and the issues above. Things change; check for yourself.