jcode: a Rust coding-agent harness built to run many sessions per machine, with swarm messaging and a self-editing mode

One curl pipe for macOS and Linux, and nothing else on the page

The install path offered in the README is a single shell pipe, labelled for macOS and Linux:

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

That runs a script fetched from jcode.sh with your user's permissions, so anyone with a policy against piping remote scripts into a shell should download it and read it first. The repository does contain other packaging material, including a packaging/ directory and a flake.nix with its flake.lock, which points to a Nix route, but the README gives no command for either. Windows users get no instruction on that page at all, so the jcode.sh site is the place to check before assuming the tool runs there. Building from source means compiling a large Cargo workspace on Rust edition 2024.

The memory and latency numbers are the project's own benchmarks

jcode sells itself on footprint. In its headless RAM benchmark, the first jcode session takes 71.3 MB and each additional one about 3.3 MB. The same table puts OpenCode at 637.1 MB then about 5.9 MB per extra session, pi at 84.0 MB then about 79.6 MB, Claude Code at 272.9 MB then about 169.3 MB, and Codex CLI at 398.6 MB then about 194.1 MB. A second table measures time until typed text appears on screen across 10 interactive launches: 19.1 ms for jcode, 596.4 ms for pi, 905.8 ms for Codex CLI, 1047.9 ms for OpenCode and 3512.8 ms for Claude Code. These are the maintainers' measurements, not an independent review, and they cover memory and input latency only, not the quality of the code an agent writes. The memory run can be reproduced with scripts/bench_headless_memory.py, and fuller figures are posted on jcode.sh.

Swarm mode warns agents about shifting files but leaves the decision to them

When two or more agents are spawned in the same repository, a jcode server manages them together. If agent A edits a file that agent B has already read, the server notifies agent B. Agent B can ignore the notice if it judges the change irrelevant, or check the diff to confirm nothing conflicts. Agents can also message each other: a direct message to one agent, a broadcast to every agent on the server, or a message to the agents in the same repository. The README claims this lets all conflicts be resolved automatically, but the mechanism it describes is a notification plus an agent's own judgment, not a merge step. If agent B wrongly decides an edit does not matter, nothing in that description stops it from writing over the change. Review the combined diff from a swarm the way you would review two developers who never spoke.

Agents can spawn their own swarms and become coordinators

Swarms do not have to be started by you. Each agent has a swarm tool that lets it spawn teammates to work on tasks in parallel. When it does, the original agent turns into a coordinator and the spawned agents become workers. The server tracks the groups, their messaging channels and their completion status, and this works either headless or with a visible interface. The practical consequence is that one prompt can fan out into several sessions you did not explicitly launch. That is where the low per-session memory figure matters, since the cost of an extra worker is small on the jcode side. Model-provider usage is a separate matter: every worker is another agent talking to a model, and the README sets no limit on how many workers a coordinator may create, so watch your provider bill and rate limits the first time you let an agent spawn a team.

Self-dev mode lets the agent rebuild and reload its own binary

Instead of a plugin or extension API, jcode offers what it calls self development. You tell the agent to enter self dev mode and it begins editing jcode's own source code. Supporting infrastructure lets it build and test those changes, reload its own binary, and continue working in your existing sessions, including several at once, without manual steps. This is the project's answer to customisation: anything the source can do, the agent can be asked to change. The trade-off is that your running jcode can drift away from any tagged release, and a change that compiles and passes tests can still alter behaviour you rely on, in every open session at the same moment. The README section on this feature still carries a placeholder comment for a demo and a fuller write-up, so the details of how self-dev changes are kept, reverted or merged with upstream updates are not on that page.

Providers arrive through OAuth sign-ins and per-vendor crates

jcode supports a range of model providers, and two sign-in routes are named outright: Claude OAuth and OpenAI Codex OAuth. The full provider list is kept at jcode.sh/docs#providers, and OAUTH.md sits at the top of the repository. The Cargo workspace shows how providers are wired in: separate crates for Anthropic, Bedrock, Copilot, OpenRouter and Antigravity, plus jcode-azure-auth, jcode-provider-env and jcode-provider-core. Other workspace crates hint at the rest of the harness, such as jcode-command-risk, jcode-compaction-core, jcode-embedding, jcode-pdf, jcode-notify-email and jcode-swarm-core. The repository also contains TELEMETRY.md and a telemetry-worker/ directory, so jcode has a telemetry component; read TELEMETRY.md before running it on code you cannot share. Token optimisation, KV cache handling and what the project calls hill-climbable measurements are covered in docs/HARNESS.md.

Preview tags move faster than the crate version

jcode releases are tagged as v1.0.0 previews and arrive in bursts: v1.0.0-preview.49 and v1.0.0-preview.52 both landed on November 2, 2026, and v1.0.0-preview.136 followed on November 3, 2026. The repository's last push was on November 2, 2026. Meanwhile the root Cargo.toml still carries version 0.99.1, so the version string in a source build does not match the release tag you downloaded. For a single developer that is a small annoyance; for a team trying to pin everyone to the same agent build, it means recording the release tag explicitly rather than trusting a version command. The same Cargo.toml describes jcode as having 30+ tools and a TUI, and the README screenshots show inline images, inline LaTeX, a resume menu for earlier sessions and a notification when the cache has gone cold.

Editorial conclusion

jcode suits developers who want to run many coding-agent sessions side by side in a terminal and are comfortable on preview builds that change several times a day; the per-session memory numbers are the clearest reason to pick it over the tools it benchmarks against. It is a poor fit if you need a stable, versioned tool for a team or a supported Windows install path. Before adopting it, rerun scripts/bench_headless_memory.py on your own machine, read TELEMETRY.md and OAUTH.md, and decide whether you will allow self-dev mode at all.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes