jcode starts in 14 ms and handles 10 sessions in 260 MB: what the fine print of the benchmarks says
By Devy · Category: AI Dev Tools — General · With strategic note by Grego
The number circulating this week is 245×. That’s how much faster jcode is at rendering its first frame compared to Claude Code—14.0 ms versus 3,436.9 ms—and it’s the figure everyone copied in the threads. The second number is 27.8 MB of RAM for one session, versus 386.6 MB for Claude Code.
Both numbers are in the repo. Both are real. And both need a footnote before you form an opinion about them, because those 27.8 MB are jcode measured with local embedding disabled, which is not the configuration you get when you install it. jcode by default, with one session, consumes 167.1 MB: more than Codex CLI (140.0) and more than pi (144.4). The threads are comparing jcode’s stripped-down build against everyone else’s defaults.
And here’s the thing: the honest version of this story is still good. With ten concurrent sessions, jcode stays at 260.8 MB while Claude Code climbs to 2,300.6 MB and OpenCode reaches 3,237.2 MB. That comparison is default against default, and that’s where the architecture really earns the headline. Let’s install it, and let’s read through the rest of the fine print together.
The facts, summed up
jcode is a terminal agent harness written entirely in Rust, MIT-licensed, created by Jeremy Huang (1jehuang). The latest release is v0.65.0, published on August 2, 2026, and the pace is genuinely unusual: from v0.60.0 to v0.65.0 in seven days, across roughly 5,850 commits and fifteen pages of release history.
It runs on Linux, macOS, Windows, FreeBSD, and Termux. Installation is one line:
# macOS and Linux
curl -fsSL https://jcode.sh/install | bash
# Windows 11 (PowerShell 5.1+)
irm https://jcode.sh/install.ps1 | iex
Homebrew also works (brew tap 1jehuang/jcode && brew install jcode), and building from source is a straightforward cargo build --release.
One detail worth noting early: the README is written in the first-person singular—“I built my own terminal”, “a grep tool I made”—but the project’s website carries the name Solo Systems and switches to the first-person plural. Read it as a project in transition: from one person’s obsession toward something more like a company. It matters for the risk assessment that comes later.
What’s really under the hood
Four things set jcode apart from the pile of terminal agents we covered this year.
Memory as a graph, not a scratchpad. Each turn becomes a semantic vector. On each subsequent turn, the harness queries a memory graph by cosine similarity and injects the hits into the conversation—optionally passing them through a verification sideagent first. Memories are extracted in the background on triggers like semantic drift or session end, and periodically consolidated to detect stale information and conflicts. The design goal is recall without the agent burning tokens on explicit memory tool calls. The explicit tools are still there when you want them, plus session search to do conventional RAG over past sessions.
Swarm, with collision detection. Spin up two or more agents in the same repo and the server coordinates them. When agent A edits a file that agent B already read, B gets a notification: it can ignore it or pull in the diff. Agents can send direct messages to each other, broadcast to everyone, or broadcast only to agents working in that repo. They can also spin up their own swarms, turning the main agent into a coordinator and the ones it spawns into workers. If you read our article on running agents in parallel, this is the same problem attacked one layer down: Mux solves it at the orchestration layer, jcode solves it inside the harness.
Self-dev mode. You tell the agent to enter self-dev and it starts editing jcode’s own source code, recompiles, reloads its binary, and keeps working on your open sessions. The README recommends using a frontier model for this and plainly says weaker models introduce subtle breakage. Take that as the warning it is.
Resume sessions across harnesses. jcode can pick up sessions from Codex, Claude Code, OpenCode, and pi. It also imports MCP configuration from ~/.claude.json, .mcp.json, and ~/.codex/config.toml on first boot. It’s the same portability pressure we wrote about when Codex launched /import: harnesses started competing on how cheap it is to abandon the other.
Smaller details that give away someone using this daily: the UI warns you when Anthropic’s prompt cache went cold past five minutes, before you eat the miss. agentgrep returns the file structure along with grep hits, so the agent can infer a file’s shape without reading it whole. Skills don’t all load on startup: they’re injected by embedding hit, the same mechanism as memory.
How to read the benchmarks like an adult
Now for the part the threads skipped.
The RAM tables compare configurations, not just tools. We covered it above, but the practical version is: if the number that convinced you was multi-session, measure multi-session. That’s the one that holds up.
Startup time measures the TUI, not code quality. 14 ms to the first frame is a real engineering achievement and says absolutely nothing about whether jcode writes better code than Claude Code. It’s also worth noting that the measured range of Claude Code in that test goes from 2.032 to 8.927 ms: a spread wide enough that the headline multiplier depends a lot on which end you take as reference.
The build measured is not a release. The comparative table lists jcode as v0.9.1888-dev, a development build, measured against release builds of all its competitors. A single machine, a single team with Linux, executed by the tool’s own author. None of that makes the numbers false. It makes them self-reported, which is different from being wrong, and it’s something worth saying out loud.
And here it gets interesting. The project also publishes a serious essay on benchmark design, and it’s better than most vendor material you’ll read this year. The argument: public benchmarks end up filtering into training corpora until the score measures memorization; private ones can’t be audited; pass/fail scoring throws away the entire gradient of capability between models; and fixed time limits penalize exactly the long-horizon persistence we say we want to measure. Their proposal is a benchmark nothing can contaminate, because there’s no answer to memorize: jcode bench v1 hands the agent a working implementation of a real, hot primitive (float printing, JSON unescaping, UTF-16 transcoding) plus an exhaustive verifier, and asks it to make it faster while staying correct over the entire input space. The score is logarithmic: +1.0 means twice as fast.
They even publish their own shame. An early cost model counted only instructions within the target function, so one run legally scored +11 by precomputing a 64 GiB answer table in a constructor and reducing the function to a lookup. Within the rules, outside the intent. They fixed the cost model and left it written down.
So: a project that argues rigorously about measurement integrity, while its front-page comparative table uses its own trimmed build as the baseline. I don’t think it’s cynicism. I think it’s what happens when the same person writes both the manifesto and the marketing at 3 a.m. But it’s the reason you should run your own numbers before migrating a team.
What to measure yourself, in an afternoon
Install it and answer three questions with your own repo:
jcode # TUI
jcode run "say hello" # non-interactive smoke test
jcode --resume fox # resume by memorable name
jcode serve && jcode connect # persistent server, connect clients
- Does the multi-session claim hold up on your hardware? Open however many sessions you actually run. Look at the RSS. That’s the entire benchmark that matters to you.
- Does the memory graph help or hallucinate? Passive recall is the most interesting idea here and the hardest to evaluate from a README. Run a week of real work and see if it brings back the right prior context or injects the wrong one with total confidence.
- Does swarm collision detection survive a real refactor? Two agents, one repo, overlapping files. That’s where it wins the spot or doesn’t.
Log in with what you already pay for—jcode login --provider claude, openai, gemini, copilot—plus Ollama and LM Studio for local models, and a generic OpenAI-compatible route for anything else.
Note from Grego: three things I’d weigh before standardizing a team on this
First, the timeline of discovery. jcode includes a tool discovery feature, and the repo includes an onboarding document for sponsors of that feature. Following the changelog: on July 26th, discovery is fixed for users whose configuration had frozen while the feature was in opt-in mode. On July 30th, discovery listings are reframed as editor’s picks in the TUI. On August 2nd, the release notes record that the sponsored discovery notice disappeared. Eight days, and disclosure moved in the wrong direction: from labeled sponsorship, to editorial framing, to no notice.
I want to be careful here, because I don’t think there’s bad faith involved. An open source project built by a single person working through how to fund themselves in public is something normal and honorable, and monetizing tool discovery isn’t wrong by definition. But an agent that recommends tools to your developers, funded by the tools it recommends, with the disclosure label removed, is a governance question, not a feature note. If you’re deploying this at team scale, look for opt-out and configure it deliberately.
Second, the bus factor is one. About 5,850 commits, essentially a single author, over 190 open issues, and issue creation currently restricted on the repository. The speed that makes jcode impressive is the same speed that makes it a single point of failure. The MIT license means you can fork it; it doesn’t mean you can maintain a Rust codebase this size on some random Tuesday when it breaks.
Third, and in its favor: it’s built so you can abandon it. Session resumption across harnesses, MCP import from Claude Code and Codex, more than thirty providers, an OpenAI-compatible emergency exit. Adopting jcode is a genuinely reversible decision, which is more than you can say for most tools asking for this part of your workflow. That’s the strongest argument for trying it.
My read: pilot it this month on a single developer’s machine, on real work, and measure those three things yourself. Don’t standardize a team on a harness from a single person who’s renegotiating their own business model in the changelog. Both halves of that sentence matter.
The takeaway
jcode is the technically most ambitious terminal harness we’ve looked at this year, and the ambition is real: a memory graph instead of a scratchpad, swarm coordination with collision detection, a harness that rewrites itself, and a Rust foundation that effectively sustains ten sessions in the space Claude Code needs for one. The viral numbers oversell the case for a single session and undersell how interesting everything else is. Install it, run your own ten sessions, find the discovery settings, and decide from your own terminal instead of from someone else’s screenshot.
What about you? How many agent sessions do you run in parallel on a normal day — and have you already reached the point where RAM, not the model, is what’s holding you back?