Show Z.ai GLM Coding Plan and Kimi Code limits for Claude relay instances

[saphid]

Problem

A common setup is a Claude provider instance pointed at an Anthropic-compatible relay with ANTHROPIC_BASE_URL: Z.ai's GLM Coding Plan (api.z.ai/api/anthropic) or Kimi Code (api.kimi.com/coding). These plans have their own 5-hour and weekly quotas, but Usage → Limits shows nothing for them.

The Claude CLI's get_usage reports rate_limits_available: false on non-Anthropic backends. The probe therefore records unsupported (claudeUsageLimits.ts), and Limits leaves the instance out (usageLimits.ts).

I reproduced this on main a1d9d72aef (web dev build, isolated state). The usage code is unchanged at 250e052f44. Both relay instances are enabled and authenticated, but neither appears on Limits:

Where the data comes from

Both relays publish quota on a read-only endpoint. Each endpoint accepts the same key the instance already gives the CLI.

• Kimi Code: GET https://api.kimi.com/coding/v1/usages (Bearer). It returns a weekly usage summary plus limits[] rolling windows (5-hour today). I checked it live today.
• Z.ai: GET https://api.z.ai/api/monitor/usage/quota/limit (bare key). It returns data.limits[] sized by unit/number. Z.ai's own glm-plan-usage plugin uses the same endpoint, and OpenCode: legacy models like other providers, and Z.AI Coding Plan 5-hour and 7-day usage #12964 describes it. My key reached it, but its plan has lapsed (success: false), so I have not seen live Z.ai windows.

Smallest scope

• This applies only to the Claude driver's existing status check. It runs only when the instance's own ANTHROPIC_BASE_URL is HTTPS on the default port with exactly one of these hosts: api.z.ai, open.bigmodel.cn, dev.bigmodel.cn, api.kimi.com. The driver then reads that relay's quota with the instance's ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY and publishes the windows into the existing usageLimits snapshot.
• No new setting, contract, client change, or polling loop. Reads have a 10-second timeout. A failed read reports probeFailed, so the last good bars stay.
• Any other base URL behaves exactly as today. The key is never sent anywhere else.
• Limits groups rows by driver, so relay rows sit under the Claude heading. Each label names its relay ("Session · Kimi"), as Claude's own "Weekly · " rows do. A relay has no account email, so a hash of the relay and key identifies the account. That way one key used on two instances or machines pools as one account, as OpenCode Go already does.

With the change, on the same isolated state (Kimi live; Z.ai reports its lapsed plan as a failed read):

Acceptance criteria

• A Kimi or Z.ai relay instance shows its session and weekly bars, with resets and its relay name, on Usage → Limits and /usage-limits.
• Anthropic and other Claude instances make no extra request.
• Lookalike hosts, http, custom ports and unknown relays get no request and no key.
• A failed read keeps the last good bars and shows a "could not read" notice.
• The same relay key on two instances counts once in pooled headroom.

Verification plan

• Focused server tests covering parsing, malformed rows, credential routing, host allowlist, key-hash identity, timeout, cancellation, and wire-schema validity of every published window.
• Live before/after on a real Kimi Code account, shown above. Live Z.ai windows need an active Coding Plan account.
• Not covered: a relay URL set only inside a --settings file is not seen, because the probe reads the instance environment. I also have not seen a relay emit Claude rate_limit_events mid-turn.

Relation to other proposals

• Generic HTTP `usageLimitSources` kind for gateway / proxy spending budgets #15042 proposes a generic, user-configured HTTP source for gateway budgets. It maps one window per source and needs a second stored secret. These relays return several windows with relay-specific unit codes and already have the instance's key. The two can coexist. If you prefer, these two relays could instead become presets of that kind.
• OpenCode: legacy models like other providers, and Z.AI Coding Plan 5-hour and 7-day usage #12964 asks for the same Z.ai windows via OpenCode, and the parser would carry over.

Decision needed

Do you want quota integrations for third-party Claude relays at all, and if so, is a small per-relay adapter inside the Claude driver acceptable? Or should this only go through a generic user-configured source like #15042?

The implementation, tests and evidence are ready on relay-usage-zai-20261005 and relay-usage-kimi-20261005. They replay the closed #13586 and #13587 onto current main. I won't open a PR until the direction is agreed.

[mertbozkir]

Same gap on the ACP Registry path

I use the GLM Coding Plan through the ACP-registry glm-acp-agent ("GLM Agent"), with Z_AI_API_KEY set on that instance. Usage -> Limits shows no row for it, because the ACP registry driver never sets usageLimits (and has no usage reader either).

The quota data is the same as the relay case, and it works live:

GET https://api.z.ai/api/monitor/usage/quota/limit
authorization: <full API key>

{"data":{"level":"lite","limits":[
  {"type":"CREDIT_LIMIT","unit":3,"number":5,"usage":2000,"currentValue":1450,"percentage":72,"nextResetTime":...},
  {"type":"CREDIT_LIMIT","unit":6,"number":1,"usage":10000,"currentValue":5470,"percentage":54,"nextResetTime":...}]},"success":true}

unit=3/number=5 -> 5-hour window, unit=6/number=1 -> weekly, percentage -> used, nextResetTime -> reset. Same mapping as the relay case; only the harness differs, so the probe would live on the ACP registry instance instead of the Claude driver. (Two edge cases to scope in: nextResetTime is sometimes absent, and Team Plan keys return limits: [].)

Is this in scope? If yes, which shape would you take:

• (a) a probe on the ACP-registry instance using its own Z_AI_API_KEY, or
• (b) a zai kind on the already-merged usageLimitSources?

Happy to implement whichever you prefer.

Filed by deepseek-v4.1-flash (OpenCode) in T3 Code.