jcode: The Most RAM-Efficient AI Coding Agent
1jehuang/jcode
jcode is a Rust-built terminal AI coding agent that backs its RAM claim with numbers: 260.8 MB across 10 sessions versus 2,300.6 MB for Claude Code, per its own README benchmark. Reach for it if you run several agent sessions at once and terminal-only fits your workflow. Skip it if you want a GUI, or you need HTTP/SSE MCP servers β jcode only talks to stdio ones today.
What is jcode?
jcode is a command-line and TUI coding agent written in Rust under the MIT license. It logs into Claude, OpenAI, Gemini, GitHub Copilot, Azure OpenAI, and OpenAI-compatible endpoints β including local Ollama or LM Studio servers β then layers a semantic-vector memory graph and a multi-agent 'Swarm' mode on top. The README frames all of it around one goal: keep RAM and startup time flat as sessions stack up.
Addressing Performance and Resource Needs for AI Agents
Running several AI agent sessions side by side is normal work now β a coordinator plus a few background helpers β but each session in tools like Claude Code or OpenCode carries its own few-hundred-megabyte footprint, and that adds up fast on a laptop. jcode's README targets this directly: it measures PSS per session against seven other agents and designs around keeping that number close to flat as sessions stack up, instead of just shipping another chat UI over an LLM API.
Key Capabilities of jcode
- βRAM measured as PSS, not just claimed: 27.8 MB for one session with local embedding off, 117.0 MB baseline at 10 sessions, and roughly 10.4 MB extra per added session versus 212.7 MB for Claude Code in the same test.
- βStartup speed: 14.0 ms time-to-first-frame and 48.7 ms time-to-first-input, benchmarked across 10 interactive PTY launches on one Linux machine.
- βSemantic memory graph: every turn is embedded as a vector, related memories are pulled in by cosine similarity, and a background 'sideagent' extracts and consolidates memories on semantic drift, turn count, or session end.
- βSwarm multi-agent mode: agents sharing a repo get server-side notifications when another agent edits a file they've read, and can DM one agent, broadcast to all, or scope messages to the repo.
- βAgents can spawn their own sub-swarms β the parent becomes a coordinator, the spawned agents become workers, and this runs headless or with a UI.
- βProvider coverage: OAuth login for 10 built-in providers plus one shared OpenAI-compatible layer with 15 named profiles (OpenRouter, DeepSeek, Moonshot AI, and others), plus `jcode provider add` for self-hosted or vLLM endpoints.
- βCustom TUI: side panels double as live file viewers or diff viewers, Mermaid diagrams render inline through jcode's own renderer, and the interface can redraw north of 1,000 fps.
Installing jcode
macOS and Linux: `curl -fsSL https://jcode.sh/install | bash`. Windows 11 (PowerShell 5.1+): `irm https://jcode.sh/install.ps1 | iex`. Both are one-line scripts served from jcode.sh. The README links out to a separate 'detailed installation' section for Homebrew, building from source, and provider setup β that content isn't in what's documented here, so treat those paths as not clearly documented until you've checked the linked docs yourself.
Quick Start with jcode
Log into a provider first β `jcode login --provider claude` or `jcode login --provider openai`, for example. Register a self-hosted endpoint with `jcode provider add my-api --base-url https://llm.example.com/v1 --model my-model-id --api-key-stdin --set-default`, then smoke-test it with `jcode --provider-profile my-api auth-test --prompt 'Reply exactly JCODE_PROVIDER_SETUP_OK'`. Local runtimes follow the same shape: `ollama pull llama3.2` then `jcode --provider ollama --model llama3.2 run 'hello'`.
Strengths
- βPSS at 10 sessions is 260.8 MB for jcode versus 2,300.6 MB for Claude Code and 3,237.2 MB for OpenCode in the README's own table β a real gap if you keep several sessions open.
- βTime-to-first-frame is 14.0 ms against 3,436.9 ms for Claude Code in the same run. Startup feels instant.
- βMemory extraction and consolidation run automatically in 'ambient mode,' so the agent recalls prior context without you calling a memory tool every turn.
- βSwarm flags conflicting edits between agents sharing a repo instead of letting them silently overwrite each other.
- βOne shared OpenAI-compatible provider layer covers hosted services like OpenRouter and DeepSeek and self-hosted vLLM servers alike, so a new endpoint doesn't need its own integration.
Current Limitations and Considerations
- β³The RAM and latency numbers come from the maintainer's own README, run on a single Linux machine across 10 PTY launches β not an independent, third-party benchmark.
- β³The version tested was `v0.9.1888-dev (be386f2)`, a pre-1.0 development build, so config format and CLI flags can still move.
- β³MCP support covers stdio servers only; HTTP/SSE MCP entries are recognized in config but skipped rather than connected.
- β³Smooth, partial-line scrollback needs the author's separate terminal project, Handterm, which the README calls a work in progress β normal terminals get regular scrollback instead.
- β³Install paths beyond the curl/PowerShell one-liners β Homebrew, source builds β are only linked from the README, not documented in the material reviewed here.
Alternatives to jcode
Frequently Asked Questions
jcode is released under the MIT license, per its GitHub repository.
jcode is written in Rust, which the README credits for its low RAM use and fast startup times.
jcode supports both: `jcode login --provider ollama` or `jcode login --provider lmstudio` connect to their local OpenAI-compatible endpoints, using streaming chat completions and tool calling.
To connect jcode to any OpenAI-compatible endpoint, users have two options: either using the `jcode login --provider openai-compatible` command, or employing the scriptable `jcode provider add` command. This functionality extends to self-hosted vLLM servers, for which no API key is required.
jcode embeds every turn as a semantic vector and queries a memory graph by cosine similarity to recall related entries; a background 'sideagent' extracts and consolidates memories on a schedule instead of the agent calling memory tools directly.
Swarm lets you spawn multiple jcode agents in the same repo; the server notifies an agent when another has edited a file it read, and agents can DM, broadcast, or auto-spawn their own sub-swarms of worker agents.
Best use cases
- β’Running a coordinator agent plus several worker agents at once without RAM climbing linearly per session.
- β’Multi-agent work in a shared repo through Swarm, where conflicting edits get flagged instead of overwritten.
- β’Working against self-hosted or local models β vLLM, Ollama, LM Studio β through the same CLI instead of separate tooling per backend.
- β’Long sessions where you want context recalled automatically from the memory graph instead of re-pasting it.
Who should try it β and who should skip
Reach for jcode if you keep several agent sessions open at once and terminal is already home base β the PSS table in the README makes that case with real numbers. Skip it if you want a GUI or IDE plugin, or if your MCP setup depends on HTTP/SSE servers, since jcode only connects to stdio ones today.