ZCode and the harness wars

Z.ai shipped ZCode on 20 September, and with it the last of the frontier labs got its own coding agent harness. DeepSeek has one, xAI has one, Z.ai now has one, and none of them will load a plugin written for another. Two days ago we scored our own prediction that somebody outside DeepSeek would adopt its plugin protocol, and the answer was no. ZCode is the fourth data point, and it points the same way. Here is the state of the harness layer, measured rather than asserted.

The field, as of today

Four harnesses matter right now. Three are built by labs that also sell you the model. One is not.

All four are permissively licensed, which is worth pausing on. Nobody is trying to lock the harness itself. The lock-in question has moved somewhere less obvious, and the numbers below find it.

Apply one test and the pattern appears

In our DeepSeek Harness writeup we argued that whether a project has its bug tracker open is the clearest single signal of whether it is a community project or a published artifact with a comment box. That test generalises unusually well here. We queried all four.

Every harness built by a frontier lab has its issue tracker closed. The only one you can file a bug against is the one no lab owns. Two of the three have no public feedback channel at all: grok-build and ZCode accept pull requests and nothing else.

This is not an accusation of bad faith. Running a public tracker on a repository with a quarter of a million stars is genuinely expensive, and DeepSeek at least kept Discussions open and credits outside contributors by name in its release notes. But if you are choosing a harness to build a product on, note what you are choosing: with three of these four, there is no public issue history to search when something breaks at 2am, and no way to find out whether anyone else hit it.

What ZCode actually is

ZCode calls itself an AI coding workspace with desktop, browser and terminal interfaces, which is a broader pitch than the others make. It is a pnpm monorepo containing an Electron desktop client, a web UI, backend services and a CLI with its own agent runtime, so the same engine drives all three surfaces.

pnpm bootstrap
pnpm dev:desktop

zcode
zcode --web --workspace /path/to/project --port 3030 --no-open

The repository description calls it "powerful, intelligent, extensible", and that third word is worth checking, because it is the word every one of these projects uses. Neither the Chinese nor the English README documents a plugin API, what a plugin can hook, or how to publish one. The DESIGN.md file, which you might expect to carry the architecture, is a design system: colours, typography, spacing.

The machinery is in the code even though the docs do not describe it. There is a plugin-sync service, a plugin-reference module in the CLI core, and plugin settings in the shared UI package. So ZCode has a plugin concept and has not yet told anyone how to use it. At seven thousand stars and ten days old that is forgivable, but it does mean that today, "extensible" is a claim rather than a documented surface.

The GLM question

There is a provider abstraction in the shared package, so ZCode is not hard-wired to one vendor. But the code has first-class concepts for Z.ai's own models that no other provider gets: a shared module defining an official GLM model id, a versioned official-GLM selection module in the session service, and a database migration dedicated to official GLM selection.

A schema migration is the tell. You do not write one of those for a provider you treat as interchangeable. The honest description is GLM-first with provider support, which is a reasonable thing for a lab to ship and a useful thing to know before you assume it is neutral. Compare OpenCode, which supports more than seventy-five providers and is the only one of the four with no model vendor behind it at all.

Nobody loads anybody else's plugins

Here is the part that decides whether any of this work is portable. Each harness has invented its own extension system.

DeepSeek built its plugin layer on Cordis, a plugin and event-bus meta-framework, and the ecosystem around it is now 16,486 repositories tagged as dsh plugins. That is a real achievement and it is also entirely captive: five weeks after we asked whether a competing harness would learn to load a dsh plugin, none has. grok-build supports skills, plugins and hooks of its own design. ZCode has its undocumented plugin machinery. A plugin you write for one of them is worth nothing to the others.

Two protocols do cross the boundary, and it is worth being precise about which. MCP has clearly won as the way a harness talks to external tools, and every serious harness speaks it. grok-build also implements the Agent Client Protocol so editors can embed it. Both of those standardise the edges, what the agent reaches out to and what embeds the agent.

Neither standardises the middle. There is no shared protocol for extending a harness itself, and that is exactly the layer where four labs have each built something incompatible. If you write plugins, you are not picking a tool, you are picking a side.

The glue is coming from outside

The most interesting response to this is not from any lab. Magpie is an MIT-licensed Go utility that sits in the macOS menu bar and routes agents to models across vendors, so you can run Codex against DeepSeek or Claude Code against Kimi. It has 3,368 stars and it exists because the labs will not do this themselves.

That is the shape of the whole layer right now. Vendors compete at the harness, the community builds the interoperability, and the only genuinely neutral option is the one with no lab behind it.

Which one should you actually run

Run OpenCode if you want vendor neutrality, an open bug tracker and seventy-five-plus providers. It is the largest genuinely independent option and the only one where filing a bug is possible. Note that it moved organisations recently, from sst to anomalyco, so update any bookmarks and pinned URLs.

Run DeepSeek Harness if the plugin ecosystem is the point. Sixteen thousand plugins is a real library and nothing else comes close, as long as you accept that the library is captive and the tracker is shut.

Run grok-build if you live in a terminal and want ACP so your editor can embed the agent, and you are comfortable with a Rust binary from a vendor with no public feedback channel.

Look at ZCode if you want one engine across desktop, browser and terminal, which is a genuinely different offer, and if being GLM-first suits you. Wait for a documented plugin API before you build anything on its extension surface.

What to watch next

Whether ZCode documents its plugin API. The machinery exists; publishing the contract is what would turn "extensible" from a description into a feature.

Whether any lab harness reopens Issues. Three for three is a pattern, not a coincidence, and the first one to reverse it will be making a real statement about who the project is for.

Whether a plugin protocol emerges the way MCP did for tools. MCP proved the labs will adopt a shared standard when the alternative is worse for everyone. The extension layer is now in exactly the state the tool layer was in before MCP.

Sources and further reading

• ZCode on GitHub
• OpenCode, formerly sst/opencode
• DeepSeek Harness
• grok-build
• Magpie, the cross-vendor router

Ten minutes: run this against whichever harness you are betting on, and read the answer as a statement about who the project is for.

curl -s https://api.github.com/repos/OWNER/REPO \
  | jq '{stars: .stargazers_count, issues_enabled: .has_issues, discussions: .has_discussions}'

Tested on: not independently tested. Star counts, fork counts, issue and discussion settings were read directly from the GitHub API on the date below and move continuously. Architecture claims about ZCode come from reading its public repository, including the absence of a documented plugin API in either README and the presence of plugin and official-GLM modules in the source tree. Install commands are quoted from each project's own documentation.
Date checked: 2026-09-30