あなたの Khoj セカンドブレインを、カスタムの OpenAI base URL で動かす。

早わかり: 初回起動時は環境変数、以降はいつでも管理パネル。

Khoj のセルフホスト用 compose ファイルには、その言葉どおり「他の OpenAI API 互換プロバイダー」向けとされる、コメントアウトされた OPENAI_BASE_URL の行があります。初回起動前に、これを https://api.apisrouter.com/v1 に設定し、OPENAI_API_KEY にゲートウェイキーを持たせておくと、Khoj の初期化処理は珍しく親切なことをしてくれます。エンドポイントのモデル一覧に問い合わせ、そのエンドポイントが提供するすべての id で chat-model テーブルをシードするため、手作業での入力なしにカタログが Khoj のモデルピッカーに現れます。 すでに初期化済みのサーバーでは、代わりに管理パネルを使ってください。ゲートウェイを指す AI Model API エントリ(フィールドは Name、Api Key、Api Base Url)を作成し、次に Name を正確なモデル id にした Chat Model エントリを作成して、Model Type を Openai に設定し、その AI Model API に紐づけます。どちらの面も、docs.khoj.dev の Khoj の OpenAI プロキシガイドにドキュメント化されています。

services:
  server:
    environment:
      - OPENAI_BASE_URL=https://api.apisrouter.com/v1
      - OPENAI_API_KEY=sk-YOUR-APISROUTER-KEY

Khoj がチャットモデルで何をするか。

Khoj(GitHub 上では khoj-ai、スター数はおよそ36K)は、セルフホスト可能な AI セカンドブレインです。あなたのノートとドキュメント(markdown、org-mode、PDF など)をインデックス化し、それらについてチャットできるようにし、独自のペルソナとツールを持つカスタムエージェントを実行し、cron で発火する自動化をスケジュールし、複数ステップのリサーチ実行を起動します。ホスト型のアプリもありますが、カスタムエンドポイントが適用されるのはセルフホストサーバーであり、それがこのページで説明するデプロイです。 それらの機能はすべて、あなたが選んだチャットモデルを通じて動きます。ドキュメントチャットは検索されたノートのチャンクをプロンプトに詰め込み、エージェントはツール呼び出しとペルソナの指示を加え、自動化は同じパイプラインを無人で実行し、リサーチモードは1つの質問につき多数のモデル呼び出しを連鎖させます。Model Type Openai は、Khoj に対して、紐づけられた AI Model API エントリの Api Base Url に /v1/chat/completions で話すよう指示し、model Name をプレーンな文字列として転送します。だからこそ、エンドポイントがそれを提供している限り、Claude や DeepSeek の id もそこで動作します。 検索のエンベディングは別のサブシステムです。Khoj はデフォルトで、ローカルの sentence-transformers モデルであなたのドキュメントを埋め込むため、チャットエンドポイントに何をしようと、インデックス作成とセマンティック検索は動き続けます。チャットをゲートウェイ経由にルーティングすることは、推論の請求だけを移動させます。

フルセットアップ: 管理パネルのエントリを順を追って。

稼働中のサーバーでは、統合の全体は3つの管理画面で完結します。まず AI Model API を追加します。/server/admin/database/aimodelapi/add を開き、名前を付け、ゲートウェイキーを Api Key に貼り付け、Api Base Url を https://api.apisrouter.com/v1 に設定します。 次にチャットモデルを追加します。/server/admin/database/chatmodel/add で、Name を正確なカタログの id(claude-sonnet-4-6、deepseek-v4-flash)に設定し、Model Type を Openai に設定し、先ほど作った Ai Model Api エントリに紐づけ、Max prompt size をモデルのコンテキストウィンドウに収まる値に設定します。ドキュメントは、Openai タイプのモデルでは Tokenizer を未設定のままにすることを勧めています。ピッカーに入れたいモデルごとに繰り返してください。 最後にモデルを選択します。/settings で、新しいチャットモデルをデフォルトとして選びます。エージェントはエージェントごとにモデルを上書きできるため、1つの Khoj インスタンスが、日々の自動化には速い id を、リサーチにはフロンティア id を使う、という形が実現します。

1) /server/admin/database/aimodelapi/add
   Name:         APIsRouter
   Api Key:      sk-YOUR-APISROUTER-KEY
   Api Base Url: https://api.apisrouter.com/v1

2) /server/admin/database/chatmodel/add
   Name:         claude-sonnet-4-6   (exact catalog id)
   Model Type:   Openai
   Ai Model Api: APIsRouter
   Max prompt size: 100000

3) /settings -> select the new chat model

セカンドブレイン向けのモデル選び。

チャットモデルは1つの AI Model API に対して追加する行であるため、ピッカーに2つか3つの id を持っておくことに何のコストもかかりません。実践的なセットアップは、速いデフォルトとフロンティアへのエスカレーションの組み合わせであり、どちらも同じキーで課金されるため、利用ログが各ティアがあなたのノートについて実際いくらかかるかを示してくれます。

• ドキュメントチャットは入力量の多い作業です。検索されたノートのチャンクが回答をはるかに上回ります。入力トークンあたりの価格が質問あたりのコストを左右し、日常的な想起には claude-haiku-4-5-20251001、deepseek-v4-flash、gemini-3.5-flash が有利です。
• リサーチモードは呼び出しを増幅させます。1つのリサーチの質問が多数のモデルターンを連鎖させることがあるため、そこに割り当てる id は、他のどの設定よりも請求額を動かします。claude-sonnet-4-6 がバランスの取れた選択で、gpt-5.4 はさらに上のエスカレーションです。
• スケジュール化された自動化は無人で実行されます。サブスクリプションのように価格を考えてください。1日あたりの呼び出し数 × 呼び出しあたりのトークン数であり、それはまさにキーごとの利用ログが報告する内容です。
• 個人の知識には矛盾が多く含まれます(計画は変わり、ノートは古くなります)。矛盾するノートを混ぜ合わせるのではなくきちんと指摘できるかどうかは、モデルによって差があります。決める前に、同じ質問セットで2つの id をテストしてください。
• Khoj では Max prompt size がチャットモデルごとに設定されるため、長文脈対応の id は、そのフィールドをそれに合わせて引き上げて初めて価値を発揮します。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Khoj に特有の失敗パターン。

この環境変数は初回起動時のシード用であり、常時有効な設定ではありません。OPENAI_BASE_URL は、プロバイダーのエントリを作成しモデルを発見するために、初期化中に読み込まれます。すでに初期化済みのサーバーでは、compose ファイルを編集しても、目に見える変化は何も起きません。初回起動後の変更には管理パネルを使うか、本当にまっさらなシードが必要ならデータベースをリセットしてください。 プレースホルダーキーの罠。OPENAI_API_KEY なしで OPENAI_BASE_URL が設定されると、Khoj は Ollama のようなローカルサーバーが動くように、キーをプレースホルダーで埋めます。ゲートウェイには本物のキーが必要なので、キーなしで初回起動のシードが行われた場合、管理パネルの AI Model API エントリにキーを貼り付けるまで、チャットは認証エラーで失敗します。 自動検出はすべてをシードします。初期化がエンドポイントの提供するすべてのモデルを一覧するため、マルチベンダーのゲートウェイは長いモデルテーブルをシードすることがあります。害はありませんが、ピッカーを使いやすく保つために、管理パネルで間引く価値はあります。 Chat model の Name は正確でなければなりません。Khoj はそれをそのまま転送するため、タイプミスは最初のメッセージで model-not-found として表面化し、ゲートウェイの /v1/models の出力が正しい綴りの拠り所です。そして、あなたのノートに対するセマンティック検索がおかしくなる場合、それはローカルのエンベディングサブシステムの問題であり、チャットエンドポイントとは関係ありません。

ゲートウェイ経由で Khoj を使うのは誰か。

• モデルファミリーごとのベンダーアカウントなしに、自分のノートに対してフロンティア級のモデルでチャットしたいセルフホスター。キー1つで Claude・GPT・DeepSeek・Gemini の id をカバーします。
• 毎日スケジュール化された自動化を実行するユーザーで、速い id が繰り返しのコストを一定に保ち、利用ログがそれを可視化してくれる人。
• インデックス作成とエンベディングをローカルに保ち、チャットプロンプトだけを1つの監査可能なエンドポイントに公開する、プライバシー重視のセットアップ。
• 同一の個人コーパスに対してチャットモデルを比較する人。各候補は、同じ AI Model API に対する1つの chat-model 行で済みます。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のチャットをデバッグする。

まずゲートウェイを確認してください。あなたのキーでモデルを一覧し、登録する予定の id を確認します。Khoj 自身の自動検出も、初回起動のシード時に同じ呼び出しを行うため、この curl が動けば、シードも動きます。 失敗はきれいに切り分けられます。認証エラーは、AI Model API エントリの Api Key が間違っているか、まだシードされたプレースホルダーのままだということです。Model-not-found は、chat model の Name がカタログの綴りと一致していないということです。回答が途中で切れる場合は、たいてい Max prompt size かモデルの出力上限が、その会話に対して低すぎるということです。インデックス作成と検索の問題は、ローカルのエンベディングパイプラインの問題であり、エンドポイントとは無関係です。 チャットが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。自動化とリサーチの実行こそが、セカンドブレインのコストが潜んでいる場所であり、キーごとの利用状況は、それを月1回の驚きとしてではなく、機能ごとに見る方法です。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

よくある質問