Vectr

Vectr

保存ではなく、届けること。 AI コードエディターにコードベースのセマンティック検索を提供し、関連するタイミングで自動的に表示される作業メモリも備えたローカルデーモンです。

バージョン 1.12.0 · 最終更新日 2026-09-03 · 変更履歴

30 秒でわかる概要

AI コードエディターは、同じ知識に対して二度コストを払っています。昨日読んだファイルをまた読み、すでに見つけたシンボルを grep し直し、会話が圧縮された瞬間に、5 ターン目で見つけた正確なシグネチャを失います。Vectr は、こうしたコストの両方を解消するローカルプロセスです。

• コードを理解した検索。 AST 対応チャンク、シンボルと呼び出しのグラフ、セマンティック検索と BM25 によるハイブリッドランキングを備えています。動作を説明すれば、grep を繰り返し、見当をつけずにファイルを 3 つ読む代わりに、1 回の呼び出しで関数全体を取得できます。
• 届けられる作業メモリ。 調査結果を一度保存すれば、50 ミリ秒以内にそのまま再取得できます。セッションフックを公開するエディターでは、エージェントが取得を求めなくても、必要なタイミングで自動的に届きます。
• ローカル、キー不要、設定不要。 pip install を 1 回実行し、vectr start を実行するだけです。埋め込みモデルはお使いのマシン上で動作します。データが外部に送信されることはなく、API キーも不要です。

pip install vectr && cd /path/to/your/project && vectr start

設定はこれだけです。Vectr がエディター用の MCP 設定を書き込み、その後バックグラウンドでインデックスを作成します。

vectr が他の AI エージェント向けメモリツールと異なる点

AI エージェント向けの汎用メモリレイヤーは健全なカテゴリを形成しており、優れたものは実際の問題をうまく解決しています。Vectr はこうしたツールと比較されることが最も多いため、違いを率直に説明します。左側の列は、これらのツールに共通する傾向のある設計を示したもので、特定の製品について述べたものではありません。ツールごとに違いがあるため、検討中のツールについては個別にご確認ください。

最初の行が重要な理由。 ボトルネックは保存ではありません。エージェントが自ら呼び出す必要のある検索です。実際、エージェントはほとんど検索を呼び出さないからです。管理された評価では、タスクに直接関係する知識をあらかじめ保存しておいたにもかかわらず、エージェントは 114 ターンを通じてメモリ操作を一度も行いませんでした。一方、注入対応の実行ではすべて決定論的な注入が行われ、監査ログに記録されたトリガー評価で誤作動は一度もありませんでした。コンパクションを繰り返すテストでは、会話内にのみ保持された 10 個の事実は、強制コンパクション 108 回のうち 106 回で失われました。それに対し、ハーネス管理のストアから注入された同じ 10 個の事実は、コンパクション後の再開 138 回すべてで完全な状態で届きました。

手法と結果の全文：保存ではなく配信：コーディングエージェントのハーネス機能としての手がかりに基づく作業メモリ（arXiv:2607.20972）。

コストと節約できるもの

仮定ではなく、実測値です。 vectr_recall で保存済みのメモを 3 件取得する場合、ツール呼び出し 1 回で 360 トークンかかります。同じ 182 ファイルの Python リポジトリで、grep と Read を使って同じ 3 つの事実を再導出すると、ツール呼び出し 6 回で約 2,060 トークンかかります。これは 50ms 未満で、トークン数を約 5.7 分の 1、ツール呼び出し回数を 6 分の 1 に削減できます（文字数を 4 で割ってトークン数を算出。詳細は実測コストの内訳をご覧ください）。

メモは会話内ではなくディスクに保存されるため、/compact を実行しても、新しいセッションを開始しても、同じように保持されます。セッションの境界は関係ありません。5 ターン目に保存した内容を 15 ターン目に取得する場合も、3 日後に取得する場合も、仕組みは同じです。

効果を発揮する場面： 不慣れなコードベースや大規模なコードベース、再開する作業、ターン数の多い長時間セッション。 効果を発揮しない場面： 熟知しているコードに対する一度きりの grep。代わりに grep を使い、vectr が逆効果になる場合をご覧ください。

ベンチマーク

公開結果は benchmarks/ にあります。以下のコーパスは、規模が大きく、モデルにとって未知のものとして選ばれた検証用データであり、それ以上の意味はありません。

大規模で未知の C コードベースを使った6タスクのスプリントは、1週間分の機能開発をシミュレートします。1回の調査セッションで、vectr_remember を使って調査結果を保存します。実装セッションはそれぞれ独立しており、6回とも初期状態から開始して vectr_recall を呼び出します。

実装セッションのみ、6タスクの合計：

タスクごとの再調査（最初の書き込みまでの Read と Bash の呼び出し数）：

0%の行は実際の結果であり、意図的に残しています。このタスクは、モデルが訓練時の知識だけですでに調査できたものです。

調査と実装について、ありのままに説明します。 調査フェーズは一度だけ実行され、vectr を使うとコストが高くなります（+94%）。コードスタブやシグネチャを豊富に保存すると、出力トークンが増えるためです。実装フェーズはタスクごとに繰り返されますが、再調査をリコールで置き換えられるため、コストは下がります。ノートを約8タスク再利用すると、オーバーヘッドを回収できます。

以前、5,856ファイルの Java コーパスで実行した測定では、**実装コストが-58%、実装時のツール呼び出し数が-72%、経過時間が-39%**でした。

測定コストについて、ありのままに

呼び出しごとのトークンコスト（中央値、182ファイルの Python リポジトリ、文字数/4でトークン化）：

トレードオフを率直に述べると、小規模で内容をよく把握しているリポジトリに対する、単一の明確な検索では grep のほうが低コストです。単一の事実を探す5タスクで、Vectr のコスト中央値はトークン数で60%増でした。また、vectr_search の往復には1.7～3.6秒かかる一方、grep は約28msのため、速度も劣ります。Vectr は呼び出しあたりのコストでは優位ではありません。ツール呼び出し数（複数回ではなく1回の往復で済む）、回答の網羅性（ファイルの一部を読むのではなく、シンボル全体を取得できる）、そして作業メモリ内のあらゆる情報で優位です。作業を再開するたびに、5.7倍のリコールによる節約が積み重なります。

補足：ツールの応答に付随する自動削除やリマインダーのバナーもトークンを消費します。常時表示される再取得フッターは約27トークン、軽い通知は約89トークンです。また、チャンクとトークンの両方のしきい値を超えても保存されなかった場合にのみ表示される、エスカレーションされた対応必須バナーは、約480～535トークンから始まり、その後は一定になります。

クイックスタート

ローカル（推奨）

python3.14 -m venv ~/.vectr-env
source ~/.vectr-env/bin/activate   # Windows: ~/.vectr-env/Scripts/activate
pip install vectr
cd /path/to/your/project
vectr start

Python 3.14 以降が必要です。 インストール方法：

• macOS：brew install [email protected]
• Ubuntu/Debian：sudo add-apt-repository ppa:deadsnakes/ppa && sudo apt install python3.14 python3.14-venv
• Windows：python.org/downloads

vectr start はすぐに戻ります。インデックス作成はバックグラウンドで実行されるため、進行状況を確認するには vectr status を実行してください。初回実行時には、埋め込みモデルが一度ダウンロードされます（約290 MB）。新しい MCP 設定を読み込むため、AI コードエディターを一度再起動してください。

Docker（CI とサーバー）

git clone https://github.com/swapnanil/vectr
cd vectr
docker-compose up api

ポート8765を公開します。Docker は IDE の設定ファイルを自動作成しないため、IDE との統合にはローカルインストールを使用してください。

AI コードエディターに接続する

vectr start は、エディターの MCP 設定を自動的に書き込みます。エディターを一度再起動してください。

「検証済み」とは、完全な統合（設定、ガイダンス、フック）がエンドツーエンドで動作確認されていることを意味します。「実験的」とは、MCP 設定は書き込まれて動作するものの、同じ検証プロセスを経ていないことを意味します。

メモリの自動配信は、ホストがセッションフックを公開しているかどうかに依存します。公開していない場合でも、以下のすべてのツールを MCP 経由で必要に応じて利用できます。

{ "mcpServers": { "vectr": { "type": "http", "url": "http://localhost:8765/mcp" } } }

{ "mcpServers": { "vectr": { "url": "http://localhost:8765/mcp" } } }

{ "servers": { "vectr": { "type": "http", "url": "http://localhost:8765/mcp" } } }

{ "mcpServers": { "vectr": { "serverUrl": "http://localhost:8765/mcp" } } }

{ "mcpServers": [{ "name": "vectr", "transport": { "type": "http", "url": "http://localhost:8765/mcp" } }] }

[mcp_servers.vectr]
url = "http://localhost:8765/mcp"

Stdio トランスポート

上記のエディターは HTTP 経由で接続します（vectr start と POST /mcp）。HTTP 接続を開く代わりに、サーバーをサブプロセスとして起動し、標準入力と標準出力経由で MCP をやり取りする MCP クライアントやホスティングプラットフォームでは、次を実行してください。

vectr mcp-stdio [WORKSPACE]

ポートもデーモンも不要です。改行区切りの JSON-RPC 2.0 を使う単一のフォアグラウンドプロセスです（標準入力と標準出力のそれぞれで、1 行につき 1 つの JSON オブジェクトを送受信し、Content-Length ヘッダーは使用しません）。initialize と tools/list はすぐに応答します。一方、埋め込みモデルの読み込みと初期インデックス作成はバックグラウンドスレッドで行われます。これらが完了する前に tools/call を実行すると、停止する代わりに「起動中」の応答が返されます。標準出力にはプロトコルの JSON のみが出力され、すべてのログは標準エラー出力に送られます。標準入力が EOF になると、プロセスは正常に終了します。--memory-only と --search-only の動作は vectr start と同じです。

動作の仕組み

1. AST を考慮したチャンク分割。 tree-sitter が各ファイルを解析し、関数、クラス、メソッドの境界で分割します。ロジックの途中でチャンクが途切れることはありません。
2. コードの埋め込み。 ibm-granite/granite-embedding-english-r2（ローカルで動作し、CPU で高速、変更可能）が自然言語のクエリをコードのシンボルに対応付けるため、「JWT validation」で verify_jwt_token が見つかります。シンボル名の完全一致には BM25 を使用します。
3. ハイブリッド検索。 ベクトル類似度と BM25 を組み合わせ、コードベースの特性に応じて重み付けします。大規模で不慣れなコードベースではセマンティック検索を、小規模でドキュメントが充実しているコードベースでは BM25 を重視します。
4. シンボルグラフ。 呼び出しエッジ、インポートチェーン、HTTP ルート（Flask、FastAPI、Express、Spring）を抽出して保存します。vectr_locate は 6 段階の検索戦略（完全一致、サフィックス、同一モジュール、インポートチェーン、部分一致、ファジー検索）を順に適用して名前を解決します。ファジー検索の結果は、確実な一致として提示せず、必ず明示的に不確かなものとして表示します。自信を持って誤ったシンボルを示すより、見つからないと伝えるほうがよいためです。
5. 作業メモリ。 vectr_remember は構造化されたメモを SQLite と ChromaDB に保存します。vectr_recall は SQL の LIKE 検索ではなく、メモを対象にセマンティック検索を行うため、複数の単語を含むクエリでも関連するコンテキストを見つけられます。
6. トリガーの評価。 各メモの条件は、ライフサイクルの節目にデーモンによって決定論的にチェックされます。セッションごとの発火記録と挿入予算により、メモは適用されるタイミングで正確に再表示され、同じ期間内に二度表示されることはありません。
7. MCP プロトコル。 23 個のツールを HTTP 経由で提供します。MCP 対応の AI コードエディターであれば、プラグインなしで接続できます。

23 個の MCP ツール

vectr start は、この表を含むガイダンスファイルをワークスペースに書き込みます。これにより、AI コードエディターは指示を受けなくても、状況に応じて使うツールがわかります。

検索ツール：インデックスからコードを取得します。

メモリツール：セッションをまたいで情報を保存し、呼び出します。

トリガー：配信レイヤー

これらのkind値には、妥当なデフォルトが設定されています。ノートでは、vectr_rememberに明示的なノートごとのtriggersを指定することもできます。

1つのエントリー内の条件はAND、エントリー間の条件はORで評価されます。発火するたびに、どのトリガーが一致したかを説明する1行の説明が付加されます。注入には予算が設定され（複数のサーフェスで共有する、ターンごとの厳格な上限）、ターン内のすべてのサーフェスでノートIDを基に重複排除され、出所情報が付与されます。そのため、未レビューの自動取得ノートが、あなたによる常設ルールと同等の権威を持つように表示されることはありません。ノートが途中で切り詰められることはありません。インデックス層の1行として丸ごと届くか、まったく届かないかのどちらかです。

ワークスペーススコープのノートは、マルチエージェントワークフローの共有バスとしても機能します。オーケストレーターとそのサブエージェントは、同じノートストアを読み書きするため、サブエージェントは完了前に、調査結果をvectr_remember(..., agent="coder-2")で記録できます。オーケストレーターはサブエージェントのトランスクリプト全体を読み直す代わりに、その結果を呼び出せます。agentパラメーターが推測されることはありません。明示的な帰属情報であり、vectr_recallのインデックス出力にタグとして表示されます。

CLIリファレンス

vectr start                           # index + start daemon for current dir
vectr start /project/api              # positional workspace: a directory or .code-workspace file
vectr start --path /project/api       # specific workspace (repeatable, multi-root)
vectr start --memory-only             # working memory + hooks only, no code index, no watcher
vectr status                          # index health, chunk count, notes count
vectr status --all                    # all running instances
vectr stop /project/api               # stop one instance (same positional as start)
vectr stop --path /project/api        # stop one instance (equivalent --path form)
vectr stop --all                      # stop all instances
vectr index --path .                  # re-index without restarting daemon
vectr fetch src/auth.py:10-42         # re-fetch a chunk by exact id, verbatim
vectr resume                          # most recent task note, latest snapshot, open gotchas
vectr init --path .                   # write guidance file + MCP config without starting
vectr init --exclude vendor           # exclude directories from indexing
vectr forget --path .                 # delete all working-memory notes
vectr memory export                   # render the working-memory store as a greppable, git-diffable markdown file (default MEMORY.md)
vectr memory export --path notes.md   # write the export to a specific file
vectr memory export --disable         # stop the auto-refresh that keeps the export file in sync
vectr memory edit                     # open the working-memory store in your $EDITOR, one block per note
vectr memory import                   # bring existing on-disk memory files into the working-memory store (see below)
vectr memory import --path NOTES.md   # import a specific file instead of the default discovery list
vectr memory import --dry-run         # preview what would be created (kind, title, source file, line range), change nothing
vectr cache prune                     # remove empty per-workspace cache dirs (live instances skipped)
vectr cache prune --dry-run           # preview what would be removed, delete nothing
vectr proxy                           # experimental: localhost API proxy (see below)
vectr mcp-stdio                       # foreground stdio MCP transport, no port or daemon (see above)

既存のメモリをインポートする

vectr memory export と vectr memory edit は、それぞれ一方向にエクスポートする経路と、チェックアウト／チェックインする経路です。vectr memory import は一方向にインポートする経路です。既存のディスク上のメモリを、手作業で再入力することなく作業メモリストアに取り込みます。すでにメモリを書き留めている新しいユーザー向けの導入経路です。

検出。 --path を指定しない場合、インポーターはワークスペースのルートにあるデフォルト候補ファイルを限定リストに従って確認します。対象は MEMORY.md、CLAUDE.md、AGENTS.md、.cursorrules、.github/copilot-instructions.md です。ほかのファイルまたはディレクトリを指定するには、--path（複数回指定可能）を渡します。ディレクトリは再帰的に検索され、*.md と *.mdc のファイルが対象になります。存在しないファイルは報告されますが、エラーにはなりません。ほとんどのワークスペースには、デフォルトファイルがすべて揃っているとは限らないためです。

粒度。 ソースファイルは、1つのメモにも、1行ごとのメモにもなりません。人が MEMORY.md をざっと読むときと同様に、Markdown の見出し境界（^#{1,6}\s+）で分割されます。見出しのないファイルは1つのメモになります。フェンス付きコードブロックや HTML コメントブロック内の見出しはスキップされるため、コード例やエクスポートファイルのヘッダーコメントがセクション境界になることはありません。以前に vectr memory export でエクスポートされたファイルは、その `` ヘッダーで検出され、vectr memory edit が使用するものと同じブロック構文で解析されます。これにより、元の各ブロックがメモとして復元され、宣言されていた kind、priority、tags、provenance が引き継がれます。

ドライラン。 --dry-run は、作成される内容（kind、タイトル、ソースファイル、ソース行の範囲、provenance）を正確に表示し、変更は行いません。メモリはユーザーが簡単には再構築できない唯一のリソースなので、まずドライランを実行するのが最善です。

vectr memory import --dry-run
# + [finding/auto] 'Project conventions'  (MEMORY.md:12-34)
# + [operational/agent] 'Test runner'  (CLAUDE.md:5-9)
# DRY RUN: would create 2 note(s), skip 0 already-imported, ...

冪等性。 インポートされた各メモには、src:、src-sha:、src-lines: のタグが付与されます。変更されていないソースファイルに対して vectr memory import を再実行すると、これらのタグが認識され、新しいメモは作成されません。ソースファイルのセクションを編集すると、ハッシュが保存済みのものと一致しない新しい本文が生成されるため、新しいメモになります。以前のメモはそのまま残ります。以前にインポートしたメモをユーザーに知らせずに削除することは、エクスポート側の設計で防いでいる、気付かれないデータ損失そのものだからです。

Provenance。 インポートされたメモには、ソースファイルを示すタグ（imported と src:FILENAME。FILENAME はソースファイルのベース名）が付与されます。そのため、imported が付いたメモを一覧表示するリコールは、「これはこのセッションでの観察ではなく、ファイルから取り込まれたものです」とユーザーに伝えます。メモの provenance はデフォルトで auto です。これは、レビューによる判断を経ずに機械が取得した事実にすでに付与されている分類です。手書きの MEMORY.md は、パーサーにとっては生成ツールの出力と構造上区別できないためです。例外は限定的かつ構造的なもので、意味に基づくものではありません。本文に命令ルールを示すマーカー（限定されたキーワードセット MUST、MUST NOT、NEVER、ALWAYS、DO NOT、DON'T、REQUIRED、FORBIDDEN）が含まれるメモは、kind="directive" に分類され、provenance="agent" に引き上げられます。これは、remember() の書き込み時ガード auto + directive があるためです。レビューされていない常設ルールは、矛盾した概念であり、インポートされたルールはまさにその組み合わせです。agent への引き上げは、auto からの逸脱を必要最小限にとどめ、ガードを満たすのに十分な対応です。レビュー後、ユーザーは vectr_promote を使ってさらに昇格させます。

パスを除外する

プロジェクトのルートに .vectrignore を作成します（構文は .gitignore と同じです）。

vendor/
node_modules/
*.pb.go
dist/

または、初期化時に --exclude を渡します。

vectr init --exclude vendor --exclude dist

除外設定は、初回のインデックス作成時の走査とライブファイルウォッチャーの両方に適用されるため、.vectrignore にディレクトリを追加すると、実行中のインスタンスによる再インデックスが停止します。次回のインデックス作成では、除外対象になったファイルや削除されたファイルのチャンクも削除されるため、最初から再構築する必要はありません。たとえば埋め込みモデルを変更した後など、クリーンな再構築が必要な場合は、強制実行します。

vectr index --path . --force      # ignore the incremental cache, re-embed everything

対応言語

HTTP ルート（Flask および FastAPI のデコレーター、Express の app.get()、Spring の @GetMapping）はシンボルとして抽出され、vectr_locate("GET /api/users") で検索できます。

コスト

セキュリティ

デフォルト設定は変わらず、引き続き最優先事項です。個人のマシンで使う個人開発者向けに、ローカルで動作し、API キー不要、設定不要です。初期状態では、デーモンは 127.0.0.1 のみにバインドされ、CORS は localhost オリジンに制限されます。各ワークスペースには、それぞれ独立した DB ディレクトリ、ポート、プロセスが割り当てられます（POSIX では所有者のみがアクセスできる 0700）。インデックスとノートは ~/.cache/vectr/ にローカル保存されます。

以下の設定はすべてオプトインです。何も有効にしなければ、何も変わりません。

認証。 VECTR_API_KEY を設定すると、/v1/* と /mcp へのすべてのリクエストにキーが必要になります（X-Api-Key: <key> または Authorization: Bearer <key>。比較には一定時間比較を使用し、死活監視用の /v1/health は認証不要です）。vectr key でキーを生成します。起動時にキーが設定されている場合、vectr が書き込むエディターの MCP 設定にはヘッダーが自動的に含まれます。これらのファイル（.mcp.json、.cursor/mcp.json、.vscode/mcp.json）にはキーが平文で保存されるため、シークレットとして扱い、共有または公開されているバージョン管理に含めないでください。

保存データの暗号化。 VECTR_ENCRYPT_KEY を設定するか、OS のキーチェーンにパスフレーズを保存すると（サービス vectr、ユーザー名 encrypt-key。pip install vectr[encryption] が必要です）、ノートの内容、ノートのタイトル、スナップショットのペイロードが Fernet と PBKDF2 から導出したキーで暗号化されます。正直なところ、コードインデックスは暗号化されません。検索エンジンには、読み取り可能なチャンクテキストとベクトルが必要だからです。OS のディスク全体暗号化で保護してください。ノートのタグとメタデータは平文のままです。また、ノートの埋め込みベクトル（ノートのテキストを損失ありで投影したもの）は、VECTR_ENCRYPT_DISABLE_NOTE_VECTORS=1 を設定しない限り、意味検索に備えて保持されます。

保持と監査。 ノートは削除するまで保持されます。VECTR_NOTES_TTL_DAYS を設定すると、起動時に指定日数より古いノートが自動的に削除されます。vectr_forget(all=true) と vectr forget --all は、ノート、スナップショット、ノートベクトルを削除します。つまり、すべてが削除されます。VECTR_AUDIT_LOG=<path> を設定すると、インデックス作成、検索、記憶、想起のイベントをローテーション付きのローカルログに記録します（デフォルトでは無効です。目的上、クエリテキストも記録しますが、送信されることはありません）。ポリシー全文：docs/data-handling.md。

チームモード（共有インスタンス）。 1 つの中央デーモンで、1 つのリポジトリを使うチームにサービスを提供できます。サーバーで VECTR_API_KEY=<key> vectr start --host 0.0.0.0 を実行します（ループバック以外へのバインドは、キーがないと起動を拒否します）。次に、各クライアントで vectr connect --url http://<host>:<port> --api-key <key> --label <you> を実行し、エディターの接続先を指定します。作業メモリは共有されます。あるエージェントが保存したノートは、接続しているすべてのエージェントが想起でき、--label はノートと監査ログの項目にラベルを付けます。ノート ID は書き込みが到着した順に中央ストアが割り当てるため、クライアントが同時に接続している場合、自分のノート ID が連続するとは限りません。他のクライアントのノート ID と交互に割り当てられます。書き込み時に返される Stored note #N の行が、そのノートを特定する正式な参照先です。次の ID も自分のものだと思い込まないでください。率直な制約として、共有キーを持つ人は全員、同等の信頼された相手です（ロールやユーザーごとの権限はありません）。サーバーの運用者はすべてを読み取れます。検索結果が参照するのはサーバー側のチェックアウトであり、ローカルのツリーとは異なる場合があります。また、vectr は平文の HTTP を使用するため、信頼できないネットワークでは、リバースプロキシまたはトンネルで TLS を設定してください。

プロアクティブなコンテキスト（実験的、localhost のみ）

プル型の想起では、エージェントが質問する必要があります。プロアクティブなコンテキストは、通信経路上に配置することで、セッションフックのないホストにも決定論的な配信を拡張します。これは実験的で、localhost のみを対象とします。1.6.0 以降、ローカルインスタンスではプロアクティブな配信がデフォルトで有効です（proactive.enabled。無効にするには VECTR_PROACTIVE=0 を設定します）。以下の通信経路はこの設定ではなく、起動時の同意によって制御されます。プロキシを起動し、エージェントをそこに向けることがオプトインとなり、プロキシを停止するかベース URL の設定を解除することがオプトアウトとなります。

vectr proxy コマンドは、エージェントとモデル API の間で動作する小さなローカルプロキシを実行します。

vectr proxy                            # starts a localhost proxy (default :8785)
export ANTHROPIC_BASE_URL=http://127.0.0.1:8785   # point your agent at it

何をするのか、何をしないのかを明確に説明します。

• デフォルトでは透過的です。 すべてのリクエストを実際の API に転送し、ストリーミングレスポンスとツール呼び出しはバイト単位でそのまま通過します。API キーは変更されずに転送され、保存もログへの記録もされません。
• 決定論的な注入です。 ワークスペースデーモンが実行中の場合、プロンプトキャッシュを無効化しないよう、最後のプロンプトキャッシュブレークポイントの後に、照合された作業メモリのノートをリクエストへ追加します。トリガーには類似度のしきい値と完全一致する構造のみを使用し、キーワードによる推測は行いません。また、リクエストごとに厳格な予算を設け、トークンを使う価値がある場合にのみヒントを追加します。
• フェイルオープンです。 インテリジェンスレイヤーの応答が遅い場合やエラーが発生した場合でも、リクエストは変更されずに送信されます。プロキシを完全に迂回するには、ベース URL の設定を解除します。 unset ANTHROPIC_BASE_URL。プロキシはリクエスト経路上にあるため、停止している場合は変数の設定を解除して API に直接接続してください。
• 単独利用かつ localhost のみです。 コンテキストを計算するために会話を読み取るため、ループバック以外へのバインドを拒否し、チームモードとは併用できません。
• ファーストパーティ以外のベース URL に関する注意点は、ホスト独自のドキュメントに記載されています。ENABLE_TOOL_SEARCH=true を設定し、プロキシがツール参照ブロックを転送しない限り、MCP ツール検索は無効になります。また、api.anthropic.com 以外のベース URL では Remote Control が無効になります。

組織全体のキャッシュ（チームモード）。 中央の共有インスタンスでは、vectr はセマンティック検索や想起結果など、コストの高い自身の処理結果を、完全一致する ID と現在のインデックス状態をキーとしてキャッシュできます。そのため、再インデックスやノートの変更によって自動的にキャッシュが無効になり、接続しているすべての開発者がその恩恵を受けられます。これはデフォルトで無効です（proactive.cache）。vectr status はヒット率と推定節約トークン数を報告するため、効果を主張ではなく測定によって確認できます。Vectr は、類似したリクエスト間で LLM のレスポンスをキャッシュすることはありません。ローカルでの、バイト単位で完全に同一なレスポンスのみを対象とし、明示的にオプトインした場合に限ります。誤ったキャッシュヒットが会話を気付かれないまま破損させるおそれがあるためです。

vectr が悪影響を及ぼす場合

コードベースの大幅な変更後にノートが古くなる場合。 ノートには、書き込んだ時点のファイルパスが保存されます。大規模なリファクタリングの後、vectr_recall は参照先の変更されたファイルに [STALE] のフラグを付けます。操作する前に再確認するか、vectr_forget(note_id=N) で古いノートを削除するか、vectr_forget(all=true) ですべてを消去してください。

よく知られた API に対して過剰に検索する場合。 モデルがトレーニングからフレームワークをすでに深く理解している場合、vectr の調査にかかるオーバーヘッドが節約分を上回ることがあります。上記のベンチマークでは、トレーニングで得た知識だけで十分に対処できたタスク debug_descriptor_priority で、その点が明確に示されています。

古くなったアーキテクチャ概要。 vectr_map_save で保存したパスポートは、インデックス作成時点のアーキテクチャを説明します。モジュール名の変更やエントリーポイントの再構成後は、確信を持って誤った情報になっている可能性があります。そのため、vectr_map が古さの警告を表示した場合は、vectr_map_save を再実行してください。

広範な想起はトークンを消費します。 クエリを指定せずに vectr_recall() を実行すると、すべてが返されます。対象を絞ったクエリを渡し、そもそも想起が必要かどうか判断できない場合は、まず vectr_status() を確認してください。

使用技術

Python 3.14 · FastAPI · sentence-transformers · tree-sitter · ChromaDB · BM25 · Docker

作者

Swapnanil Saha · swapnanilsaha.com