jcode: A coding agent harness that treats resource efficiency as a feature

The most revealing number in the jcode README is not the 14 millisecond boot time. It is the 27.8 MB baseline RAM figure for a single active session with local embeddings turned off. That is less than one-tenth of what Claude Code consumes in the same test. It is less than one-fifteenth of Cursor Agent. It is less than one-thirteenth of OpenCode.

The gap is not a matter of optimization polish. It is a design philosophy collision.

jcode is a new open-source coding agent harness built by a single developer, 1jehuang. It supports multi-session workflows, memory graphs, swarm collaboration, and a dozen provider integrations. On paper, it competes with Claude Code, Codex CLI, Cursor Agent, and the rest of the field. On resource benchmarks, it does not compete. It dominates.

The developer ran controlled tests on a Linux machine across 10 interactive PTY launches. The results are stark. jcode’s time to first frame is 14.0 ms, with a range of 10.1 to 19.3 ms. The next closest tool, Antigravity CLI, takes 383.5 ms — 27 times slower. Claude Code takes 3,436.9 ms, or 245 times slower. The gap in time to first input is similar: jcode at 48.7 ms versus Claude Code at 3,512.8 ms.

Memory scaling tells the same story. Each additional jcode session adds roughly 10.4 MB of PSS. Each additional Claude Code session adds 212.7 MB. Each additional OpenCode session adds 318.4 MB. At 10 concurrent sessions, jcode uses 260.8 MB total. OpenCode uses 3,237.2 MB. GitHub Copilot CLI uses 1,756.5 MB.

These numbers matter because they expose an implicit assumption baked into every major coding agent product: that developers will tolerate heavyweight clients. The assumption has gone largely unchallenged because the market has been supply-constrained. Anthropic, OpenAI, Cursor, and GitHub all compete on capability — model quality, tool-use breadth, context window size — and treat the client as a thin wrapper around a cloud API. jcode treats the client as the product.

The harness is built in Rust and ships as a single binary. It uses a custom terminal, Handterm, to implement a native scroll API and avoid the flicker and alignment issues that plague terminal-based agents. It includes a Mermaid rendering library written from scratch in Rust, which the developer claims renders diagrams 1,800 times faster than the standard JavaScript implementation. The entire stack is designed to minimize overhead at every layer.

Memory management is where jcode diverges most sharply from its competitors. The harness embeds each turn or response as a semantic vector, then queries a graph of related memories via cosine similarity. Memories are extracted and stored automatically based on semantic drift, turn count, or session end. A memory sideagent verifies relevance before injecting context into the conversation. The system also includes explicit memory tools for manual search and storage, and an ambient mode that consolidates, reorganizes, and checks for staleness.

This is a fundamentally different approach from the dominant pattern in coding agents. Most tools rely on large context windows and raw token dumps. Claude Code, for example, loads the entire conversation history into context on every turn. That works when the context window is 200,000 tokens. It does not scale to multi-session workflows with dozens or hundreds of interactions. jcode’s memory graph is designed for exactly that scenario: persistent, searchable, and cheap.

The swarm feature extends the same logic to multi-agent collaboration. A jcode server can host multiple agents working in the same repository. When one agent edits a file that another agent has open, the server notifies the second agent automatically. Agents can message each other directly, broadcast to the group, or spawn sub-agents autonomously. The main agent becomes a coordinator, delegating tasks to worker agents that can run headlessly.

This is not a toy feature. The ability to run multiple agents in parallel on the same codebase, with automatic conflict detection and resolution, is a capability that no major coding agent product offers today. Cursor and Codex CLI are single-session tools. Claude Code supports some multi-turn workflows but not true parallel agent collaboration. jcode’s swarm is closer to a lightweight orchestration layer than a chat interface.

The provider integration list is comprehensive. jcode supports login flows for Claude, OpenAI, Google Gemini, GitHub Copilot, Azure OpenAI, Alibaba Cloud, Fireworks, MiniMax, LM Studio, and Ollama. It also supports any OpenAI-compatible endpoint through a configurable profile system. The developer has pre-built profiles for OpenRouter, DeepSeek, Moonshot AI, Hugging Face, Nebius, and others. Users can add custom endpoints with a single command, including local vLLM instances that require no API key.

The OAuth flows are subscription-backed, meaning users can bring their existing Claude Pro, ChatGPT Plus, or GitHub Copilot subscriptions and use jcode as a drop-in client. This is a significant practical advantage. Most coding agents require users to provision API keys directly, which adds friction and cost. jcode piggybacks on existing subscriptions.

The project is not without rough edges. The developer acknowledges that Handterm is a work in progress. The scrollback implementation in standard terminals is limited to full-line scrolling, and smooth partial-line scrolling requires the custom terminal. The memory graph system is complex and may be opaque to new users. The documentation, while detailed, assumes a high level of technical comfort.

But the core thesis is sound. The coding agent market has converged on a set of design patterns — large context windows, heavy JavaScript or Python clients, single-session workflows — that are not inevitable. They are choices. jcode demonstrates that an alternative set of choices is possible: Rust over Electron, memory graphs over raw context, multi-session over single-session, sub-50 ms boot times over multi-second startups.

The question the industry should ask is not whether jcode is production-ready today. It is whether the major players will treat resource efficiency as a competitive feature or continue to treat it as irrelevant. The numbers in the jcode README suggest that the gap is not closing. It is widening.