> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokenlab.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenCodex

> モデル固有のAPIルーティングを備えたOpenCodexを通じてCodexをTokenLabに接続する

## エージェントにセットアップを任せる

コンピューター上で既に実行されているエージェントに次のタスクをコピーしてください：

```text theme={null}
Read https://docs.tokenlab.sh/ja/integrations/opencodex and help me connect OpenCodex to TokenLab.
Check my installed OpenCodex and Codex versions, active configuration, and running proxy first.
Preserve existing accounts, providers, models, and permissions. Back up files before changing them.
Have me enter the API key locally; never ask for, print, or paste it in chat.
Use the TokenLab preset and the selected model's documented API format.
Check configuration loading first. Explain the cost before running a small real request.
Match the reply with its TokenLab request record.
```

## 接続の仕組み

[OpenCodex](https://github.com/lidge-jun/opencodex) は、Codex とモデル API の間のローカルプロキシです。このガイドでは **OpenCodex 2.73.0** および **Codex CLI 0.149.0** を使用します。

TokenLab プリセットの Chat Completions 統合は 2.72.0 でリリースされ、エンドツーエンドで検証されました。[バージョン 2.73.0](https://github.com/lidge-jun/opencodex/releases/tag/v2.73.0) ではその統合を維持しつつ、モデル固有の Responses および Anthropic Messages ルーティングが追加されています。以下にリストされているルートは、ストリーミングテキストおよび function-call/result の往復処理によって TokenLab との間で検証されています。

Codex は Responses リクエストを**ローカルの OpenCodex プロキシ**に送信します。その後、OpenCodex は選択されたモデルのリクエストを **TokenLab** に送信します。ローカル接続での Responses リクエストは、モデルが TokenLab の Responses API を通じて呼び出されることを意味するわけではありません。

| Codex で選択されたモデル | OpenCodex → TokenLab |
| - | - |
| `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-sol`, `gpt-6-luna`, `grok-4.7`, `deepseek-v4.1-flash`, `deepseek-v4-pro`, `kimi-k3`, `glm-5.3` | Responses: `POST /v1/responses` |
| `claude-opus-5`, `claude-opus-5-5`, `claude-sonnet-5`, `claude-sonnet-5-5`, `claude-fable-5`, `claude-fable-5-1` | Anthropic Messages: `POST /v1/messages` |
| `gemini-3.8-flash` | Chat Completions: `POST /v1/chat/completions` |

プリセットの Base URL は `https://api.tokenlab.sh/v1` です。変更しないでください。OpenCodex は一致する Messages または Responses URL を自身で構築します。記載されている Responses デフォルトおよび Claude ルーティング以外のモデルは、プリセットの Chat アダプターを使用します。

TokenLab は宣言されたモデルに対して Gemini のネイティブ API をサポートしていますが、**OpenCodex 2.73.0 の TokenLab プリセットは Chat Completions 経由で Gemini を呼び出します**。プロバイダー全体を Responses や Gemini に変更しないでください。そのフォーマットを受け入れないモデルのリクエストまで変更されてしまいます。

## インストールまたはアップデート

npm インストールには Node.js 18 以降を使用してください：

```bash theme={null}
npm install -g @bitkyc08/opencodex@2.73.0
ocx --version
codex --version
```

Codex もインストールされている必要があります。OpenCodex は[インストール手順](https://opencodex.me/getting-started/installation/)および [Codex 接続手順](https://opencodex.me/getting-started/quickstart/)を提供しています。ネイティブの Windows と WSL は個別の設定を持つため、セットアップと Codex は同じ環境で実行してください。

## TokenLab の追加

[TokenLab API Keys](https://tokenlab.sh/dashboard/api?tab=keys) でキーを作成します。ターミナルでのセットアップについては、コマンド履歴にキーの値を残さずに `TOKENLAB_API_KEY` を設定するために [クイックスタート](/ja/quickstart) に従ってください。そのターミナルから OpenCodex を起動します。バックグラウンドサービスの場合は、独自の起動環境内にこの変数が必要です。

**OpenCodex を新規インストールする場合**は、`ocx init` を実行して TokenLab を選択し、キーをローカルに入力するか、環境変数のリテラル参照 `${TOKENLAB_API_KEY}` を使用します。ウィザードの Codex 接続および自動起動の選択肢を確認してから適用してください。

**既存のインストール環境の場合**は、他のプロバイダーを置き換えることなくプリセットを追加します：

```bash theme={null}
ocx provider add tokenlab --api-key '${TOKENLAB_API_KEY}'
```

シングルクォートを使用することで、キーの値ではなく環境変数の参照として保存されます。このコマンドは PowerShell でも動作します。`tokenlab` が既に存在する場合は、`--force` で上書きするのではなく、ダッシュボードでそのプロバイダーを編集してください。

ダッシュボードの **Add provider** リストで **TokenLab** を選択し、そこでキーを入力することもできます。OpenCodex は設定を `$OPENCODEX_HOME/config.json`（通常は `~/.opencodex/config.json`）に保存します。

プロキシがまだ実行されていない場合は起動し、ダッシュボードを開きます：

```bash theme={null}
ocx start
ocx status
ocx gui
```

プロバイダーページで、Base URL と検出されたモデルを確認します。このプリセットは `GET /v1/models?category=chat` を検出対象とし、`tool-use` 機能を備えたモデルを保持します。画像、動画、音声、embeddings、および意思決定モデルは除外されます。キーを使用した検出には、そのキーのモデル権限と配信ポリシーが反映されます。

`ocx sync` を実行して Codex を接続し、モデルカタログを更新してから、新しい Codex セッションを開始します。これにより Codex のプロキシ接続とカタログが変更されます。同期する前に既存のカスタムプロバイダー設定を確認し、バックアップを保持してください。アカウントや権限ポリシーを置き換える必要はありません。

## モデルの選択とリクエストの検証

Codex のモデルピッカーで `tokenlab/<model-id>` エントリを選択するか、CLI の単一起動時に指定します：

```bash theme={null}
codex -m "tokenlab/gpt-6.1-sol"
```

OpenCodex は `tokenlab/` を使用してプロバイダーを選択します。TokenLab に送信されるモデル ID は `gpt-6.1-sol` です。[Models](https://tokenlab.sh/ja/models) から現在利用可能な正確な ID を選択してください。

簡易的な接続チェックを行うには、以下を送信します：

```text theme={null}
Reply only with TOKENLAB_CONNECTION_OK. Do not use tools or modify files.
```

このリクエストには TokenLab の残高が消費されます。[Requests](https://tokenlab.sh/dashboard/runs?section=requests) で応答と、それに一致するモデル、時刻、ステータスを確認してください。プロバイダーの検出と起動の成功だけでは、推論へのアクセスが検証されたことにはなりません。

ストリーミングと function calling は表にあるルートで動作します。画像入力と thinking コントロールは選択したモデルに依存します。モデルの機能を確認し、OpenCodex がそのモデルに対して提供する effort の選択肢のみを使用してください。画像入力と thinking リクエストは、Responses および Messages ルートの代表的なモデルで検証されています。Gemini の画像入力は Chat ルートで検証されています。thinking をサポートしているモデルであっても、必ずしも思考テキストを出力したり、すべての effort レベルをサポートしたりするとは限りません。

## Responses モデルを Chat Completions で維持する

記載されている Responses モデルのいずれかで Chat パスを使用するには、OpenCodex の設定にある**既存の** `providers.tokenlab` オブジェクトに `modelAdapters` エントリをマージします。この例では、Codex 向けに `gpt-6-astra` を Chat のまま維持します：

```json theme={null}
{
  "modelAdapters": {
    "gpt-6-astra": "openai-chat"
  }
}
```

これはプロバイダーフィールドの例であり、設定全体を置き換えるものではありません。他のモデルオーバーライド、認証情報、およびプロバイダーを保持した上で、プロキシを再起動し、新しい Codex セッションを開始してください。このモデルエントリのみを削除すると、Responses のデフォルトに戻ります。

Claude の Messages ルーティングは正規の TokenLab エンドポイントに関連付けられています。上記の Chat オーバーライドは Responses デフォルトに適用されるものであり、Claude を Chat に切り替えるものではありません。Chat ネイティブのクライアントの場合、記載されている Responses モデルはこのオーバーライドがなくても既に Chat を使用しています。[OpenCodex provider routing](https://opencodex.me/guides/providers/#3-api-key-catalog) を参照してください。

## 配信ポリシーとその他の TokenLab ツール

このプリセットは `X-TokenLab-Delivery-Policy` ヘッダーを強制しません。TokenLab は API キーの配信ポリシーのデフォルトを使用します。Chat、Responses、または Messages の選択は、配信ポリシーの選択とは別個のものです。[TokenLab provider settings](/ja/guides/tokenlab-provider) を参照してください。

他の API ツールについては [TokenLab MCP server](/ja/integrations/tokenlab-mcp-server) を、統合手順については [TokenLab Skills](/ja/integrations/coding-agent-skill) を追加してください。これらはメインモデルのプロバイダーや API フォーマットを変更しません。

**OpenCodex 2.73.0 の JEV Auto は TypeSafe の意思決定バックエンドを使用します。** バックエンドとして TokenLab は提供されていません。MCP 経由で TokenLab の [System One API](/ja/api-reference/systemone/create-decision) を呼び出すのは別の操作です。TypeSafe の認証情報フィールドに TokenLab のキーを入力しないでください。

## トラブルシューティングと設定の復元

* **ピッカーに TokenLab が表示されない場合:** `ocx --version` を確認してください。このガイドは 2.73.0 を対象としています。`ocx sync` でカタログを更新し、新しい Codex セッションを開始してください。
* **401 または認証情報の不足:** キーが有効であり、OpenCodex を実行しているプロセスから利用可能であることを確認してください。別のターミナルにある環境変数は、既に実行されているサービスには反映されません。
* **モデルが見つからない場合:** 正確な ID、キーの権限、および現在の利用状況を確認してください。非チャットモデルおよび `tool-use` のないチャットモデルは、このプリセットには含まれません。
* **サポートされていないリクエストまたは誤ったエンドポイント:** 選択したモデルをルーティングテーブルと比較し、保存されているアダプターのオーバーライドを確認してください。必要なフォーマットは[モデルの詳細](/ja/api-reference/models/get-model)内の `tokenlab.accepted_request_formats` です。モデル一覧はその詳細フィールドの代わりにはなりません。Codex がローカルで Responses を使用しているという理由だけで、Claude や Gemini を Responses に送信してはなりません。
* **ツールまたは画像入力が失敗する場合:** 元のエラーと Request ID を保持してください。設定を変更する前に、モデルの機能とアクティブな OpenCodex ルートを確認してください。エラーを隠すために会話履歴やツール結果を削除しないでください。

プロキシ経由での Codex のルーティングを停止するには、`ocx stop` を使用します。OpenCodex はプロキシを停止し、ネイティブの Codex 接続を復元します。`ocx restore` は、他のクライアント向けにプロキシを実行したまま、ネイティブ接続を復元します。他のクライアントと共有されている環境を変更する前に、[OpenCodex CLI reference](https://opencodex.me/reference/cli/) を確認してください。