Browse by type
The next generation coding agent harness to raise the skill ceiling.
Built for multi-session workflows, infinite customizability, and performance.
Website · Features · Install · Quick Start · Further Reading · Contributing
# macOS & Linux
curl -fsSL https://jcode.sh/install | bash
# Windows 11 (PowerShell 5.1+)
irm https://jcode.sh/install.ps1 | iex
Need Homebrew, source builds, provider setup, or want an agent to set it up for you? Jump to detailed installation.
jcode is built to be as performant and resource efficient as possible. Every metric is optimized to the bone, which is important for scaling multi-session workflows. Here we sample a few metrics to show the difference: RAM usage and boot up.
1 active session
|
10 active sessions
|
| Tool | Time to first frame | Range | Comparison |
|---|---|---|---|
| jcode | 14.0 ms | 10.1–19.3 ms | baseline |
| Antigravity CLI | 383.5 ms | 363.1–415.4 ms | 27.4× slower |
| pi | 590.7 ms | 369.6–934.8 ms | 42.2× slower |
| Codex CLI | 882.8 ms | 742.3–1640.9 ms | 63.1× slower |
| OpenCode | 1035.9 ms | 922.5–1104.4 ms | 74.0× slower |
| GitHub Copilot CLI | 1518.6 ms | 1357.4–1826.8 ms | 108.5× slower |
| Cursor Agent | 1949.7 ms | 1711.0–2104.8 ms | 139.3× slower |
| Claude Code | 3436.9 ms | 2032.7–8927.2 ms | 245.5× slower |
Measured on this Linux machine across 10 interactive PTY launches.
(time until typed probe text appears on the rendered screen; Antigravity uses its internal input-ready log marker because the sign-in screen suppresses probe echo.)
| Tool | Time to first input | Range | Comparison |
|---|---|---|---|
| jcode | 48.7 ms | 30.3–62.7 ms | baseline |
| Antigravity CLI | 383.7 ms | 363.4–415.7 ms | 7.9× slower |
| pi | 596.4 ms | 373.9–955.2 ms | 12.2× slower |
| Codex CLI | 905.8 ms | 760.1–1675.7 ms | 18.6× slower |
| OpenCode | 1047.9 ms | 931.1–1116.9 ms | 21.5× slower |
| GitHub Copilot CLI | 1583.4 ms | 1422.8–1880.0 ms | 32.5× slower |
| Cursor Agent | 1978.7 ms | 1727.3–2130.0 ms | 40.6× slower |
| Claude Code | 3512.8 ms | 2137.4–9002.0 ms | 72.2× slower |
Measured on this Linux machine across 10 interactive PTY launches. Antigravity CLI was unauthenticated for this run; its sign-in screen rendered normally and emitted an internal CLI ready for user input marker, but did not echo the typed probe.
| Tool | Extra PSS per added session | Comparison |
|---|---|---|
| jcode (local embedding off) | ~9.9 MB | baseline |
| jcode | ~10.4 MB | 1.1× more RAM |
| pi | ~76.5 MB | 7.7× more RAM |
| Codex CLI | ~21.6 MB | 2.2× more RAM |
| OpenCode | ~318.4 MB | 32.2× more RAM |
| GitHub Copilot CLI | ~158.1 MB | 16.0× more RAM |
| Cursor Agent | ~157.5 MB | 15.9× more RAM |
| Claude Code | ~212.7 MB | 21.5× more RAM |
| Antigravity CLI | ~86.4 MB | 8.7× more RAM |
versions tested for this corrected memory rerun:
jcode v0.9.1888-dev (be386f2)pi 0.62.0codex-cli 0.120.0opencode 1.0.203GitHub Copilot CLI 1.0.24 for the 1-session rerun, GitHub Copilot CLI 1.0.27 for the 10-session rerunCursor Agent 2026.04.08-a41fba1Claude Code 2.1.86 (Claude Code)Antigravity CLI 1.0.0jcode performance demonstration
Jcode embeds each turn/response as a semantic vector. Every turn does queries a graph of memories to efficiently find related memory entries via a cosine similarity check. The embedding hits are fed into the conversation, or optionally uses a memory sideagent which verifies the memories are relevant, and potentially does more work for information retreival before injecting into the conversation. This results in a human like memory system which allows the agent to automatically recall relevant information to the conversation without actively calling memory tools or being a token burner. ot To have memories which are retrieved, they must also be extracted and stored. Every so often (semantic drift, K turns since last extraction, session end, etc), memories are extracted via a memory sideagent, and put into the memory graph.
The harness also provides explicit memory tools to allow the agent to actively search or store the memory without relying on a passive background process. The harness also provides session search for traditional RAG on previous sessions.
Memories are automatically consolidated every so often via the ambient mode. This reorganizes, checks for staleness and conflicts, etc
jcode memory demonstration
The side panel is a place for auxiliary information. Tell your jcode agent to load a file into the side panel and see it update in real time, or tell your agent to write directly to the side panel, or use it as a diff viewer. The side panel (and chat) is able to render mermaid diagrams inline.
To make this possible, I created a new mermaid rendering library to render diagrams 1800x faster. It has no browser or Typescript dependency. See https://github.com/1jehuang/mermaid-rs-renderer
To show you important information without taking space away from the screen that could be used for responses, I developed info widgets. Info widgets will only ever take up the negative space on the screen to show you information, and will get out of the way if there isn't any.
Jcode can render at over a thousand fps. Your monitor will not have the refresh rate to show you, but this means you will not have silly flicker problems.
The custom scrollback implementation of jcode allows it to do much more than a native scrollback. However, it is a terminal-level limitation that I cannot have smooth, partial line scrolling with a custom scrollback. To fix this, I made my own terminal. Handterm https://github.com/1jehuang/handterm implements a native scroll api, and also happens to be very effiecent. This is a work in progress. Scrolling is still well implemented for normal terminals.
Jcode is left-aligned by default. You can switch to centered mode with the Alt+C hotkey, with the /alignment command, or in the config.
Spawn two or more agents in the same repo, and they will automatically be managed by the server to allow native collaboration. When agent A edits a file that agent B has read (code shifting under its feet), the server notifies agent B. Agent B can ignore it if it is not relevant, or it can check the diff to make sure that it doesn't conflict. Each agent has messaging abilities, capable of DMing just one agent, broadcasting to all other agents hosted by the server, or just agents working in that repo. This allows you to spawn multiple sessions in the same repo, and have all conflicts automatically resolved.
<img src="https://github.com/1jehuang/jcode/releases/download/readme-assets/jcode-swarm-demo
browse all types & interfaces →
$ claude mcp add jcode \
-- python -m otcore.mcp_server <graph>