Codex・Cursor・Cline・DSH で GPT-6 Astra を使う:そのまま動く設定(2026)
モデル文字列ひとつ、コーディングエージェント四種。Codex CLI・Cursor・Cline・DeepSeek Harness 向けにコピペできる GPT-6 Astra の設定と、先に決めておくべき effort 設定とキャッシュの罠。
GPT-6 Astra は、どのコーディングエージェントもすでに使っているのと同じ OpenAI 互換プロトコルを話す。だから「追加する」といっても、それは統合作業ではなくモデル文字列の変更だ。 実際に判断が要るのは effort の段階とキャッシュ読み取りの単価のほうである。この記事では Codex CLI・Cursor・Cline・DeepSeek Harness の動く設定と、既定にする前に詰めておく価値のある 2 つの設定を扱う。
モデル ID: openai/gpt-6-astra
エイリアス: gpt-6-astra、gpt-6-astra-2026-09-03
エンドポイント:/v1/chat/completions、/v1/responses
Base URL: https://api.ofox.ai/v1
価格: 100 万あたり 入力 $10.00 / 出力 $50.00
キャッシュ: 読み取り $1.00 / 書き込み $12.50
コンテキスト: 入力 1,050,000 / 出力 128K
effort 段階: low、medium、high、xhigh、max
Astra が掲載された 2026 年 9 月 5 日に、ライブの /v1/models エンドポイントから取得。
先にこの 2 つを決める
設定ブロックの前に、これが自分のワークロードにとって良い選択かどうかを決める 2 つの設定について。
Effort は max ではなく high から始める。 Astra は 5 段階を公開している。Artificial Analysis の計測では max が Intelligence Index で 61、high が 60——1 点差——である一方、max は出力トークンを 4200 万書き(high は 1600 万)、同じ指数を回すのに $3,013(high は $1,429)かかった。推論トークンは読もうが読むまいが出力単価で課金されるので、effort の設定は品質仮説の付いた価格の乗数だと言える。払う前に、その 1 点が自分のタスクで存在するかを確かめてほしい。
キャッシュ読み取りは Claude Fable 5.1 の 4 倍だ。 表示価格はどちらも 100 万あたり $10 / $50。だが Astra はキャッシュされた入力を 100 万あたり $1.00 で読むのに対し、Fable 5.1 は $0.25 で読む。コーディングエージェントは同じシステムプロンプト、ツール定義、ファイルコンテキストを毎ターン送り直すので、長いセッションではキャッシュ入力が請求書の最大項目になることが多い。エージェントのループが長い前置きを繰り返し流しているなら、この行のほうが表示単価よりも請求額を動かす。
独立ベンチマークから得られる正直なまとめはこうだ。Astra はエージェント向けに作られ、エージェント向けに値付けされている。Coding Agent Index では GPT-5.6 Sol の 65 に対して 67 を取り、しかも Codex ハーネスでは使用トークンが約 3 分の 1 なので、タスク全体のコストは Sol とだいたい同じところに着地する。短いプロンプトでは、動かなかった汎用スコアに対してトークンあたり 2.5 倍を払っていることになる。
Codex CLI
環境変数 2 つとモデル指定のフラグ。
export OPENAI_API_KEY=<あなたの ofox キー>
export OPENAI_BASE_URL=https://api.ofox.ai/v1
codex --model openai/gpt-6-astra "Migrate this module off the deprecated client"
単一エンドポイントならこれで設定は終わりだ。インストールと確認手順は Codex の設定ガイドにまとめてある。
環境変数方式が通じなくなるとき
この 2 変数の小技はエンドポイントを 1 つに固定してしまう。OpenAI 直結とゲートウェイを同じターミナルで同時に使いたくなった瞬間、あるいはプロジェクトごとに別のモデルを使いたくなった瞬間に、~/.codex/config.toml が必要になる:
[model_providers.ofox]
name = "ofox.ai gateway"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "chat"
request_max_retries = 4
[profiles.astra]
model = "openai/gpt-6-astra"
model_provider = "ofox"
model_reasoning_effort = "high"
codex --profile astra "Refactor the auth layer"
ここで間違えられやすいキーが 2 つある:
wire_api = "chat"であって"responses"ではない。どちらの値も受け付けられ、OpenAI 自身のファーストパーティ設定は"responses"が既定だが、サードパーティの OpenAI 互換ゲートウェイは/v1/chat/completionsで Chat Completions のスキーマを公開している。ゲートウェイ経由なら"chat"を指定すること。env_keyは変数名を指すもので、キーそのものを入れる場所ではない。 Codex は実行時にその環境変数を読む。TOML にトークンを貼り付けないこと。
ブロックの残りの部分は、組織スコープが必要なゲートウェイ向けの http_headers も含め、マルチプロバイダの詳解で扱っている。
Cursor
Settings → Models → Override OpenAI Base URL。
- Override OpenAI Base URL の欄に
https://api.ofox.ai/v1を入れる。/v1は省かないこと——Cursor は入力された値に/chat/completionsを付け足す。 - OpenAI API Key の欄にゲートウェイのキーを入れる。ラベルは OpenAI だが、キーは上で設定したエンドポイントに送られる。
- + Add Model をクリックし、
openai/gpt-6-astraを正確に入力する。この文字列はエンドポイントがリクエストボディで期待するものと一致していなければならない。
Cursor のオーバーライドはモデル単位ではなく全体に効く。これがこの経路の既知の制限で、有効にすると OpenAI 名義のモデルすべてが自分のエンドポイントを向くことになる。何が壊れるかと回避策は Cursor と Cline の設定ガイドにある。
Cline
OpenAI Compatible プロバイダを使う。
Cline の設定パネルで API Provider に OpenAI Compatible を選び、3 つの項目を埋める:
| 項目 | 値 |
|---|---|
| Base URL | https://api.ofox.ai/v1 |
| API Key | ゲートウェイのキー |
| Model ID | openai/gpt-6-astra |
Model ID にはプロバイダの接頭辞が要る。gpt-6-astra 単独はゲートウェイが解決するエイリアスだが、Cline での「model not found」報告はほぼ例外なく、接頭辞を求める経路に対して openai/ なしの文字列を入れていたケースにたどり着く。Cline の設定ガイドには Anthropic プロバイダ経路も載っているが、それが効くのは Claude 系のモデルであって、このモデルではない。
DeepSeek Harness(dsh)
Settings → Models → Add a custom provider。 フォームは 5 つを尋ねてくる:
| 項目 | 値 | 制約 |
|---|---|---|
| Provider ID | ofox | 小文字、先頭は英字、変更不可 |
| Display name | ofox.ai gateway | あとから変更可 |
| Base URL | https://api.ofox.ai/v1 | あとから変更可 |
| API protocol | openai-completions | 他に openai-responses、anthropic-messages |
| API key | ゲートウェイのキー | 書き込み専用、$DSH_HOME 配下に保存 |
$DSH_HOME/settings.yaml に直接書いてもいい:
llm-pi-ai:
providers:
ofox:
apiKeyEnv: OFOX_API_KEY
api: openai-completions
baseURL: https://api.ofox.ai/v1
models:
- id: openai/gpt-6-astra
dsh 固有の罠が 3 つ、いずれもクリーンインストールで確認済み:
- models のリストはそのルートのカタログを拡張するのではなく置き換える。 宣言していないモデルは、リクエストが端末を出る前に
UNKNOWN_MODELで失敗する。カスタムプロバイダには「とりあえず送る」という経路がない。 - Provider ID は変更できない。 セッション、既定値、資格情報の参照がすべてこれをキーにしているので、名前を変えるということは新しいプロバイダを作って古いほうを消すということだ。
- プロバイダを定義しても既定にはならない。 headless プロファイルは、別のプロバイダを完全に設定してあっても内蔵の DeepSeek ルートを起動し
DEEPSEEK_API_KEYを要求してくる。まず Web アプリ側で既定モデルを設定すること。
dsh はまだ開発者プレビューで、それは自身の README に大文字で書かれている。気にかけているリポジトリに向ける前に何を意味するかは、dsh セットアップガイドとバージョンと安定性についての注記にまとめてある。
経路の確認
どのエージェントを設定したかによらず、確認方法は同じだ——これが補完を返すなら転送層は問題なく、まだ壊れているものはエージェント側の設定だ:
curl -X POST https://api.ofox.ai/v1/chat/completions \
-H "Authorization: Bearer $OFOX_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-6-astra",
"messages": [{"role": "user", "content": "Reply with exactly: ok"}],
"reasoning": {"effort": "high"}
}'
コストを見積もる前に、自分のプロンプトで usage を読むこと。出力 100 万トークンあたり $50 で推論も同じ単価で課金される以上、料金表よりトークン数のほうが効いてくる。
model_not_found が返ってきたら
ほぼ必ず、古いか壊れたモデル文字列だ。 有効な識別子は openai/gpt-6-astra、それにエイリアスの gpt-6-astra と gpt-6-astra-2026-09-03。
具体的な罠が 2 つ:
- 古い Codex のガイドは
openai/gpt-5.4-mini-codexを勧めている。 このモデルはもうカタログになく、同じmodel_not_foundを返す。現行の Codex 系の選択肢はopenai/gpt-5.1-codex-mini($0.25 / $2.00)とopenai/gpt-5.3-codex($1.75 / $14.00)だ。 - GPT-6 にティア接尾辞はない。 GPT-5.6 は Sol・Terra・Luna として出荷されたが、GPT-6 は Astra と Astra Pro だ。ティアを付け足してモデル文字列を組むルーターや設定テンプレートは一致するものを見つけられない。この命名変更が他に何を壊すかは世代間比較で扱っている。
何が呼べるかは、このページを含むどのページでもなく GET https://api.ofox.ai/v1/models が権威だ。
実際にどのモデルへ向けるべきか
Astra は最新だというだけで自動的に正しい既定になるわけではない。同じ $10 / $50 の価格帯には、自分のタスクで比べてみる価値のある経路が他に 3 つある:
| モデル | 100 万あたり 入力 / 出力 | キャッシュ読み取り | AA Coding Agent Index |
|---|---|---|---|
openai/gpt-6-astra | $10.00 / $50.00 | $1.00 | 67 |
anthropic/claude-fable-5.1 | $10.00 / $50.00 | $0.25 | 70 |
openai/gpt-5.6-sol | $5.00 / $30.00 | $0.50 | 65 |
openai/gpt-5.3-codex | $1.75 / $14.00 | — | — |
Fable 5.1 は Coding Agent Index を 70 で先頭に立ち、キャッシュを Astra の 4 分の 1 の単価で読む。長いエージェントセッションで最も効いてくるのがこの組み合わせだ。対する Astra の言い分はトークン効率で、Codex ハーネスでは Sol の約 3 分の 1。表示価格が高いのにタスクあたりのコストが Sol の近くに着地するのはそのためだ。詳しい内訳は直接対決にある。
上のどのエージェントも同じエンドポイント経由でこの 4 つすべてに届くので、切り替えは文字列 1 つで済む。自分のタスクを 3 つ選んで 2 モデルで走らせ、usage を読むこと——その比較は数セントで済み、本サイトのものを含めてどんなベンチマーク表よりも役に立つ。
出典
- https://ofox.ai/models/openai/gpt-6-astra
- https://developers.openai.com/codex/config-reference
- https://artificialanalysis.ai/articles/benchmarking-gpt-6-astra
- https://ofox.ai/docs/integrations/cline
モデル ID、料金、コンテキスト長、エンドポイントは 2026 年 9 月 5 日にライブの Ofox /v1/models エンドポイントから取得した。Coding Agent Index のスコアと effort 段階のコスト比較は Artificial Analysis のもので、2026 年 9 月 4 日に閲覧。Codex の config.toml のキーは OpenAI の設定リファレンスに従っている。dsh の provider フォームの項目と 3 つの罠は、以前の dsh セットアップガイド執筆時にクリーンインストールで確認し、本記事でも再度突き合わせた。dsh は引き続き開発者プレビューであり、メンテナ自身が破壊的変更を予告している。
よくある質問
- Codex CLI で GPT-6 Astra を使うには?
- Codex を OpenAI 互換ゲートウェイに向け、モデル文字列を渡すだけです。環境変数 2 つで済みます。OPENAI_BASE_URL=https://api.ofox.ai/v1 と、ゲートウェイのキーを入れた OPENAI_API_KEY を設定し、codex --model openai/gpt-6-astra を実行します。複数のプロバイダを併用したい場合は、代わりに ~/.codex/config.toml に [model_providers.ofox] ブロックを wire_api = "chat" 付きで宣言してください。
- GPT-6 Astra には専用の provider ブロックが必要?
- 不要です。Astra は標準の OpenAI 互換プロトコルで /v1/chat/completions と /v1/responses から提供されるので、すでに OpenAI 互換エンドポイントと話せるエージェントなら、モデル文字列を openai/gpt-6-astra に変えるだけで届きます。気を配るべきは転送方式ではなく、reasoning effort の設定とキャッシュ読み取りの単価のほうです。
- コーディングにはどの reasoning effort を使うべき?
- high から始めてください。Astra は low、medium、high、xhigh、max を公開しています。Artificial Analysis の計測では high から max への一段で得られたのは指数 1 点で、コストはおよそ倍、出力トークンは 1600 万に対して 4200 万でした。max を既定にする前に、その 1 点が自分のタスクで存在するかを測ってください。
- コーディング用途で GPT-6 Astra は GPT-5.6 Sol より価値がある?
- エージェント型のワークロードでは、表示価格が 2.5 倍でも見合うことが多いです。Artificial Analysis の Coding Agent Index では Astra が 67、Sol が 65 で、しかも Codex ハーネスでは使用トークンがおよそ 3 分の 1 のため、タスクあたりのコストは Sol に近くなります。一方、短いプロンプトやチャットでは、動かなかった汎用知能スコアに対してトークンあたり 2.5 倍を払うことになります。
- DeepSeek Harness で GPT-6 Astra を動かせる?
- 動かせます。カスタムプロバイダ経由です。Settings → Models → Add a custom provider でプロバイダ ID、ベース URL、API プロトコル、キーを入力し、プロトコルは openai-completions を選び、models に openai/gpt-6-astra を並べます。$DSH_HOME/settings.yaml に直接書くこともできます。なお models のリストはそのルートのカタログを拡張するのではなく置き換えるので、宣言していないモデルはリクエストが端末を出る前に UNKNOWN_MODEL で失敗します。
- エージェントが GPT-6 Astra に対して model_not_found と言うのはなぜ?
- たいていはモデル文字列が古いからです。カタログ上の ID は openai/gpt-6-astra で、エイリアスは gpt-6-astra と gpt-6-astra-2026-09-03。古いガイドは openai/gpt-5.4-mini-codex も勧めていますが、これはすでにカタログに存在せず同じエラーを返します。どのページからも文字列をコピーせず、GET https://api.ofox.ai/v1/models を確認してください。


