# Jcode – open-source AI coding agent for the terminal

> Source: <https://jcode.sh/>
> Published: 2026-08-11 10:20:23+00:00

## Show commit history

Backed by Combinator

An open source terminal coding agent, written in Rust.

```
curl -fsSL https://jcode.sh/install | bash
```

[All builds](https://github.com/1jehuang/jcode/releases/latest) · [Docs](/docs) · [Pricing](/pricing) · [GitHub ](https://github.com/1jehuang/jcode)

Backed by Combinator

Jcode is built on three bets.

The bottleneck to massive parallelism is resource efficiency. Spawn dozens of agents and RAM consumption balloons, unfeasible on most consumer machines: when each agent takes hundreds of megabytes, you run a handful and queue your work behind them. Jcode fixed that. We optimize to the bone so spawning another agent is a non-decision and running dozens of sessions is actually possible, with none of it traded for speed. Every number below is sampled from real launches of real agents on the same machine.

Extra proportional memory (PSS) each additional client adds once one is already running. Ten jcode sessions cost about 100 MB, less than half of one Claude Code.

| Tool | Extra PSS | Graph | Comparison |
|---|---|---|---|
| jcode | ~10.4 MB | baseline | |
| Claude Code | ~212.7 MB | 20.5× more RAM |

| Tool | Extra PSS | Graph | Comparison |
|---|---|---|---|
| jcode (local embedding off) | ~9.9 MB | baseline | |
| jcode | ~10.4 MB | 1.1× more RAM | |
| Codex CLI | ~21.6 MB | 2.2× more RAM | |
| pi | ~76.5 MB | 7.7× more RAM | |
| Antigravity CLI | ~86.4 MB | 8.7× more RAM | |
| Cursor Agent | ~157.5 MB | 15.9× more RAM | |
| GitHub Copilot CLI | ~158.1 MB | 16.0× more RAM | |
| Claude Code | ~212.7 MB | 21.5× more RAM | |
| OpenCode | ~318.4 MB | 32.2× more RAM |

How long until you can actually type: time until typed probe text appears on the rendered screen, 10 interactive PTY launches each. Antigravity uses its internal input-ready log marker because its sign-in screen suppresses probe echo.

| Tool | Time | Graph | Comparison |
|---|---|---|---|
| jcode | 48.7 ms | baseline | |
| Antigravity CLI | 383.7 ms | 7.9× slower | |
| pi | 596.4 ms | 12.2× slower | |
| Codex CLI | 905.8 ms | 18.6× slower | |
| OpenCode | 1047.9 ms | 21.5× slower | |
| GitHub Copilot CLI | 1583.4 ms | 32.5× slower | |
| Cursor Agent | 1978.7 ms | 40.6× slower | |
| Claude Code | 3512.8 ms | 72.2× slower |

How long until anything renders, same 10 interactive PTY launches.

| Tool | Time | Graph | Comparison |
|---|---|---|---|
| jcode | 14.0 ms | baseline | |
| Antigravity CLI | 383.5 ms | 27.4× slower | |
| pi | 590.7 ms | 42.2× slower | |
| Codex CLI | 882.8 ms | 63.1× slower | |
| OpenCode | 1035.9 ms | 74.0× slower | |
| GitHub Copilot CLI | 1518.6 ms | 108.5× slower | |
| Cursor Agent | 1949.7 ms | 139.3× slower | |
| Claude Code | 3436.9 ms | 245.5× slower |

Running the standard evals against these harnesses showed us how poorly they represent what agents can actually do. Existing benchmarks face a forced choice. Public benchmarks leak their solutions into training corpora, so scores measure memorization and misrepresent capability. Private benchmarks resist that, but they demand trust in a hidden test set, offer less transparency, and are hard to get access to. Beyond that choice, they share two structural flaws. They impose timeouts, so an agent is penalized for allocating more time to a problem, exactly the long-horizon behavior we want agents to develop. And they score on a coarse, discrete boundary: the gap between two very different models can show up as a single task completion. A model that solves 70% of a bench may sit next to a remaining 30% that demands a far higher capability level, and that entire delta is invisible between the discrete tasks. So we designed a new class of benchmarks with a spec:

This design is immediately trustable because everything is public. Training on a previous model's transcript may even help a little, but it doesn't score better unless the model has genuinely generalized from it: replaying a transcript only matches the old score, and beating it requires optimizing past what was memorized, which is the capability the benchmark measures in the first place.

jcode bench v1 provides three tasks that follow this spec: float-print, json-unescape, and utf16-transcode. We chose these tasks because they grade in seconds and are pure coding on real world functions that are useful and genuinely benefit from optimization: a tight loop the agent can climb, on work that actually ships in libraries. The tasks are also chosen so the implementation cannot be overfit to the test suite: correctness is verified over the entire input space, not a sample. Compare measuring grep's speed by timing it on the Linux repo, where an implementation can be overfit to the Linux repo specifically. Above, we plot the score of the agent over time, from a single user prompt. Note that time is 1:1 correlated with cost and token utilization, because tool call time is negligible in these tasks. Both runs used Opus 4.8 with high thinking, identical prompts, launched concurrently, each stopping on its own judgment. On float-print both passed the full 2³² correctness gate; jcode finished at +8.64 (398x speedup) versus Claude Code's +7.17 (144x).

[The uncontaminatable benchmark design](/bench) · [jcode bench](/jcode-bench)

[harness-agnostic frontier model results](/models) · [full results and agent transcripts](/jcode-bench#leaderboards)

The harness comparison is fully matched: the same 113 DeepSWE v1.1 tasks, GPT-5.6 Sol, xhigh reasoning effort, untimed natural completion, and k=1. Only the harness changes. The current result is an exact tie: on the 112 mutually scored tasks Jcode won 11 tasks that Codex failed and Codex won 10 that Jcode failed.

[Every task, with audited per-task outcomes from both runs](/benchmarks/deepswe.html)

DataCurve also publishes every mini-SWE-agent rollout. Their official GPT-5.6 Sol results use the revised v1.1 grader and four whole-benchmark runs, so they are useful context but are not ranked against the v1 k=1 harness results above.

Official 95% run-to-run intervals: max ±2.8 points; high ±1.4 points. [DataCurve leaderboard](https://deepswe.datacurve.ai/) · [derived per-task data and provenance](/benchmarks/data/deepswe-v11-datacurve-miniswe-sol-2026-07-17.json)

89 terminal tasks, claude-opus-4-8, run through the Harbor harness on Modal. Our best cell is medium effort at 77.8% (k=2), against Claude Code's published 78.9%. Medium beats xhigh while costing less per trial and finishing tasks 30% sooner, so more thinking stops paying for itself past medium on this benchmark. We also read and classified 28 failing xhigh trials: 22 real misses, 3 infra flakes, 3 borderline thresholds, and 0 grader disputes.

[Every run, with accuracy against cost and per-task transcripts](/benchmarks/terminal-bench.html)

Jcode's todo tool asks the agent to rate its confidence in each task item, both when the item is assigned and when it's marked done. Tracing those scores across our Terminal-Bench runs showed a clear pattern: confidence is always high after, but sometimes low before, and failures rarely come from tasks the agent was confident about at assignment. The low scores at assignment are real signal, and the jump to 100 at the end is not. So when we see a large spike in confidence, we force the agent to go back and check its work instead of accepting the claim. Ideally, confidence rises incrementally as validation happens during implementation, with each passing test earning a step up. Above, both harnesses on Terminal-Bench 2.1: each line is one trial, from confidence at assignment to confidence at completion. The extra checking pays: trials that finish in time pass more often (92% vs 88%), and even trials cut off by the benchmark's 15 minute limit are more likely to already contain correct work (47% vs 42%).

Agents are at their most capable when they have a metric to hill-climb. This is likely because reinforcement learning trains models to optimize against reward signals, so measurable feedback helps agents keep improving over longer time horizons, and those additional productive iterations lead to better results. Most users never take full advantage of this. Jcode does this for the user when applicable. Every agent goal receives a hill-climbability rating from 0 to 100, based on how quantifiable and iterable its progress really is. A high score is not credible without a stated objective to climb toward. When a goal scores low, the harness pushes back: reframe the goal into a verifiable objective and build the harness that measures it. Without this, an open-ended task leaves the agent with nothing to iterate against, no signal it can use to make its next attempt better than its last.

[See the hill-climbability implementation](https://github.com/1jehuang/jcode/search?q=hill_climbability&type=code) · [Download the aggregate data](/research/hill-climbability-distribution.json)

Persistence is the other half of intelligence: most agent failures are not wrong answers but early exits. Models love to declare victory. Jcode checks the todo list first. When a turn ends with incomplete todos, the harness pokes the model back to work automatically. Pokes are smart about failure too: transient network errors are retried, while non-retryable errors stop the loop instead of burning tokens. The same mechanism drives headless runs, so `jcode run` keeps iterating on a task across turns until the work is actually finished.

[See the persistence implementation](https://github.com/1jehuang/jcode/search?q=auto-poke&type=code) · [Read the full run transcript](/benchmarks/jcode-bench-transcript-jcode-float-print.html)

The same discipline is applied to everything between you and the model: every token, every cache hit, and every background process is engineered so the model spends its capacity on your problem instead of on overhead.

The single biggest lever on latency and cost is the prompt cache: providers charge a fraction for tokens the model has already seen, and reading them back is far faster than recomputing attention from scratch. Jcode is built so that cache almost never breaks. The prompt prefix is stable and the conversation is strictly append-only, so the longest possible shared prefix survives between turns instead of being silently invalidated. Things that would normally bust the cache are kept out of the prefix: tool schemas come from a fixed on-disk cache, MCP tools are advertised up front so a late connection never rewrites earlier turns, and dynamic context like memory recalls and system reminders are placed where they do the least damage. The result is consistently high cache-hit rates, lower bills, and noticeably snappier turns, especially on long sessions where naive agents pay to re-read the whole history every time.

Most agents make you wait: they block startup while every MCP server handshakes, or they connect lazily and then quietly invalidate the model's prompt cache the first time a tool shows up, costing you a full re-read of the conversation. Jcode does neither. On startup it advertises every configured MCP tool instantly from an on-disk schema cache, so the model sees the complete tool list in its very first request and the prompt cache stays warm. The actual server connections happen in the background, connect-on-first-call: if the model reaches for an MCP tool before its server has finished connecting, that single call transparently waits for the handshake, while everything else stays non-blocking. The result is that you can start typing and the agent can start working the instant a session spawns, MCP tools included, with no startup delay and no cache penalty. This works the same across the interactive TUI, the server, and headless `jcode run`.

Ask an agent to watch a build or a test run and it usually writes a polling script: sleep 500, check once, give up. Jcode has background tools instead. Start any command with run_in_background and it becomes a task the agent can list, tail, inspect, cancel, or wait on. The wait action blocks until the task finishes or hits its next progress checkpoint, so the agent wakes on events rather than burning turns on sleep loops. A foreground command that outruns its timeout is never killed: jcode adopts it into the background, and the task survives even a reload of the agent's own binary. Jcode parses task output for progress and renders each task as a live card in the TUI: percent, counts like 6/10 tests, byte ratios, and ETA, read from structured JCODE_PROGRESS lines or inferred from ordinary output. An agent can run a dozen tasks at once and let the server wake it when one needs attention.

Pushing the frontier is pointless if the tool is unpleasant to use. Jcode is also just a good everyday dev tool, with an interface built for real terminal work.

Jcode keeps the speed and focus of a TUI while rendering the things coding work actually needs: generated images, structured edits, math, links, diagrams, side panels, and live session states. Select any screenshot to view it at full resolution.

Jcode embeds each turn and response as a semantic vector. Every turn queries a graph of memories to efficiently find related entries via cosine similarity. The embedding hits are fed into the conversation, or optionally a memory sideagent verifies the memories are relevant and does more retrieval work before injecting them. This results in a human-like memory system: the agent automatically recalls information relevant to the conversation without actively calling memory tools or burning tokens.

Jcode is MIT licensed, open source, and open research. Everything we build and everything we measure is published, benchmark transcripts and failures included. A tool this close to your work should be one you can read, audit, and reshape.

Jcode is inventing a new form of customizability. One that doesn't limit you to what a plugin or extension can do. Tell your jcode agent to enter self dev mode, and it will start modifying its own source code. Jcode is optimized to iterate on itself. There is significant infrastructure around self development, which allows it to edit, build, and test its own source code, then reload its own binary and continue work in your (potentially many) sessions, fully automatically.

This is the normal-session system prompt compiled into Jcode, fetched live from the master branch. It measured 671 tokens with OpenAI's [ o200k_base](https://github.com/openai/tiktoken) tokenizer at revision 8def6862. Your static system prompt may include additional prompts from self-dev mode, AGENTS.md, or CLAUDE.md.

live from master · 671 tokens at 8def6862

Prompt architecture is a choice, not a leaderboard. Some harnesses keep the system role tiny and move procedure into user messages or tool schemas. Others put the operating manual in the core prompt. These are the default, publicly identifiable core instructions from pinned source revisions.

| Harness | Core tokens | Graph | Measured scope |
|---|---|---|---|
|

Measured July 11, 2026 with [ o200k_base](https://github.com/openai/tiktoken). Tool schemas, repository instructions, skills, memory, runtime context, and task messages are excluded. Claude Code is reconstructed from its leaked v2.1.88 source and rounds to 2,300 core tokens. A source comment describes broader prompt-cache invalidation as busting roughly 20,000 tokens; that cached prefix is not charted because tool schemas are excluded for every harness. SWE-agent places most procedure in its user template. Aider varies by edit mode. Dynamic rows are included for projects that do not expose one canonical static prompt asset.

Release highlights, with commit messages filling the gap until the next release notes are ready. The full history lives on [GitHub releases](https://github.com/1jehuang/jcode/releases).

Strict todo status validation

Release highlights.

More reliable autonomous runs

Release highlights.

A more capable desktop workspace

Release highlights.

Better ACP controls and focused session workflows

Release highlights.

Focused desktop sessions and provider reliability

Release highlights.