1jehuang/jcode

jcode The most RAM efficient harness The most intelligent harness Website · Docs · SDK · Benchmarks · Features · Install · Quick Start · Further Reading · Contributing Installation # 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 . Updating Run /update in the TUI to download the latest stable release in the background and reload with your session preserved. From a terminal, use jcode update , then restart the client. Both commands use the same update policy, including for dev builds. Older or equal release versions are skipped. For a development build, Jcode also compares the running binary's Git commit with the release tag. Builds ahead of, identical to, or diverged from the release are preserved. If ancestry cannot be verified locally or through GitHub, the update stops rather than risking a downgrade. The displayed dev patch includes a commit-count offset, so it is not used as a release version comparison. This is the default features.update_channel = "stable" behavior. An explicit "main" channel still opts into source-branch updates. Use /rebuild or the self-dev build workflow to rebuild your own checkout. Performance & Resource Efficiency 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. RAM comparison 1 active session Tool PSS Comparison jcode (local embedding off) 27.8 MB baseline jcode 167.1 MB 6.0× more RAM pi 144.4 MB 5.2× more RAM Codex CLI 140.0 MB 5.0× more RAM OpenCode 371.5 MB 13.4× more RAM GitHub Copilot CLI 333.3 MB 12.0× more RAM Cursor Agent 214.9 MB 7.7× more RAM Claude Code 386.6 MB 13.9× more RAM Antigravity CLI 243.7 MB 8.8× more RAM 10 active sessions Tool PSS Comparison jcode (local embedding off) 117.0 MB baseline jcode 260.8 MB 2.2× more RAM pi 833.0 MB 7.1× more RAM Codex CLI 334.8 MB 2.9× more RAM OpenCode 3237.2 MB 27.7× more RAM GitHub Copilot CLI 1756.5 MB 15.0× more RAM Cursor Agent 1632.4 MB 14.0× more RAM Claude Code 2300.6 MB 19.7× more RAM Antigravity CLI 1021.2 MB 8.7× more RAM Headless sessions (swarm workers) Swarm workers run headless, so this is the number that matters when you fan out agents. Each session completed 5 real model turns (file listing, file read, repo search, summary, reply) with tool calls, then total PSS of every process was measured. jcode sessions share one daemon; Claude Code runs one claude -p --input-format stream-json process per session. Both used claude-sonnet-4-6 . Concurrent headless sessions jcode Claude Code Comparison 1 32.6 MB 261.0 MB 8.0× less RAM 5 51.0 MB 908.6 MB 17.8× less RAM 10 66.7 MB 1749.7 MB 26.2× less RAM 20 90.6 MB 3376.8 MB 37.3× less RAM Each additional session ~3.1 MB ~164 MB ~54× less RAM Measured 2026-09-29 on Linux with jcode v0.89.19-dev (default build, local embeddings not compiled in) and Claude Code 2.1.267 . Reproduce with python3 scripts/bench_headless_memory.py . Time to first frame 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 to first input (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. Additional clients / memory scaling 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.0 codex-cli 0.120.0 opencode 1.0.203 GitHub Copilot CLI 1.0.24 for the 1-session rerun, GitHub Copilot CLI 1.0.27 for the 10-session rerun Cursor Agent 2026.04.08-a41fba1 Claude Code 2.1.86 (Claude Code) Antigravity CLI 1.0.0 jcode performance demonstration Memory (Agent memory) 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 retrieval 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 UI: Side panels, Diagrams, Info Widgets, rendering, scrolling, alignment The panel tool opens a new desktop panel from Markdown content or a linked Markdown/PDF file, and supports update, focus, close, and list actions. See Desktop panels for the API, PDF limits, and compatibility details. 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.