How to Track Claude Code Usage, Tokens, and Spend

1. Identify the billing path before reading the numbers

Claude Code can consume an individual Claude subscription, an eligible Team or Enterprise seat, or usage from an Anthropic Console API key. Those paths do not report cost in the same way. A Pro or Max user is consuming plan capacity; an API-key user is creating metered token spend; an organization may also have administrator analytics.

Start each setup by checking which account is signed in and whether an ANTHROPIC_API_KEY is intentionally present in the environment. This prevents a common mistake: assuming a session is covered by a subscription while it is actually billing the API account.

2. Check usage, cost, and context inside the session

Claude Code exposes different views for different questions. Use /usage to inspect plan and rate-limit status, /cost to review session token usage and spend when cost reporting applies, and /context to see what is occupying the current context window. /model helps confirm which model the session is using before a large task begins.

Check these views at natural boundaries: after repository exploration, before a large refactor, and after a tool-heavy debugging loop. The goal is not constant surveillance. It is to catch a growing context, an unexpectedly expensive model, or an unintended billing path while the session is still easy to correct.

1. At the start, confirm the signed-in account and selected model.
2. After exploration, open /context and remove or compact material that no longer helps the task.
3. For API-billed work, check /cost after a representative task and use it as a baseline—not a guarantee for every future task.
4. For subscription work, check /usage before starting another long agentic run.

3. Understand shared subscription limits

For Pro and Max users, Claude and Claude Code draw from shared capacity. A long coding session can therefore affect availability in the Claude app, and heavy app usage can affect the next Claude Code session. Published capacity is variable because task complexity, model choice, conversation length, and tool use all matter.

When a warning appears, reduce unnecessary context first. Split unrelated work into a new session, ask for smaller outputs, and use a faster model when frontier reasoning is not required. Upgrading should be the last step after confirming that the workload—not an avoidable workflow habit—is driving the limit.

• Do not translate a plan warning into a fabricated token allowance.
• Do not assume every repository or prompt consumes capacity at the same rate.
• Do record the task type and model when a limit arrives earlier than expected.

4. Use organization analytics when your role supports them

Eligible Team, Enterprise, and Console roles can use Claude Code analytics for an organization-level view. This is useful for adoption, activity, and cost governance, but it is not a substitute for understanding an individual session. Personal Pro and Max accounts should not expect the same administrative dashboard.

For teams, review trends by week rather than reacting to one expensive day. Pair usage data with successful task counts, pull requests, or time saved. Cost per successful outcome is more useful than raw token volume because a cheap run that produces rework is not actually efficient.

5. Adopt a ten-minute weekly review

Review which model handled each recurring workflow, which sessions repeatedly filled their context, and whether API-billed tasks had a stable cost range. Then choose one adjustment for the next week: a smaller model for routine edits, a shorter repository briefing, or a fresh session between unrelated tasks.

Use the calculator to compare the observed API-equivalent value with your subscription fee. Because Claude plan limits are variable, treat the result as a decision aid and keep the provider evidence open before buying or upgrading.

• Record one representative /cost result for each API-billed workflow.
• Record when shared plan warnings appear and what task preceded them.
• Remove stale instructions and duplicated context from project setup files.
• Revisit the plan only after two or three weeks of comparable data.