Skip to content

[Feature request]: support the free Start Plan "ZCode Trust Build" (GLM-5.3-Flash) #6673

Closed as not planned
Closed as not planned
[Feature request]: support the free Start Plan "ZCode Trust Build" (GLM-5.3-Flash)#6673
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, planscatalogModel catalog, slugs, visibility, routed entriesenhancementNew feature or requestproviderProvider adapters, OpenAI-compat presets, upstream API quirks

Description

@chelaxian
chelaxian
opened on Oct 6, 2026

Area

Provider adapters

What are you trying to accomplish?

I use ZCode (the Z.ai coding agent) and OpenCodex on the same machine. ZCode has two separate plans (endpoints/models):

  • the paid Z.ai "GLM Coding" plan
  • the free Start Plan "ZCode Trust Build", which almost always includes free quota for the GLM-5.3-Flash model

The outcome I need: be able to route OpenCodex requests to that free plan too, so I always have a free model available to finish projects when all my other providers are out of quota.

What prevents this today?

OpenCodex currently has no way to connect to the free "ZCode Trust Build" plan — only paid providers can be configured. The free GLM-5.3-Flash quota granted on that plan is therefore unusable from OpenCodex.

The only workaround is leaving OpenCodex and using the ZCode app directly, which means I lose the ability to use it from other harnesses like Codex and Claude Code.

What should OpenCodex do?

Treat the free "ZCode Trust Build" plan as a regular provider:

  • I can log in to it from OpenCodex (OAuth or whatever auth ZCode uses for the free plan);
  • GLM-5.3-Flash (and any other models the plan exposes) shows up in the model catalog and the dashboard;
  • I can route prompts to it directly and/or use it as a fallback in combo routing when other providers return quota/rate-limit errors.

Observable result: when the paid plan's quota is exhausted, I can switch the provider/model to the free Z.AI plan and requests keep working instead of failing with 429 errors on the main paid plan. Even better: OpenCodex could do this automatically via combo fallback, without manual intervention.

Example usage or interface

CLI sketch (illustrative — exact names don't matter):

ocx login zai-trust-build # one-time login to the free plan
ocx provider list # shows zai-trust-build / glm-5.3-flash with free-quota info
ocx combo set --fallback zai-trust-build/glm-5.3-flash

Or a config fragment:

  {
    "providers": {
      "zai-trust-build": { "plan": "trust-build", "models": ["glm-5.3-flash"] }
    }
  }

Before: paid providers exhausted → request fails, free quota sits unused.
After: same failure → OpenCodex falls back to glm-5.3-flash on the free plan, the turn completes.

Alternatives or workarounds

No response

Additional context

Image Image Image

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

  1. chelaxian
    added
    enhancementNew feature or request
    on Oct 6, 2026
  2. chelaxian
    changed the title [-]Feature request: support the free "ZCode Trust Build" plan (GLM-5.3-Flash)[/-] [+]Feature request: support the free Start Plan "ZCode Trust Build" plan (GLM-5.3-Flash)[/+] on Oct 6, 2026
  3. chelaxian
    changed the title [-]Feature request: support the free Start Plan "ZCode Trust Build" plan (GLM-5.3-Flash)[/-] [+]Feature request: support the free Start Plan "ZCode Trust Build" (GLM-5.3-Flash)[/+] on Oct 6, 2026
  4. github-actions
    added
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    catalogModel catalog, slugs, visibility, routed entries
    providerProvider adapters, OpenAI-compat presets, upstream API quirks
    on Oct 6, 2026
  5. chelaxian
    changed the title [-]Feature request: support the free Start Plan "ZCode Trust Build" (GLM-5.3-Flash)[/-] [+][Feature request]: support the free Start Plan "ZCode Trust Build" (GLM-5.3-Flash)[/+] on Oct 6, 2026

  6. chelaxian commented on Oct 6, 2026

    @chelaxian
    chelaxian
    on Oct 6, 2026
    Author

    I did a deep dive into how ZCode's two plans work under the hood — here are the technical details that should make this feature implementable.

    How the plans actually differ

    A "plan" is not a model property — it's a specific backend + auth chain. The ZCode client's built-in provider config ships these:

    Provider Endpoint Protocol Auth Models
    GLM Coding Plan (paid) https://api.z.ai/api/anthropic Anthropic Messages plain API key GLM-5.3, GLM-5.3-Flash
    Start Plan / "Trust Build" (free) https://zcode.z.ai/api/v1/zcode-plan/anthropic Anthropic Messages ZCode OAuth JWT + client request signing + Aliyun captcha GLM-5.3-Flash, GLM-5.2, GLM-5-Turbo
    Idle plan (hidden, off-peak) https://zcode.z.ai/api/v1/off-peak/anthropic Anthropic Messages app + x-off-peak-ticket-id GLM-5.3, GLM-5.3-Flash

    There is also an OpenAI-compatible surface for the free plan at https://zcode.z.ai/api/v1/zcode-plan.

    This also explains the "switching the model to GLM-5.3-Flash doesn't help" part: the request still goes to the paid api.z.ai backend and burns coding-plan quota. The free quota is only reachable through the zcode.z.ai backend, with app-level auth.

    Why the free endpoint is not a normal API

    Verified empirically (raw JWT, OAuth token and API key all → 401) and by inspecting the ZCode client bundle (resources/glm/zcode.cjs, visible in any ZCode install):

    • Login is OAuth through chat.z.ai (public client id client_P8X5CMWmlaRO9gyO-KSqtg); the client keeps JWT access tokens.
    • Every request to zcode.z.ai must be signed by the client: headers X-Client-Ts, X-Client-Version, X-Client-Sig, X-Client-Nonce, X-Client-Pow (proof-of-work), X-App-Id, X-Session-Id, established via a server signing handshake. Client-side error codes: VERIFY_SIGNATURE_INVALID, VERIFY_APIKEY_EXPIRED.
    • On top of that, an Aliyun invisible captcha is required: X-Aliyun-Captcha-Verify-Param.
    • Plan availability is a per-account server-side entitlement (the client's plan cache literally has coding_plan_not_entitled as a status).

    So the actual gap: there is no public API key for the free plan — access is deliberately locked to the official client.

    Reference implementations (working code)

    • liu5269/zcode2api (AGPL-3.0, Python + Node) — a gateway that converts ZCode quota (including the free in-app quota) into a standard Anthropic Messages API, with multi-account rotation, quota monitoring and auto-switching:
    • The paid plan needs none of this — it's the documented public endpoint https://api.z.ai/api/anthropic with a regular API key.

    What I'd suggest for OpenCodex

    1. Short term: document/support pointing an Anthropic-protocol provider at a zcode2api-compatible local gateway (base_url = http://localhost:3000, model glm-5.3-flash). That alone unlocks free-quota fallback via combo routing. A built-in preset/alias for it would be a nice touch.
    2. Longer term: a native zcode account provider implementing the zcode.z.ai chain (OAuth login → request signing → captcha), using zcode2api as the protocol reference. It's admittedly fragile (Aliyun fingerprint changes break solvers) and ToS-gray, so opt-in with a clear warning would make sense.
    3. The clean path: Z.AI exposing official API keys for the free Start Plan would turn this into a trivial provider preset — maybe worth relaying upstream.

    Happy to help test if you take this on.

  7. Ingwannu commented on Oct 7, 2026

    @Ingwannu
    Ingwannu
    on Oct 7, 2026
    Owner

    Thanks for separating the paid API lane from the reported app-entitlement/authentication lane. The client-bundle observations and third-party gateway are compatibility leads, not evidence of a supported third-party API or authorization to reproduce client signing/captcha behavior. I have not tested those implementations or the free-plan entitlement, and this triage does not endorse a gateway or guarantee free quota.

    Before a built-in preset/native login can be considered, please provide primary Z.AI documentation or written confirmation for third-party access, the intended authentication flow and model discovery, relevant terms/operating entity, and a maintenance owner/verification date. The canonical-preset evidence requirements in MAINTAINERS.md still apply. A generic user-managed custom endpoint is a separate interoperability surface; adding a named built-in alias would itself advertise a supported destination. @lidge-jun an owner decision on that support boundary is needed before implementing either native auth or a promoted preset. No login, signing handshake, captcha automation or provider call was attempted.

  8. lidge-jun commented on Oct 9, 2026

    @lidge-jun
    lidge-jun
    on Oct 9, 2026
    Owner

    Closing as not planned. ZCode free/Start Plan login falls under the same policy as #4647 (no first-party-app plan reuse or captcha solving).

  9. lidge-jun
    closed this as not plannedon Oct 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, planscatalogModel catalog, slugs, visibility, routed entriesenhancementNew feature or requestproviderProvider adapters, OpenAI-compat presets, upstream API quirks

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions