Skip to main content
Glama
PavolKum

claude-quota-mcp

by PavolKum

claude-quota-mcp

Let your agent check its own Claude usage limits, so it can plan long-running work around resets instead of dying mid-task.

Every Claude usage monitor renders for human eyeballs: statuslines, tray apps, terminal dashboards. This is the other direction: a single MCP tool the agent calls to answer questions like:

  • "The session window resets in 40 minutes and I'm only at 30%. Front-load the heavy work now."

  • "The weekly window is at 85%. Downshift to a cheaper model before the wall, not after."

  • "Quota resets before this migration would finish. Schedule the second half for the next window."

Where the numbers come from

The tool tries three sources, best first, and always says which one answered.

Source

What it is

Credential

Network

Windows

Statusline snapshot (default)

The documented rate_limits fields Claude Code pipes to its statusline command (five_hour and seven_day: used_percentage, resets_at), persisted locally by claude-quota-statusline

none

none

5-hour, weekly (account-wide)

OAuth usage endpoint (opt-in only)

The undocumented endpoint behind Claude Code's /usage, reached with your Claude Code OAuth token

your Claude Code token, read-only

api.anthropic.com, cached 180 s

5-hour, weekly, per-model weekly

Local estimate (fallback)

Reconstruction from ~/.claude/projects/**/*.jsonl using the ccusage "blocks" method

none

none

5-hour, times exact, percent estimated against this machine's own history

Why the endpoint is off by default. Anthropic's Claude Code legal page says the consumer OAuth token is intended exclusively to support ordinary use of Claude Code and other native Anthropic applications, and the endpoint is not documented. Anthropic publishes no usage or quota API for individual Pro or Max subscriptions. The statusline fields, by contrast, are documented at https://code.claude.com/docs/en/statusline, carry exact subscriber numbers, and need no credential at all. So that is the default. If you understand the terms question and still want the per-model windows, set CLAUDE_QUOTA_ALLOW_OAUTH_ENDPOINT=1 for the MCP server or hook, or pass --allow-oauth to the CLI. The request then identifies itself honestly as claude-quota-mcp; nothing here impersonates Claude Code.

Limits of the statusline source, stated plainly: account-wide windows only, no per-model weekly window; data exists only after Claude Code has made its first API response and rendered a statusline; freshness equals the last render, and the tool reports the snapshot age and labels it stale after fifteen minutes.

Related MCP server: Claude Code Usage

What it returns

| Window | Used | Resets in | Severity |
|---|---|---|---|
| 5-hour session | 17% | 4h 36m | normal |
| Weekly (all models) | 5% | 2d 3h | normal |

Why exact percentages matter: local-transcript estimators can only guess percent-used against your own historical maximum. On the machine this was built on, that estimate said 0.7% when the real figure was 13%. Reset times reconstruct fine locally; percentages don't.

Install

Source: https://github.com/PavolKum/claude-quota-mcp. PyPI release: pending (the uvx claude-quota-mcp one-liner will appear here once the first release is published). Until then install straight from GitHub, or from a local clone:

python -m pip install git+https://github.com/PavolKum/claude-quota-mcp
# or, inside a clone:
python -m pip install .

Then register the MCP server with your host. Claude Code:

claude mcp add quota -- claude-quota-mcp

Any MCP host's config:

{
  "mcpServers": {
    "quota": { "command": "claude-quota-mcp" }
  }
}

Non-MCP agents and scripts can shell out instead:

python -m claude_quota                # best available source, JSON
python -m claude_quota --local        # force the transcript estimate
python -m claude_quota --allow-oauth  # permit the undocumented endpoint for this call
python -m claude_quota --codex        # Codex snapshot only

Feed the snapshot: the statusline command

The default source needs Claude Code to hand its statusline payload to this package once per render. Two ways:

Standalone. Use the bundled command as your statusline. It writes the snapshot and prints a compact (5h) 53% (7d) 6%:

"statusLine": { "type": "command", "command": "claude-quota-statusline" }

Alongside your own statusline. Run it quietly first, then your script, by teeing stdin to both (any shell that has tee and process substitution):

tee >(claude-quota-statusline --quiet) | python my_statusline.py

Or call it from Python inside your statusline:

from claude_quota.statusline import write_snapshot
write_snapshot(stdin_data)  # the parsed JSON Claude Code piped in

Only the documented rate_limits fields are persisted. Session ids, working directories, model names and context-window data in the payload are not written anywhere. Snapshot location: %LOCALAPPDATA%\claude-quota-mcp\statusline-snapshot.json (override with CLAUDE_QUOTA_SNAPSHOT).

The hook: quota awareness the agent can't forget

A tool the agent must remember to call gets forgotten exactly when it matters, deep in a long task. The included quota-guard hook inverts that: quota state is pushed into context instead of pulled.

  • SessionStart: always injects a one-line baseline (5h session 23% (resets 4h 11m); weekly 5% ...).

  • UserPromptSubmit: silent in the common case; speaks only when a window crosses a threshold (default 70%), severity escalates, or there's an opportunity: the session window resets soon with usage to spare. Unused quota expires at reset, so it nudges the agent to front-load heavy work. Repeats are throttled per session.

Claude Code settings.json:

"hooks": {
  "SessionStart":     [{ "hooks": [{ "type": "command", "command": "claude-quota-hook" }] }],
  "UserPromptSubmit": [{ "hooks": [{ "type": "command", "command": "claude-quota-hook" }] }]
}

Tune with env vars: QUOTA_HOOK_WARN_PERCENT (70), QUOTA_HOOK_OPPORTUNITY_MINUTES (60), QUOTA_HOOK_OPPORTUNITY_MAX_PERCENT (50), QUOTA_HOOK_REMIND_MINUTES (30). The hook reads the statusline snapshot, so per-prompt frequency costs nothing.

Every emitted line carries the current local time (Now Fri 2026-07-18 15:04); agents have no clock, and "resets in 40m" is meaningless without one. Set QUOTA_HOOK_TIME_ALWAYS=1 to also emit a minimal <now> tag on every prompt even when quota has nothing to say (about 10 tokens of temporal grounding; default off).

Codex too

The same tool reports OpenAI Codex limits (provider: "codex"; the default "all" covers both). Codex CLI echoes the server's own rate-limit state into its local rollout logs (~/.codex/sessions/**/rollout-*.jsonl), so the exact numbers are read straight from disk: no token, no endpoint, no rate-limit risk. Freshness equals Codex's last activity and is always reported (snapshot_age_seconds). This is the same local-only pattern the Claude statusline source follows.

To let Codex check its own quota, register the server in ~/.codex/config.toml:

[mcp_servers.quota]
command = "claude-quota-mcp"

Design notes

  • One tool, tiny schema. MCP servers tax every message with their tool schemas; this one adds a single tool with two optional parameters.

  • Documented sources first. Both default sources (Claude statusline snapshot, Codex rollout logs) are local files written by the vendors' own tools. No credential leaves the machine unless you opt in.

  • 429-safe when opted in. The OAuth endpoint rate-limits aggressively per token. Responses are disk-cached (180 s TTL, shared across processes), and any network failure serves stale cache before falling back.

  • Graceful degradation. No snapshot, no opt-in, offline: falls back to the local transcript reconstruction (times exact, percent estimated) and says so in the output. It never fails silently into wrong numbers.

  • Stdlib core. quota.py and statusline.py are plain stdlib; mcp and pydantic are needed only by the MCP server itself.

Tests

python test_hook_bridge.py
python test_statusline.py

Why this exists

Built as a side quest of a multi-agent orchestration experiment: agents coordinating over a shared bus needed to decide when to push hard and when to wind down a lane, which turns out to require knowing your own quota.

MIT licensed.

Available Tools

1 tool
quota_statusA

Check the agent's own usage limits so long-running work can be planned around resets - e.g. if a window resets soon with usage to spare, front-load heavy work now. Providers: 'claude' (5-hour and weekly percentages from the documented Claude Code statusline snapshot, no credential; the undocumented OAuth usage endpoint only when the host opted in via CLAUDE_QUOTA_ALLOW_OAUTH_ENDPOINT=1; transcript-estimate fallback) and 'codex' (latest server-issued rate-limit snapshot from local Codex rollout logs - exact numbers, freshness = Codex's last activity). Default 'all' reports both.

ParametersJSON Schema
NameRequiredDescriptionDefault
providerNoall
response_formatNomarkdown

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so well: it discloses the data sources per provider, that the statusline snapshot needs no credential, that the OAuth endpoint is undocumented and gated behind CLAUDE_QUOTA_ALLOW_OAUTH_ENDPOINT=1, that there is a transcript-estimate fallback, and that Codex freshness equals the last activity in local rollout logs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and use case are front-loaded in the first sentence, with provider detail following. The nested parentheticals make the second sentence dense, but nearly every clause carries load-bearing information about data provenance and caveats.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. The description covers the provider semantics, data sources, credential requirements, and freshness caveats an agent would need before invoking the tool, leaving no significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for the provider enum: it explains what 'claude' and 'codex' return, their provenance, and that default 'all' reports both. The response_format parameter is never mentioned, but its markdown/json enum is self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Check the agent's own usage limits') and immediately frames the scope as the agent's own quota, not general account usage. It also distinguishes the tool's purpose from generic monitoring by tying it to planning long-running work around resets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete when-to-use scenario: front-load heavy work if a window resets soon with usage to spare. There are no sibling tools, so no alternatives need naming, but no explicit when-not-to-use condition is offered either.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.2.1
    • First observedquota_status

TDQS

A4.6/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection between tools. Its purpose (report agent usage limits across providers) is clearly stated and self-contained.

Naming Consistency5/5

A single tool named quota_status in snake_case noun_status form; a lone name cannot conflict with any other convention. It is readable and predictable.

Tool Count4/5

One tool is thin against the 3-15 guideline, but the server's scope is a narrow read-only status probe, so a single entry point is defensible. No tool feels redundant or bolted on.

Completeness4/5

The domain is quota/limit reporting, and the tool covers both providers with default 'all' plus fallbacks, which is close to a complete surface for a read-only probe. It lacks historical usage or per-model breakdowns, but these are minor gaps an agent can work around.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    Not graded
    maintenance
    Provides real-time visibility into Claude Pro and Max subscription usage limits directly within Claude Code by utilizing local OAuth tokens. It enables users to monitor session and weekly usage across different models and receive alerts regarding rate-limiting status.
    4
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Surface Claude Code token usage, estimated cost, and plan-limit status in any MCP client. Enables agents to query usage data from local logs and Anthropic API.
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides coding agents with pre-flight cost estimation by analyzing local logs to forecast token usage and quota impact before expensive work, exposing tools for remaining quota, per-task cost estimates, and attempt affordability.
    26 npm
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables agents to check remaining Anthropic and OpenAI rate-limit quotas with reset times, plus Hermes Agent token usage, so bots can throttle or stop before hitting limits.
    MIT