OAuth Integration Request: ZCode with GLM Models

[Minus-Brain]

Hello OmniRoute team,

I would like to suggest adding OAuth provider support to ZCode within OmniRoute. The goal is to make it possible to authenticate and access GLM models directly through ZCode.

This integration would bring several benefits:

Simplified authentication: Developers could securely connect using OAuth without handling tokens manually.

Unified access: GLM models would be available through the same OmniRoute gateway, alongside other providers.

Improved usability: Easier onboarding for new users and smoother workflows for existing projects.

Flexibility: OAuth support would allow broader compatibility with enterprise and cloud environments.

Could you please consider implementing this feature? I believe it would make OmniRoute even more powerful and developer‑friendly.

Thank you for your great work on this project!

[diegosouzapw]

Thanks, @Minus-Brain. GLM model access is already present through the glm, zai, and zai-web providers. The current catalog includes the GLM 5.x and 4.x families, and Qoder also exposes GLM models through its own API-key path.

The part that may still be new is OAuth specifically through the ZCode client. If ZCode has a public OAuth or device-flow specification that differs from the existing ZAI paths, please link it here with the authorization URL, token URL, and model endpoint. I can then assess that as an authentication integration rather than duplicating the GLM provider itself.

[Minus-Brain]

Thank you for the detailed response!
The main motivation behind proposing ZCode integration is that ZCode provides free daily usage limits/quotas for GLM models. Having OAuth support for ZCode would allow users to conveniently utilize these daily free quotas directly inside OmniRoute, without needing standard paid API keys.
I looked into the ZCode OAuth specification, and here are the exact endpoints and authentication flow details:
ZCode OAuth Endpoints
Authorization URL: https://chat.z.ai/api/oauth/authorize
Token URL: https://zcode.z.ai/api/v1/oauth/token
Business Login URL: https://api.z.ai/api/auth/z/login
User Info URL: https://chat.z.ai/api/oauth/userinfo
Authentication Flow
User Authorization: Redirect user to https://chat.z.ai/api/oauth/authorize to authorize the app.
OAuth Token Exchange: POST code to https://zcode.z.ai/api/v1/oauth/token to receive the OAuth access_token.
Business JWT Exchange: POST to https://api.z.ai/api/auth/z/login to exchange the OAuth token for a zcodejwttoken.
API Requests: GLM model endpoints accept requests using x-api-key: .
Since this OAuth flow grants access to ZCode's specific quotas and daily free tier, integrating it as an authentication provider in OmniRoute would be extremely helpful for the community.
Please let me know if you need any further information or specification details. Thanks again!

[diegosouzapw]

Follow-up @Minus-Brain -- I opened #9107 to track the ZCode OAuth integration, with your endpoints and the captcha caveat from #3873 noted. The validation gate (a clean model call via the OAuth-minted token, no browser) is the first thing to confirm before any code lands.

[diegosouzapw]

Excellent -- those endpoints are exactly what I needed, @Minus-Brain. The three-step flow (OAuth authorize -> token exchange -> business JWT mint -> x-api-key) is genuinely new in OmniRoute; none of the existing glm, zai, or zai-web providers use chat.z.ai/api/oauth or zcode.z.ai.

One thing to flag before I wire it up: this feature was requested before in #3873, which was closed after investigation found the ZCode model endpoint behind an invisible Aliyun captcha that required browser anti-detection. The reference implementation (LuckyWithLab/zcode_proxy) was also dead at the time. The OAuth path you described may bypass that captcha entirely -- but I need to verify that the zcodejwttoken minted via OAuth actually unlocks model access without hitting the captcha wall.

I will open a tracking issue with your endpoints and the captcha caveat. If you have a working curl example that shows a successful model call with the OAuth-minted token, that would be the fastest way to confirm the path is clean.

[Minus-Brain]

Final technical report on the ZCode OAuth / GLM free-tier investigation. Since the maintainers asked for a clean model call as the validation gate, I want to be fully
transparent: I ran a complete reverse-engineering pass over both the web client and the Electron client, got the OAuth chain and the captcha to a working state, and then hit a
hard server-side blocker that has nothing to do with auth or captcha. Full details below, in the order I worked through them.
>
> ## 1. Web client (chat.z.ai) — fully reverse-engineered, fully captcha-walled
>
> - Downloaded and unpacked the production frontend bundle (prod-fe-1.1.79) from the z-cdn.chatglm.cn CDN.
> - Reverse-engineered the X-Signature request signing: the HMAC key and the exact algorithm (HMAC-SHA256 over a 5-minute window key, then over sortedPayload + "|" + base64(vibeInfo) + "|" + timestamp) were extracted from the minified bundle and reproduced in both Python and Node — verified byte-identical (MATCH) against the browser's own
requests.
> - Enumerated every model endpoint: /api/v2/chat/completions (returns SSE but always FRONTEND_CAPTCHA_REQUIRED), /openai/chat/completions (403/500),
/api/chat/completions (405 from Alibaba WAF), /ollama, /api/agent/v2, /api/v2/chat/continue, plus /openai/models (works, lists the GLM family).
> - Result: every web model request is unconditionally gated by an interactive AliyunCaptcha (slider + behavioral analysis). The captcha_verify_param is only minted by
browser JS after interaction. I confirmed this is not a WAF/TLS issue: with a correct X-Signature, correct headers and a fresh session token, the server always answers
FRONTEND_CAPTCHA_REQUIRED / missing_param. No pure-HTTP path exists on the web target.
>
> ## 2. Electron client (ZCode 3.5.3) — OAuth chain fully reproduced
>
> - Downloaded the Linux AppImage and unpacked app.asar (host, renderer, preload, scheduler).
> - Extracted the complete provider configuration and endpoints:
> - Authorization URL: https://chat.z.ai/api/oauth/authorize
> - Token URL: https://zcode.z.ai/api/v1/oauth/token
> - Business Login URL: https://api.z.ai/api/auth/z/login
> - User Info URL: https://chat.z.ai/api/oauth/userinfo
> - Model endpoint (Anthropic format): https://zcode.z.ai/api/v1/zcode-plan/anthropic/v1/messages
> - Billing: https://zcode.z.ai/api/v1/zcode-plan/billing/balance?app_version=3.5.3
> - OAuth flow verified working end-to-end with plain HTTP:
> 1. POST chat.z.ai/api/oauth/authorize (form-urlencoded, action=approve, client_id, redirect_uri=zcode://oauth/callback, state) → returns code=code-...
> 2. POST zcode.z.ai/api/v1/oauth/token {provider:"zai", code, codeLength, redirect_uri, state} → returns zcodejwttoken and a separate zai.access_token
> 3. POST api.z.ai/api/auth/z/login {token: } → returns business access_token
> - I also verified the exact same flow is what the Electron client itself performs (the renderer's buildAuthorizeUrl matches redirect_uri, response_type, client_id, state;
the token exchange body matches provider, code, codeLength, redirect_uri, state), so the OAuth integration sketch in the issue description is accurate.
>
> ## 3. AliyunCaptcha — decompiled, traceless mode found and reproduced
>
> - Decompiled the AliyunCaptcha SDK (the same AliyunCaptcha.js the Electron client loads from o.alicdn.com).
> - Extracted the region configuration: host no8xfe.captcha-open-southeast.aliyuncs.com, -verify host for VerifyCaptcha, upload host, sceneId 11xygtvd, prefix no8xfe,
region sgp.
> - Extracted and AES-decrypted the embedded SDK keys (KEY_ID / KEY_SECRET / ACCESS_SEC) and the RPC signature scheme (Action=InitCaptchaV3, SignatureMethod=HMAC-SHA1,
SignatureVersion=1.0, Version=2023-03-05).
> - Key finding: the SDK has a traceless verification mode (startTracelessVerification) that completes without any slider interaction and without showing the
captcha UI at all. This is the mode ZCode itself uses for automated model calls.
> - Proof it works: on 2026-06-22, ZCode made 63 consecutive successful GLM-5.2 requests from this exact server using traceless captcha parameters (the model-io session
logs are preserved locally: X-Aliyun-Captcha-Verify-Param on every request, all finishReason: stop/tool-calls, SSE responses).
>
> ## 4. What I tried to get a working model call
>
> ### 4a. Pure-HTTP captcha attempts (all failed)
> - Hand-built InitCaptchaV3 RPC against no8xfe.captcha-open-southeast.aliyuncs.com with the extracted keys and correct HMAC-SHA1 signature → 404 /
{"code":400,"message":"not allowed to invoke!"}. The gateway requires real browser device data (canvas/WebGL fingerprint) — the DeviceData payload must come from a live
browser context.
> - Ran the actual SDK in Node with full browser mocks (window, document, navigator, fetch, XHR, iframe): the INIT request is emitted correctly, but the SDK's post-INIT
device-fingerprint stage requires a real DOM/iframe environment, so the verify step cannot complete headlessly without a browser engine.
> - Tried curl_cffi with impersonate=chrome (JA3/JA4 TLS fingerprint mimicry), plain curl, --http2, Node fetch — all hit the same wall. This confirmed the blocker is
the captcha device check, not TLS fingerprinting.
>
> ### 4b. Headless captcha via CDP (works)
> - Running the actual ZCode Electron binary under Xvfb with --remote-debugging-port, I drove the renderer over the Chrome DevTools Protocol:
> - loaded the real AliyunCaptcha SDK,
> - called initAliyunCaptcha({SceneId:'11xygtvd', mode:'popup', language:'en', ...}),
> - called instance.startTracelessVerification(),
> - received a valid captchaVerifyParam (base64 JSON {"certifyId":"...","sceneId":"11xygtvd","isSign":true,"securityToken":"..."}, ~280 chars) in the success callback.
> - Verified the SDK itself performs the VerifyCaptcha round-trip against the -verify host (no8xfe-verify.captcha-open-southeast.aliyuncs.com, HTTP 200) before returning
the param.
> - This is fully automatable and slider-free, but it is a headless-browser dependency, not a pure-curl path — worth being explicit about in the implementation plan.
>
> ### 4c. Model request matrix — every combination tried
> - Methods: POST, GET, PUT, PATCH, OPTIONS.
> - Paths: /api/v1/zcode-plan/anthropic/v1/messages, /api/v1/zcode-plan/anthropic/messages, /api/v1/zcode-plan/v1/messages, /api/v1/zcode-plan/messages,
/api/v1/zcode-plan/chat/completions, /api/v1/zcode-plan/v1/chat/completions, /api/v1/zcode-plan/openai/*, /responses, /v1beta/messages; plus the alternate hosts
api.z.ai (/api/anthropic/v1/messages, /api/v1/zcode-plan/anthropic/v1/messages), open.bigmodel.cn (/api/anthropic/v1/messages,
/api/coding/paas/v4/chat/completions), api.chatglm.site, zcode.chatglm.site.
> - Captcha placement: header (X-Aliyun-Captcha-Verify-Param), lowercase header, query string, request body, anthropic-beta header.
> - Auth headers: Authorization: Bearer with zcodejwt / zai access token / business token / raw zai token; x-api-key with each of those; combinations of both.
> - ZCode headers: X-ZCode-App-Version (3.5.3 and 3.1.2), X-Title: Z Code@electron, X-ZCode-Agent: glm, HTTP-Referer: https://zcode.z.ai, User-Agent (ZCode and
full Electron/Chrome UA), x-request-id, x-zcode-trace-id, x-query-id, x-session-id, X-Device-Mid (the device's real bc99d063-...), X-Os-Category, X-Os-Version,
Accept: text/event-stream.
> - Bodies: stream true/false, max_tokens 100/200/64000, thinking/output_config (as ZCode sends them), system prompt, minimal body.
> - Models: GLM-5.2, GLM-5-Turbo, glm-5-turbo, glm-5.2.
> - Billing checks: /api/v1/zcode-plan/billing/balance and /billing/current (with app_version query), via both curl and urllib.
> - Quota/subscription: api.z.ai/api/monitor/usage/quota/limit and api.z.ai/api/biz/subscription/list with business token.
> - Login-path attempts: writing tokens into the renderer's localStorage and reloading the UI; clicking "Connect to Z.ai" in the UI and capturing the OAuth window;
emulating the zcode://oauth/callback redirect via CDP (window.location, window.open, Target.createTarget, window.zcode.onOAuthCallback) — the callback requires the
Electron main process protocol handler and an external browser approval, so it cannot be replayed from the renderer alone.
>
> ## 5. The blocker (not auth, not captcha)
>
> Every model request that carries a fresh, valid traceless captcha, correct headers and a freshly minted token returns:
>
>
> 405 {"code":3012,"msg":"method not allowed"}
>
>
> And critically, the same 405 now comes back on the billing endpoints too (/api/v1/zcode-plan/billing/balance, /billing/current) that earlier returned 200 with plan
data. The diagnosis:
>
> - The free Start Plan (daily 5M tokens: 3M GLM-5.2 + 2M GLM-5-Turbo, plan id zcode-v3-start-plan-0615) has expired.
> - The entitlement snapshot the client itself cached shows expireTime: 2026-06-24.
> - The ZCode UI shows Start Plan — Expired/Ended on every account tested, including a brand-new account registered during this investigation.
> - api.z.ai/api/monitor/usage/quota/limit returns "当前用户不存在coding plan" ("user has no coding plan") — the server does not see any active plan for these accounts.
> - One billing call yesterday briefly returned an "active" plan (starts 2026-08-01, ends 2026-08-06) — a one-time activation artifact; today the same call returns 3012 again.
>
> ## 6. Conclusion for the maintainers
>
> 1. The OAuth flow in the issue description is correct and fully working — all three steps verified with plain HTTP, no browser needed.
> 2. The captcha caveat from #3873 is solvable: traceless mode completes without a slider; it needs a headless browser session (Xvfb + CDP) for the device fingerprint,
which is automatable but is not a pure-curl path.
> 3. However, the integration would currently authenticate but serve zero models. The free daily quota that motivated this feature is discontinued server-side — every
account, new or old, gets 3012 method not allowed. This is not something an OmniRoute provider can work around from the client side.
>
> Recommendation: hold the provider implementation until ZCode resumes or renews the Start Plan program (or until there is official word that the free tier still exists
under a different mechanism). The moment the quota is back, I can deliver a working end-to-end script for the validation gate — the OAuth chain, the traceless-captcha
acquisition, and the model call are all already proven individually; the only missing piece is the server re-enabling plan grants.
>
> Thanks again for keeping #9107 structured the right way — the acceptance criteria (auth completes, model call succeeds without browser, captcha finding documented) are
exactly what made this investigation conclusive.

[diegosouzapw]

@Minus-Brain -- this is exactly the report I needed to close the validation gate. Thanks for the depth of the RE work; the X-Signature HMAC + traceless-captcha acquisition alone would have taken a week to reproduce.

Outcome for #9107: hold, not implement. Your three findings settle it:

1. The OAuth chain (authorize -> token -> business login -> x-api-key) matches the spec and works end-to-end in plain HTTP.
2. The captcha wall from [Feature] Add ZCode / Z.ai GLM Provider Proxy Support #3873 is solvable via startTracelessVerification on a real browser context (Xvfb + CDP), but it is not a pure-curl path.
3. The model endpoints (and now billing too) return 405 code 3012 method not allowed for every account -- the zcode-v3-start-plan-0615 free quota expired server-side on 2026-06-24 (confirmed via api.z.ai/api/monitor/usage/quota/limit: "user has no coding plan"), so even clean OAuth + clean captcha authenticates but serves zero models.

OmniRoute will not ship a provider that authenticates but returns 3012 on every request. I will keep #9107 open but flip its plan-file verdict to blocked-upstream (your three findings are the blocker, not an OmniRoute gap). When ZCode resumes or renews the Start Plan -- or publishes a documented non-captcha API contract -- the validation gate can be re-run with your reproduced scripts as the regression guard.

If a paid-only ZCode tier appears (no quota gating, billed per token), ping me here and I will re-assess; the OAuth flow you reproduced would slot in cleanly in that scenario.

[diegosouzapw]

Follow-up @Minus-Brain - ZCode OAuth integration for GLM free-tier quotas is already tracked in #9107. I am linking this discussion there rather than opening a duplicate.

[spiwar]

Looks like the ZCode starter plan is available again, it might be worth revisiting this.
Had a crack at doing this myself, but I can't get past the captcha wall. Every time it fails, The starter plan is temporarily disabled on my ZCode account for 1 hour (405).

[diegosouzapw]

Hey @spiwar! Thanks for testing. That matches what @Minus-Brain's investigation found in #9107 -- traceless-captcha acquisition is the hard blocker (would take significant reverse-engineering effort to reproduce reliably, and it's fragile against ZCode API changes). #9107 stays on hold for that reason; the starter plan being temporarily available again doesn't change the captcha-wall problem. If you find a way past the captcha that doesn't involve browser automation, that would reopen the case.

[xz-dev]

Note at here http://github.com/vibe-coding-labs/zcode-reverse-engineer/blob/main/README.md

[diegosouzapw]

Thanks for the pointer, @xz-dev -- will take a look. Doesn't change the outcome in #9107 by itself (the captcha-wall blocker was the hard stop, not lack of endpoint knowledge), but if that repo has a working captcha-bypass approach that isn't browser automation, that would be worth revisiting. I'll check it out.

[shabeer]

@diegosouzapw As per #9107 it is already a work in progress, but it's closed as Not planned. It's quite confusing. I don't see any zcode-related commit within origin/release/v3.8.51 branch. Plz clarify.

[diegosouzapw]

@shabeer you are right to be confused, and the confusion is our fault, not a gap in your reading. There is no ZCode work in progress, and you will not find a commit because none exists.

What actually happened to #9107

The real outcome, from @Minus-Brain's investigation in this thread, was hold (blocked-upstream). The OAuth chain works end to end in plain HTTP, and the captcha is solvable via traceless verification, but reproducing captcha acquisition reliably requires deep reverse engineering and stays fragile against any ZCode API change. @spiwar independently hit the same wall in August, with the starter plan disabling for an hour on each failed attempt.

Then #9107 picked up an automated closing comment that said the opposite:

Good news: implementation for this request is already in progress. We're closing the issue to keep the tracker lean.

That is a template applied by a bulk-closing pass, and it was wrong for this issue. It landed on a ticket that was explicitly on hold, contradicting the hold verdict sitting directly above it, and the not planned state is the only accurate part of the result. Nothing is in flight.

So the correct reading: ZCode OAuth is not planned for now, blocked on the captcha wall, not on endpoint knowledge or on anyone's willingness to build it.

What would reopen it

A way past the captcha that does not require browser automation. @xz-dev pointed to the zcode-reverse-engineer repo in August and I still owe this thread a verdict on whether its approach clears that bar. If you have looked at it, or have a captcha path that works headlessly, that is the contribution that unblocks this.

Meanwhile GLM models are reachable today through the glm, zai and zai-web providers, and through Qoder's API-key path. What ZCode adds is specifically the free daily quota, not model access.

Thanks for flagging the contradiction rather than assuming the tracker was right. I am going to fix the closing template so it stops claiming work is in progress on issues that are on hold.

[shabeer]

@diegosouzapw glm, zai and zai-web providers - do not provide the starter plan which is available in zCode. Thats the impact. I am trying to use the starter plan credits of Zcode in omniroute.

[spiwar]

I don't think you read what he said. The thing is on hold because there is no reliable way to get past the captcha wall block.

[shabeer]

I understand about the captcha wall block.

If you find a way past the captcha that doesn't involve browser automation, that would reopen the case.

Does above statement mean, with browser automation - we can go past the captcha? Instead of doing browser automation, can a user do that manually - so that complexity of automation is avoid.

If above understanding is correct, can you plz list the manual steps (or any workaround) to go past the captcha wall block.

[diegosouzapw]

@shabeer short answer: no, a manual captcha step does not work, and I owe you a correction on the details, since I simplified the blocker too far in my last reply.

Correcting what I said

Re-reading @Minus-Brain's August report, the captcha was not the wall that stopped the investigation. It was solved: AliyunCaptcha has a traceless mode that completes without a slider, and it was driven successfully through a headless browser (Xvfb plus the Chrome DevTools Protocol). What actually stopped it was server-side: with valid OAuth, a valid captcha and correct headers, every model call returned 405 {"code":3012,"msg":"method not allowed"}, because the free Start Plan had been switched off for every account, new or old.

@spiwar later reported the starter plan was available again and hit the captcha when trying it. Nobody has re-run the full investigation since, so the current state of the plan is unverified.

Why a manual captcha does not help

Two findings from that report decide it:

1. The captcha parameter goes on every model request. In ZCode's own successful session, each request carried a fresh X-Aliyun-Captcha-Verify-Param. Nothing in the investigation showed a parameter that stays valid across requests. A manual solve would be one solve per request, which is unusable for a proxy.
2. Acquiring it needs a live browser fingerprint. Pure-HTTP attempts were rejected with not allowed to invoke! because the captcha service requires device data from a real browser context. So "automate it" means shipping and running a headless browser inside OmniRoute for every call.

That is why the acceptance gate on #9107 was "a model call succeeds without a browser". Browser automation was not missing know-how, it was the thing the gate ruled out.

What would actually move this

Re-validation that the Start Plan grants quota today, followed by a clean model call. If you have a ZCode account with an active starter plan, the billing endpoint (/api/v1/zcode-plan/billing/balance) returning an active plan would be the first data point. @Minus-Brain offered to deliver an end-to-end script the moment the quota is back, and that is still the fastest path.

[shabeer]

Thanks @diegosouzapw, for the detailed explanation.
@Minus-Brain Thanks for efforts you spent on investigating this issue. Greatly appreciate it. Hope to get this issue soon.

[diegosouzapw]

@xz-dev, @shabeer: I owe this thread the verdict on the zcode-reverse-engineer repo I said I'd give, so here it is, with its limits stated.

What I did. I read the README of vibe-coding-labs/zcode-reverse-engineer (Apache-2.0, last push 2026-08-17). I did not run it: testing it needs a ZCode account with an active Start Plan.

What it documents. The three-step OAuth chain (authorization code, then access token, then a business JWT), a Start Plan quota path at zcode.z.ai/api/v1/zcode-plan/anthropic with a Bearer JWT, and an npm run proxy that exposes an Anthropic-style local gateway.

What it doesn't cover. The README never mentions the captcha. I searched it in English and in Chinese. The blocker recorded in #9107 is that model calls carried a fresh X-Aliyun-Captcha-Verify-Param on every request, and that with valid OAuth and headers they returned 405 {"code":3012,"msg":"method not allowed"} while the starter plan was off. A repo that documents the login and the endpoint, without addressing either point, doesn't clear the bar of "a model call succeeds without a browser". Its claim of a validated MVP is also undated, so I can't tell whether it still works against the current service.

So this isn't a rejection of the repo. It just doesn't move the case yet, and the state stays as I described it on 09-15: not planned, blocked upstream, with no ZCode work in progress on our side.

What would move it. A successful model call through that path, without a browser, using an account whose starter plan is active today. Post the request/response with the token and the captcha header value redacted, and note the date. If that works, it reopens the case. If it needs a browser for each request, it doesn't.

Until then, GLM models stay reachable through glm, zai and zai-web, but I know none of them offer the ZCode starter plan you're after. I'm leaving this thread open.

[spiwar]

ZCode removed the captcha verification in a recent update (part of their changelog). Might be worth revisiting again haha. I'll do it myself some time later if no one does it.

[diegosouzapw]

@spiwar Thanks for the update. If ZCode really dropped the captcha, that changes this case. I can't see their changelog from here, so I haven't verified it myself and I'm taking your word for it until someone tests.

If you do re-test, this is what would settle it, and it's simpler than before:

• An account whose starter plan is active today, and its billing balance showing it.
• A model call that succeeds without a browser, with no X-Aliyun-Captcha-Verify-Param header on the request.
• The request and response posted here, with tokens redacted, and the date. If the calls still return 405 {"code":3012,...}, say so too, since that's useful evidence either way.

@Minus-Brain offered an end-to-end script earlier in this thread; if you two can compare notes, that's the fastest route. If the call works, I'll reopen #9107 and treat it as a real implementation task. Until a result is posted I can't promise anything.

(Side note: the link you posted is OmniRoute's v3.8.51 release page. If you meant ZCode's changelog, please post that link so others can check the entry.)

[spiwar]

ZCode Start Plan API: current state on 3.14.4

Status report from testing against my own account on 2026-10-04/05, ZCode 3.14.4 on Windows.

Context for the earlier posts in this thread: those were run against ZCode 3.5.3. ZCode has since published its client source (zai-org/ZCode, repo created 2026-09-20) and the current build differs from the one the August investigation used. The captcha work and the plan-loss behavior described earlier belong to that older client. What follows is what the endpoint does today.

Auth

The credential is the 255-char zcodejwttoken from ~/.zcode/v2/credentials.json, sent twice: authorization: Bearer <jwt> and x-api-key: <jwt>.

No captcha is involved. The 3.14.4 bundle contains no AliyunCaptcha, startTracelessVerification or scene id; X-Aliyun-Captcha-Verify-Param survives only as a diagnostic redaction key, and captured model requests do not carry it.

No client signing is involved for this provider. The app log emits model.client_signing.unsigned_sent with reason: access_mode and providerId: account:zai-start-plan. The Ed25519 handshake code is present in the bundle but gated behind isEnabled: async () => false.

Session id, query id, max_tokens, the user message text and the metadata.user_id contents do not affect the result. Fresh random values pass.

The 3012 response

405 {"code":3012,"msg":"request has been blocked due to unusual activity."} comes from a check on the request's system prompt. Changing one thing at a time in the captured 997-char title-generation prompt:

change to system[0].text	result
none	200
2 chars dropped from the end, middle or start	405
2 chars prepended, or text prepended before the prompt	405
anything appended, from 1 to 100+ chars	200
equal-length filler prose, or a generic short prompt	405

The rule that fits every row is system.startsWith(knownPrompt): the prompt must match byte for byte over its full length, and anything after it is ignored.

Conclusion

This is not viable as a provider. The check is on the request's system prompt, and it only accepts bodies that reproduce ZCode's own prompts verbatim. Any provider that forwards a user's own system prompt gets 405 3012, so there is nothing to build here.