What jcode Actually Is

jcode is a terminal-based (TUI) coding agent harness written in Rust. One binary, MIT licensed, runs on Linux, macOS, and Windows. It wraps the model providers you already pay for — Claude, OpenAI, Gemini, GitHub Copilot, even Ollama and LM Studio for local models. So it’s less a brand-new agent and more a better house to run the agents in. If you’ve seen my pi-agent-harness review, this one just pushes the RAM angle further.

Honestly, the claim that made me install it is the resource-efficiency pitch — “the most RAM efficient harness.” So that’s the first thing I tested.

I Tested jcode’s RAM Claim on My Own Machine

The README ships a benchmark table, but I wanted to see it with my own htop. So I launched a single session each of jcode and Claude Code on my Ryzen 9, let them both sit at idle, and checked resident memory.

The gap is real. My Claude Code sat at around 380 MB idle while jcode, with its local memory embeddings running, held near 165 MB. That’s not a rounding error — it’s a different design philosophy. When you’re running ten sessions at once (the multi-agent “swarm” mode), the difference compounds fast. OpenCode scaled to over 3.2 GB for ten sessions in their bench; jcode stayed under 300 MB.

Yet if you run agents all day on a work machine, that’s the whole ballgame.

Quick Start: Running jcode for the First Time

Install is one line, and the config actually handles itself:

# macOS & Linux
curl -fsSL https://jcode.sh/install | bash

# or Homebrew
brew tap 1jehuang/jcode && brew install jcode

After install, jcode login --provider claude picks up my existing subscription — no API key juggling. Then jcode drops you into the TUI. First launch felt instant; the time-to-first-frame in their bench is ~14 ms versus Claude Code’s ~3.4 seconds, and honestly the terminal stays snappy even mid-stream. I ran a simple refactor across a small Rust repo and it handled context fine.

The Features That Make It Worth Watching

Two things stood out beyond the memory story. First, agent memory: jcode embeds each turn as a semantic vector and pulls in relevant memories automatically — a human-like recall that doesn’t burn tokens on memory-tool calls. Same recall instinct I covered in claude-mem, built in rather than bolted on. Second, self-dev mode: you can tell jcode to modify its own source, rebuild, and reload its binary mid-session. So it’s a personal assistant that can patch itself.

On top of that, there’s a swarm mode where multiple agents work the same repo and the server coordinates file-conflict notifications between them, plus a built-in Firefox browser bridge for automation. Because that swarm keeps a coordinating server running across all your agents, a cheap DigitalOcean Droplet ($200 free credit for new users) is a tidy place to host that persistent server and keep the load off your workstation (affiliate link). Though for a young project, the feature surface is ambitious.

What to Watch Out For

Honesty time. jcode is moving at breakneck speed — the version numbers jump daily, and I hit one config wrinkle that the docs caught but wasn’t obvious. Also, the self-dev features explicitly want a frontier model (their words: weak models “can make subtle, breaking changes” to the codebase). And its MCP support is currently stdio-only — HTTP/SSE servers are detected and skipped. If you lean on remote MCP, that’s a gap to check before switching.

Bottom Line

jcode is the rare case where the hype number and the measured reality agree. It’s the leanest coding agent harness I’ve run — RAM-wise, nothing else comes close — the terminal is genuinely fast, and the memory/swarm features point at where multi-agent workflows are headed. It’s young and shipping fast, so pin a release before betting your whole workflow on it. But if your machine chokes under three agents at once, give jcode a weekend — 812 stars in a single day says I’m not the only one who noticed.