live-memory

██╗     ██╗██╗   ██╗███████╗
██║     ██║██║   ██║██╔════╝
██║     ██║██║   ██║█████╗
██║     ██║╚██╗ ██╔╝██╔══╝
███████╗██║ ╚████╔╝ ███████╗
╚══════╝╚═╝  ╚═══╝  ╚══════╝
███╗   ███╗███████╗███╗   ███╗ ██████╗ ██████╗ ██╗   ██╗
████╗ ████║██╔════╝████╗ ████║██╔═══██╗██╔══██╗╚██╗ ██╔╝
██╔████╔██║█████╗  ██╔████╔██║██║   ██║██████╔╝ ╚████╔╝
██║╚██╔╝██║██╔══╝  ██║╚██╔╝██║██║   ██║██╔══██╗  ╚██╔╝
██║ ╚═╝ ██║███████╗██║ ╚═╝ ██║╚██████╔╝██║  ██║   ██║
╚═╝     ╚═╝╚══════╝╚═╝     ╚═╝ ╚═════╝ ╚═╝  ╚═╝   ╚═╝
        always-up-to-date codebase memory for Claude Code · ask, don't re-read

Live Memory — Claude Code プラグイン

リポジトリを学習する、安価で常時稼働のモデル。エージェントが同じ内容を読み直す必要はなくなります。 Live Memory は、コードベースに関する知識をセッションをまたいで蓄積する、長期稼働型の MCP サーバーとして、別個の安価な大規模コンテキストモデルを実行します。毎回のセッションで同じファイルを読み直す代わりに、エージェントは 1 つの読み取り専用ツール ask_live_memory に、広い視点での理解が必要な質問――「X はどこにあるか、Y はどのように動作するか、Z を呼び出しているのは何か」――を尋ねます。Live Memory は、メインのエージェントが有意義な作業（編集など）を始められるようにする形で回答します。エージェント自身が読み取った内容や編集内容から受動的に学習し（フック経由で渡されるため、追加の読み取りは不要です）、リポジトリの変更（修正や削除）に応じて最新の状態を保ちます。読み取り専用かつパス制限されているため、編集、作成、実行は一切できません。Claude のサブスクリプション（Haiku、API キー不要）で設定不要です。メモリモデルは差し替え可能で、ローカルモデルや OpenAI 互換エンドポイントを指定できます。

仕組み

flowchart LR
  repo[("Your repo")]
  subgraph sessions["Claude Code sessions — premium model (many, over time)"]
    agent["Agent"]
  end
  agent -->|"reads / edits files"| repo
  agent -. "PostToolUse / FileChanged hooks<br/>tee file content — passive learning (free)" .-> lm
  agent ==>|"ask_live_memory(question, cwd)<br/>one read-only MCP tool"| lm
  lm ==>|"grounded answer — no file re-reading"| agent
  subgraph server["Live Memory — one MCP server per workspace (singleton)"]
    lm["Cheap / local large-context model<br/>+ accumulating context window<br/>append-only · neutral compaction to a ledger"]
    lm --> snap[("Local JSON snapshot<br/>persists across sessions")]
  end

エージェントは通常どおりファイルを読み取ったり編集したりします。フックはその内容をさりげなくサーバーに渡すため、追加コストなしで学習できます。エージェントが何かを理解する必要がある場合、ファイルを読み直す代わりに ask_live_memory に質問します。サーバーは、ワークスペースごとに蓄積したメモリから回答します（まだ見たことのない内容であれば、読み取り専用でコードを読み取ります）。1 つのサーバーですべてのセッションに対応し、セッションをまたいで動作します。

ベンチマーク

実際のリポジトリでの A/B テスト。タスクを完了するまで実行した場合のタスクあたりのコストです。コストは 3 通りで示します。プレミアム（構築）モデルの請求額――コンパニオンは安価なモデルまたはローカルモデルで動作するため、高価なモデルが使用する金額――と、コンパニオン自体のコストも含めた総額（DeepSeek-v4-flash または Haiku を使用）です。

タスクあたり	プレミアムモデルの請求額	総額 · DeepSeek-flash†	総額 · Haiku	高速化
理解中心（追跡／把握）	−61%	−57%	−25%	約22%
ハイブリッド（理解してから編集：バグ修正＋機能追加）	−28%	−26%	−11%	約11%
編集／実行のみ	約損益分岐	約損益分岐	約損益分岐	約0

理解中心の作業では、プレミアムモデルがコードベースを読むトークンの約93%も肩代わりし（コストのばらつきも低減）、ハイブリッドタスクでは正確性が一度も低下しませんでした（使用時も未使用時も12/12で合格）。DeepSeek-v4-flash は Haiku と同等の回答精度（3 回の試行で 98% 対 91%）を、トークン単価約 8 分の 1 で実現しました。ローカルのコンパニオンならほぼ無料のため、総額はプレミアムモデルの請求額とほぼ同じです。完全に再現可能で、監査済みです（人間＋Fable）。詳細な数値と方法論については、benchmark/results/RESULTS.md をご覧ください。

_{† コンパニオンを DeepSeek-v4-flash の料金で再計算（Haiku の約 8 分の 1）。理解中心のケースでは実測値、ハイブリッドのケースでは実測コスト比から算出しています。}

開発の経緯： Live Memory は、もともと**shofer.dev（Arkware の並列マルチエージェント型コーディングプラットフォーム）の機能として始まりました。そこではセッション間で同期されたコードベースのメモリを共有します。これは、そのアイデアを単独で動作する Claude Code プラグイン**として実現したものです。新たに実装され、自己完結しており、shofer への依存はありません。slang-workflows とともに、shofer Claude Code プラグインファミリーの一部です。設計については DESIGN.md、Copilot／Cursor との比較については COMPARISON.md、テストについては TESTING.md、プライバシーについては PRIVACY.md をご覧ください。

クイックスタート

live-memory は、一度起動する HTTP MCP サーバー（すべての Claude Code セッションに対応するシングルトン）と、 ask_live_memory、フック、スラッシュコマンドを登録するプラグインで構成されています。まずサーバーを起動してください。 Claude Code はサーバーに接続するだけ（サーバーを起動することはありません）なので、サーバーが起動していないと接続エラーが発生します。

1 — サーバーを起動（Claude のサブスクリプションがあれば設定不要で Haiku を利用できます。API キーは不要です）：

git clone https://github.com/shofer-dev/claude-code-live-memory
cd claude-code-live-memory/deploy && ./install-service.sh   # venv + user systemd service, auto-starts on boot
# …or just run it in a terminal:
#   cd claude-code-live-memory/server && pip install -e . && python -m live_memory

2 — プラグインをインストール（Claude Code セッション内で実行）：

/plugin marketplace add shofer-dev/claude-code-live-memory
/plugin install live-memory@shofer-live-memory

エージェントにリポジトリ全体について質問してみてください。ファイルを読む代わりに ask_live_memory を呼び出します。 /live-memory-stats では蓄積されたナレッジとコストを確認できます。/live-memory-config ではモデル／プロバイダーを切り替えられます。/live-memory-empty ではメモリを消去できます。/live-memory-reset では、設定済みのプリロードドキュメントを再読み込みしてワークスペースを初期化できます。プロバイダー、systemd、ワークスペース、並行処理については、以下で詳しく説明します。

構成

live-memory/
├── .claude-plugin/plugin.json     # plugin manifest
├── .mcp.json                      # registers the server (type:http, explicit timeout)
├── hooks/                         # PostToolUse(Read|Write|Edit|…) + FileChanged → TEE file content (passive learning)
│   ├── hooks.json
│   └── notify.py
├── skills/live-memory/SKILL.md    # tells the agent when/why to call ask_live_memory
├── commands/                      # USER-facing slash commands (not agent tools)
│   ├── live-memory-stats.md       # /live-memory-stats  → GET /stats
│   ├── live-memory-config.md      # /live-memory-config → set model/provider, hot-reload
│   ├── live-memory-empty.md       # /live-memory-empty  → wipe memory (this workspace or `all`)
│   ├── live-memory-reset.md       # /live-memory-reset  → drop history + re-preload configured docs
│   ├── stats.py · config.py · empty.py · reset.py
├── settings.json
├── deploy/                        # systemd unit + env example + install-service.sh
└── server/                        # the long-running MCP server (Python, asyncio)
    ├── pyproject.toml             # deps + mypy(strict) + pytest config
    ├── tests/                     # pytest unit suite (mocked; no network)
    └── live_memory/
        ├── __main__.py            # entrypoint: python -m live_memory
        ├── server.py              # MCP (HTTP) ask_live_memory + /health + /stats + /notify + /clear + /reset + /reload
        ├── workspace.py           # per-cwd state registry (window + queue + store); fork/commit
        ├── manager.py             # the agent loop (process one question); compaction
        ├── context_window.py      # budget; file-context evict, Q&A summarize; fork/clone
        ├── summarizer.py          # NEUTRAL, query-agnostic knowledge-ledger summarization
        ├── question_queue.py      # per-workspace admission (serial/parallel) + per-entry timeout
        ├── async_jobs.py          # opt-in fire-and-forget job registry (submit/poll)
        ├── keep_warm.py           # background KV/prompt-cache keep-warm loop
        ├── conversation_store.py  # versioned JSON snapshot (SHA-256 file validation)
        ├── llm_client.py          # provider-pluggable: Anthropic Messages | OpenAI-compatible
        ├── oauth.py               # subscription OAuth credential + auto-refresh (zero-config)
        ├── config.py              # layered config (env > config.json > defaults) + provider knowledge
        ├── constants.py           # ALL tunable magic numbers + defaults, centralized (config sources its defaults here)
        ├── models.py              # core dataclasses (ChatMessage, FileContext, QuestionResult, …)
        ├── tool_executor.py       # read-only tools (Read/Grep/Glob/find_paths/git/…), path-jailed
        ├── preload.py             # configured preload globs → verbatim docs on workspace load
        ├── directory_tree.py      # workspace scan, ~10% context cap
        ├── pricing.py             # per-model USD cost (+ env overrides)
        ├── logging_setup.py       # stderr→journald + optional rotating file
        └── prompts.py             # system prompt + neutral-summary prompt

アーキテクチャ（設計の詳細な根拠については DESIGN.md を参照してください）

• 外部から監視される、冪等な HTTP MCP サーバー（シングルトン）が、すべての Claude Code セッションに対応します。状態はワークスペースごとに（cwd をキーとして）管理されます。
• モデルは独立しており、プロバイダーを切り替え可能：サーバーはセッションのモデルではなく、独自の低コストモデルを実行します。ほぼすべてのケースに対応する 2 つのアダプターがあります。Anthropic Messages （cache_control を使用）と OpenAI 互換（DeepSeek/OpenAI/ゲートウェイ）です。 設定不要：Claude のサブスクリプションがあり、キーが設定されていない場合は、サブスクリプションの OAuth トークン（自動更新）を使用して Haiku を利用します。
• 受動的な（自然な）学習：PostToolUse/FileChanged フックが、エージェントが読み取り／編集したファイルの内容を メモリに渡すため、実際の作業を通じて追加費用なしで知識が蓄積されます。未知の情報については、 ask_live_memory が能動的なフォールバックになります。
• プリロード用 glob（任意）：preload_globs（例：docs/*.md）で、ワークスペースの 読み込み時にシステムプロンプトへそのまま読み込む参考ドキュメントを指定します。メモリは最初からその内容を認識します。 これらは観察内容として扱われるため、圧縮時には負荷に応じてナレッジ台帳へ要約されます。 /live-memory-reset を実行すると、ワークスペースの履歴を破棄し、ドキュメントを新たにプリロードします。
• 圧縮まで追記のみのウィンドウ。圧縮とは、ハイ／ローヲーターマークに基づくバッチ処理による中立的な要約 （まれにまとめて実施）です。観察したファイルと質疑応答を、クエリに依存しないナレッジ台帳へ集約します。 先頭から切り詰めることはありません。
• 固定された揮発性ブロックと観察差分（KV キャッシュの保持）：揮発性システムブロック（台帳、プリロード／観察した内容、マニフェスト）は 圧縮と圧縮の間は固定され、毎回バイト単位で同一の内容が再送されます。その間に届いた変更（渡されたファイルや古い情報の通知）は、 ブロックを変更せず、差分メッセージとして履歴に追加されます。これにより、最初に変更されたバイトで切り詰められることなく、 プロバイダーのプレフィックスキャッシュとの一致が保たれます。
• 2 段階のタイムアウト：ask_live_memory(question, cwd, max_answer_tokens?) は、 サーバーで設定されたソフト予算（default_timeout_s、既定値は 60 秒。ツール引数ではなくなりました）までブロックし、 ハードな .mcp.json の MCP タイムアウトより前に、最善努力による回答を返します。
• 開示された回答長の上限：回答にはハード上限（既定値は LIVE_MEMORY_MAX_ANSWER_TOKENS）が設定され、モデルにもその上限が伝えられます。そのため、文の途中で切り詰められるのではなく、 モデル自身が長さを調整します。任意の max_answer_tokens 引数を指定すると、質問ごとに上限を上書きできます。
• 人間向けステータスは /live-memory-stats スラッシュコマンド（→ /stats）で確認できます。エージェントのツール一覧には表示されません。

インストール

前提条件： Python ≥ 3.10；ripgrep（rg）を推奨（Grep を利用できます）；git は任意（git_search / get_changed_files を利用できます）。

1. サーバーをインストールします：

cd server
pip install -e .          # runtime deps (mcp, anthropic, starlette, uvicorn, watchdog, httpx)
# for development/tests:  pip install -e ".[dev]"   # adds mypy, pytest, pytest-asyncio

2. プラグインを Claude Code にインストールします。 .mcp.json、フック、 スキル、スラッシュコマンドが読み込まれるようにします。リポジトリのルートは単一プラグインの マーケットプレイス（.claude-plugin/marketplace.json）も兼ねています。/plugin install でインストールできるのは マーケットプレイスからのものだけで、ディレクトリを直接指定することはできません。そのため、まずマーケットプレイスを追加し、 そこからインストールします。Claude Code のセッション内で次を実行します。

/plugin marketplace add https://github.com/shofer-dev/claude-code-live-memory
/plugin install live-memory@shofer-live-memory

shofer はマーケットプレイス名、live-memory はプラグイン名です。代わりにローカルのクローンからインストールするには、 チェックアウトディレクトリを add に指定します。

/plugin marketplace add /ABSOLUTE/PATH/TO/claude-code-live-memory
/plugin install live-memory@shofer-live-memory

後でプラグインファイルを編集した場合は、/plugin marketplace update shofer を実行してから /reload-plugins を実行します（インストール済みプラグインは ~/.claude/plugins/ にキャッシュされるため、 ソースを編集してもすぐには反映されません）。

ローカル開発の場合は、マーケットプレイスを使わず、プラグインを直接読み込んで Claude Code を起動します。 この方法では /reload-plugins によって編集内容が反映されます。

claude --plugin-dir /ABSOLUTE/PATH/TO/claude-code-live-memory

（ステップ 3 のサーバーは、Claude Code が接続する前に起動している必要があります。.mcp.json は type:http エンドポイントを指定しており、Claude Code はこれに接続するだけで、サーバーを起動することはありません。サーバーが停止していると、 /plugin の「Errors」タブに接続エラーが表示されます。）

3. サーバーを実行します（次のセクションを参照）。4. 開発時のチェック： mypy live_memory/ && pytest

サーバーの実行

HTTP トランスポートでは、Claude Code が接続する前にサーバーがすでに起動している必要があります （Claude Code は type:http サーバーを起動しません）。外部のスーパーバイザー（systemd／コンテナなど）で実行してください。

設定不要（API キー不要）：Claude のサブスクリプションにログインしていれば、その認証情報をサーバーが再利用し （自動更新）、Haiku で動作します。

cd server && pip install -e .
python -m live_memory
# serves MCP at http://127.0.0.1:7711/mcp  (+ /health, /stats, /notify, /reload)

サブスクリプションを使う方法では、サブスクリプションのレート制限枠を使用します（使用量に応じた料金は発生しません）。 これは利用規約上、グレーゾーンであることが明記されています。常時稼働するサービスには、キーの使用をおすすめします。

任意のモデル／プロバイダーを選択できます。環境変数を使うか、/live-memory-config スラッシュコマンドを使います （config.json に書き込み、ホットリロードされるため、再起動は不要です）。

# DeepSeek (cheap, recommended), via env:
LIVE_MEMORY_PROVIDER=openai LIVE_MEMORY_BASE_URL=https://api.deepseek.com \
  LIVE_MEMORY_API_KEY=sk-... LIVE_MEMORY_MODEL=deepseek-chat  python -m live_memory

# …or at runtime, from inside Claude Code:
/live-memory-config set provider=openai base_url=https://api.deepseek.com model=deepseek-chat api_key=sk-...
/live-memory-config show

対応プロバイダー：anthropic（Messages API と Bedrock／Vertex／ゲートウェイ。API キーまたはサブスクリプションの OAuth） および openai（OpenAI 互換エンドポイント全般：OpenAI、DeepSeek、ローカルモデル、ゲートウェイ）。次にプラグインを有効にして、 Claude Code が .mcp.json を読み込み、接続できるようにします。

systemd サービスとして実行する

deploy/ にひな形があります。次のコマンド 1 つで登録して起動できます。

cd deploy
./install-service.sh            # user service (recommended — see below)
./install-service.sh --system   # system-wide (best for API-key setups)

仮想環境を作成してサーバーをインストールし、~/.config/live-memory/live-memory.env に設定ファイルを書き込みます （live-memory.env.example を元に作成されます。プロバイダー／モデル／キーに合わせて編集してください）。さらに、 live-memory.service をインストールし、ログインしていなくてもサービスが実行されるように設定してから、サービスを起動します。設定は systemd の EnvironmentFile= を通じてプロセスに渡されます。

• 再起動後もデータは自動的に保持されます。 ワークスペースごとのスナップショットは LIVE_MEMORY_DATA_DIR（デフォルトは ~/.claude/plugins/data/live-memory）に保存されるため、 再起動後、各ワークスペースの次回のクエリ時にメモリが読み込まれます。
• サブスクリプション（設定不要）認証にはユーザーサービスが必要です（デフォルト）。自分のユーザーとして実行されるため、 ~/.claude/.credentials.json を読み取り、Claude のログイン認証情報を再利用できます（自動更新）。--system サービスでも可能ですが、 ユニットに User= と Environment=HOME=… を設定する必要があります（インストーラーが設定します）。

systemctl --user status live-memory
journalctl --user -u live-memory -f
systemctl --user restart live-memory     # after editing the env file

ログ

デフォルトでは、サーバーは標準エラー出力にログを記録し、systemd がこれをジャーナルに取り込みます。ローテーションとユニット／PID のメタデータが付くため、ログの記録先として適しています。

journalctl --user -u live-memory -f          # user service
sudo journalctl -u live-memory -f            # system service

注意点が 2 つあります。また、代替手段もあります。

• ユーザーサービスのジャーナルが再起動後も保持されるのは、journald の永続ストレージが有効な場合（/var/log/journal が存在する場合）だけです。揮発性の場合、ログは再起動時に消失します。
• 永続的で grep 可能なプレーンテキストログを確実に残すには、LIVE_MEMORY_LOG_FILE を設定してください（システムサービスなら /var/log/live-memory/live-memory.log、ユーザーサービスなら ~/.local/state/live-memory/ 以下の絶対パスなど）。これはローテーション対応のハンドラー（LIVE_MEMORY_LOG_MAX_BYTES × LIVE_MEMORY_LOG_BACKUPS）で、journald に加えてログを書き込みます。 LIVE_MEMORY_LOG_LEVEL（デフォルトは INFO）で詳細度を調整できます。

ワークスペースと cwd

メモリは、ask_live_memory に渡された cwd に基づいてワークスペースごとに管理されます。 cwd は絶対パスである必要があります（相対パスは拒否されます。共有サーバーではセッションを基準に解決できません）。デフォルトでは、サーバーは各 cwd をその包含するGit リポジトリのルートに揃えるため、サブディレクトリとリポジトリルートで同じメモリを共有します。

環境変数	デフォルト	効果
LIVE_MEMORY_CANONICALIZE_WORKSPACE	true	cwd を Git リポジトリルートに揃えます。false に設定すると、ディレクトリごとに個別のメモリを使用します。
LIVE_MEMORY_REPO_ROOT_MODE	nearest	サブモジュール／ワークツリー内の場合：nearest = サブモジュール独自のルート（Git のデフォルト）、outermost = スーパープロジェクトのルート（サブモジュールに関する質問を親のメモリにまとめます）。

事前読み込みグロブ — ドキュメントの内容を最初から把握する

preload_globs には、各ワークスペースルートからの相対パスでグロブパターンを指定します。一致するファイルはディスクから読み込まれ、ワークスペースの読み込み時に毎回システムプロンプトにそのまま取り込まれます。これにより、メモリは最初の質問を受ける前から参照資料を把握できます。事前読み込みされた内容は観察結果として扱われ、独自の見出しの下にインラインで表示されます。その後、圧縮時に知識台帳へ要約され、予算の逼迫に応じて元のバイト列が破棄されます。

/live-memory-config set preload_globs=docs/*.md,README.md      # or:
LIVE_MEMORY_PRELOAD_GLOBS="docs/*.md,README.md"

環境変数	デフォルト	効果
LIVE_MEMORY_PRELOAD_GLOBS	(空)	ワークスペースの読み込み時にそのまま事前読み込みする、カンマ区切りのグロブ（ワークスペースルートからの相対パス。** に対応）。絶対パターン、およびワークスペース外へ抜けるシンボリックリンク先の一致ファイルはスキップされます。バイナリファイルもスキップされます。
LIVE_MEMORY_PRELOAD_MAX_TOTAL_BYTES	2097152	ワークスペースごとに事前読み込みする全ファイルの合計上限（ファイルごとの上限は LIVE_MEMORY_PASSIVE_MAX_FILE_BYTES）。実際の上限はさらにウィンドウ予算（compaction_floor × LIVE_MEMORY_MAX_CONTEXT_TOKENS）によって制限されます。フロアを超えて事前読み込みしても、最初の質問で直ちにドキュメントが要約され、元データが破棄されるだけだからです。約 300 KB を超えるコーパスを事前読み込みするには、LIVE_MEMORY_MAX_CONTEXT_TOKENS も引き上げてください。

注意事項：

• 事前読み込みはワークスペースの読み込み時に実行されます。つまり、サーバー起動後の最初のクエリ、/live-memory-empty の実行後、または設定変更後です。/live-memory-config によるグロブの変更は、読み込み済みのワークスペースには次回のリセットまたは再起動時に適用され、遡って適用されることはありません。
• /live-memory-reset を使うと、ワークスペースを一度の操作で最初からやり直せます。現在の履歴（Q&A 履歴、知識台帳、ファイルマニフェスト、メモリ、ディスク上のスナップショット）を破棄し、設定済みのグロブをディスクから直ちに新たに事前読み込みします。蓄積された履歴が古くなったものの、詳しい参照ドキュメントは再び読み込ませたい場合に使います。(/live-memory-empty は、先行して事前読み込みを行わずに同じ内容を消去します。ドキュメントは次の質問時に遅延読み込みされます。)

監視範囲（file_globs）と質問のタイムアウト

環境変数／設定キー	デフォルト	効果
LIVE_MEMORY_FILE_GLOBS / file_globs	(空 — すべてを監視)	カンマ区切りの fnmatch パターン（ワークスペース相対。* は / にも一致します）。設定すると、ファイル変更フィード（受動的な取り込み、古くなったファイルや削除されたファイルの追跡、変更のヒント）は、一致するパスにのみ適用され、それ以外はすべてワークスペースの境界で除外されます。ドキュメントのみを対象にするメモリには、preload_globs と組み合わせます。例：/live-memory-config set preload_globs=docs/*.md file_globs=docs/*.md。
LIVE_MEMORY_DEFAULT_TIMEOUT_S / default_timeout_s	60	質問ごとのソフトな時間制限です。ask_live_memory は**timeout 引数を受け取らなくなりました**。呼び出し元には設定済みの時間制限が適用され、モデルにはその時間制限が伝えられ、期限までに最善の回答が返されます。ハードな .mcp.json の MCP タイムアウトより短くしてください。

スコープ設定は、キャッシュの安定性にも重要です。スコープを設定しないフィードは、エージェントが操作するすべてのファイルを取り込み、新しい観察内容はそれぞれ差分として、次の質問に引き継がれます。ドキュメントのみを対象にすれば、メモリを絞り込み、プロンプトを小さく保てます。

並行処理

同じワークスペースへの質問は、次のいずれかのモデルで受け付けられます。

環境変数	デフォルト	効果
LIVE_MEMORY_CONCURRENCY	parallel	parallel（デフォルト）＝キュー待ち時間なし。質問ごとにウィンドウをフォークし、MAX_PARALLEL_QUERIES まで同時に実行します。コードベースを最も多く調査したフォークが変更をコミットします（ほかのフォークも回答は返しますが、共有メモリは更新しません）。serial ＝ワークスペースごとに一度に1件の質問を処理します（共有ウィンドウがその場で拡張されます。キャッシュの局所性が最も高くなり、同時に呼び出した場合は待機します）。
LIVE_MEMORY_MAX_PARALLEL_QUERIES	4	parallel モードで、ワークスペースごとに同時実行できる質問の最大数です。

（異なるワークスペースへの質問は、この設定にかかわらず常に並行して実行されます。）

非同期（ファイア・アンド・フォーゲット）ツール — オプトイン

MCP ツールの呼び出しが返るまで、呼び出し元はそのターンを進められません。時間のかかるクエリをエージェントに送信させ、作業を続けながら、後で回答を取得したい場合は、LIVE_MEMORY_ASYNC_TOOLS=true を設定すると、次のツールも利用できるようになります。

• ask_live_memory_submit(question, cwd) → すぐに job_id を返します。
• ask_live_memory_result(job_id) → 回答が準備できていれば回答を返し、準備中の場合は [running] を返します。再度ポーリングしてください。

ポーリングはエージェントが行います（Claude Code は実行中のターンに完了通知を送信できません）。デフォルトでは無効ですが、ask_live_memory（同期型）は常に利用できます。

キャッシュのウォーム状態維持

デフォルトでは無効です。有効にするには、LIVE_MEMORY_KEEP_WARM=true を設定するか、スラッシュコマンド /live-memory-config set keep_warm=true を実行します。バックグラウンドループが、最近アクティブだった各ワークスペースのプレフィックスに対して max_tokens=1 で ping を送り（出力は破棄）、質問の間にプロバイダーの KV／プロンプトキャッシュが冷えるのを防ぎます。これにより、次の実際のクエリは、キャッシュがない状態で全内容を読み直すのではなく、キャッシュヒット時の料金で処理されます。ハートビートの間隔はプロバイダーに応じて設定されます。Anthropic／OpenAI では 4分（240秒。分単位のキャッシュ TTL をわずかに下回る間隔）で、DeepSeek では自動的に非常に長い間隔に設定されます（ディスクキャッシュは数時間から数日間保持されるため、有効にしていてもそこで自動的に無効になります）。LIVE_MEMORY_KEEP_WARM_INTERVAL_S または /live-memory-config set keep_warm_interval_s=… で間隔を変更できます。LIVE_MEMORY_KEEP_WARM_MAX_IDLE_S を使うと、アイドル状態のワークスペースでウォーム状態の維持をより早く停止できます。/live-memory-stats で、キャッシュが最後に更新された時刻を確認できます。