jcode：共有デーモンで 20 並列のコーディングエージェントを 91 MB に収める

概要：メモリ使用量を第一の指標に据えたコーディングエージェント基盤

jcode（1jehuang/jcode）は Rust で書かれたターミナル向けコーディングエージェントのハーネスです。MIT ライセンスで、Linux、macOS、Windows に対応します。自己紹介は二行だけです。最も RAM 効率が高く、最も賢いハーネス。Claude Code、Codex CLI、OpenCode、GitHub Copilot CLI、Cursor Agent、pi、Antigravity CLI と同じ分野に属しますが、賭け方が違います。多くのツールはプロンプトやツール連携に力を入れます。jcode はまず実行基盤そのものを極限まで軽くし、その上に記憶グラフ、マルチエージェント協調（swarm）、高速なターミナル描画を載せています。

導入は一行です。macOS と Linux は `curl -fsSL https://jcode.sh/install | bash`、Windows 11 は PowerShell で `irm https://jcode.sh/install.ps1 | iex` を実行します。TUI 内で `/update`、またはシェルで `jcode update` を実行すると、最新の安定版をバックグラウンドで取得し、セッションを保ったまま再読み込みします。README にはダウングレード防止の方針も書かれています。古い版や同じ版はスキップし、開発ビルドは手元のバイナリの Git コミットをリリースタグと比べ、系統を確認できないときは更新を止めます。既定は `features.update_channel = "stable"` で、`"main"` を明示したときだけソースブランチに追従します。

中核の設計：共有デーモン一つに軽いクライアント多数

最も重要な設計は、複数のセッションが一つのデーモンを共有する点です。README のヘッドレス計測の説明は明快です。jcode のセッションは一つのデーモンを共有し、Claude Code はセッションごとに `claude -p --input-format stream-json` のプロセスを起動します。プロセスモデルの違いが、メモリ曲線の傾きを決めます。

作者のヘッドレスベンチマークは次の方法です。各セッションが、ファイル一覧、ファイル読み取り、リポジトリ検索、要約、返信という五回の実モデル呼び出しを行い、すべてのプロセスの PSS 合計を測ります。両者とも claude-sonnet-4-6 を使用しました。結果は次のとおりです。1 セッションで jcode は 32.6 MB、Claude Code は 261.0 MB（8.0 倍）。5 セッションで 51.0 MB 対 908.6 MB（17.8 倍）。10 セッションで 66.7 MB 対 1749.7 MB（26.2 倍）。20 セッションで 90.6 MB 対 3376.8 MB（37.3 倍）。セッションを一つ増やすごとに、jcode は約 3.1 MB、Claude Code は約 164 MB で、約 54 倍の差です。測定日は 2026-09-29、jcode v0.89.19-dev（既定ビルド、ローカル埋め込みは非搭載）と Claude Code 2.1.267 を使い、`python3 scripts/bench_headless_memory.py` で再現できます。

大事なのは個々の値より傾きです。エージェントを大量に起動する作業者として扱い、たとえば 20 並列にすると、Claude Code 方式は約 3.4 GB、jcode 方式は約 91 MB です。並列度の制約はメモリではなく、モデルの利用枠と API 費用に移ります。

対話時の性能：最初のフレームまで 14 ミリ秒

README はメモリのほかに起動遅延も測っています。対話式 PTY 起動を 10 回行った結果です。最初のフレームまでの時間は、jcode が 14.0 ms（範囲 10.1 から 19.3 ms）、Antigravity CLI が 383.5 ms、pi が 590.7 ms、Codex CLI が 882.8 ms、OpenCode が 1035.9 ms、GitHub Copilot CLI が 1518.6 ms、Cursor Agent が 1949.7 ms、Claude Code が 3436.9 ms（範囲 2032.7 から 8927.2 ms）で、jcode の約 245.5 倍です。最初に入力できるまでの時間は、jcode が 48.7 ms、Claude Code が 3512.8 ms で、約 72.2 倍です。

対話式のメモリ表はより複雑で、より誠実です。1 セッションでは、ローカル埋め込みをオフにした jcode が 27.8 MB、オンにした jcode が 167.1 MB で、pi は 144.4 MB、Codex CLI は 140.0 MB、Claude Code は 386.6 MB です。つまりローカルの意味埋め込みを有効にすると、単一セッションの jcode は pi や Codex より小さくありません。優位はスケールしたときに現れます。10 セッションでは jcode が 260.8 MB（埋め込みオフで 117.0 MB）、Codex CLI が 334.8 MB、pi が 833.0 MB、Claude Code が 2300.6 MB、OpenCode が 3237.2 MB です。セッション追加あたりの PSS は、jcode が約 10.4 MB、Codex CLI が約 21.6 MB、pi が約 76.5 MB、Claude Code が約 212.7 MB、OpenCode が約 318.4 MB です。

記憶システム：埋め込みと記憶グラフ

jcode が「賢い」とされる主な理由はエージェントの記憶です。README によると、各ターンの入力と応答は意味ベクトルとして埋め込まれ、毎ターン、記憶のグラフに対してコサイン類似度で関連項目を探します。ヒットした記憶は会話に注入されるか、記憶サイドエージェントが関連性を確認してから渡されます。

書き込みも非同期です。意味のずれが生じたとき、前回の抽出から K ターン経ったとき、セッション終了時などに、サイドエージェントが記憶を抽出してグラフに保存します。さらに明示的な記憶ツールがあり、エージェントは受け身の背景処理に頼らず、能動的に検索と保存ができます。過去セッションに対する通常の RAG であるセッション検索もあります。最後に、アンビエントモードが定期的に記憶を整理し、再編、陳腐化の確認、矛盾の検査を行います。受動的な想起、能動的な読み書き、背景での整理という三つの経路を分けた設計です。

Swarm：サーバーが状況を把握する協調

同じリポジトリで二つ以上のエージェントを起動すると、サーバーが自動で管理し、協調が成立します。鍵は衝突の検知です。エージェント A が、エージェント B の読んだファイルを編集した場合、つまり B の足元でコードが変わった場合、サーバーが B に通知します。B は無関係なら無視でき、必要なら読み直せます。エージェントは swarm ツールで自らチームメイトを生成することもでき、その場合、主エージェントは調整役、生成されたエージェントは作業者になります。

設定面では、ルートの推論強度と作業者の強度が分かれています。`~/.jcode/config.toml` の `[agents]` にある `swarm_root_effort`（`/effort swarm`）と `swarm_deep_root_effort`（`/effort swarm-deep`）は、どちらも既定が `max` です。指定できる水準は none、minimal、low、medium、high、xhigh、max で、各プロバイダーの対応範囲に写像されます。環境変数は `JCODE_SWARM_ROOT_EFFORT` と `JCODE_SWARM_DEEP_ROOT_EFFORT` です。これらは作業者の `swarm_effort` を変えません。タスクのコストに応じて、ルートは浅く作業者は深く、あるいはその逆に調整できます。

プロバイダーとエコシステム：サブスクリプションログインと OpenAI 互換

jcode はサブスクリプション型の OAuth ログインに対応し、すでに支払っているモデル枠を使い回せます。必要なら直接 API に切り替えられます。組み込みログインは、Claude、OpenAI/ChatGPT/Codex、Google Gemini、GitHub Copilot、Azure OpenAI、Alibaba Cloud Coding Plan、Fireworks、Novita AI、MiniMax、Meta Model API、LM Studio、Ollama、独自の OpenAI 互換エンドポイントです。組み込みの OpenAI 互換プロファイルには openrouter、deepseek、zai、kimi、moonshotai、opencode などがあります。ネイティブの OpenAI プロバイダーは Responses WebSocket v2 を使い、背景での事前接続と HTTPS へのフォールバックを備えます。

スクリプトやエージェント向けの `jcode provider add` は、プロファイルを一度で書き込みます。`--api-key-stdin`（鍵をシェル履歴に残さない）、`--api-key-env`、`--context-window`、`--no-api-key`（vLLM や Ollama などローカルサーバー用）に対応します。`extra_body` と環境変数 `JCODE_OPENAI_EXTRA_BODY` で、非標準のトップレベル項目をリクエストに注入できます。README の例は NVIDIA NIM 上の DeepSeek-V4 で、`chat_template_kwargs` がないと思考が有効になりません。Anthropic Messages 互換ゲートウェイは `type = "anthropic-compatible"` のプロファイルで扱え、Bearer、独自ヘッダー、認証なしを選べます。ストリームの無通信タイムアウトは既定 180 秒で、推論強度に応じて伸びます（high で 2 倍、xhigh で 3 倍、max で 4 倍）。

MCP では、`~/.jcode/mcp.json` とプロジェクト内の `.jcode/mcp.json` を読みます。Claude Code の `~/.claude.json` とリポジトリ直下の `.mcp.json` も、読み込みのたびに直接参照し、古い複製を残しません。現時点では stdio サーバーのみ対応で、HTTP と SSE は認識したうえでスキップされます。各リクエストの既定タイムアウトは 30 秒で、`timeout_secs` で調整できます。Codex CLI から移行する場合、`~/.codex/config.toml` が一度だけ取り込まれ、取り込まれた環境変数に秘密情報が含まれることがあります。

UI の工学：速度のための自作部品

作者はブラウザにも TypeScript にも依存しない mermaid 描画ライブラリ（mermaid-rs-renderer）を自作し、図の描画が 1800 倍速いと主張しています。これにより、サイドパネルやチャットにフローチャートをそのまま描けます。`panel` ツールは Markdown や PDF からデスクトップパネルを開きます。

情報ウィジェットは画面の空き領域だけを使い、空きがなければ退きます。jcode は毎秒 1000 フレーム超で描画でき、ちらつきを避けられるとしています。独自のスクロールバックは多くのことを可能にしますが、端末側の制約で行の途中までなめらかにスクロールすることはできません。そのため作者は専用の端末 Handterm も作りました。

影響、限界、所見

開発者にとっての価値は、並列エージェントの限界費用をほぼゼロに近づけることです。ノート PC で数十のセッションを動かしても、メモリは問題になりません。企業にとっては、OAuth サブスクリプションの再利用、Anthropic 互換と OpenAI 互換のゲートウェイ、独自ヘッダー、自社運用の vLLM への対応により、社内ゲートウェイに接続しやすくなります。

注意すべき点があります。第一に、すべてのベンチマークは作者が自分の Linux 機で行ったもので、第三者による再現は示されていません。表ごとに版も異なり、ヘッドレス試験は jcode v0.89.19-dev と Claude Code 2.1.267、対話式のメモリ再測定は jcode v0.9.1888-dev と Claude Code 2.1.86 です。比較するときは各表の条件を確認してください。第二に、PSS が測るのはメモリであり、タスクの質ではありません。「最も賢い」は自己申告で、README の数値は競合より問題解決が優れる証拠にはなりません。第三に、ローカル埋め込みを有効にした単一セッションのメモリは最小ではなく、優位性は共有デーモンと埋め込みオフの構成に依存します。第四に、HTTP/SSE の MCP は未対応で、Windows と macOS の個別の数値は示されていません。第五に、共有デーモンは障害の影響範囲を集中させます。デーモンが落ちれば全セッションに影響しうるのに、README はこの点に触れていません。

総じて、jcode は価値のある方向を示しています。まずエージェント基盤を本当に軽い基礎設備にし、そのうえで記憶と協調を語るという順序です。大規模な並列コーディングエージェント、CI での一括レビュー、低スペックの開発機で作業する場合は、`scripts/bench_headless_memory.py` を自分の環境で実行して数値を確かめる価値があります。