coco
1
最近、Codex CLIであまり安定していないアップストリームにつないで使っているときに、笑えるけど実際にはかなり困る問題にぶつかりました。
Codexはいま、ストリーミングの再接続をハードコードされた指数バックオフにしています。最初の数回は普通に見えるのですが、後半になると膨らみ方が極端です：
- 1回目は約 0.2 秒
- 5回目は約 3.2 秒
- 10回目でもう 1 分以上
- その先は十数分、数十分に1回まで上がることさえあります
問題は、この設計が「失敗が長く続くほど、再試行は遅くすべきだ」という前提をデフォルトで置いていることです。でも現実の多くのアップストリームはそうではありません：
- ゲートウェイがたまに不調になる
- バックエンドのルーティングが不安定
- 一部の OpenAI 互換中継が短時間だけ 403 を返す／クォータ状態が更新されていない
- 実際には、何回か多めに試せばすぐ復旧する
つまり、本当に必要なのは：
- ユーザー自身が再試行頻度を決められること
- 少なくとも固定間隔の再試行（例：500msごと）を許可すること
- ハードコードされた指数バックオフに縛られないこと
さらにひどいことに、Codexはいまユーザーに stream_max_retries は提供しているのに、再試行間隔やバックオフ戦略を設定できません。これによって：
回数を 100 回に増やせても、10回目以降は毎回の待ち時間が不合理なほど長くなり、「多めに何回か試せば通る」系のシナリオから完全に外れてしまいます。
この問題はすでにアップストリームに報告しました：
この問題の本質は、単にパラメータ選定が悪いというより、設計が独断的すぎてユーザーに自由な選択を与えていない点だと思います。
TOMLで少なくとも次のような設定を明示的にサポートできれば、ようやく選択権をユーザーに返したと言えるはずです：
[model_providers.custom]
stream_max_retries = 100
stream_retry_delay_ms = 500
stream_retry_backoff = "fixed"
こういうニーズは実際とてもよくあります：
「このアップストリームはよく不調になるけど、連続で素早く何回か試すとたいてい復帰するので、自動で数十分に1回みたいに引き延ばさないでほしい。」