待翻译：Jcode – open-source AI coding agent for the terminal

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

jcode An open source terminal coding agent, written in Rust. curl -fsSL https://jcode.sh/install | bash macOSLinuxWindows All builds · Docs · Pricing · GitHub GitHub stargazer historyShow commit historyHide commit historyGitHub commit history Backed by Combinator Mission Jcode is built on three bets. Parallelism is the biggest lever on coding productivity. You should never wait while coding. Every moment an agent is working is a moment you could be handing out the next task: spin up another session instead of watching this one finish, and your throughput becomes as many tasks as you can give out. Jcode makes it possible to run dozens of agents in parallel, and a dozen agents is a dozen times the output of one. The harness matters as much as the model. The same model produces very different results depending on what surrounds it: the tools it can reach, the context it sees, the memory it keeps, and the feedback loops that catch its mistakes. Model progress arrives on its own schedule. Harness progress is ours to make, and it compounds with every model release. Dev tools must be open source. A coding agent reads your code, edits your files, and runs commands on your machine. A tool with that much reach has to be inspectable, and it has to be modifiable: the best dev tools have always been the ones their users could open up and change, and your agent's source should be yours to customize. Jcode is MIT licensed, and everything we measure and learn is published. read moreread less Resource efficiency 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. Memory per additional session 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. ToolExtra PSSGraphComparison jcode~10.4 MB~10.4 MBbaseline Claude Code~212.7 MB~212.7 MB20.5× more RAM Show the full comparisonHide the full comparison Memory per additional session, all tools ToolExtra PSSGraphComparison jcode (local embedding off)~9.9 MB~9.9 MBbaseline jcode~10.4 MB~10.4 MB1.1× more RAM Codex CLI~21.6 MB~21.6 MB2.2× more RAM pi~76.5 MB~76.5 MB7.7× more RAM Antigravity CLI~86.4 MB~86.4 MB8.7× more RAM Cursor Agent~157.5 MB~157.5 MB15.9× more RAM GitHub Copilot CLI~158.1 MB~158.1 MB16.0× more RAM Claude Code~212.7 MB~212.7 MB21.5× more RAM OpenCode~318.4 MB~318.4 MB32.2× more RAM Time to first input 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. ToolTimeGraphComparison jcode48.7 ms48.7 msbaseline Antigravity CLI383.7 ms383.7 ms7.9× slower pi596.4 ms596.4 ms12.2× slower Codex CLI905.8 ms905.8 ms18.6× slower OpenCode1047.9 ms1047.9 ms21.5× slower GitHub Copilot CLI1583.4 ms1583.4 ms32.5× slower Cursor Agent1978.7 ms1978.7 ms40.6× slower Claude Code3512.8 ms3512.8 ms72.2× slower Time to first frame How long until anything renders, same 10 interactive PTY launches. ToolTimeGraphComparison jcode14.0 ms14.0 msbaseline Antigravity CLI383.5 ms383.5 ms27.4× slower pi590.7 ms590.7 ms42.2× slower Codex CLI882.8 ms882.8 ms63.1× slower OpenCode1035.9 ms1035.9 ms74.0× slower GitHub Copilot CLI1518.6 ms1518.6 ms108.5× slower Cursor Agent1949.7 ms1949.7 ms139.3× slower Claude Code3436.9 ms3436.9 ms245.5× slower Watch the performance demojcode performance demonstrationWatch the swarm session20 agents in parallel Intelligence optimization task float-print score over time, jcode vs Claude Code, Opus 4.8 high thinking 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: uncontaminatable by construction: there is no answer to memorize, so everything can be public hard to saturate by construction: scored on optimization depth, so the ceiling stays open past the frontier deterministic by construction: same submission, same score, always quantifiable by construction: the metric falls out of the task definition, no rubric, no judge continuous by construction: an analog score axis instead of pass/fail, so capability differences show up as score differences at every level, and time is recorded rather than capped cheat-resistant by construction: we provide a good reference implementation as the starting point, so web searching for ready-made solutions is only cheating at lower capability levels. At the frontier, there are no implementations left to copy that aren't useful recombinations 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). read moreread less The uncontaminatable benchmark design · jcode bench harness-agnostic frontier model results · full results and agent transcripts DeepSWE v1.1 harness comparison 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. RankHarnessScore barScore 01Jcode75 / 11366.4% 01Codex CLI75 / 11366.4% Every task, with audited per-task outcomes from both runs DataCurve DeepSWE v1.1 reference 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. EffortHarnessScore barPass rate MAXmini-SWE-agent327 / 450 attempts · k=472.7% HIGHmini-SWE-agent313 / 451 attempts · k=469.4% Official 95% run-to-run intervals: max ±2.8 points; high ±1.4 points. DataCurve leaderboard · derived per-task data and provenance Terminal-Bench 2.1 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 Confidence stepping per-trial confidence, assignment to completion, and pass rates before and after confidence stepping, Terminal-Bench 2.1, Opus 4.8 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%). read moreread less the full confidence study · every trial transcript Hill-climbable goals How hill-climbable did the model think the work was? n = 2,012goal-score submissions reframe below 90 555 160 570 1775 378 1180 382 29085 2888 75490 8592 194 67595 696 297 1798 109100 hill_climbability score → 91.29mean 90median 18.0%below the gate 55–100observed range Hill-climbability scores submitted through Jcode's todo tool across all persisted transcripts through July 12, 2026: 2,012 ratings from 1,973 todo calls across 815 sessions. Repeated updates to the same goal are counted separately. Scores not displayed received no submissions. 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. read moreread less See the hill-climbability implementation · Download the aggregate data Auto-poke The longest Jcode Bench v1 run, with its harness contin [truncated for AI cost control]