OpenCodex Quota MCP
Retrieves OpenAI provider quota and balance data via the local OpenCodex dashboard, keeping OpenAI account-pool aggregates separate from the current account's quota, along with reset times and measurement timestamps.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@OpenCodex Quota MCPShow all provider quotas, balances, and reset times"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OpenCodex Quota MCP
A small, read-only MCP server that lets tool-capable models in Codex query provider quotas, balances and reset times from the local OpenCodex dashboard.
This is an independent third-party integration, not an official OpenCodex or OpenAI plugin. OpenCodex supplies the provider connections, authentication, quota collection and dashboard. This project exposes that existing data as one MCP tool; it does not implement its own provider billing integrations. See Acknowledgements.
What it does
Lists configured providers or filters by an exact provider name or dashboard label, case-insensitively.
Returns used and remaining percentages, balance text, reset times and measurement timestamps when available.
Keeps OpenAI account-pool aggregates separate from the current account's quota.
Marks missing readings as
unavailable_or_unsupported, rather than treating them as zero usage.Keeps dashboard session tokens, CSRF tokens, API keys and provider request headers out of tool results.
Related MCP server: openclaw-usage-mcp
Requirements
Node.js 22 or newer, npm, and Git if cloning.
A working OpenCodex installation, with configured providers and a dashboard accessible at
http://localhost:10100.Codex or another client supporting local stdio MCP servers, and a model that supports tool calls.
The MCP process and OpenCodex must run on the same machine. The dashboard address is fixed in this version.
Validated locally with OpenCodex 2.93.0, Node.js 24, and Windows. Ubuntu/Windows with Node.js 22/24 are included in CI for the offline tests. OpenCodex's dashboard interfaces are internal APIs and may change between versions. Remote dashboards and authentication setups that do not issue a local dashboard session are not supported.
Install in Codex
1. Download and install dependencies
git clone https://github.com/wujiseclusion/opencodex-quota-mcp.git
cd opencodex-quota-mcp
npm ciAlternatively, download and extract a release, then run npm ci inside the extracted directory. Keep this directory in a permanent location: Codex will launch the server from it.
2. Register the local MCP server
Windows PowerShell, from the project directory:
$nodePath = (Get-Command node).Source
$serverPath = (Resolve-Path ./server.mjs).Path
codex mcp add opencodex-quota -- $nodePath $serverPath
codex mcp get opencodex-quotamacOS / Linux, from the project directory:
codex mcp add opencodex-quota -- "$(command -v node)" "$(pwd)/server.mjs"
codex mcp get opencodex-quotaIf opencodex-quota is already registered and you want to replace it, run codex mcp remove opencodex-quota first. You can also configure it manually in ~/.codex/config.toml, using your own absolute paths:
[mcp_servers.opencodex-quota]
command = "/absolute/path/to/node"
args = ["/absolute/path/to/opencodex-quota-mcp/server.mjs"]
tool_timeout_sec = 150On Windows, forward slashes work in TOML paths, for example C:/tools/opencodex-quota-mcp/server.mjs. The optional 150-second timeout allows for slow dashboard queries and a single authentication retry. See the official Codex MCP documentation for client configuration.
3. Start a new Codex chat
Make sure OpenCodex is running, then start a new chat. If the tool is missing, check MCP settings and restart Codex if necessary. Ask:
Use get_provider_quotas to show all provider quotas, balances and reset times. Include the measurement time.
Or:
Check the remaining Anthropic quota with get_provider_quotas.
Tool reference
get_provider_quotas accepts one optional argument:
{}{ "provider": "anthropic" }Use the exact configured provider name or dashboard label. For example, anthropic, openai, deepseek or kimi, if configured. Omit the argument to discover names. No arbitrary URL, credential or write-operation parameters are exposed.
Field | Meaning |
| When this tool assembled its response; not the measurement time. |
| Timestamp supplied by the dashboard quota response. |
| Measurement timestamp and age, when supplied. |
| Used percentage and |
| Reset time, or |
| Balance as displayed by OpenCodex; no invented percentage or currency conversion. |
| Structured USD credit data when supplied by OpenCodex. |
| Account-pool summary and current-account quota, separately. |
| Whether OpenCodex reports a passive observation instead of an active measurement. |
|
|
All output timestamps use UTC ISO 8601. Convert them to the user's timezone when presenting them. For a pool, nextRecoveryAt describes the next capacity recovery, which is different from a full pool reset.
Data access and limitations
The server fetches the local dashboard HTML to obtain its session, then sends authenticated GET requests to /api/providers and /api/provider-quotas. Authentication is held in process memory and is not written to files. HTTP redirects are rejected. A 401/403 response triggers one session renewal and retry per request. Responses are projected to quota-related fields rather than forwarding provider configurations.
The tool uses OpenCodex's existing cache policy. It does not pass refresh=1, send model completions, change routing or modify provider settings. OpenCodex may itself contact providers or update its own caches while serving its quota endpoint. This is an on-demand query tool, not a background monitor.
Quota availability depends on OpenCodex and the upstream provider. A configured provider can have no supported quota interface or no current reading. This server cannot add missing upstream quota support. Balance-only readings are returned as balance text, without interpreting the dashboard's placeholder percentage. Model tool-call support must be checked separately; not every routed model has been tested.
Test
npm testRuns offline fixtures and a real stdio MCP handshake/tool-discovery test. It does not require OpenCodex, provider credentials or live quota queries. The live test is skipped by default.
With a running local OpenCodex dashboard and at least one configured provider:
npm run test:liveRuns the same suite plus real quota queries, provider filtering and unknown-provider handling. Live provider names/statuses may appear in the console; avoid sharing logs if those names are private. live-test.env only enables this test and contains no credentials.
Troubleshooting
Problem | Action |
Tool not listed | Check |
Unreachable or timed out | Open |
No local session / HTTP 401 or 403 | Check dashboard authentication and local access. Do not paste tokens into chat. This integration requires local session bootstrap. |
Missing provider quota | Check the same provider in the OpenCodex dashboard; missing data is not zero usage. |
Unknown provider | Query without arguments, then use the returned name or label exactly. |
Response structure changed | Check OpenCodex version compatibility; dashboard API changes may require an integration update. |
Update / uninstall
Update from a Git checkout with git pull --ff-only followed by npm ci, then restart the MCP client. If the installation path changes, remove and register the MCP entry again.
codex mcp remove opencodex-quotaThen remove the project directory if no longer needed. This does not uninstall OpenCodex.
Acknowledgements
OpenCodex — lidge-jun/opencodex: the upstream proxy and dashboard this integration depends on; provider authentication, quota measurements and labels come from OpenCodex. Its code is licensed under MIT.
Model Context Protocol TypeScript SDK: stdio MCP server and client implementation.
This repository contains an independently written adapter; it does not bundle OpenCodex. Project names belong to their respective owners. This adapter is licensed under MIT.
Available Tools
1 toolget_provider_quotasOpenCodex provider quota and balanceARead-onlyIdempotent
查询本机 OpenCodex 各提供商的额度、余额、剩余比例、重置时间和数据更新时间。Read provider quotas from the local dashboard. Omit provider to list all. Missing quota means unavailable or unsupported, never zero usage. Uses dashboard caching; does not force refresh or send model completions.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Exact configured provider name or dashboard label, e.g. anthropic, openai, deepseek, kimi, mimo. Omit for all providers. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| providers | Yes | |
| queriedAt | Yes | |
| generatedAt | Yes | |
| dashboardUrl | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already establish read-only, idempotent, non-destructive, open-world), the description adds genuinely useful behavior: it reads cached dashboard data, does not force a refresh, and does not send model completions (i.e., no token cost). It also pre-empts a misinterpretation by stating missing quota means unavailable/unsupported, never zero usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded: the purpose leads, then usage and behavioral caveats. The Chinese and English sentences partially duplicate each other, which is slight overhead, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full parameter coverage, the description only needs to cover purpose and interpretation caveats, which it does—especially the missing-quota rule and cache behavior. An agent has everything needed to call and interpret it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single `provider` parameter is fully documented with examples and the omit-for-all rule in the schema itself. The description restates 'Omit provider to list all' without adding format or matching semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: read provider quotas (amount, balance, remaining ratio, reset time, data refresh time) from the local OpenCodex dashboard. It is unambiguous about scope ('本机'/local) although there are no sibling tools to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operating context: omit `provider` to list all, and it explicitly notes the tool uses cached dashboard data rather than forcing a refresh. It does not state when an agent should prefer a refresh path or what to do if data is stale, so it stops short of full when/when-not guidance.
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 tool update
v1.0.0- First observed
get_provider_quotas
TDQS
Scored across 1 tool
Only one tool exists, so there is no possible overlap or misselection risk. Its purpose (read provider quotas) is stated unambiguously.
Single name get_provider_quotas follows a clean verb_noun snake_case convention that matches what a consistent set would look like. No mixed conventions to worry about.
A single read-only query tool is thin even for a narrow domain; users would expect at least a companion for per-provider detail or a refresh action. It is defensible for a read-only dashboard mirror, but it sits at the borderline of 1-2 tools.
Reading quotas, balances, reset times and update timestamps covers the core read need, with omit-provider listing all. The main gap is the explicit absence of any force-refresh or historical view, so an agent stuck with stale cached data has no escape hatch.
Maintenance
Related MCP Connectors
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Related MCP Servers
- AlicenseAqualityCmaintenanceA read-only MCP server for querying AI provider administration APIs, providing normalized usage, cost, and dashboard data for OpenAI and Anthropic.417 npmMIT
- AlicenseNot gradedqualityDmaintenanceMCP server that reads local OpenClaw session files to provide token usage and cost data without any network calls or authentication.MIT
- FlicenseAqualityBmaintenanceMCP server that exposes a single tool to retrieve ChatGPT/Codex quota via the signed-in Codex CLI, reporting rate-limit windows and usage percentages.1-
- AlicenseAqualityBmaintenanceA local, read-only MCP server that gives Codex a plan-aware view of its remaining usage and helps choose work that fits the current usage window.21MIT