Skip to main content
Glama
pihme
by pihme

claude-budget-mcp

CI License: MIT Release Website Node.js

A small, local MCP server (stdio) that lets a Claude Code agent ask "how much of my 5-hour and weekly usage limits is left, and when do they reset?" — the same figures the interactive /usage command shows for a Claude subscription (Pro, Max, Team, Enterprise).

Today an agent has no first-class way to get these numbers: /usage is interactive, and the status line's rate_limits only reach the status line script. This server reads your existing Claude Code login and returns the figures as JSON. It is the sister project of grok-budget-mcp.

WARNING

Unofficial, undocumented endpoint. This server calls https://api.anthropic.com/api/oauth/usage, the private route Claude Code itself uses for /usage. It is not a public Anthropic API, has no stability guarantee, and Anthropic can change or remove it at any time. When the shape changes, this server fails loudly (error or warning + null fields) instead of guessing numbers.

Terms of service / risk. Calling private product endpoints may conflict with Anthropic's terms. Use it only as a personal, local helper with your own account — not as a hosted or shared service. You are responsible for how you use it. This project is not affiliated with or endorsed by Anthropic.

NOTE

Linux first. The server reads the login from ~/.claude/.credentials.json, where Claude Code keeps it on Linux (and Windows). On macOS Claude Code stores it in the Keychain instead, which this version does not read.

What it does

One tool, get_budget, with no input. Each call re-reads the credentials file and makes exactly one HTTPS request (15 s timeout, no retries, no caching).

get_budget output

All fields are always present; anything the endpoint did not return is null and explained in warning.

Field

Meaning

session_used_percent / session_remaining_percent

The 5-hour session window (five_hour.utilization), remaining clamped to [0, 100]

session_resets_at

When the 5-hour window resets

weekly_used_percent / weekly_remaining_percent

The weekly window across all models (seven_day.utilization)

weekly_resets_at

When the weekly window resets

windows

Every window found as { window, used_percent, remaining_percent, resets_at }: five_hour, seven_day, per-model buckets like seven_day_opus, and weekly_scoped:<model> rows from limits[]. Buckets that are null upstream are left out.

subscription_type

Your plan as stored by Claude Code (e.g. max), or null

source

always "api.anthropic.com:/api/oauth/usage"

fetched_at

ISO 8601 time of the fetch

warning

Human note when data is partial or the shape looks different; null when everything was present

Example (illustrative values):

{
  "session_used_percent": 24,
  "session_remaining_percent": 76,
  "session_resets_at": "2026-10-02T22:00:00.000000+00:00",
  "weekly_used_percent": 61.5,
  "weekly_remaining_percent": 38.5,
  "weekly_resets_at": "2026-10-06T08:00:00.000000+00:00",
  "windows": [
    { "window": "five_hour", "used_percent": 24, "remaining_percent": 76, "resets_at": "2026-10-02T22:00:00.000000+00:00" },
    { "window": "seven_day", "used_percent": 61.5, "remaining_percent": 38.5, "resets_at": "2026-10-06T08:00:00.000000+00:00" },
    { "window": "seven_day_opus", "used_percent": 12, "remaining_percent": 88, "resets_at": "2026-10-06T08:00:00.000000+00:00" }
  ],
  "subscription_type": "max",
  "source": "api.anthropic.com:/api/oauth/usage",
  "fetched_at": "2026-10-02T19:00:00.000Z",
  "warning": null
}

Mapping rules: numbers are never invented. A missing 5-hour or weekly window gives null fields and a warning. If no window with a utilization can be parsed at all, the tool returns an error.

Errors

Errors are returned as MCP tool errors (isError: true) with a code and a readable message:

Situation

Message

Credentials file missing / unreadable

NOT_LOGGED_IN — run claude and sign in with /login

No claudeAiOauth.accessToken (API key, Bedrock, Vertex, …)

AUTH_SHAPE_UNEXPECTED — only claude.ai subscription logins have usage windows

expiresAt is in the past

SESSION_EXPIRED — use Claude Code once (it refreshes its own token) or /login (no request is made)

HTTP 401 / 403

UNAUTHORIZED — same hint

HTTP 429

RATE_LIMITED — retry later; do not call in a loop

HTTP 5xx / other / network / timeout

REQUEST_FAILED — includes the HTTP status if any

200 but unparseable / no usage window

SHAPE_CHANGED — usage response shape changed

Anything else (unexpected internal error)

INTERNAL — generic message; details are never echoed

Related MCP server: claude-usage-mcp

Token handling (read-only)

  • Reads $CLAUDE_CONFIG_DIR/.credentials.json if CLAUDE_CONFIG_DIR is set, else ~/.claude/.credentials.json, the file Claude Code writes on /login.

  • Uses claudeAiOauth.accessToken as the Bearer token; expiresAt is checked locally.

  • Never refreshes the token, never writes the file, never calls an auth endpoint. Claude Code rotates the refresh token on every refresh, so an outside refresh could sign out your sessions.

  • Never logs, prints or returns the token, the Authorization header, or the raw upstream body.

  • No secrets go into MCP config env.

Request sent (once per tool call):

GET https://api.anthropic.com/api/oauth/usage
Authorization: Bearer <accessToken from .credentials.json>
anthropic-beta: oauth-2025-04-20
Accept: application/json
User-Agent: claude-budget-mcp/<version>

The base URL can be overridden with CLAUDE_BUDGET_MCP_BASE_URL (for tests or a proxy). The server identifies itself honestly; the endpoint is known to rate-limit clients that are not Claude Code more strictly, so call it once before expensive work rather than often.

Install / build

Requires Node.js 22+.

git clone https://github.com/pihme/claude-budget-mcp.git
cd claude-budget-mcp
npm install        # also builds dist/ via the prepare script
npm run build      # tsc -> dist/
npm test           # unit + stdio smoke tests (mocked fetch, fixture credentials)
npm run smoke      # optional: start the server over stdio, list tools, call get_budget once with YOUR login

Prebuilt alternative: each release has a claude-budget-mcp-X.Y.Z.tgz (built dist/, no build step); npm install -g ./claude-budget-mcp-X.Y.Z.tgz puts claude-budget-mcp on your PATH. Versions follow SemVer; nothing is published to npm.

Wiring into Claude Code

claude mcp add --scope user claude-budget -- node /path/to/claude-budget-mcp/dist/index.js
# or, with the binary on your PATH:
claude mcp add --scope user claude-budget -- claude-budget-mcp

Check it with claude mcp list or /mcp. The tool appears as mcp__claude-budget__get_budget. No env is needed. See the official Claude Code MCP docs.

A good agent instruction (for example in CLAUDE.md): "Before starting long or expensive work, call mcp__claude-budget__get_budget once; if session_remaining_percent or weekly_remaining_percent is low, tell me and ask before continuing."

Not covered

  • macOS Keychain logins, CLAUDE_CODE_OAUTH_TOKEN from claude setup-token, API keys, Bedrock, Vertex, Foundry.

  • Not API-key rate limits or Console spend — different ledgers.

  • No dollar cost (Claude Code computes that on the client), no extra-usage spend, no caching or polling.

Background

Design notes and the research behind this server: SPEC.md. Community prior art that documents the endpoint (not endorsements): andrewleech cc-usage, FullFran/claudeops-tui, cship.

Contributing

Issues, ideas and pull requests are welcome: see Contributing. Website and handbook: pihme.github.io/claude-budget-mcp.

License

MIT

Available Tools

1 tool
get_budgetClaude usage limitsA
Read-onlyIdempotent

Return the Claude subscription's usage limits (same figures as /usage): the 5-hour session window (session_*) and the weekly window across all models (weekly_*), each with used and remaining percent and reset time. windows lists every window found, including per-model weekly limits, so you can pick the relevant one. Data comes from an UNOFFICIAL, undocumented endpoint; null fields plus warning mean partial data. Call it once before expensive work; do not poll in a loop.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description goes further with genuinely non-obvious traits: the data source is an UNOFFICIAL, undocumented endpoint, and 'null fields plus `warning` mean partial data'. It doesn't state rate limits or caching beyond the no-polling warning, but this is well above the annotation baseline.

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

Conciseness5/5

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

Three sentences, each carrying distinct load: what is returned, how to interpret partial data, and how often to call. The critical 'what/when' content is front-loaded and there is no filler.

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?

No output schema exists, so the description must carry the return-shape burden, and it does — naming the window types, the percent fields, the reset time, and the `windows` list. Combined with the partial-data warning, an agent has everything needed to call and interpret this tool.

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?

The tool takes no parameters, so the 4 baseline applies. The description's field-level detail (session_*, weekly_*, windows) actually documents return shape rather than inputs, which is useful but doesn't change the zero-parameter picture.

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?

States a specific verb and resource ('Return the Claude subscription's usage limits') and enumerates exactly which figures come back (5-hour session window, weekly window across all models, used/remaining percent, reset time). There are no siblings to disambiguate from, but the scope is unambiguous on its own.

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

Usage Guidelines5/5

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

Gives explicit timing guidance — 'Call it once before expensive work; do not poll in a loop' — which tells the agent both when to invoke it and a concrete anti-pattern to avoid. That is the strongest form of usage guidance available for a zero-param read tool.

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.1.0
    • First observedget_budget

TDQS

A4.6/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or misselection. The single tool's purpose is clear and distinct.

Naming Consistency5/5

The tool name 'get_budget' follows a clear verb_noun snake_case convention. With only one tool, consistency is trivially maintained.

Tool Count4/5

One tool is slightly under the typical 3-15 range, but it perfectly matches the narrow read-only scope of fetching a single usage endpoint. No additional tools are needed for the stated purpose.

Completeness4/5

The tool covers the core read operation for subscription usage limits, including session and weekly windows with detailed fields. However, it lacks any write or management operations for budgets or alerts, which the server name might imply.

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
    -
  • F
    license
    A
    quality
    C
    maintenance
    Reports your Claude subscription usage (5-hour and weekly limits) with a forecast and velocity recommendation, using Claude Code's existing OAuth session without requiring an API key.
    2
    4
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables Claude Code sessions to check account rate-limit headroom, local token spend, and live session status, with read-only MCP tools for limits, summaries, token usage, and session listing.
    MIT