Framework and Product: A Star-Map Survey of Agent Harnesses

The joy of star-map surveying is making two stars of wildly different brightness develop on the same plate — brightness has never been the only measure of distance.

I. Two open-source routes

deepseek-harness (dsh) and ZCode, both agent harnesses from Chinese AI labs open-sourced in August–September 2026, walked two entirely different roads. dsh is DeepSeek’s “developer preview”: repository opened 2026-08-13, MIT, TypeScript around 51.5MB, 60+ packages, 245k stars, 29k forks, 42 contributors — about seven weeks from creation, quite possibly the fastest star explosion in history. ZCode is Z.ai’s coding-agent workbench: repository opened 2026-09-20, Apache-2.0, TypeScript around 34.6MB, 14 packages, v3.14.3 stable, 7.5k stars — and its GitHub repository is in substance a release mirror (2 contributors, a single release, PRs from collaborators only), with real development happening internally; reading its community numbers would badly underestimate its engineering mass.

II. Architectural philosophy: composition tree vs. layered governance

The greatest divergence is philosophical. dsh’s runtime is a plugin tree assembled at launch by profile: dsh-base provides model adapters, tool registry, persistence, sandbox and approval, credentials, and telemetry, followed by bundle order, profile patch, home patch, and --patch overlay layers; the substrate is DeepSeek’s own Cordis framework, where plugins contribute services, typed events, and reversible side effects to a shared context. Its slogan borders on manifesto — “the model adapter, tool registry, session log, and the agent loop itself are all plugins; there exists no privileged core.” The session log is an append-only SessionEvent, with context rebuilt by deriveMessages(); the model layer is a ctx.llm seam, where swapping the provider swaps the entire product. It even lets the agent build plugins for itself mid-conversation (the site demoed a pomodoro floating plugin generated by dialogue), and experimentally added a Claude Code Mods compatibility layer.

ZCode walks the opposite road: a spec-first layered monorepo — 14 packages each with its duty, an .architecture-baseline.json baseline, architecture-policy.yaml, pnpm architecture:check --changed, the single-state-owner principle, the desktop side talking to the agent process via stdio + zcode-protocol, CommandInbox serial admission, and a distinction between real-time and recoverable link chains. This is the route of “guaranteeing large-team collaboration with engineering discipline,” the exact dual of dsh’s “eliminating the core through composability.”

III. Security views and ecological niches

On security, dsh guards against “the agent doing dangerous things” (independent guard/sandbox/credentials/identity packages, the Web UI actively asking consent, SAFETY.md in the most prominent place); ZCode guards against “the service being accessed without authorization” (token auth, remote pairing and heartbeat, log redaction, sha256 verification of CDN resources). On ecological niche, one sentence fixes it: dsh’s plugins are an architectural concept; ZCode’s plugins are a distribution channel — the former gains exposure via the dsh-plugin topic, while the latter has a full official marketplace (built-in seeding + sha256-verified CDN downloads on demand + personal sources, lifecycle covering install to uninstall, curated lists remotely controlled via the official CDN).

IV. Verdict

The final judgment of the survey is calm and fair: dsh is a plugin-ized agent framework (developer preview); ZCode is a mature coding-agent product — the two are not competitors of equal maturity but rather a contrast of “framework” and “product.” The former’s edge is everything-is-a-plugin plus the Cordis composition tree, suited to developers who want to build or hack agent runtimes, at the price of breaking changes and preview instability; the latter’s edge is a consistent three-end product experience, plugin marketplace, remote development, and architectural governance, suited to out-of-the-box users and teams. Measuring ZCode with dsh’s community numbers, or demanding dsh with ZCode’s product completeness, is simply holding the wrong ruler.

Real coordinates

• dsh: DeepSeek, repo opened 2026-08-13, MIT, TS ~51.5MB, 60+ packages, 245k stars/29k forks/42 contributors, v0.2.1-alpha.1, request params limited to temperature/maxTokens/stop with llm-retry as a separate package for retries; official adapter lines dsh-llm-deepseek + dsh-llm-pi-ai; test/benchmark fanaticism (6 vitest configs + benchmarks/snapshots + jscpd)
• ZCode: Z.ai, repo opened 2026-09-20, Apache-2.0, TS ~34.6MB, 14 packages (including formal-proof, zcode-cua), v3.14.3 (2026-09-24), 7.5k stars/2,284 forks, 2 public contributors (release mirror); configurable provider surface (ZCODE_BUILTIN_PROVIDER_CONFIG_FILE + remote default.json + model-option-map)
• Philosophical dual: the Cordis composition tree (everything is a plugin, no privileged core) vs. the layered monorepo (architecture baseline + spec-first + dependency-boundary checks)
• Security dual: dsh guards against agent misbehavior (guard/sandbox + SAFETY.md) vs. ZCode guards against unauthorized service access (token/pairing/redaction/sha256)
• Ecological dual: plugin-as-architecture-concept (topic exposure + dialogue-built plugins + Claude Code Mods compatibility) vs. plugin-as-distribution-channel (official marketplace + CDN zips + full lifecycle)
• Verdict: framework vs. product, not competitors of equal maturity; star count is not the only measure of engineering mass