GPT-6 SolのHighとXHigh、追加の推論はいつ必要？

複雑なコード修正では、まず high を評価し、追加の推論に見合う改善を確認できたタスクだけ xhigh に切り替える方法が実用的です。 これは gpt-6-sol という同じモデルの設定比較です。推論量が増えても、パッチの正しさが保証されるわけではありません。

公式資料の確認日は2026年9月25日です。同じタスクを両設定で実行した実測記事ではありません。以下は設定方法、仮定した費用例、評価手順です。ドル価格はOpenAI直結APIのもので、Ofoxの価格やChatGPTの契約料金ではありません。

変更するのはモデルではなくeffort

Solのモデル資料では、none、low、medium、high、xhigh、max が使え、既定値は medium です。highも既定設定からの変更に当たります。推論ガイドは、より高い設定の効果を遅延や費用と合わせて評価するよう説明しています。

このタスク分類は評価の出発点であり、性能順位ではありません。失敗するテストや期待動作が曖昧なら、まず問題の記述を直します。無関係なファイルの調査を長く続けるだけでは、追加の推論に価値はありません。

比較条件を固定する

推論とツール呼び出しを併用するならResponsesを使います。SolのChat Completionsは none の場合だけ関数呼び出しに対応するため、そこでhighを指定した際のエラーをモデルの失敗に数えてはいけません。ツール呼び出しの移行手順も確認してください。

{"model":"gpt-6-sol","reasoning":{"effort":"high"},"input":"Review the supplied patch against the stated acceptance tests."}

これは未実行のリクエスト形式例で、完全なリポジトリエージェントではありません。比較側はeffortだけをxhighに変更します。実際にはcommit、プロンプト、ツール定義、権限、出力上限、再試行回数も固定します。reasoning.mode の standard と pro はeffortとは独立した実行モードです。この例では省略して既定のstandardを使っています。modeとeffortを同時に変えると比較条件が混ざるため、modeも固定してください。機密情報を除いた正確なリクエスト、リクエストID、使用量記録も保存します。

毎回同じクリーンな状態から開始し、先に生成されたパッチや隠しテストの答えを後の実行に渡さないようにします。複数の代表的タスクで実行順を入れ替え、失敗とタイムアウトも保存します。失敗した側だけ追加実行すれば、比較は偏ります。

単価が同じでも総額は変わる

Standard処理で入力が272Kトークン以下なら、Solは通常入力100万トークン当たり2ドル、出力10ドルです。API料金表にhigh/xhigh別の単価はありませんが、推論による課金対象出力や、ツール往復後の入力が増える可能性があります。

仮に未キャッシュ入力が5万トークン、課金対象出力が5,000なら入力$0.10＋出力$0.05で $0.15、出力が15,000なら$0.10＋$0.15で $0.25 です。これは任意に設定した数量であり、highとxhighの測定値ではありません。見える回答だけで出力量を数えず、プロバイダーのusageを使います。

キャッシュ読み書き、ツール、処理モードは別に計算します。入力が272Kを超えるとリクエスト全体の入力・キャッシュ単価が2倍、出力単価が1.5倍になります。長文料金への移行とeffort変更を混同しないでください。Solの費用解説に区分があります。

合格した修正を基準に選ぶ

回答を見る前に、元の不具合が直る、必要なテストが通る、無関係な動作を変えない、レビュアーが修正理由を説明できる、という基準を決めます。人のレビュー時間も別に記録します。長い説明は、正しさやレビューの省力化を意味しません。

失敗を含む全評価費用を合格タスク数で割ります。合格がゼロなら比率は定義できません。最初のトークンが出るまでの時間だけでなく、合格パッチを得るまでの総時間も比べます。

合否が同じでhighの実費や時間が小さいならhighを維持し、xhighが継続的に合格数を増やす領域に限定して使います。両方失敗する場合は、先に要件や検索対象を改善します。モデル自体の選択はSol・Luna・Astraの比較を参照してください。プロンプト、commit、テストコマンド、失敗記録を残せば、環境が変わった後も判断を再検証できます。