アダプター

アダプターは opencodex の内部リクエスト/レスポンスモデルとプロバイダーの wire 形式の間を変換します。すべてのアダプターは ProviderAdapter インターフェース（src/adapters/base.ts）を実装します。

interface ProviderAdapter {
  name: string;
  buildRequest(parsed, incoming?): AdapterRequest | Promise<AdapterRequest>;
  fetchResponse?(request, context): Promise<Response>;   // custom retry/transport
  parseStream(response): AsyncGenerator<AdapterEvent>;
  parseResponse?(response): Promise<AdapterEvent[]>;   // non-streaming
  runTurn?(parsed, incoming, emit): Promise<void>;      // bidirectional transport
}

buildRequest は OcxParsedRequest を上流の HTTP リクエストに落とし、parseStream / parseResponse はプロバイダーのレスポンスを内部 AdapterEvent に持ち上げます。fetchResponse があると、アダプターがリトライとタイムアウトを直接担います。runTurn は 1 回の HTTP fetch とその後のレスポンスストリームでは表現できない伝送方式をサポートします。その後 bridge.ts がイベントを Responses SSE に変えます。

`openai-chat`

対象: OpenAI Chat Completions（POST {baseUrl}/chat/completions）および互換プロバイダー — xAI、Kimi、DeepSeek、GLM、Groq、OpenRouter、Ollama（ローカル）など。 認証: key（Bearer）。

内部メッセージを OpenAI role に変換し、ツールは {type:"function", function:{…}} と tool_choice（auto/none/required または指定関数）にマッピングします。
ツール結果内の画像は、role:"tool" がテキスト専用のため、ツールラウンドが閉じた後に後続の user vision メッセージ（image_url パート）として送られます。ツールメッセージ側には [image] マーカーがアンカーとして残ります。
Codex の GPT-5 アイデンティティプロンプトを書き直し、モデル中立な紹介に変えます。そのためルーティングされたモデルが自分を OpenAI だと主張しません。
正確な段階がないときは reasoning_effort をモデルが公表したサブセットに合わせて調整します。プロバイダーが明示的に alias を設定しない限り、xhigh と max は異なるラベルのまま保ちます。provider.noReasoningModels に含まれる id には値を 一切送りません。
delta.content（テキスト）、delta.reasoning_content（thinking）、delta.tool_calls[] をストリーミングし、usage を収集します。
ClinePass は、ライブ検証済みのゲートウェイ形式 reasoning: { enabled: true, effort } （reasoning を無効にする場合は { enabled: false }）を使用します。公開 API ドキュメントには現在このリクエスト形式が明記されていません。アダプターは要求された low、medium、high、 xhigh、max tier をそのまま保持し、delta.reasoning_content または delta.reasoning を reasoning delta として扱い、stream_options.include_usage でストリーム usage を要求し、非ストリームのレスポンス envelope からも usage を読み取ります。

`ollama-native`

対象： OpenAI 互換サーフェスではなく、Ollama 自身の Chat API（POST /api/chat）。組み込みの ollama-cloud プロバイダーはこの adapter にレジストリで選択され、別名のカスタム / セルフホスト Ollama プロバイダーに adapter: "ollama-native" を設定して使うこともできます。 認証： cloud / カスタム宛先は key（Bearer）。loopback または authMode: "local" の宛先には資格情報を送りません。

レジストリ選択が実質的に効きます。 組み込みの ollama-cloud 行は /v1/models によるライブ探索のため https://ollama.com/v1 を維持しつつ、推論は POST https://ollama.com/api/chat に正規化されます。このプロバイダー行では設定した adapter は破棄されます。通常の組み込みローカル Ollama は openai-chat のままです。ローカル / セルフホスト宛先に ollama-native を選ぶのは、プロバイダー設定での明示的な判断であり、ホストで判定されるため非 Ollama 宛先が黙って書き換えられることはありません。
モデルメタデータ： /v1/models にはモデルごとのメタデータがないため、正規の Ollama Cloud では 上限付き の POST /api/show（応答 256 KiB、1 要求 8 秒、並列 4、48 要求、フェーズ全体に 12 秒の締切）で発見された各 id を補完し、実際の context window と vision 対応を取得します。show 要求は同一オリジンでリダイレクトを追わず、失敗してもその 1 モデルだけが劣化し、発見自体は失敗しません。
ストリーミング： Ollama ネイティブの NDJSON。テキストと message.thinking の delta を到着順に転送し、done: true の終端レコードでのみターンを完了します。buffer された done: false や終端の欠落では部分的なテキストも tool call も一切出力しません。
Reasoning： Ollama ネイティブの think フィールド（low / medium / high / max と boolean）に対応し、モデルの公開 ladder へクランプし、上流で設定された __omit__ sentinel の意味論に従います。
画像： vision 対応モデルではメッセージの images 配列でネイティブ送信します。video は誤送信ではなく拒否され、リモート画像 URL の取得は行いません。
ツール： Ollama のネイティブ形状で宣言し、ストリームされる tool call は arguments がオブジェクトの whole-call レコード、tool result のリプレイは call id と tool 名で厳密に対応付けられます。tool_choice: "none" と auto は通常どおりです。required や名前指定は fail closed です。Ollama の /api/chat にはそれを強制できる tool_choice フィールドがありません。
構造化出力は正規の Ollama Cloud では拒否されます。 Ollama は Cloud で構造化出力が未対応であると現在ドキュメントしており、Cloud は format フィールドを強制しません。そのため OpenCodex は、schema 指定の要求に対して自由文を返すのではなく、要求を閉じて失敗させます。ローカル / カスタムの ollama-native エンドポイントは Ollama ネイティブの format マッピング（json_object → "json"、json_schema → schema オブジェクトそのもの）を保持します。

`openai-responses`

対象: OpenAI Responses API。passthrough: true — 通常は元のリクエストとレスポンスをそのまま渡し、ルーティング先ゲートウェイに必要な限定的な互換変換だけを適用します。 認証: canonical OpenAI forward は安全な呼び出し元ヘッダー許可リストだけを中継します。非 canonical な forward は呼び出し元の authorization を中継せず、設定済みの静的ヘッダーだけを使用します。key は設定済み provider key を使用します。

非 canonical な Responses ゲートウェイには、Codex のクライアント実行型 tool_search 宣言を既存の公開 function tool と衝突しない名前で送り、対応するリクエスト履歴と JSON/SSE function call をクライアント向けの非公開 tool_search ライフサイクルに復元します。 canonical OpenAI forward はネイティブな非公開型を維持します。

key 認証では、retryOn429 もここに適用されます: プリストリームの 429 は、翻訳された openai-chat / Anthropic リクエスト経路と同様に、他の処理やフェイルオーバーに先立って、同じキーで同一リクエストを待機して再送します。カスタム runTurn トランスポートは HTTP リトライループの対象外です。

DeepSeek のステートレス Responses パーサーは、プロバイダーにスコープされた履歴正規化を受けます: フックで注入されたコンテキストは、あいまいさのない tool-call/result バッチの後に移動します。並列呼び出しは、それぞれの出力の前にグループ化されたままなので、すべての呼び出しが推論を含むアシスタントターンにとどまります。寛容なプロバイダーと、重複・欠落・順序不正の call ID は元の入力順を保持します。
forward URL → {baseUrl}/responses。key provider はデフォルトで従来の {baseUrl}/v1/responses 構築を使います。
key provider は検証済みの相対 responsesPath を設定できます。adapter は baseUrl 末尾の / を 1 つ除き、{trimmedBaseUrl}{responsesPath} に送信します。Ark Agent Plan では baseUrl: "https://ark.cn-beijing.volces.com/api/plan/v3" と responsesPath: "/responses" を使います。
forward モードでは安全なヘッダー許可リスト（FORWARD_HEADERS）だけを中継します。authorization、ChatGPT account id、OpenAI beta/originator/session ヘッダーが対象です。この ChatGPT ログイン経路はサイドカーにも使われます。

`anthropic`

対象: Anthropic Messages（/v1/messages）。 認証: key（デフォルトは x-api-key、または apiKeyTransport: "bearer" による Authorization: Bearer）または oauth（Bearer + anthropic-beta、Claude Pro/Max 用）。

メッセージを Anthropic content block（text、base64 image、tool_use、thinking）に変換します。
Extended thinking の計算: Anthropic は max_tokens > thinking.budget_tokens を要求します。アダプターは reasoning effort を budget にマッピングし（minimal 1024 … max 32000）、出力余裕を取った安全な max_tokens を計算します。thinking がオンのときは Anthropic が禁止する temperature/top_p を削除します。
adaptive thinking の表示: adaptive thinking モデル（Opus 4.7+、Sonnet 5、Fable）には thinking.display: "summarized" を送るため、長い思考は数分間の heartbeat ではなく reasoning delta として Chat と Responses のクライアントに届きます。reasoning の要約を隠すリクエスト（reasoning.summary: "none"）はプロバイダーの既定値を維持します。
常に anthropic-version: 2023-06-01 を送ります。content_block_delta（text_delta、 thinking_delta、input_json_delta）をストリーミングします。

`google`

対象: Google Gemini、Vertex AI、Antigravity Cloud Code Assist。AI Studio は /v1beta/models/{model}:streamGenerateContent、それ以外のモードはそれぞれ Google ネイティブエンドポイントを使います。 認証: googleMode に応じて API キー、Vertex ADC、Google Antigravity OAuth のいずれかを選びます。

システムプロンプト → systemInstruction；メッセージ → contents[]（assistant → model）；ツール → functionDeclarations。data URL 画像 → inline_data。
Gemini が tool-call id を省略すると合成します。Vertex と Antigravity では不透明な thoughtSignature 値を保存・再利用し、tool-result の継続ターンでも reasoning の連続性を保ちます。署名キャッシュは設定ディレクトリにスナップショットされるため、プロキシ再起動後も継続ターンを維持できます。

`kiro`

対象: Kiro が使う Amazon CodeWhisperer Streaming GenerateAssistantResponse サービス（https://runtime.{region}.kiro.dev/）。 認証: Kiro 認証情報の region/profile メタデータと Kiro OAuth access token（Bearer）。

Kiro の conversationState を作り、Codex ツールとツール結果をマッピングし、Kiro wire が対応する画像 block を送ります。
application/vnd.amazon.eventstream をデコードして text/thinking/tool イベントを復元し、途切れたツール JSON を検出します。上流がトークン数を返さないため使用量は推定します。
fetchResponse で限られた回数だけリトライし、エラーを分類/マスクします。非ストリーミングパーサーはウェブ検索ループのために同じイベントストリームを最後まで消費します。

完了とネイティブ stop reason

Kiro のアシスタントテキストには、それ自体で end-turn を示す信頼できる区別がありません。ただし終端の metadataEvent がネイティブの stopReason を運ぶことがあります。END_TURN または STOP_SEQUENCE は終了した推論であることは示しますが、進捗文にも付く場合があるため、ツール有効ターンではそのテキストだけを最終回答にしません。通常テキストは commentary のまま、非公開の完了ツールを一度検証します。

END_TURN、STOP_SEQUENCE、または stop reason が無い場合は一度だけ完了互換パスに入れます。それ以外の明示的な理由はすでに上流で推論を終了させているため、もう一度モデルに投げ直すのではなくそのまま報告します。出力トークン上限は継続可能な incomplete、コンテキストウィンドウの枯渇は再試行不可の context-length エラー、フィルタリングやガードレールによる停止は filtered incomplete になります。実際のツール呼び出しを伴わない TOOL_USE は進捗ではなく矛盾として扱います。

ツール有効ターンでは非公開の codex_kiro_final_answer を追加します。再試行は空の assistant/user ターンを生成せず、元の user/tool-result を保持し、送信前にロール交互性、空の構造メッセージ、tool use/result の対応を検証します。完了ツールの回答は以前の commentary と同じでも final_answer として送出します。ユーザーしか出せない判断・情報・確認が得られず先に進めない場合も、その質問を完了ツールで送って停止するよう契約が指示します。これも commentary ではなくターンを終えた final_answer として届きます。

Reasoning effort

GPT-5.6 系は additionalModelRequestFields.reasoning.effort、claude-opus-5 は additionalModelRequestFields.output_config.effort を使用します。gpt-5.6-luna と gpt-5.6-terra では、検証済みの low、medium、high、max だけをネイティブフィールドで送信します。両モデルの xhigh は未検証のため、従来の上限付き thinking 指示によるエミュレーションを維持します。 gpt-5.6-sol と claude-opus-5 の既存のネイティブ段階（low、medium、high、xhigh、max）は変更しません。その他の Kiro モデルはエミュレーションを使用し、effort の選択肢だけではネイティブ対応を意味しません。

`cursor`

対象: デフォルトでは api2.cursor.sh の HTTP/2 Connect ストリーミング agent.v1.AgentService/Run。upstreamHttpVersion: "http1.1"（または "h1"）では Cursor の HTTP/1.1 互換トランスポートを使い、サーバー出力を agent.v1.AgentService/RunSSE、クライアントメッセージを aiserver.v1.BidiService/BidiAppend で送受信します。この設定は inference と live model discovery の両方に適用されます。 認証: provider.apiKey または転送された authorization ヘッダーの Cursor OAuth/access token。

通常の fetch/parse 経路の代わりに runTurn を使います。リクエスト、サーバーイベント、ツール引数、使用量 checkpoint、クライアントレスポンスは cursor/gen/agent_pb.ts の @bufbuild/protobuf スキーマでエンコードしたのち Connect メッセージとして framing します。
content-addressed blob で対話状態を再生し、サーバーツール呼び出しを Codex に再マッピングします。protobuf の GetUsableModels RPC でリアルタイム Cursor モデルを探し、run リクエストが wire に commit される前だけリトライします。
ツールなしで正常終了したターンでは、返された ConversationStateStructure をプロセスローカルに保持し、検証済みの線形継続で checkpoint を再利用します。tool-result ターンでは、対象メッセージ境界が判明している場合、最後に正常終了したターンの checkpoint に未収録の suffix だけを追加します。ref のない prefix lookup は、記憶済みの Cursor conversation または安定した client thread（制限付きの Desktop session/thread fallback を含む）があり、同じ provider conversation が所有する checkpoint が一意に一致する場合だけ許可します。それ以外は full replay に戻ります。compaction、helper/shadow の分離、account/model の不一致、ref の欠落、decode の失敗、forced-fresh recovery、invalid_argument retry でも full replay を使います。プロセスを再起動するとメモリ内 store は失われ、full replay になります。Cursor Connect は権威ある cache_read_tokens を公開しないため、OpenCodex usage は cache-hit counter ではありません。制限付き Desktop fallback が保存するのはプロセスローカルで HMAC から導出した owner だけで、raw session/thread header や OAuth/authorization material を checkpoint state に書き込みません。OAuth-backed live transport とアカウントで絞り込む live model discovery は実験的です。ログインと transport の設定は provider guide と Cursor provider configuration を参照してください。checkpoint reuse 自体は自動で、ユーザー設定はありません。
cursor/grok-4.5-fast は選択可能なモデルとして維持しつつ、Cursor には正規の grok-4.5 モデルを送信し、個別の effort および fast=true 値は requested_model.parameters に格納します。
Cursor ネイティブのローカルファイルシステム/shell/network 実行はデフォルトで拒否します。明示的な mcpServers と desktopExecutor 統合はそれぞれ別の opt-in です。nativeLocalExec: "on" はより広い組み込み executor を有効にし、Codex の承認/サンドボックスルールを迂回します。従来の unsafeAllowNativeLocalExec: true は、nativeLocalExec が設定されていない場合にのみ同等です。

`devin`

対象: Cognition の exa.api_server_pb.ApiServerService/GetChatMessage（server.codeium.com、Connect ストリーミング）。 認証: provider.apiKey または転送された authorization ヘッダーの Devin/Cognition API キー。ログインはまず、インストール済み Devin CLI が保持する認証情報の取り込みを試みます。devin auth login は CLI 自身の PKCE サインインを完了し、devin-session-token を CLI の credentials.toml に書き込みます。これは SeatManagementService.RegisterUser がブラウザサインインに発行するものと同じ資格情報です。利用できる CLI 資格情報がない場合は Auth0 のブラウザサインインにフォールバックし、貼り付けたトークンを RegisterUser で長期キーに交換します。devin-cli は非推奨エイリアスとして残るだけで、ocx login devin-cli も devin にルーティングされ、旧 id で保存された設定は起動時に書き換えられます。

通常の fetch/parse ではなく runTurn を使います。リクエストとサーバーイベントは devin/cloud-direct/wire.ts の手動 protobuf フレーミングで扱います。
GetCascadeModelConfigs でアカウントごとにモデルを取得し、プランに含まれないモデルはリクエスト時ではなく一覧の段階で外れます。
Cognition はツール説明の長さ制限と完全一致のブロックリストを課します。アダプターが既知の語句を書き換え、長すぎる説明を切り詰めます。
キーは更新されません。失効したら ocx login devin をやり直してください。
CLI インポート経路でもローカルなのは資格情報だけで、ターン自体はどちらの経路でも Cognition へ送られます。以前のビルドには devin-cli id で、ローカルの devin acp 子プロセスに対して Agent Client Protocol セッションとしてターンを実行する第2のアダプターがありましたが、削除されました。そのアダプターをまだ指す保存済み設定は起動時に devin へ書き換えられ、"devin-acp" のようなカスタム名の行も同様です。

`azure-openai`（別名: `azure`）

対象: Azure OpenAI。openai-responses を包むため、同じく passthrough: true です。 認証: api-key ヘッダーの key（Bearer ではない）。

リクエスト構成は Responses passthrough に任せます。baseUrl に未解釈のテンプレート placeholder がないか検証し、Authorization を api-key に差し替えます。設定 URL が Azure v1 Responses API を直接指すため、api-version は追加しません。
別のプロバイダーが生成した推論状態に対する Responses の復旧を共有します。400 invalid_encrypted_content を受けると、その状態（暗号化コンテンツと推論アイテムの rs_… ID）を除いて一度だけ再送します。

画像ユーティリティ（`image.ts`）

画像を扱うアダプターが一緒に使うヘルパーです。

parseDataUrl(url) — data:<type>;base64,<data> URL を { mediaType, base64 } に分け、Anthropic/Google の画像 block に使います。
contentPartsToText(content) — テキスト専用ツールメッセージのために content part をテキストに平坦化します。説明のない画像はトークンを増やす base64 blob の代わりに短い [image] marker になります。

アダプター

openai-chat

ollama-native

openai-responses

anthropic

google

kiro