[Feature]: ZCode provider for GLM Coding Plan models

[0xgeorgemathew]

I built and live-verified a ZCode provider that lets GLM Coding Plan subscribers run
GLM-5.3 and GLM-5.3-Flash in T3 Code. It is a large change, about 11k lines across a
new protocol package, the server adapter, web and mobile settings, and docs. Before
opening a PR I want to confirm this fits the direction you want, and that its
maintenance cost is acceptable upstream.

Demo

ZCode in Settings → Providers. Enabled, authenticated against the Z.ai account,
models read from the app's account store.

The model picker with the account's entitled models, GLM 5.3 and GLM 5.3 Flash.

glm-5.3-flash-streaming.mp4

A real GLM-5.3-Flash turn streaming in a T3 Code thread.

What this enables

Sign in to the ZCode app once on the machine running your environment and T3 Code
drives it like any other provider. Threads stream, follow the shared permission
modes, accept image attachments on vision models, switch models mid-thread, resume
after restart, and share session history with the ZCode app.

How it works

ZCode bundles a CLI runtime that speaks a JSON-RPC app-server protocol over stdio,
the same shape as Codex's. The integration adds an effect-zcode-app-server package
mirroring effect-codex-app-server and runs one CLI child per session.

There is one wrinkle. Models newer than the CLI's built-in catalog, GLM-5.3 today,
exist only in the desktop app's provider store. The provider reads that store plus
the app's plan-entitlement cache and pushes the entitled provider registry into each
session with workspace/updateProviderRegistry. That is the same call the ZCode
desktop host makes. The picker then offers the models the signed-in plan actually
serves.

Implementation status

The working implementation covers the server adapter, shared contracts, web and
mobile settings, user documentation, mock-peer tests, and live verification against
ZCode CLI 0.16. CI never spawns the real CLI.

Maintenance boundary

The Codex and Claude providers use vendor-distributed tooling. This one talks to an
undocumented wire protocol that already broke incompatibly once, between 0.15 and
0.16. Upstreaming it creates a real maintenance obligation whenever ZCode updates.

The implementation limits the damage with a minimum-version gate that warns the
user, strict protocol schemas, mock fixtures derived from live traffic, and a
fallback to the CLI's baseline catalog when the registry push fails. Those measures
reduce the cost. They do not remove it. If Z.ai ships an official SDK later, the
adapter boundary is where it would go.

Decision requested

Does a ZCode provider belong in T3 Code, and should it start as Early Access the way
Grok did? If you are on a GLM Coding Plan and would use this, a 👍 on this post
helps the maintainers gauge demand. Comment if your setup differs from what is
shown.

Reference implementation

The full change is in a standalone repo:

0xgeorgemathew/t3code-zcode-provider @ zcode-provider

Since the branch is upstream main plus one commit, the commit page shows the
complete diff:

d4eab428 — feat(providers): add ZCode for GLM coding plans

There is no PR attached and nothing asking for review. To try it, check out
the branch and run it the same way you run main.

[juliusmarminge]

Closing as a wash of the prior decision on #8116.

That PR proposed the same ZCode / GLM Coding Plan provider surface. It was closed on 2026-08-28 with an explicit maintainers note that T3 Code is not adding ZCode to the current provider set (protocol, auth, packaging, and client support maintenance cost).

Nothing in this discussion changes that boundary. If you believe the earlier close was in error, reopen #8116 (or a fresh PR) and explain what changed.