jcode

Single-author Rust terminal coding agent, MIT, 13,127★ / 1,452 forks on 2026-07-29, created 5 January 2026 and pushed the day it was read (v0.9.1888-dev). Linux, macOS, Windows; site at jcode.sh. Its own tagline: “The most RAM efficient harness / The most most intelligent harness” (typo in the original). T1 for what it is; the numbers in it are self-run vendor benchmarks and graded separately below.

The minimal-Rust-CLI end of the agentic-coding-harness spectrum, where claw-code already sits — but where claw-code is thin by design, jcode is dense: agent memory, multi-agent swarm, a custom terminal and a mermaid renderer, all under one binary.

The performance claims, and what they actually say

Startup, measured over 10 interactive PTY launches on one Linux machine:

The RAM headline needs reading carefully. The baseline row is “jcode (local embedding off)” at 27.8 MB PSS, and every comparison is anchored to it — including jcode’s own default configuration, which appears in its own table at 167.1 MB, “6.0× more RAM.” At that default, jcode uses more RAM than pi (144.4 MB) and Codex CLI (140.0 MB). So “the most RAM efficient harness” holds against Claude Code (386.6 MB) and OpenCode (371.5 MB) at any setting, and against the leanest competitors only with a feature switched off.

The marginal-cost table is the strong claim and it isn’t ambiguous. Per additional session, jcode adds ~10.4 MB against Codex CLI’s ~21.6 MB, Antigravity’s ~86.4 MB, Claude Code’s ~212.7 MB and OpenCode’s ~318.4 MB. Whatever the baseline argument, the scaling slope is 20–30× flatter than the heavyweights, which is the number that matters for the multi-session workflows the swarm feature below exists to serve.

Disclosure quality is above this corpus’s norm. Exact versions of all eight tools tested, ranges rather than bare means, the method stated, and a footnote that Antigravity ran unauthenticated and was measured by an internal readiness marker because its sign-in screen suppressed the probe echo. Compare jetbrains-ponytail-tested: the failure mode there was a mean over hand-picked cases presented without method. jcode shows its method. It is still a single machine, a single author, and metrics the author chose — and “the most intelligent harness” has nothing behind it at all.

Agent memory without tool calls

Every turn is embedded as a semantic vector and queried against a memory graph by cosine similarity; hits are injected into the conversation directly, or routed through a memory sideagent that verifies relevance and can do further retrieval first. Extraction runs on triggers — semantic drift, K turns since the last extraction, session end — and an “ambient mode” periodically consolidates, reorganising and checking for staleness and conflicts. Explicit memory tools and session search over past sessions sit alongside the passive path.

The design goal is stated as recall “without actively calling memory tools or being a token burner”, which puts it directly on two existing threads. It is agent-memory implemented inside the harness rather than behind MCP, where iai-pme and knowledge-rag both sit — and its consolidation-with-conflict-checking is close to iai-pme’s decay and contradiction surfacing, arrived at independently. Against context-rot, passive relevance-gated injection is a bet that retrieval beats accretion; nothing here measures whether it works.

Swarm: peer agents with a shared-state protocol

Two or more agents in the same repo are managed by a server that gives them something the corpus’s existing model lacks. When agent A edits a file agent B has read, the server notifies B — code shifting under its feet — and B can ignore it or diff it. Agents can DM one another, broadcast to all agents on the server, or broadcast to agents in the same repo. They can also spawn their own swarms, which turns the spawner into a coordinator and the spawned into workers, headless or headed.

agent-orchestration in this wiki has meant orchestrator → parallel subagent fan-out: a tree, with coordination happening at the root. jcode’s swarm is peer-to-peer with cache invalidation — the stale-read problem solved the way a filesystem or a CPU cache solves it, rather than by keeping agents in separate worktrees. agent-kanban shares a board; this shares a repo and reconciles.

Skills loaded by embedding hit, not by description

“Skills are not all loaded on startup. The conversation is embedded as a semantic vector, and will automatically inject a skill if there is an embedding hit similar to memories.” Manual activation remains available through a skill tool and slash commands.

This is a concrete alternative to the mechanism agentskills-spec is built on. Progressive disclosure decides what to load by having the agent read short skill descriptions and pick; jcode decides by vector similarity against the live conversation, on the same index that serves its memory. Description-based selection needs a well-written description and a model willing to spend attention on the menu; embedding-based selection needs neither and inherits retrieval’s failure mode instead — a skill that is relevant but phrased unlike the conversation never surfaces. Nobody has measured either. Related to reasoning-scaffolds, whose one honest experiment on skills came back null.

The author rejects worktrees, and says so

Under planned features: “Agents dont like to commit in dirty git state with active changes. Git was clearly not built for multi-agent workflows, and git worktrees is not a good solution. Given this, I believe that is an opporunity for a new git like primitive to be born.”

Worth recording because it is the swarm design decision stated as a premise. The corpus’s usual answer to multi-agent collision is a worktree per agent; jcode’s read-tracking server exists because its author thinks that answer is wrong, and he is looking past it to a replacement for git’s concurrency model rather than a better use of it. A stated intention with nothing built behind it — but it explains the topology.

The rest

Side panels that the agent can write to or use as a diff viewer, inline mermaid rendering via a purpose-built mermaid-rs-renderer claimed at 1800× faster with no browser or TypeScript dependency, “info widgets” that occupy only negative screen space, rendering above 1000 fps, a custom scrollback, and — because terminal scrollback has limits the author didn’t accept — his own terminal, handterm, work in progress. Plus subscription-backed OAuth flows, OpenAI-compatible and self-hosted vLLM endpoints, MCP config, and browser automation. A native iOS app is announced but unshipped: drive jcode on your own machine from a phone over Tailscale, with “Openclaw like features” bundled — see openclaw, which solved the same reach-your-machine-from-elsewhere problem first.

Cross-spoke context (not split — recorded here)

• ../ui-frameworks-wiki — the TUI layer is a genuine second subject: a custom terminal emulator, a from-scratch mermaid renderer, and a negative-space widget system belong next to opentui as terminal-UI engineering. Routed here because the harness is what jcode is; the renderer is how it draws.
• ../webperf-wiki — the byte-budget instinct applied to a local process rather than a page.

Related

agentic-coding-harness · claw-code · agent-memory · iai-pme · agent-orchestration · context-rot · agentskills-spec · reasoning-scaffolds · jetbrains-ponytail-tested · agent-kanban · openclaw · 1jehuang · synthesis