ProductDesktopUsage provider APIs

06 — z.ai, MiniMax, and Kimi usage APIs

Compares subscription-quota sources, credential paths, and limit semantics for z.ai, MiniMax, and Kimi.

Summary

Z.AI, MiniMax, and Kimi each expose subscription limits, but their authentication and reset semantics require provider-specific adapters.

Question and scope

For each of z.ai (GLM coding plan), MiniMax (coding/agent plan), and Kimi (Moonshot AI, Kimi for Coding): (1) which official endpoint(s) expose subscription/coding-plan usage quotas — windows (5-hour/daily/weekly), percent or counts remaining, reset times; (2) what auth is required and where credentials live (location/type only); (3) is a plan label available via API; (4) which display elements have no direct API source (deficit, run-out projections).

This chapter informs jackin-desktop.

Method

Verification cutoff: 2026-07-24 Method: web + codebase cross-reference. Verified live 2026-07-24. Clean-room constraint honored: CodexBar and OpenUsage source/docs excluded (their repo pages surfaced in several searches and were discarded; no endpoint lifted from them). No embedded instructions were observed in any fetched external content.

Findings

z.ai

Q1 — Endpoints.

  • Quota endpoint (real, but officially undocumented): GET https://api.z.ai/api/monitor/usage/quota/limit (global) and https://open.bigmodel.cn/api/monitor/usage/quota/limit (CN; also seen as bigmodel.cn). It appears in no official z.ai doc page checked (devpack FAQ, ZCode configuration); it is corroborated by ≥4 independent third-party clients: opencode-glm-quota, opencode-mystatus (+ its docs mirror), pi-zai-usage, and a cc-switch issue quoting the response. Confidence: HIGH that the endpoint exists and serves quota; MED on any individual response detail (no primary doc). jackin already calls exactly this path: crates/jackin-usage/src/usage/zai.rs:257-266 (fetch) and zai.rs:276-290 (URL resolution, env overrides ZAI_QUOTA_URL/Z_AI_QUOTA_URL, ZAI_API_HOST/Z_AI_API_HOST, default host https://api.z.ai).
  • Response shape (third-party observed, MED): {code, msg, success, data:{limits:[…], level}}; each limits[] entry: type ("TOKENS_LIMIT" or "TIME_LIMIT"), unit, number, usage (total), currentValue (used), remaining, percentage, nextResetTime (epoch ms). Source: cc-switch issue #1588. jackin parser matches field-for-field: zai.rs:104-117 (ZaiLimitRaw), percent math zai.rs:174-195, window decode from unit/number zai.rs:197-209, reset from nextResetTime ms→s zai.rs:215.
  • Windows (official, HIGH): docs.z.ai/devpack/faq documents 5-hour prompt quotas (Lite ~80 / Pro ~400 / Max ~1600 prompts per 5 h), a weekly quota ("refreshed and reset on a 7-day cycle" anchored to order time), and monthly MCP tool counts (Web Search/Reader: 100/1,000/4,000 per month by tier). The quota endpoint's three buckets map onto these: two TOKENS_LIMIT entries (5-hour + weekly) and one TIME_LIMIT entry (MCP monthly) — window labels per opencode-glm-quota ("5h Token", "Weekly", "MCP (1 Month)"), MED. jackin renders the same triple: zai.rs:128-160.
  • Two sibling endpoints exist per opencode-glm-quota (MED), but they are outside jackin limits-only scope and are not called (crates/jackin-usage/CLAUDE.md).
  • Quota is also shown in the provider web console (Usage Statistics); official docs point users there rather than to an API (docs.z.ai/devpack/faq, zcode.z.ai configuration). HIGH.

Q2 — Auth. API key (console-issued), sent in the Authorization header. Two independent third-party sources state the header carries the raw key with no Bearer prefix: opencode-glm-quota ("The plugin does NOT use 'Bearer' prefix… The token is passed directly") and the cc-switch issue script ("Authorization": "{{apiKey}}"). MED. jackin sends Bearer via get_json_bearer (zai.rs:259) — see Contradictions. Storage: environment variable only (jackin surfaces "API token · env {key_name}", zai.rs:58-62); ecosystem tools read it from their own config stores (e.g. opencode auth.json under ~/.local/share/opencode/, type: API key — location/type only, per opencode-mystatus). No OAuth flow observed for the coding plan.

Q3 — Plan label. The quota response carries data.level (observed value "pro") per cc-switch issue #1588 — MED, single observation. Official plan tier names Lite/Pro/Max are documented (docs.z.ai/devpack/faq, HIGH) but no official plan-label API is documented. Cross-reference gap: jackin deserializer aliases planName/plan/plan_type/packageName (zai.rs:95-101) and does not map level, so the one plan field actually observed in the wild would be dropped.

Q4 — No direct API source. Deficit/run-out projection, burn rate/pace, and per-prompt counts for the 5-hour window (official framing is "prompts", the API reports token-ish counts/percentages) have no API source; any projection must be computed client-side from percentage + nextResetTime. Account identity (email/username) is not in the quota response as observed.

MiniMax

Q1 — Endpoints.

  • Officially documented (the only provider of the three with a primary-source quota API): curl 'https://www.minimax.io/v1/token_plan/remains' --header 'Authorization: Bearer <API Key>' under FAQ "How to check Token Plan usage?" — platform.minimax.io/docs/token-plan/faq. HIGH.
  • Windows (official, HIGH): "Included Token Plan quota: Controlled by a 5-hour rolling window and a weekly window"; "Unused included Token Plan quota does not carry over to the next billing cycle" (token-plan FAQ, token-plan intro).
  • Response shape (MED — field names quoted by users in MiniMax's own repo tracker, no staff confirmation): model_remains[] with model_name (e.g. "general"), current_interval_total_count, current_interval_usage_count, current_interval_remaining_percent, current_weekly_total_count, current_weekly_usage_count, current_weekly_remaining_percent, plus account-level remains_time; start_time/end_time bound the windows. Sources: MiniMax-M2.7 issue #48, issue #47, OpenClaw MiniMax provider docs. jackin parser matches: crates/jackin-usage/src/usage/minimax.rs:116-144 (MiniMaxModelRemain incl. end_time, remains_time, weekly_end_time, per-window status), error envelope base_resp.status_code/status_msg minimax.rs:85-91.
  • Hosts/paths: jackin fans out over api.minimax.io and api.minimaxi.com × /v1/token_plan/remains and legacy /v1/api/openplatform/coding_plan/remains (minimax.rs:384-396). The official doc uses host www.minimax.io; OpenClaw's docs use the api.* hosts (MED). The legacy coding_plan/remains path on www.minimaxi.com was reported to reject API keys with {"base_resp":{"status_code":1004,"status_msg":"cookie is missing, log in again"}}MiniMax-M2 issue #88, MED, no staff reply. jackin fallback ordering (token_plan first) is consistent with that report.
  • Reset time: end_time (epoch, ms or s) or countdown remains_time; jackin prefers end_time and derives from remains_time only as fallback (minimax.rs:410-417). Caveat: issue #47 reports remains_time draining passively — countdown-derived resets are suspect (MED).
  • Plan tiers (official, HIGH): Plus $20 / Max $50 / Ultra $120 per month — token-plan intro, tier names confirmed in FAQ.

Q2 — Auth. Coding-plan API key, Authorization: Bearer <key> (official FAQ, HIGH). Storage: environment variable; ecosystem env names MINIMAX_CODE_PLAN_KEY, MINIMAX_CODING_API_KEY, MINIMAX_OAUTH_TOKEN, MINIMAX_API_KEY (OpenClaw docs, MED). jackin reads env MINIMAX_API_KEY / prompts for MINIMAX_CODING_API_KEY (minimax.rs:49-56) and adds a self-identifying MM-API-Source: jackin-capsule header (minimax.rs:349) — no external evidence this header is required. No credential file observed; key is console-issued.

Q3 — Plan label. Not documented. jackin speculatively parses current_subscribe_title / plan_name / combo_title / current_plan_title / current_combo_card.title (minimax.rs:97-114, minimax.rs:201-217); no external source corroborates any of these field names — open unknown. Official tier names exist only as docs prose.

Q4 — No direct API source. Plan label (unverified), burn rate/pace, run-out projection, and window duration labels (must be derived from start_time/end_time); per-model quotas other than general reportedly return zeros in some plan states (issue #48, MED).

Kimi

Q1 — Endpoints. Two distinct usage surfaces exist; neither is in official docs.

  • Coding-plan API-key surface: GET https://api.kimi.com/coding/v1/usages (fallback …/usage). Not documented on kimi.com/code docs (which document only the inference base URLs https://api.kimi.com/coding/v1 OpenAI-compatible and https://api.kimi.com/coding/ Anthropic-compatible) nor on platform.kimi.ai. Corroborated by the third-party tracker Golden0Voyager/kimi-code-usage: source builds base_url + "/usages" with Authorization: Bearer {api_key} and — notably — spoofs User-Agent: KimiCLI/1.6; parsed fields include data/usage/limits, limit, used, remaining, resetTime/reset_at/reset_time, and window objects window.duration/timeUnit (HIGH for that library's behavior; MED that the endpoint is stable/official). jackin calls the same URL (crates/jackin-usage/src/usage/kimi.rs:258-267) but with User-Agent: jackin-capsule/usage (kimi.rs:265).
  • Web billing gateway (OAuth session): POST https://www.kimi.com/apiv2/kimi.gateway.billing.v1.BillingService/GetUsages with body {"scope":["FEATURE_CODING"]}, plus fallbacks https://www.kimi.com/api/user/usage and https://www.kimi.com/api/usages; Authorization: Bearer <access_token> plus web headers (connect-protocol-version: 1, x-msh-platform: web, etc.). Response fields: usages[] with scope (FEATURE_CODING), detail{limit,used,remaining,resetTime}, limits[] with window{duration,timeUnit}, and membership/level/name. Source: blindlight86/kimi-code-usage-skill scripts (scripts/get_kimi_usage.sh). MED (working third-party scripts; internal web API, no doc). jackin KimiUsageResponse parses exactly this shape — usages[].scope == "FEATURE_CODING", detail, limits[].window.duration/timeUnit (kimi.rs:88-160) — even though it sends the request to the api.kimi.com/coding/v1/usages URL, implying both surfaces return the same schema (unconfirmed; see Open unknowns).
  • Windows: official docs state only the 5-hour request window ("approximately 300–1,200 requests per 5-hour window", 30 concurrent) — kimi.com/code docs, HIGH. A weekly quota window is shown by multiple third-party trackers (kimi-code-usage README status bar "Wee:%… 5Ho:%", MED) but is not stated in official docs. Reset time arrives as an ISO string resetTime (jackin parses it at kimi.rs:110-112, kimi.rs:237); rate-limit window duration/unit arrive structured (kimi.rs:120-125, kimi.rs:199-218).

Q2 — Auth. Two credential types (locations/types only):

  • API key sk-kimi-… created in the Kimi Code Console, held in env (KIMI_API_KEY in third-party tooling — kimi-code-usage; jackin uses env KIMI_CODE_API_KEY, kimi.rs:63).
  • OAuth-style short-lived access_token + refresh_token + expires_at JSON written by Kimi Code CLI login to ~/.kimi/credentials/kimi-code.json (mode 0600); some tools also reference ~/.kimi-code/credentials/kimi-code.json. Sources: blindlight86/kimi-code-usage-skill (states that credentials are written only to ~/.kimi/credentials/kimi-code.json), pi-provider-kimi-code, pi-kimi-coder (MED each, converging). Official kimi-cli docs document config at ~/.kimi/config.toml and a /login wizard but do not document the credentials file (HIGH for config.toml only). jackin probes both credential paths with expiry check (kimi.rs:269-297).

Q3 — Plan label. Membership tiers Moderato / Allegretto are official (kimi.com/code docs, HIGH). Via API, a plan label (membership/level/name) is only evidenced on the web BillingService/GetUsages surface (MED); no evidence the API-key GET /coding/v1/usages returns one. jackin currently sets plan_label: None for Kimi (kimi.rs:60) — consistent with the evidence.

Q4 — No direct API source. Pace/run-out projection (jackin computes quota_pace_label locally, kimi.rs:238-239); plan label on the API-key surface; account identity/username. Client gating is a risk, not a display element: the coding inference endpoint rejects non-whitelisted agents ("Kimi For Coding is currently only available for Coding Agents such as Kimi CLI, Claude Code, Roo Code, Kilo Code, etc." — nanobot issue #354, MED), and the one third-party tracker with visible source spoofs KimiCLI/1.6 UA — whether /usages enforces the whitelist/UA is unknown.

Dead ends and contradictions

  • CodexBar docs excluded (clean-room). github.com/steipete/CodexBar/docs/zai.md and docs/kimi.md were top hits for four separate queries; discarded unread. All endpoints above are sourced from official docs, vendor repo trackers, or non-banned third-party repos, and cross-checked against jackin existing probes.
  • z.ai Authorization header: raw key vs Bearer. Two independent third-party clients send the raw key with no Bearer prefix; jackin sends Bearer (zai.rs:259) and presumably works. Both may be accepted server-side; unproven either way. MED contradiction, resolvable only with a live key.
  • z.ai quota API is officially undocumented. Checked docs.z.ai/devpack/faq, devpack overview, and ZCode configuration: quota semantics yes, endpoint no. Ruled out: any official OpenAPI/reference page for /api/monitor/usage/quota/limit.
  • MiniMax host mismatch. Official FAQ curl uses www.minimax.io; jackin and OpenClaw use api.minimax.io/api.minimaxi.com (minimax.rs:388-394). Whether the api.* hosts serve /v1/token_plan/remains identically is unverified here.
  • MiniMax legacy path auth. Docs said Bearer; MiniMax-M2 issue #88 showed coding_plan/remains demanding a browser cookie session (status 1004). The newer token_plan/remains is the documented key-auth path; the legacy path in jackin fallback list may only ever fail for key auth.
  • MiniMax remains_time semantics disputed (issue #47 reports passive drain) — contradicts "consumption-only" expectation; supports jackin end_time-first reset derivation (minimax.rs:410-417).
  • Search-summary noise dropped: one aggregated search result claimed Z_AI_QUOTA_URL=https://open.bigmodel.cn/api/coding/paas/v4 as a "quota URL override" — that path is the chat-completions endpoint, not the quota endpoint; dropped as conflation. Similarly, unofficial blog domains (aipricing.guru, minimax-ai.chat, kimi-ai.chat, lorphic.com, nxcode.io) were treated as leads only and nothing was sourced from them.
  • Kimi official docs dead end: neither kimi.com/code docs nor kimi-cli docs document any usage-query endpoint or command. platform.moonshot.ai now redirects into the platform.kimi.ai / kimi.com doc set; no moonshot.ai-hosted usage API doc found.

Implications for jackin

Keep provider-specific adapters and confidence labels because these quota surfaces differ in authentication, reset semantics, and documentation quality.

Limitations and unknowns

  • z.ai: Does the quota endpoint accept Bearer-prefixed auth (jackin current form, zai.rs:259)? Enumeration of data.level values (only "pro" observed) and whether level is the sole plan field — jackin aliases (zai.rs:95-101) match nothing observed. A LOW-confidence lead says the API shifted toward percentage-only (counts zeroed) around Feb 2026 — unverified. All three need an operator-authenticated probe (curl with a live coding-plan key; no browser needed).
  • z.ai: exact team-account behavior (usageScope: team seen in one search summary only — LOW, dropped from findings).
  • MiniMax: Do any plan-title fields (current_subscribe_title etc., minimax.rs:97-114) actually appear in the token_plan/remains response? Needs an operator-authenticated response capture (API key curl suffices).
  • MiniMax: Whether api.minimax.io/api.minimaxi.com serve token_plan/remains identically to documented www.minimax.io; full response envelope (data wrapper vs root model_remainsjackin accepts both, minimax.rs:219-226).
  • Kimi: Exact JSON schema of GET https://api.kimi.com/coding/v1/usages — including whether it returns usages[]/FEATURE_CODING (the shape jackin parses), whether it includes a membership/plan field, and whether it is User-Agent/client-whitelist gated (third-party tool spoofs KimiCLI/1.6; jackin sends jackin-capsule/usage, kimi.rs:265). Needs an operator key; if the endpoint is UA-gated, needs header experimentation.
  • Kimi: Whether the OAuth access_token from ~/.kimi/credentials/kimi-code.json is accepted by api.kimi.com/coding/v1/usages (jackin assumes yes, kimi.rs:269-283) or only by the www.kimi.com/apiv2 billing gateway. The gateway's stability and required x-msh-* headers would need an operator-authenticated browser session to inspect network traffic.
  • Kimi: Official existence/size of the weekly window (docs state only the 5-hour window; trackers show weekly). Needs authenticated response capture or official doc update.

Sources

On this page