GPT-6 Solの公開は2026年9月22日、GPT-6.1 Solはその1週間後の9月29日でした。既存システムのモデルIDをすぐに入れ替えるべきかを考えるとき、私は「新しいか」よりも「今のタスクで検証できる改善があるか」を先に見ます。特に、処理順序が結果を変えるコード、正確な件数、利用者が待つAPI応答は分けて評価したいところです。
9月30日にCrazyrouterのhttps://api.crazyrouter.com/v1/chat/completions経由で両モデルへ同じ英語の課題を送信しました。保存した生成コードは11月3日にローカルで再実行しています。この日に新たな推論リクエストは行っていません。以下は限られた課題とアクセス経路についての記録であり、現時点の稼働率を測ったものではありません。
GPT-6.1 SolとGPT-6 Solで、業務ロジックの処理順序を守れるか
請求イベントを集計する関数を考えます。要件は、イベントIDごとに最初の記録を残し、その後で時間範囲を適用し、テスト用アカウントを除外して、請求額と返金額を集計することです。時間範囲の絞り込みを先に行うと、範囲外の初回イベントが消え、範囲内にある同じIDの後続イベントを初回と誤認する可能性があります。
例えば、IDがaの初回イベントが時刻-1、後続イベントが時刻5で金額90、集計範囲が[0,10)の場合です。先に重複排除すれば、残った初回イベントは範囲外なので、このIDの請求額は増えません。順序を逆にすると90を誤計上しかねません。
両モデルの保存済み回答は重複排除を先に置いていました。各モデルから得た2つの関数、計4つを122項目のローカルチェックで再確認し、すべて通過しました。これは明確に定義した小さな関数についての結果です。未知の大規模リポジトリや複数ファイルの修正能力まで示すものではありません。
実務では、この境界例を回帰テストに残すのが役立ちます。指示文に処理順序を書くだけでなく、範囲外の初回イベントと範囲内の重複イベントを同じテストケースに入れる。既存のGPT-6 Solの出力がそのテストを安定して通るなら、この関数だけを急いで移行する理由は見つかりません。
GPT-6.1 SolとGPT-6 Solに長文の件数を尋ねるとき
別の課題では、合成した360件の規則から条件に合う項目数を答えさせました。独立した計算で正解は72件と確認しています。指定した優先規則が存在するかという質問も加えましたが、その規則は文書にありません。
保存済みの2回ずつの回答で、GPT-6 Solは72件を2回、GPT-6.1 Solは72件と71件を各1回返しました。存在しない優先規則については両モデルとも正しく否定しています。1回の数え漏れからモデル全体の優劣を決めることはできません。ただし、もっともらしい説明と正しい集計値は別々に検証すべきだと分かります。
規程や請求資料に使うなら、モデルには該当する規則IDと判断根拠を列挙させ、最終件数は重複排除を含むプログラムで算出します。数字が食い違った際に元の項目へ戻れるためです。金額や日付を伴う判断でも、最終値をモデルの一文だけに任せない方が扱いやすくなります。
GPT-6.1 SolとGPT-6 Solの応答時間をどう扱うか
9月30日のイベント抽出課題では、完了したGPT-6.1 Solの2回の応答が約19.25秒と12.62秒、GPT-6 Solが約22.83秒と20.62秒でした。一方、別のコード課題では同じ速さの傾向が続きませんでした。
全体では各モデル8種類の課題を2回ずつ実行し、reasoning_effort: "high"、出力上限8192トークンを使用しました。元の実行には並列リクエストが含まれます。GPT-6 Solは16回中16回、GPT-6.1 Solは16回中14回が完了し、後者の規則検索2回はクライアント側の約240秒タイムアウトに達しました。16回は独立した16題ではなく、特定日の小さなリクエスト群です。これをサービス全体の障害率や恒常的な速度差には換算できません。
バックグラウンド処理なら後から再試行できても、画面上で利用者が待っている場合は別です。応答期限、失敗時の表示、再試行が二重書き込みを起こさないかを先に設計します。品質評価でも、誤答と未完了を同じ「失敗」にまとめず記録すると、改善すべき箇所が見えます。
GPT-6.1 SolとGPT-6 Solを同じ条件で試す接続手順
OpenAI互換のチャットクライアントなら、接続の起点はCrazyrouterの連携案内で確認できます。Base URLはhttps://api.crazyrouter.com/v1、今回のチャットリクエスト先はhttps://api.crazyrouter.com/v1/chat/completionsです。モデルIDはgpt-6-solとgpt-6.1-solを使います。後者の小数点をWebページのURLにあるハイフンと取り違えないようにします。
まずアカウントで両IDが見えるかを確認し、実際のタスクを送って応答を確かめます。モデル一覧に載っているだけでは推論成功とは言えません。入力、英語の指示文、推論設定、出力上限、検査用データを固定してモデルIDだけを変え、出力と未完了の両方を保存します。共通の接続先を使えることと、自動再試行やフォールバックが実装済みであることも別です。
小さな関数が既存のGPT-6 Solで十分に検証できているなら、その部分は維持します。修正を繰り返す複雑な課題ではGPT-6.1 Solを候補として試し、実際の手戻りが減るかを見る。件数の確定と応答期限は、どちらのモデルを選んでもアプリケーション側で管理するのが私の判断です。