coco
1
最近在用 Codex CLI 接一个不太稳定的上游时，踩到了一个很搞笑、但又很实际的问题。
Codex 现在把流式重连做成了硬编码的指数退避。前几次看起来还正常，但到了后面会膨胀得非常夸张：
- 第 1 次大约 0.2 秒
- 第 5 次大约 3.2 秒
- 第 10 次已经到 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"
这种需求其实非常常见：
“这个上游经常抽风，但连续快速试几次通常就恢复，请别给我自动拉成几十分钟一次。”