jcode

Jcode is built on three bets.

1. 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.
2. 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.
3. 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.

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).

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%).

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.

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.

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 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.