jcode Setup: The Rust Coding Agent That Barely Uses RAM

jcode is a terminal coding agent written in Rust, and its whole pitch is a resource bill: the maintainer's own benchmark puts ten concurrent jcode sessions at 260.8 MB of memory against 2,300.6 MB for the same ten sessions of Claude Code. It picked up roughly 527 stars in a day to reach 14,700 total, and v0.64.2 landed on July 30. Installing it takes one command and about two minutes, and because it can log in with the Claude, ChatGPT, Gemini or Copilot subscription you already pay for, you can try it without buying anything new.

• One line installs it: a shell script on macOS and Linux, a PowerShell one liner on Windows, with a Homebrew tap and a source build as alternatives.
• It speaks to Claude, OpenAI, Gemini, Copilot, Azure, Ollama, LM Studio and roughly thirty other providers through OAuth or an OpenAI compatible endpoint.
• The headline feature past speed is swarm mode: several agents in one repository, with the server telling agent B when agent A edits a file it had already read.
• MIT licensed, seven months old, and written and benchmarked by one person, which is the caveat that shapes everything below.

What is jcode and why is it trending?

jcode is a single Rust binary that puts a coding agent in your terminal, in the same product category as Claude Code, Codex CLI, OpenCode and Cursor Agent. The repository description is three words: the most RAM efficient harness. That framing is doing a lot of work right now, because the way people actually use these tools changed faster than the tools did. One agent per repo was fine. Four terminals running four agents against four branches is now normal, and every one of those Node based harnesses drags its own runtime along. jcode's README puts a number on the difference: about 10 MB of extra memory per added session versus roughly 213 MB for Claude Code and 318 MB for OpenCode.

RelatedSuperpowers Setup: Give Your AI Coding Agent a Real Workflow

Speed gets the same treatment. Time to first rendered frame is 14.0 ms for jcode against 3,436.9 ms for Claude Code and 1,035.9 ms for OpenCode on the same machine. The project also shipped its own mermaid renderer and its own terminal emulator, Handterm, because the existing ones were in the way. That is either admirable or a warning sign depending on your appetite for a young codebase, and it is worth holding both thoughts at once.

How do you install jcode on macOS, Linux and Windows?

Each platform has a one liner, and the installer picks the right architecture and checks the download against the release's SHA256SUMS. Pipe-to-shell installers deserve the usual scrutiny, so read the script first if that matters to you.

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

# macOS, via Homebrew instead
$ brew tap 1jehuang/jcode
$ brew install jcode

Windows 11 needs PowerShell 5.1 or newer, and the installer will not silently start a long compile if a matching release asset is missing:

# Windows 11 x64 or ARM64
irm https://jcode.sh/install.ps1 | iex

The v0.64.2 assets give you a sense of the footprint on disk: 41 MB for the Linux x86_64 tarball, 43 MB for Apple Silicon, and 110 MB for the standalone Windows x86_64 executable. Building from source works everywhere and needs a Rust toolchain:

# any platform, from source
$ git clone https://github.com/1jehuang/jcode.git
$ cd jcode
$ cargo build --release
$ scripts/install_release.sh

How do you point it at a model?

This is where jcode is unusually generous. It supports subscription backed OAuth flows for the major vendors, so the plan you already pay for is the plan it uses. Log in with whichever you have:

# pick one; each opens a browser OAuth flow
$ jcode login --provider claude
$ jcode login --provider openai
$ jcode login --provider gemini
$ jcode login --provider copilot

# confirm whatever is already configured actually works
$ jcode auth-test --all-configured

Beyond those, jcode ships named profiles for OpenAI compatible services including openrouter, deepseek, moonshotai, kimi, baseten, nebius and more, plus ollama and lmstudio for local models. A custom endpoint goes through jcode login --provider openai-compatible, which now accepts a localhost server with no API key at all. Settings live in ~/.jcode/config.toml, and MCP servers are configured separately in ~/.jcode/mcp.json globally or .jcode/mcp.json per project. On first run it will try to import MCP servers you already defined for Claude Code or Codex rather than making you retype them.

What do the first commands actually do?

# launch the TUI
$ jcode

# one shot, non-interactive: the smoke test
$ jcode run "say hello"

# background server, then attach clients to it
$ jcode serve
$ jcode connect

# resume an earlier session by its memorable name
$ jcode --resume fox

That serve and connect pair is the piece worth understanding, because it is what swarm mode is built on and where the memory story pays off. Spawn several agents in one repo and the server mediates between them: when one edits a file another has already read, the second gets told, and can pull the diff instead of confidently working from a stale copy. Agents can also spawn their own workers, which turns the original into a coordinator. The other quietly useful trick is cross harness session resume, with support for Codex, Claude Code, OpenCode and pi sessions, so a broken session in one tool does not mean starting the conversation over.

How do the numbers compare with the incumbents?

Read row one before row two. At a single session Codex CLI is actually lighter than jcode's default configuration, and jcode only reaches 27.8 MB there with local embedding switched off, which costs you the memory feature. The advantage is entirely about scaling: jcode adds about 10 MB per session while the others add hundreds, so the gap barely exists at one agent and becomes absurd at ten. If you run one agent at a time, none of this changes your life.

RelatedOpenWork Setup: Open-Source Claude Cowork in 15 Minutes

What are the gotchas before you rely on it?

Start with provenance. Every number above comes from the project's own README, measured by its own author on one Linux machine, comparing his tool against everyone else's. Nobody has independently reproduced them. The methodology looks reasonable and PSS is the right memory metric to use, but this is a vendor benchmark in the most literal sense, and the honest move is to run your own before repeating the multiples.

Then maturity. The repo is seven months old with one primary maintainer, the README carries visible typos and a stray line of text mid paragraph, and the benchmarked build is labelled v0.9.1888-dev while releases are numbered v0.64.2. Features arrive faster than documentation settles. Two concrete limits are worth knowing up front: MCP support is stdio only, so HTTP and SSE server entries are recognised, logged and skipped, and a Windows source build needs Visual Studio 2022 Build Tools with the Desktop development with C++ workload, not just Rust. Termux users need pkg install glibc patchelf first. And self dev mode, where you tell the agent to edit its own source, is genuinely interesting and genuinely a way to break your install if you point a weak model at it. The maintainer says as much.

Our take

Install it if you run agents in parallel. That is the whole recommendation, and the qualifier is the important half. jcode is not competing on model quality, since it uses the same models through the same subscriptions as everything else; it is competing on the cost of having the harness open, and it only wins that fight when you have several open at once. For the developer with four terminals against four branches on a 16 GB laptop, a couple of gigabytes back is not a benchmark curiosity, it is the difference between working and swapping.

What makes it worth watching beyond the numbers is that it treats multi agent work as the default case rather than a bolt on. The server mediating file conflicts between agents, the memory graph pulling in relevant history without the model burning tokens on memory tool calls, the lazy loading of skills by embedding hit: these are all answers to problems that only exist once you have stopped running one agent at a time. Most harnesses are still catching up to that shape. The risk is the obvious one, a very young project with one author and self reported wins, so keep your primary tool installed. But two minutes to find out is a cheap experiment.

Original analysis by GenZTech. Tool documentation: 1jehuang/jcode on GitHub.