jcode: a Rust coding-agent harness with a very small memory footprint

What jcode is and which problem it targets

jcode is a coding-agent harness written in Rust and published under the MIT licence by 1jehuang. The repository describes it as a harness rather than a model: it owns repository search, tool execution, session state and model-provider support, and the model is something you point it at. That split matters. If you already pay for an API key, jcode is the layer that decides what gets read from your working tree, which commands run, and how the conversation is carried between turns.

The stated problem is resource cost at scale. The README leads with two claims, that jcode is the most RAM efficient harness and the most intelligent harness, and then supports the first with a table of proportional set size (PSS) figures at one and ten active sessions. The framing is explicitly about multi-session workflows: the README says every metric is optimized for scaling multi-session workflows. So the target user is someone who keeps several agent sessions open at once, not someone who runs a single chat window. The homepage points at jcode.sh, which hosts docs, an SDK page and a benchmarks page.

The architecture visible in the workspace layout

Cargo.toml declares a workspace rather than a single crate, and the member list is the clearest statement of how the project is divided. There is a provider layer (jcode-provider-core plus jcode-provider-anthropic, jcode-provider-openai, jcode-provider-bedrock, jcode-provider-copilot, jcode-provider-openrouter, jcode-provider-antigravity and others), a runtime layer (jcode-agent-runtime, jcode-app-core, jcode-core), a terminal layer (jcode-tui), and state and storage crates (jcode-session-types, jcode-storage, jcode-memory-types, jcode-compaction-core).

That separation is the mechanism. Adding a provider means implementing the provider-core trait in a new crate instead of editing the agent loop. Context handling is its own crate (jcode-compaction-core), which suggests compaction is a policy applied to the session rather than something buried in the model client. Tool safety has a dedicated crate, jcode-command-risk, which is worth noting because command execution is the part of a harness that can hurt you. The repository also carries crates/jcode-harness-api and crates/jcode-harness-api-server, and the README links an SDK page, so the harness is intended to be callable from outside the TUI. The README does not document the wire format of that API, and the repository root does not include a spec file for it, so treat the SDK as something to read from source before you depend on it.

Installing jcode and opening a first session

The README gives a one-line install for macOS and Linux that pipes a script from jcode.sh into bash. Run it from a shell with write access to your user directories; the README does not document the install path the script chooses, so check where the binary lands before adding it to a PATH you rely on.

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

Windows 11 users get a PowerShell equivalent, which the README states requires PowerShell 5.1 or later.

# Windows 11 (PowerShell 5.1+)
irm https://jcode.sh/install.ps1 | iex

The README also points to a detailed installation section for Homebrew, source builds and provider setup, and says an agent can set it up for you. Source builds are plausible given the Cargo.toml workspace, but the README does not spell out the build command in the text available here, so follow the docs site rather than guessing flags.

Before the first real session you need a provider. The workspace lists provider crates for Anthropic, OpenAI, Bedrock, Copilot, OpenRouter and Antigravity, and the repository root contains OAUTH.md, which suggests at least some providers authenticate through an OAuth flow rather than a plain key. The README does not document the exact environment variable names or the config keys for provider selection, so the honest next step is the docs site or OAUTH.md. Once a provider is configured, launching jcode opens the TUI, and the README's own benchmark methodology describes measurement across interactive PTY launches, which tells you the normal mode of use is an interactive terminal session, not a scripted one.

jcode vs Claude Code and jcode vs OpenCode: where the RAM numbers come from

The README's comparison tables put jcode next to pi, Codex CLI, OpenCode, GitHub Copilot CLI, Cursor Agent, Claude Code and Antigravity CLI. At one active session, jcode with local embedding off is listed at 27.8 MB PSS, jcode with embedding on at 167.1 MB, Claude Code at 386.6 MB and OpenCode at 371.5 MB. At ten sessions the gap widens in absolute terms: jcode with embedding off is 117.0 MB, jcode 260.8 MB, OpenCode 3237.2 MB and Claude Code 2300.6 MB.

Read the first row carefully. The headline number is the local-embedding-off configuration, and turning embedding on multiplies it by roughly six at one session. If repository search depends on local embedding, you may be choosing between the memory figure you saw in the title and the search behaviour you actually want. The README does not state whether embedding is on by default, so that is the first thing to check in your own install.

The time-to-first-frame table is a different kind of measurement. jcode is listed at 14.0 ms, with the other tools between 383.5 ms and 3436.9 ms, measured across 10 interactive PTY launches on a Linux machine. Startup latency is a real user-facing property, but it is also the metric most sensitive to binary size, dynamic linking and whether a runtime is bundled. A single Rust binary starting fast is not surprising; the interesting question is whether the same binary stays fast once a provider connection and an embedding index are live. The README does not report that.

Limitations, and when jcode is the wrong tool

The comparison tables are self-reported and machine-specific. The README says the figures were measured on this Linux machine across 10 interactive PTY launches, which is a narrow basis for a claim as broad as the most RAM efficient harness. There is no stated methodology for how the other tools were configured, what prompts were sent, or whether their embedding features were enabled. Treat the ratios as a starting hypothesis, not a result.

Provider coverage is broad but uneven in documentation. The workspace lists crates for Anthropic, OpenAI, Bedrock, Copilot, OpenRouter and Antigravity, and the Cargo.toml member list is truncated in the published file, so there may be more. What the README does not provide is a table of which providers are first-class, which are experimental, and what each one requires for authentication. OAUTH.md exists at the repository root, which is a signal that auth is non-trivial enough to need its own document.

Version numbering is another caution. Cargo.toml declares version 0.84.0 while the most recent release listed is v0.81.2 from 2026-08-29, so the crate version and the release tag are not in lockstep. That is common in fast-moving projects but it means you should read the changelog directory rather than trusting a version string. The README does not document a rollback procedure or a stability guarantee, so pinning to a release tag is your own responsibility. If you need a GUI, a managed cloud service, or a project with a published support policy, jcode is the wrong tool: it is a TUI-first Rust binary aimed at people comfortable running a build from source when a release lags.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-08-29, with three releases in the days before it (v0.81.0 and v0.81.1 on 2026-08-26, v0.81.2 on 2026-08-29). That is a tight release cadence, and it cuts both ways: fixes arrive quickly, and so does churn. A harness that owns session state and storage has upgrade risk in the persisted format, and the repository carries jcode-session-types and jcode-storage as separate crates, which is exactly where a format change would land. The README does not describe a migration path between versions, so back up any session directory you care about before upgrading.

Licensing is MIT, which is permissive and imposes no copyleft obligation on your own code. The practical implication is that you can vendor jcode into an internal tool or a commercial product, provided you keep the licence text and copyright notice. This is not legal advice; read LICENSE and your own organisation's policy.

The workspace also contains a telemetry-worker directory and a TELEMETRY.md file at the root, which means the project has a telemetry component. The README does not state in the text published here what is collected or whether it can be disabled. If you work somewhere with data-handling constraints, read TELEMETRY.md before the first run, not after.

Editorial conclusion

Adopt jcode if you run many concurrent agent sessions on one machine and want a single Rust binary with provider choice, and if you are willing to supply your own API keys and verify the provider path you need in the workspace crates. Do not adopt it if you need a documented stability policy or a GUI, because the README does not state one and the repository is a TUI-first project. Before committing, run the curl install script from jcode.sh, open a session, confirm your provider is present under crates/ in the workspace listing, and re-read the PSS table knowing that the 27.8 MB baseline is the local-embedding-off configuration, not the default.

Frequently asked questions

Official sources

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