Claude Code Usage (2026): Check Limits, Track Spend & Monitor Sessions

Check Claude Code usage with /usage in the CLI or at claude.ai/settings/usage. Subscription limits sit on two clocks: a 5-hour rolling window (short-term throttle) plus a weekly cap (long-term ceiling). When either fills, you wait for reset, upgrade, or switch that work to the API — not a mystery token counter you never see.

That’s the short answer. The rest is how those limits actually behave, how to check them mid-session, which trackers are worth installing, why heavy agent days burn the window faster than chat, and how to watch sessions when you’re not at the desk.

How Claude Code usage limits actually work

Claude Code on a Claude subscription (Pro / Max / Team Premium) is not billed per token the way the API is. You pay a flat monthly seat and Anthropic meters shared usage across Claude Code and the Claude apps. The product does not publish a permanent “you get N million tokens” number for Pro or Max. Instead you get relative capacity by plan (Pro and Max tiers differ) and live remaining allocation in the product UI.

Two clocks matter in practice:

1. 5-hour rolling window — the short-term throttle. Heavy agent work can chew through a meaningful slice of one window even when your week still has headroom. As the window rolls forward, capacity frees up without waiting for calendar midnight.
2. Weekly cap — the long-term ceiling. You can stay under the 5-hour bar all day and still hit the week if you run long autonomous sessions every day. Max plans also surface model-class nuance (for example separate pressure on Sonnet-class models); trust the bars on your account rather than a blog’s fixed multiplier table.

Pro vs Max in one breath. Pro is comfortable for light agent use mixed with chat; it is a poor all-day driver if every session is a multi-file refactor. Max is the “I code with an agent most workdays” tier, with higher capacity for multi-hour or multi-agent days where Pro users would live in reset timers. Exact plan prices and relative capacity live in our Claude Code pricing guide — this article stays on how usage is measured and monitored, not the price table.

API path is different. On Console/API keys there is no subscription-style usage window. You pay input/output tokens, set spend limits yourself, and still hit API rate limits. Usage tracking then means cost dashboards and token logs, not a 5-hour bar.

Anthropic changes caps and UI labels over time. Treat mechanism (rolling window + weekly ceiling + relative tiers) as stable; treat any blog’s absolute token guesses as stale the day after publication. Your source of truth is always the in-product usage page for the signed-in account.

How to check your usage

You need three layers: instant CLI feedback, the account usage page, and optional local trackers for history.

1. /usage in Claude Code. Mid-session, run /usage (and related status surfaces your client version exposes) to see remaining window / weekly headroom without leaving the terminal. Use this when you feel a long refactor accelerating and want to know whether to finish now or split the work.

2. Claude settings → Usage. Open claude.ai/settings/usage (or the in-app Settings → Usage path on desktop/mobile). This is the account-level view of shared subscription metering — Claude Code and chat draw from the same pool on Pro/Max. If CLI and web disagree for a few minutes, refresh and re-check after the current turn settles; the settings page is the product source of truth.

3. Statusline / session chrome. Newer Claude Code builds surface compact usage hints in the statusline or session chrome so you notice “approaching limit” before the hard stop. Treat those as early-warning, not a historical dashboard.

What you will not get from Anthropic alone: a full multi-week chart of every tool call, MCP token burn, or “which skill ate Tuesday.” For that people reach for local usage trackers and session monitors — next section.

Subscription vs API check. On subscription, watch windows and weekly bars. On API, watch Console spend, rate-limit headers, and your own logging. Mixing both on one machine is fine; do not assume /usage on a sub-backed CLI explains an API key’s bill.

Usage trackers and monitors compared

Search interest for claude usage tracker, claude code usage monitor, and claude usage tracker extension is real because the official UI answers “how much do I have left?” better than “what burned last week?” Community tools fill the history gap. Categories, not product endorsements:

Approach	Examples (community)	How it works	Strength	Weakness
Local log / cost CLI	ccusage-style tools	Read local Claude Code session logs or cost files on disk	Fast, private, good for post-hoc spend	Needs local files; no phone view; format can break on CLI upgrades
Realtime usage monitor	Claude-Code-Usage-Monitor class apps	Poll or stream usage/status while you work	Catches window pressure live	Another process to trust; OAuth or log access setup
Editor extension	VS Code “usage tracker” extensions	Badge or panel inside the IDE	Low friction if you live in VS Code	Often Claude.ai or API oriented; may not match Claude Code agent windows 1:1
Official product only	/usage + settings/usage	Anthropic’s own meters	Authoritative for limits	Weak historical analytics

Local logs vs OAuth API. Local readers never leave your machine but only see what the CLI wrote. OAuth / account API style tools can mirror account-level bars but require login scopes and break when Anthropic changes endpoints. Prefer tools that are open-source enough to audit, pin a version, and fail closed if auth dies — not a random marketplace badge that phones home.

Realtime vs after-the-fact. Realtime monitors help you stop a runaway agent before the weekly bar hits 100%. After-the-fact CLIs help you answer “was it MCP, subagents, or plain Opus verbosity?” Prefer one of each only if you actually look at the history; two dashboards you ignore are noise.

None of these replace the official settings page for “am I allowed to start another Max session right now?” Trackers are for visibility and habit; Anthropic’s UI is for the hard gate.

Why your usage burns faster than expected

If chat feels cheap and Claude Code feels expensive, that is usually correct. An agent loop is not one prompt — it is many tool rounds, re-reads of the same files, diffs, test output, and often subagents. A few concrete burn multipliers:

MCP servers and plugins inflate context. Every connected MCP server and tool schema sits in the model’s working set. “Just in case” servers you never call still cost context on each turn. Disable unused MCP servers for long sessions; load only the tools the task needs.

Long sessions that never compact. Leaving one session open all day with growing transcript, failed approaches, and huge tool results keeps replaying history. Start a fresh session for a new goal, or use compact / clear flows your client provides, so the agent is not re-paying for dead ends.

Subagent concurrency. Parallel subagents multiply tool calls and context. Great for wall-clock speed on independent work; terrible for a Pro window if you spawn four explorers for a one-file bug. Cap concurrency when you are near a limit.

Wrong model for mechanical work. Flagship models burn the same window faster in practice because turns are longer and outputs are larger. Route routine edits to a cheaper/faster model when your client allows model choice; save flagship capacity for hard reasoning. Pricing detail: Claude Code pricing guide.

Permission thrash and retry loops. An agent stuck re-running the same failing command or re-reading the same 2k-line file without a plan is pure waste. Interrupt early, restate the goal, or constrain the path — do not “let it cook” when the statusline already says you are near the bar.

Actionable defaults. One goal per session. Trim MCP. Compact when context is fat. Prefer Max only after you measure real weekly agent hours — not gut feel alone. If you hit limits every afternoon on Pro, that is a signal to change workflow or tier — not a bug in the meter.

Monitor your agents from anywhere

Official usage bars answer “how much quota left?” They do not answer “what is the agent doing on my machine while I am away?” SeaWork is a local control surface for coding agents already running on your machine: see sessions and activity from your phone, approve or steer without re-hosting the repo. For Codex-side metering see Codex usage; for the product surface see remote control. Quota still comes from Anthropic (or your API key); SeaWork does not replace /usage — it keeps the live agent legible when you leave the desk.

FAQ

How do I check Claude Code usage? Use /usage in the Claude Code CLI for a mid-session snapshot, and open claude.ai/settings/usage (or Settings → Usage in the apps) for the account-level bars. Those two are official. Optional community trackers (ccusage-style CLIs, usage monitors, VS Code extensions) add history and local cost views but are not the source of truth for whether you can start another turn.

What happens when I hit the limit? On a subscription, new Claude Code work waits until the 5-hour rolling window and/or weekly cap free capacity again — or you upgrade the plan, thin out concurrent agents, or move that workload to the API path. The active turn may finish under product rules; do not expect unlimited catch-up. On the API there is no subscription window; you hit rate limits or spend caps you configured instead.

Do MCP servers count against usage? Yes in practice. MCP tool schemas and results consume context that subscription windows and API tokens both meter. Idle “connected but unused” servers still cost context each turn. Keep only the MCP servers the current task needs if you are burning windows faster than expected.