jcode: The Coding Agent That Raises the Skill Ceiling, vs opencode and pi
There is a new class of tool quietly reshaping how software gets written: the AI coding agent harness. In the last year, three have risen to the top: opencode, pi, and jcode. All three are fast, terminal-first, and opinionated. But jcode keeps shipping capabilities the others haven't, and some of those feel less like features and more like a shift in what an agent is allowed to do.<br>This post walks through what makes jcode distinct, and how the three stacks compare head to head.<br>The landscape<br>opencode is an open source agent built in TypeScript with an extensible plugin ecosystem. It ships a polished TUI plus a desktop app, IDE extension, web interface, and CLI. Extensibility is its identity: plugins are npm packages, and it speaks MCP, LSP, and ACP. OpenCode Zen, its hosted gateway, is a curated list of models tested and verified by the opencode team. It's the most full-featured and polished of the three out of the box.<br>pi is radical minimalism. It ships without built-in MCP, sub-agents, permission popups, plan mode, built-in to-dos, or background bash, by design. The harness stays small and the complexity lives in TypeScript extensions, skills, and prompt templates. You get four interfaces (interactive, print/JSON, RPC, and SDK), a session tree with in-place branching, and aggressive context engineering.<br>jcode is a Rust-native harness built around one idea: the agent should be able to operate on itself and alongside other agents. It's the only one of the three that routinely rebuilds its own binary, runs in a swarm with other jcode agents, and remembers across sessions the way a human does.
Capability<br>jcode<br>opencode<br>pi
Language / runtime<br>Rust (native binary)<br>TypeScript / Bun<br>TypeScript / Node
Self-dev (agent rebuilds itself)<br>Yes, first-class<br>No<br>No
Swarm / multi-agent in one repo<br>Yes, native, with conflict detection<br>No (session-centric)<br>No
Persistent semantic memory<br>Yes (vector-embedded graph)<br>No (session-based)<br>No built-in (extensible)
Ambient / autonomous mode<br>In development (designed)<br>No<br>No (SDK only, e.g. OpenClaw)
Native inline mermaid rendering<br>Yes (custom Rust renderer)<br>No<br>No
Side panels + info widgets<br>Yes<br>Limited<br>Via extensions
Cross-harness session resume<br>Yes (Claude Code, Codex, opencode, pi)<br>No<br>No
Cache-aware request interleaving<br>Yes<br>No<br>No
Plugins<br>Yes<br>Yes (npm, broad)<br>Yes (TS extensions)
MCP<br>Yes<br>Yes<br>Build-your-own via extensions
Background bash<br>Yes<br>No<br>Deliberately absent
The rest of this post goes deep on jcode's differentiating features, and the situations where they earn their keep.<br>1. Self-dev: the agent that upgrades itself<br>jcode runs in "self-development mode," a dedicated pipeline for its own source. When you ask it to change its own code, it doesn't stop at writing a patch. It kicks off a coordinated build, waits for it to succeed, and reloads itself onto the new binary mid-session, then keeps going. The command is jcode selfdev --build: it builds and tests a new canary version before launching, then hands the running server off to the fresh binary so your sessions survive the upgrade.<br>Why it matters: jcode dogfoods itself so aggressively that its feature velocity compounds. Features get shipped, tested on itself, and iterated in hours, not weeks. That's not a gimmick, it's a closed feedback loop no other harness in this comparison has. For jcode's own maintainers it's the difference between "the tool changed" and "the tool changed itself."<br>2. Swarm: agents that actually collaborate<br>Multi-agent setups usually mean "launch a few processes and hope they don't collide." jcode's swarm mode is different: multiple jcode agents work the same repository and the harness itself coordinates them.<br>File-change conflict detection: if agent A edits a file that agent B read, the server notifies B before B acts on stale data. B can ignore it or check the diff.<br>Native messaging: agents can DM one another or broadcast to the server-wide group or just the agents in that repo.<br>Autonomous spawning: an agent can spawn its own teammates to parallelize work, turning itself into a coordinator and the spawned agents into workers. This can run headless or headed.<br>The practical use case is a large refactor. Instead of one agent churning through every module serially, you spin up a swarm that splits the work across files, with the server arbitrating conflicts and a shared plan tracking the DAG of tasks. Where pi refuses sub-agents by design and opencode's model is session-centric rather than swarm-aware, jcode treats a group of agents as a first-class runtime primitive.<br>3. Semantic memory: recall without burning context<br>Sessions in most agents are amnesiac. jcode gives its agents something closer to long-term memory.<br>Every turn is embedded as a semantic vector, and jcode queries a graph of memories to find related entries via cosine similarity. A memory sideagent verifies the results are actually relevant before they're injected,...