BYOK - Bring Your Own Key

BYOK（Bring Your Own Key）は、すべてのプランで Kodus が LLM を使用するデフォルトの方法です — Community、Teams、Enterprise を問わず。自分のプロバイダーアカウントを接続し、使いたいモデルを有効化し、各タスクを実行するモデルを選択します。プロバイダーに直接支払い、Kodus はトークンに上乗せ料金を請求せず、APIキーを平文で見ることも決してありません。

プランとの対応関係

BYOK は Community では無料、Teams では利用可能（トークン費用に加えてアクティブ開発者1人あたり月10ドル）、Enterprise では2つのオプションのうちの1つです（もう1つは Kodus が管理する APIキー）。

BYOK の仕組み

BYOK はプロバイダーファーストです：プロバイダーを一度接続し、使いたいモデルをそれに追加し、それらのモデルを Kody のタスクにルーティングします。/organization/byok 画面には3つのタブがあります：

Providers

キーを使ってプロバイダーを接続し、それぞれで使うモデルを有効化します。カウントバッジは接続したプロバイダーの数を表示します。

Routing

各タスクを実行するモデルを選択します — すべてのタスク向けの1つのデフォルト、任意のフォールバック、エージェントごとのオーバーライド。

Budget

接続したモデル全体にわたる任意の月次支出上限を設定します。

編集できるユーザー。 BYOKページは Owner 専用です — キーの接続・テスト・削除には Owner ロールが必要です。他のロール(Billing Manager、Repo Admin、Contributor)は /organization/byok にアクセスできません。ワークスペースのロールを参照してください。

プロバイダーを接続する

BYOK 設定を開く

app.kodus.io/organization/byok にアクセスします。新しいワークスペースでは Connect your first provider が表示されます。

プロバイダーを選択

プロバイダーのグリッドは2つに分かれています：

Providers — APIキーだけで接続できるファーストクラスのプロバイダー（OpenAI、Anthropic、Google AI Studio、OpenRouter、Novita…）。
Custom — 独自のエンドポイントを指定したり任意のモデルを実行したりするプロバイダー：OpenAI-compatible、Anthropic-compatible、Google Vertex AI、Amazon Bedrock。これらには Custom endpoint のヒントが付いています。

すでに接続済みのプロバイダーには Connected · N models と表示されます。

モデルを追加

プロバイダーを選ぶと、その Add a model フォームが開きます。APIキーを一度貼り付けると（その後そのプロバイダーに追加する各モデルで再利用されます）、モデルを選択します：

Kodus がプロバイダーのモデルをリスト化できる場合、ドロップダウンが表示されます。
そうでない場合（カスタムエンドポイント、セルフホスト、またはプラットフォームキーが未設定の場合）、正確なモデル ID を入力します。

カスタムエンドポイント（OpenAI-compatible / Anthropic-compatible）では、まず base URL も求められます。

Advanced settings を調整（任意）

Advanced settings の下：thinking/reasoning、temperature、最大出力トークン、最大入力トークン、最大同時リクエスト数。デフォルト値はほとんどのプロバイダーで適切です — モデルごとに Kodus がロックまたは非表示にするフィールドについては Reasoning と Temperature を参照してください。

テストして保存

Test をクリックしてプロバイダーをプローブするか、Test & save をクリックしてテストを実行し成功時に保存します。キーは一度だけ貼り付ければよいので、プロバイダーには好きなだけモデルを追加できます。

別のプロバイダーを追加 するには、いつでも Providers タブから行えます。各プロバイダーは独自のキーを保持します。接続済みのプロバイダーでさらにモデルを有効化しても、キーを再度求められることはありません。

保存前にテストする

Test ボタンは、実際のレビューが壊れる前に設定を検証します。何を行うかはプロバイダーによって異なります：

プロバイダー	Test が行うこと
Anthropic-compatible ブランド（Kimi、Z.ai、DeepSeek）、OpenAI-compatible、Novita	正確なモデルに対して実際の 1トークンのチャットリクエストを送信します — レビューが行うのと同じ呼び出しです。誤ったモデル ID、制限されたキー、エンドポイントの問題をその場で検出します。
OpenAI、Anthropic、Google（Gemini/Vertex）、OpenRouter、Bedrock	安価な identity/metadata 呼び出し（list-models、トークン交換、または STS）— キーとエンドポイントが機能することを確認します。

チャットプローブのパスでは、Test は 設定したチューニングをモデル自身のルールに対しても検証 し、モデルがサイレントに無視する設定を保存する代わりに、早期に具体的なエラーを返します：

常に thinking するモデルが尊重しない temperature（1 に固定されます — Temperature を参照）。
常に reasoning し無効化できないモデルで reasoning を Off にした場合。

チャットプロバイダーは実際のモデルを実行するようになったため、モデル ID のタイプミスは最初のレビューではなく Test の時点で検出されます — レスポンスは Model not found で返ってきます。

ルーティング：各タスクを実行するモデル

2つ以上のモデルを接続すると、Routing タブがどのモデルが何を実行するかを決定します。ルーティングはフラットです：オーバーライドするまで、すべてのタスクがデフォルトを使用します。

Policy

Manual · you choose が現在有効です。Auto · Kodus optimizes は近日公開予定です。

Defaults

Model for all tasks — オーバーライドされない限り、すべてのタスクが使用する1つのモデル。
Fallback (optional) — タスクのモデルが失敗したときに Kody が呼び出しを一度だけ再実行する別のモデル：無効または期限切れのキー、クレジット不足、またはプロバイダーのダウン（プロバイダー自身のリトライの後）。

Per agent

さまざまな Kody タスク（コードレビュー、Kody Rules、チャット、要約など）は、それぞれ異なるモデルを実行できます — 深いレビューには高価なモデル、要約には安価なモデル。特定のタスクを実行できないモデルは、その行で無効化されツールチップが表示され、保存前に分かります。

Save routing をクリックして保存します。Reset agents to default は、すべてのエージェントごとのオーバーライドをデフォルトに戻し、フォールバックをクリアします（デフォルトモデル自体は保持されます）。下部の読み取り専用の Per repository パネルは、Code Review Settings で設定されたリポジトリごとのモデルオーバーライドを反映します。

接続済みのモデルが1つの場合、ルーティングはスキップされます — すべてのタスクがそのモデルを使用します。ルーティングを意味のあるものにするには、2つ目のモデルを接続してください。

モデルの選択

プロバイダーが提供する任意のモデルが利用できます。どこから始めればよいか分からない場合、これらはコードレビューに適した選択肢です：

Claude Sonnet / Opus

最良のバランス / フラッグシップ品質。 Anthropic の適応的な拡張思考と強力なクロスファイル分析。キー：console.anthropic.com。

Gemini Pro

最大のコンテキスト。 Google のフラッグシップ — 大規模な PR やモノレポで最強。キー：aistudio.google.com/apikey。

GPT (latest)

高速で一貫性がある。 OpenAI のフラッグシップライン — 信頼性の高い低レイテンシ、幅広い知識。キー：platform.openai.com/api-keys。

Kimi / GLM (coding plans)

サブスクリプションで最安。 Moonshot の Kimi と Z.ai の GLM は、月次支出を抑える定額のコーディングプランを提供しています。下記の Kimi と GLM の接続を参照してください。

デフォルトの推奨: 最良の全体的な体験には Claude Sonnet から始めましょう。コストが優先事項の場合、GLM Coding Plan または Kimi Code Plan が定額サブスクリプションを提供します。プロバイダーが文書化している正確なモデル ID を入力してください — Kodus はそこから表示名を導出します。

Kimi (Moonshot) と GLM (Z.ai) の接続

Moonshot と Z.ai はどちらも、ペイパートークンの Developer API とは 異なるエンドポイント のサブスクリプションプランを提供しています。各プランは独自のキーを持つ別々のアカウントです — 持っているキーに合ったベース URL を選択してください。

Kimi (Moonshot AI)
GLM (Z.ai)

プラン	エンドポイント	キーの取得元	最適な用途
Developer API	`https://api.moonshot.ai/v1`（OpenAI-compatible）または `https://api.moonshot.ai/anthropic`（Anthropic-compatible）	platform.moonshot.ai	ペイパートークン、同時実行数はリチャージティアとスケール
Kimi Code Plan	`https://api.kimi.com/coding/v1`	kimi.com/code	専用コーディングエンドポイント付きサブスクリプション

Kimi Code Plan は 30 concurrent リクエストの上限が文書化されています — maxConcurrentRequests=30 を設定してください。常に reasoning する Kimi バリアント（例：kimi-k2p7-code、kimi-k3）は temperature を 1 に固定し、reasoning をオフにできません — Temperature を参照してください。

プラン	エンドポイント	キーの取得元	最適な用途
Developer API	`https://api.z.ai/api/paas/v4/`	z.ai/manage-apikey	バースト的なワークロード、ペイパートークン
Coding Plan	`https://api.z.ai/api/coding/paas/v4`	z.ai/subscribe	予測可能なチーム使用量、定額月額料金

GLM Coding Plan のキーは /api/coding/paas/v4 でのみ動作します。Lite および Pro ティアはしばしば 1 concurrent リクエスト に制限されています — maxConcurrentRequests=1 を設定し、Max ティアの場合のみ（最大 30 まで）引き上げてください。

対応プロバイダー

おすすめの用途: 最新の GPT モデルと信頼性の高いパフォーマンス。APIキーの取得方法:

OpenAI API Keys にアクセス
Kodus 用の新しいキーを作成
請求情報を追加

ベータ。 単一キーが基本の他プロバイダーより認証の手順が複雑です。

こんな場合に： すでに Google Cloud を使っていて、既存の GCP の請求・IAM・データレジデンシー要件のもとで Gemini（または Claude）を使いたいチーム。設定方法：

接続フローでプロバイダーに Google Vertex AI（Custom の下）を選びます。
サービスアカウント JSON ファイルの中身を Service Account JSON 欄に貼り付けます（base64 でも可）。Kodus は JSON から project_id を自動で抽出します。
Region — グローバルエンドポイントを使う場合は空のままにします（推奨）。データレジデンシー要件がある場合のみ、リージョン（例：us-east5）を固定します。

サービスアカウントには、そのプロジェクトで Vertex AI の予測 API を呼び出す権限が必要です。Test は実際に設定されたモデルをプローブするため、利用できないモデル/リージョンは Test の時点で失敗します。

ベータ。 単一キーが基本の他プロバイダーより認証の手順が複雑です。

こんな場合に： AWS に標準化していて、モデルの利用料を自社の AWS アカウントで請求したいチーム。設定方法：

接続フローでプロバイダーに Amazon Bedrock（Custom の下）を選びます。
Bedrock API キー（ベアラートークン）を入力します — Bedrock API キーの生成方法を参照。
Region を設定します（例：us-east-1、us-west-2、eu-central-1）。

上級：API キーの代わりに IAM 認証情報を使う

Bedrock API キーへ移行していないチームは、Advanced — use IAM user credentials instead を開いて、静的なアクセスキー ID とシークレット（STS の一時認証情報の場合はセッショントークンも）を入力します。IAM プリンシパルには bedrock:InvokeModel が必要です。API キーが優先されます。ベアラートークンが設定されている場合、IAM の項目は無視されます。

おすすめの用途: 特化プロバイダー（Moonshot、Z.ai、Fireworks、Together、Groq、DeepSeek）またはセルフホストエンドポイント。設定方法:

接続フローで、プロバイダーとして OpenAI Compatible（Custom の下）を選択します。
ベース URL を入力します（例：https://api.moonshot.ai/v1、https://api.z.ai/api/paas/v4/、https://api.fireworks.ai/inference/v1）。
キーとモデル ID を提供します。

モデル ID はプロバイダー固有です — 一部はディープパスを使用します（例：Fireworks：accounts/fireworks/models/kimi-k2p7-code）。プロバイダーのダッシュボードから正確な ID をコピーしてください。Test は実際のリクエストを送信するため、誤った ID は即座に失敗します。

Z.ai (GLM) ガイド

Coding Plan の詳細を含む完全な Z.ai セットアップ。

Moonshot (Kimi) ガイド

Kimi + Kimi Code Plan のセットアップ。

Fireworks AI

Fireworks 固有のセットアップ。

Together AI

Together AI のセットアップ。

こんな場合に： OpenAI 形式ではなく Anthropic の Messages API を話すエンドポイント — Kimi のようなコーディングプランのエンドポイントを含みます。設定方法：

接続フローで Anthropic-compatible（Custom の下）を選びます。
ベース URL、キー、モデル ID を入力します。

ベース URL はプロバイダーが示す形式のまま貼り付けてください — 末尾の /v1 はあってもなくても構いません（例：https://api.kimi.com/coding または https://api.kimi.com/coding/v1）。Anthropic の 2 つの SDK 経路は /v1 の位置の解釈が異なるため、Kodus が内部で正規化します。既知のブランドの場合、キーのみの接続でエンドポイントが自動的に解決されます。

Reasoning / 拡張思考

Add a model フォームでは、Advanced settings の下に Thinking トグル（Off / Low / Medium / High / Custom）が表示されます。利用可能なオプションは、モデルが実際にできることを反映しています：

reasoning できないモデルは注記付きで Off に固定されます。
特定のレベルでのみ reasoning するモデル（例：GPT-5 の medium/high）は、無効なものを無効化します。
デフォルトで reasoning するモデルは、妥当な出発点として Medium が設定されます。

プリセットレベル

Low / Medium / High を選択すると、Kodus はそのレベルを各プロバイダーのネイティブフォーマットに自動的に変換します：

プロバイダー	”medium” のマッピング
Anthropic (Claude adaptive)	`thinking: { type: "adaptive" }` + `effort: "medium"`
Google (Gemini)	`thinkingConfig: { thinkingLevel: "medium" }`
OpenAI (GPT-5 / o-series)	`reasoningEffort: "medium"`
OpenRouter	`reasoning: { effort: "medium" }`
OpenAI-compatible / Anthropic-compatible (Kimi, GLM, DeepSeek)	`thinking: { type: "enabled" }` — バイナリの on/off、レベルは無視

Kimi と GLM は現在、reasoning を単一の on/off フラグとして公開しています。Low、Medium、High のいずれを選んでも同じペイロード（thinking 有効）を生成します。常に reasoning するバリアント（Kimi k2p7-code/k3、GLM-5.3）は無条件に reasoning します — Off にできず、フォームはそのオプションを無効化します。

カスタム JSON オーバーライド

Thinking トグルで Custom を選択すると JSON テキストエリアが表示されます。プロバイダーオプションを直接貼り付けてください — Kodus がアクティブなプロバイダーの名前空間の下に自動でラップします。Vercel AI SDK のルーティングルールを知る必要はありません。以下の場合に使用します：

Claude に特定の budgetTokens 値が必要な場合（プリセットの effort マッピングの代わり）
OpenAI 互換プロバイダーでモデルごとに thinking を有効/無効にしたい場合
reasoning 以外のフィールドが必要な場合 — キャッシュ、サービスティア、safety settings、user タグなど。オーバーライドは providerOptions にマージされるため、アダプターの任意のフィールドがそのまま通過します
Kodus がまだラップしていない新しいフィールドがプロバイダーに追加された場合

例（名前空間不要 — そのまま貼り付け）

Anthropic
Google Gemini
OpenAI
OpenRouter
OpenAI-compatible (Kimi、GLM など)

Claude の thinking 予算を正確に 20,000 トークンにオーバーライド：

{
  "thinking": { "type": "enabled", "budgetTokens": 20000 }
}

プロンプトキャッシュを有効化（reasoning 以外の例）：

{
  "cacheControl": { "type": "ephemeral" }
}

明示的な thinking 予算（Gemini 2.5）またはレベル（Gemini 3+）：

{
  "thinkingConfig": { "thinkingBudget": 16000 }
}

safety settings を調整：

{
  "safetySettings": [
    { "category": "HARM_CATEGORY_DANGEROUS_CONTENT", "threshold": "BLOCK_NONE" }
  ]
}

OpenAI 固有のフィールドを伴う reasoning：

{
  "reasoningEffort": "high",
  "serviceTier": "flex",
  "store": false,
  "user": "kodus-review"
}

reasoning を強制しつつ特定の上流を無視：

{
  "reasoning": { "effort": "high" },
  "ignore": ["deepinfra"]
}

予算ヒント付きで thinking を有効化：

{
  "thinking": { "type": "enabled", "budget_tokens": 25000 }
}

thinking を明示的に無効化（それをサポートするモデルでのみ）：

{
  "thinking": { "type": "disabled" }
}

上流プロバイダーが認識しないフィールド（例：それを無視するサーバー上の budget_tokens）はサイレントに破棄されます。プロバイダーのドキュメントを確認して受け入れるものを確認してください。

名前空間を手動で指定する（上級者向け）

JSON がすでに既知の名前空間キー（下記のマッピング表のいずれかのキー）でトップレベルから始まっている場合、Kodus はそれをそのまま残します。複数のプロバイダー名前空間を混在させたい場合や、明示的に記述したい場合に便利です：

{
  "openrouter": {
    "reasoning": { "effort": "high" },
    "provider": { "order": ["moonshot"], "allow_fallbacks": false }
  }
}

内部的に、Kodus は以下の名前空間マッピングを使用しています：

BYOK プロバイダー	名前空間キー
`anthropic` / `anthropic_compatible`	`anthropic`
`google_gemini`	`google`
`google_vertex`	Gemini は `google`、Vertex 上の Claude は `anthropic`
`openai`	`openai`
`openai_compatible`	`openaiCompatible`
`azure`	`azure`
`amazon_bedrock`	`amazonBedrock`（`bedrock` も可）
`novita`	`novita`
`open_router`	`openrouter`

注意点

有効な JSON のみ。 カンマの欠落や末尾のカンマはパースを壊し、Kodus はオーバーライドを無視します。
優先順位: JSON オーバーライドは effort プリセットの名前空間ブロックを完全に置き換えます — anthropic.thinking をオーバーライドしつつ anthropic.effort を忘れると、そのフィールドは送信されません。OpenRouter routing（Pin providers / Allow fallbacks）は唯一の例外で、openrouter の下でオーバーライドとディープマージされます。
未知のプロバイダー = ラップなし。 BYOK プロバイダーが上記の名前空間テーブルにない場合、Kodus は JSON をそのまま通過させます。

Temperature

Temperature は Advanced settings の下にあり、フィールドはモデルのルールに適応します — フォームが推測するのではなく、プロバイダーによって設定されます：

モデル	Temperature フィールド
ほとんどのモデル	編集可能（0 = 決定的、2 = 創造的）。
常に reasoning する Anthropic プロトコルのモデル（Kimi `k2p7-code`/`k3`、GLM-5.3）	`1` に固定。このプロトコルは thinking 中に temperature を 1 に固定するため、1 が唯一の妥当な値です — フィールドにはロックが表示され、保存された値に関わらず Kodus は `1` を送信します。
Claude 4.7+ および OpenAI GPT-5 / o-series	非表示。これらのモデルは temperature を廃止し、それを設定するリクエストを拒否します — 代わりに thinking レベルで調整してください。

チャットプローブのプロバイダーでは、Test が設定した temperature をこれらのルールに対して検証し、保存前にエラーを返します — モデルが尊重しない値を保存することは決してありません。

OpenRouter プロバイダーの固定

OpenRouter はルーターです — モデル（例：moonshotai/kimi-k2）をリクエストすると、複数の上流プロバイダー（Moonshot 直接、Together、Groq、Fireworks、Novita…）のいずれかに呼び出しを転送します。呼び出しごとに異なるバックエンドに着地する可能性があります。便利ではありますが、サイレントな変動を招きます：

品質ドリフト — 上流は異なる精度（FP8、INT4、full）で動作し、同じプロンプトに対して微妙に異なる出力を返します
ツール呼び出しの不整合 — 一部のバックエンドは関数呼び出しを同じ方法でサポートせず、不正な tool use を引き起こします
Reasoning フォーマットの変動 — ある上流は reasoning_effort を尊重し、別の上流は thinking.enabled のみ、また別の上流は両方を無視します
レイテンシの揺れ — ルーティングが変わると p50 が 800ms から 4s に跳ね上がることがあります
レート制限の意外な発生 — 明示的に選んでいないバックエンドでクォータにヒットします

固定する方法

BYOK プロバイダーが OpenRouter の場合、Advanced settings パネルに2つのフィールドを持つ OpenRouter routing セクションが表示されます：

Pin providers (in order) — 上流名のカンマ区切りリスト（例：moonshot, together）。OpenRouter は順番に試し、最初に利用可能なものを使用します。
Allow fallbacks — オフの場合、固定されたプロバイダーのいずれも利用できないとリクエストはハードフェイルします。オン（デフォルト）の場合、OpenRouter はそのモデルを提供する他の任意の上流にフォールバックできます。

安定した構成のためには、単一のプロバイダーを固定し、フォールバックをオフにします（Pin: moonshot、Allow fallbacks: off）。リクエストは常に同じ上流に到達するか、明示的に失敗します — サイレントな品質変動はありません。トレードオフは、その1つの上流がダウンした場合に回復力がゼロになることです。障害を吸収するために、異なる Routing Fallback（例：Anthropic）と組み合わせてください。

上流名は OpenRouter のカタログと一致している必要があります。プロバイダータグを openrouter.ai/docs/features/provider-routing で確認してください — 一般的な値には moonshot、together、groq、fireworks、novita が含まれます。

内部的に、Kodus は Vercel AI SDK 呼び出しに次のように出力します：

{
  "openrouter": {
    "provider": {
      "order": ["moonshot", "together"],
      "allow_fallbacks": false
    }
  }
}

上級者向け：生の JSON オーバーライド

order と allow_fallbacks 以外のフィールド（例：ignore、data_collection、require_parameters）が必要な場合は、Advanced settings で Thinking を Custom に切り替え、完全なルーティングペイロードを貼り付けます — 任意の reasoning 設定と並んで providerOptions にマージされます：

{
  "openrouter": {
    "provider": {
      "order": ["moonshot"],
      "allow_fallbacks": false,
      "ignore": ["deepinfra"],
      "data_collection": "deny"
    },
    "reasoning": { "effort": "medium" }
  }
}

同時実行数とレート制限

maxConcurrentRequests フィールド（Advanced settings の下）は、Kodus がプロバイダーに並行して送信するインフライトリクエストの数を制限します。ほとんどの場合、デフォルトで問題ありません — ただし、厳密な同時実行上限があるサブスクリプションプランでは明示的に設定する必要があります。

設定する値

プロバイダー / プラン	値	理由
GLM Coding Plan (Lite/Pro)	`1`	サブスクリプションは1つのインフライトリクエストのみ許可。それ以上は 429 をトリガー。
GLM Coding Plan (Max)	最大 `30`	Max は最大 30 の同時実行を許可 — フル予算を使うにはここで引き上げてください。
Kimi Code Plan	`30`	Moonshot のコーディングエンドポイントで文書化された上限。
GLM Developer API	(空)	制限はキーごとにスケール；適切なグローバルデフォルトはありません。
Kimi Developer API	(空)	リチャージティアとスケール（Tier 1 ≈ 50、Tier 5 ≈ 1000）。
Anthropic / OpenAI / Google / OpenRouter	(空)	プロバイダーは独自の TPM/RPM を適用；Kodus は制限しません。

チューニングのタイミング

上げる

Moonshot/OpenRouter で高ティアのリチャージがあり、大きな PR でより高いスループットが欲しい
GLM Coding Plan を Max に上げ、30-concurrent の予算をフル活用したい
マルチファイル PR でレビューがシリアル化されていると感じ、429 が発生していない

下げる

レビューログに 429 や Too much concurrency エラーが見られる
プロバイダーがダッシュボードでレート制限について警告している
より多くの PR にわたって Coding Plan のウィンドウ（5時間/週次）を節約したい

同時実行数 vs. RPM vs. TPM。 maxConcurrentRequests は並行するインフライトリクエストのみを制限します。多くのプロバイダーは、別の RPM（1分あたりのリクエスト数）や TPM（1分あたりのトークン数）制限も適用します。同時実行数は問題ないのに RPM/TPM にヒットしている場合、通常の対処法はティアをアップグレードするか、時間をかけて負荷を分散することです — maxConcurrentRequests を変更することではありません。

フォールバックとの相互作用。 タスクのモデルが 429 にヒットし、Kody が Routing Fallback にフェイルオーバーするとき、フォールバック自身の maxConcurrentRequests が適用されます。異なるプロバイダーに寛大なフォールバックを設定することは、メインのモデルがタイトなサブスクリプション上にある場合にバーストを吸収する良い方法です。

ベストプラクティス

セキュリティ

専用キー

Kodus 用の別の APIキーを作成します。使用状況の監査とキーのローテーションが容易になります。

定期的なローテーション

定期的にキーをローテーションし、BYOK 設定で更新します。

使用状況の監視

異常なパターンがないか、プロバイダーのダッシュボードを確認します。

安全な保管

キーをリポジトリにコミットしないでください。Kodus は保存時および転送時に暗号化して保存します。

ルーティング戦略

デフォルトとフォールバックには異なるプロバイダーを使用します（例：Anthropic デフォルト、Google フォールバック）。プロバイダー固有の障害から保護します。
厳しい同時実行制限のあるサブスクリプション（GLM Coding Plan Lite/Pro、Kimi Code Plan）は単独の構成としては適していません — バースト的な PR が枯渇しないよう、ペイパートークンのフォールバックとペアにします。
重いタスク（深いコードレビュー）を最も強力なモデルに、軽いタスク（要約、チャット）を安価なモデルに Per agent でルーティングします。

トラブルシューティング

Test クリック時の 'Invalid API key'

余分なスペース、引用符、末尾の改行なしでキーをコピーします。
請求が有効になっており、アカウントにクレジットがあることを確認します。
GLM Coding Plan / Kimi Code Plan のキーについては、base URL がプランと一致していることを確認してください — サブスクリプションキーは Developer API エンドポイントでは動作せず、その逆も同様です。

Test クリック時の 'Model not found'

チャットプローブのプロバイダー（Anthropic-compatible、OpenAI-compatible、Novita）では、Test はモデルに実際のリクエストを送信するため、誤った、またはスペルミスのモデル ID はここで失敗します — これは想定された動作であり、レビュー時に失敗するよりも優れています。
プロバイダーのダッシュボードから正確なモデル ID をコピーしてください。一部のプロバイダーはディープパス（例：Fireworks accounts/fireworks/models/kimi-k2p7-code）を使用したり、バージョンの綴りが異なったり（k2p7 対 k2.7）します。

Test クリック時の 'Endpoint not found'

ベース URL がプロバイダーと正確に一致していることを確認します（一部では末尾のスラッシュが重要です）。
OpenAI 互換プロバイダーの場合、エンドポイントは通常 {baseURL}/chat/completions です（Kodus がパスを追加します）。

Test が設定した temperature または reasoning を拒否する

一部のモデルは temperature を固定したり常に reasoning したりします（Kimi k2p7-code/k3、GLM-5.3；Claude 4.7+/GPT-5 は temperature を完全に廃止）。Test はチューニングをモデルのルールに対して検証し、具体的なメッセージを返します — それに従ってください（temperature を未設定のままにするか、必要な値を使用し、常に reasoning するモデルで reasoning を Off にしないでください）。Temperature を参照してください。

'Rate limited' または 'Too much concurrency'

Advanced settings で Max concurrent requests を下げます。
GLM Coding Plan Lite/Pro では 1 concurrent を維持します。より高いスループットが必要な場合は Max（30 concurrent）にアップグレードしてください。
Kimi Code Plan では文書化された上限は 30 concurrent です。

セルフホスト環境変数が表示されない

Kodus が .env（セルフホスト Fixed Mode）で設定されている場合、BYOK 画面はアクティブなプロバイダー/モデルを表示する青い情報バナーを表示します — セキュリティのためキーは決して表示されません。
モデルを接続して保存すると、.env の設定がオーバーライドされます。

予想外の高コスト

Reasoning はトークンを追加します。コストが急増している場合、Thinking を Medium から Low に下げるか、重いタスクを Per agent で安価なモデルにルーティングしてください。
プロバイダーのダッシュボードでモデルごとの内訳を確認し、Budget タブで上限を設定します。

よくある質問

いつでもプロバイダーを切り替えられますか？

はい。変更は次のレビューに有効になります — 再デプロイは不要です。

APIキーのクレジットがなくなった場合はどうなりますか？

フォールバックが設定されている場合、レビューは自動的に Routing Fallback に切り替わります。フォールバックがない場合、レビューは失敗してエラーを返します。常にフォールバックを設定してください。

デフォルト / フォールバックシステムはどのように機能しますか？

すべてのタスクは、Routing でエージェントごとにオーバーライドしない限り、デフォルトモデルを使用します。タスクのモデルが失敗した場合（レート制限、5xx、タイムアウト、無効なキー）、Kody はフォールバックで一度再試行します。実際に呼び出しを処理したプロバイダーに対してのみ支払います。

異なるタスクで異なるモデルを使用できますか？

はい — それが Routing → Per agent の目的です。深いコードレビューを強力なモデルに、要約やチャットを安価なモデルにルーティングします。ルーティングを意味のあるものにするには、少なくとも2つのモデルを接続する必要があります。

APIキーは安全に保管されますか？

はい。キーは保存時および転送時に暗号化され、平文でログに記録されることはありません。BYOK ステータスエンドポイントは生のキーを返しません。

セルフホスト LLM（例：Ollama、vLLM）を使用できますか？

はい — OpenAI Compatible プロバイダー（Custom の下）を介して使用できます。エンドポイントのベース URL、公開しているモデル ID、およびプレースホルダーの APIキーを入力します（ほとんどのセルフホストランタイムはキーヘッダーを無視しますが、依然として必要です）。

プランとの対応関係

​BYOK の仕組み

Providers

Routing

Budget

​プロバイダーを接続する

​保存前にテストする

​ルーティング：各タスクを実行するモデル

​モデルの選択

Claude Sonnet / Opus

Gemini Pro

GPT (latest)

Kimi / GLM (coding plans)

​Kimi (Moonshot) と GLM (Z.ai) の接続

​対応プロバイダー

Novita セットアップガイド

Z.ai (GLM) ガイド

Moonshot (Kimi) ガイド

Fireworks AI

Together AI

​Reasoning / 拡張思考

​プリセットレベル

​カスタム JSON オーバーライド

​例（名前空間不要 — そのまま貼り付け）

​名前空間を手動で指定する（上級者向け）

​注意点

​Temperature

​OpenRouter プロバイダーの固定

​固定する方法

​上級者向け：生の JSON オーバーライド

​同時実行数とレート制限

​設定する値

​チューニングのタイミング

上げる

下げる

​ベストプラクティス

​セキュリティ

専用キー

定期的なローテーション

使用状況の監視

安全な保管

​ルーティング戦略

​トラブルシューティング

​よくある質問

BYOK の仕組み

プロバイダーを接続する

保存前にテストする

ルーティング：各タスクを実行するモデル

モデルの選択

Kimi (Moonshot) と GLM (Z.ai) の接続

対応プロバイダー

Reasoning / 拡張思考

プリセットレベル

カスタム JSON オーバーライド

例（名前空間不要 — そのまま貼り付け）

名前空間を手動で指定する（上級者向け）

注意点

Temperature

OpenRouter プロバイダーの固定

固定する方法

上級者向け：生の JSON オーバーライド

同時実行数とレート制限

設定する値

チューニングのタイミング

ベストプラクティス

セキュリティ

ルーティング戦略

トラブルシューティング

よくある質問