解决Any 5.5高频报错：修改Codex配置提升重试成功率

最近在折腾 Any 5.5 的 API 调用，中间件用的依然是顺手的 Codex。不过，可能是用的人实在太多了，最近频频遭遇如下报错：

Codex 遇到高负载时的报错提示

We're currently experiencing high demand, which may cause temporary errors.

简单来说，就是服务端太忙了，请求直接被拒或者超时。最让人头疼的是，Codex 默认的重试机制只有区区 5 次。在高峰期，这 5 次重试简直就是“秒没”，导致请求根本无法成功通过，极其影响体验，根本没法“爽用”。

问题分析

这本质上是客户端与服务端在高并发场景下的博弈。服务端暂时无法处理，抛出错误是正常的，但客户端如果稍微“坚持”一下，多尝试几次，往往就能钻过空子成功建立连接。Codex 本身是支持自定义重试策略的，只是默认的 5 次对于当前热门模型的拥挤程度来说，实在是显得过于保守。

解决方案

在社区佬友的指点下，找到了解决办法。我们需要手动修改 Codex 的配置文件 config.toml。

我们需要找到 [model_providers] 相关的配置段落。在你的具体 Provider 配置下，新增或修改一项名为 stream_max_retries 的参数。

建议将其值设置为 50。这意味着当 API 返回临时错误时，Codex 会在后台自动帮我们重试最多 50 次，大幅增加“挤”进去的概率。

配置示例

以下是我的修改示例，供大家参考（注意你需要根据自己实际的配置名称进行对应修改）：

[model_providers.aimai1]
name = "AiMaMi 智能路由"
base_url = "http://127.0.0.1:25817/codex/router/v1"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false
stream_max_retries = 50

体验反馈

修改完配置并重启服务后，效果立竿见影。虽然偶尔还是会遇到高并发的提示，但绝大多数时候，系统会在几次自动重试后成功获取响应，终于可以继续愉快地“刷刷刷”了。

小结

如果你也在使用类似的中转服务或者直面 API 遭遇频繁的临时错误，不妨检查一下你的客户端配置，适当调大重试次数往往能以极低的成本解决大问题。当然，这个配置仅供参考，具体数值可以根据网络环境和个人需求微调。