[Provider compatibility] BigModel Responses Coding Plan: missing quota probe and GLM-5.3-Flash catalog support

[bluesmilery]

Client or integration

Codex App / OpenCodex provider configuration and quota UI

Provider or upstream service

Zhipu BigModel GLM Coding Plan — zhipu-bigmodel-responses

OpenCodex version

2.49.0 (installed npm package)

Endpoint or capability

Responses preset at https://open.bigmodel.cn/api/v1: account quota visibility and glm-5.3-flash model availability.

Summary

The new Responses preset should preserve the existing Coding Plan experience when changing the API wire format. From a user's perspective this is still the same GLM Coding Plan subscription, accessed through Responses instead of Chat Completions. Switching to the new preset currently loses quota visibility and the built-in glm-5.3-flash selection.

This issue tracks those two related gaps. The quota selector omission is confirmed by local source inspection; Flash support on this specific Responses endpoint still needs endpoint-specific validation.

Current behaviour

1. The new provider is not connected to the existing quota reader.

In the installed 2.49.0 src/providers/quota.ts:

• isCanonicalZaiBaseUrl() already accepts https://open.bigmodel.cn/api/v1 (around line 348).
• fetchZaiQuota() already selects the domestic monitor endpoint and its raw Authorization API-key convention.
• However, keyQuotaReaderForProvider() (around line 2894) restricts this reader to provider names zai, glm, glm-cn, and zhipu-bigmodel-coding. It omits zhipu-bigmodel-responses.
• Consequently, providerApiKeyQuotaMode() returns unsupported for the new preset, and fetchProviderApiKeyQuotas() returns an empty list before making a quota request.

This is a provider-name eligibility gap, not a missing domestic Responses URL in the canonical URL check.

2. glm-5.3-flash is absent from the new model catalog.

In src/providers/registry.ts:

• Existing zhipu-bigmodel-coding includes glm-5.3-flash (around line 2628).
• New zhipu-bigmodel-responses seeds only glm-5.3 and glm-5-turbo (around line 2651).
• The saved local Responses provider also contains only those two model IDs.

We acknowledge the prior discussion in #3641 / #3828: the static subset was landed deliberately, while live HTTP model discovery and exact Flash Responses metadata were deferred. This is a request to complete that remaining support, not a claim that it was accidentally removed.

Expected behaviour

• Using the Responses preset with an eligible domestic Coding Plan key should expose the same account quota information available through the existing Coding Plan quota reader, while retaining response-driven handling of whichever quota windows the account actually returns.
• The preset should offer glm-5.3-flash if the domestic Responses endpoint supports it, with verified context, modalities, and reasoning metadata. If the endpoint does not support it, please document that specific upstream restriction and the resulting difference from the Chat preset.
• The product expectation is continuity of the same subscription when changing API access method. This does not require assuming that every model or every metadata field is identical across wire protocols.

Minimal redacted reproduction

1. On OpenCodex 2.49.0, configure the built-in Zhipu AI — BigModel Coding Plan (Responses) provider using a domestic Coding Plan API key.
2. Inspect its Usage/quota capability: the provider is classified as unsupported by the quota reader selector.
3. Inspect the built-in model selection: glm-5.3 and glm-5-turbo are seeded, but glm-5.3-flash is absent.
4. Compare the existing zhipu-bigmodel-coding preset, which is admitted by the quota selector and includes Flash in its model roster.

Relevant redacted configuration fields:

{
  "providers": {
    "zhipu-bigmodel-responses": {
      "adapter": "openai-responses",
      "baseUrl": "https://open.bigmodel.cn/api/v1",
      "models": ["glm-5.3", "glm-5-turbo"]
    }
  }
}

Credentials are omitted. This report is based on the observed configuration and read-only inspection of installed source; no new inference or authenticated quota/model-list request was made during this investigation.

Actual response or error

No upstream error is required to trigger the quota gap: the local selector rejects the provider before dispatch. Flash is missing from the preset catalog; this report does not claim a failed Flash inference request.

Upstream documentation

Official domestic Coding Plan Codex guide, checked 2026-09-10:

https://docs.bigmodel.cn/cn/coding-plan/tool/codex

The guide places Codex under GLM Coding Plan and specifies the domestic /api/v1 endpoint with the Responses wire format. Its current local model-catalog example lists GLM-5.3 and GLM-5-Turbo. The example alone does not prove either Flash support or an authenticated HTTP /models contract; those need separate evidence.

Suggested mapping or implementation notes

• Connect the built-in zhipu-bigmodel-responses ID to the existing domestic Coding Plan quota reader while retaining exact destination checks, domestic authentication, and redirect refusal.
• Add a regression case proving this preset is quota-probe eligible and dispatches to the domestic monitor endpoint. Preserve unsupported/custom destination safeguards.
• Validate Flash on the domestic Responses endpoint and add verified model metadata. Static Flash support can be completed independently of a general live-discovery implementation; there is no need to treat the official local JSON example as an HTTP discovery contract.

Related issues and PRs

• [Feature]: complete GLM Coding Plan quota support for open.bigmodel.cn #1168 / fix(quota): correct GLM Coding Plan auth and exclude MCP allowance from model quota #2976: existing domestic Coding Plan quota support, already completed; this report concerns the new Responses provider ID omitted from reader selection.
• Z.ai: quota probe returns nothing when baseUrl is the Anthropic-compatible coding endpoint (https://api.z.ai/api/anthropic) #4154 / fix(zai): recognize coding quota endpoints without crossing regions #4174: international api.z.ai quota eligibility for Anthropic/Responses paths. Related but different from this domestic provider-name omission.
• feat(providers): support BigModel's OpenAI Responses endpoint with live discovery #3641 / feat(providers): add documented BigModel Responses preset #3828: introduction of the domestic Responses preset; Flash metadata and live discovery explicitly deferred. Please use this issue to track the remaining user-visible parity gaps.

Checks

• I searched existing provider and compatibility issues and related PR discussions.
• Credentials and personal configuration details are omitted.
• The expected behaviour is based on the official Coding Plan integration guide and a concrete client requirement.

[Ingwannu]

Confirmed the quota-selector omission on current dev 6d3ad12: the registry already defines zhipu-bigmodel-responses at the domestic /api/v1 endpoint, and the existing quota transport already accepts that base and uses the domestic monitor/raw Authorization convention. The reader's provider-name list does not include the new preset.

I will send a small independent quota-only PR adding that preset to the existing guarded reader, with domestic destination/auth assertions and a no-dispatch custom-destination control. This does not depend on #4174's international URL mapping.

Flash remains a separate open part of this issue: the registry explicitly records a deliberately static Responses roster. I will not copy Chat model capabilities into the Responses preset without endpoint-specific evidence or turn the local catalog example into a claimed HTTP discovery contract. No live credentials or inference probes are needed for the quota-selector fix.

[Ingwannu]

Quota-only Draft PR #4210 is open and @lidge-jun has been requested for review. It adds the Responses preset ID to the existing guarded domestic reader, preserves the raw-key/redirect behavior, and adds mocked positive and negative coverage. Local privacy and diff checks passed; product CI and docs build are still pending. Flash support is deliberately unchanged, so this issue remains open for that separately evidenced part.