什么值得做
GitHub 开源项目 · 11-6 写
NewBeeM4n/codex-overload-fix · NewBeeM4n

一条官方 issue 下的根因分析:一个修 Codex 报错的小工具,13 天 250 star

它是什么 一个本机跑的 Python 小中继,夹在 Codex 和 OpenAI 中间,看到容量已满的报错就在输出前自动重发,用户感觉不到中断。

为什么火了 这个报错拖了几个月,官方 10 月中说修好了其实没修好;作者在 61 条评论的官方 issue 下发了一篇带数据的根因分析,再用中文 X 帖和讲安全、能还原的三平台工程完成度,拿走了同类里几乎全部关注。

B你可以怎么跟 别再做 Codex 重试;照它的打法,找 Claude Code、Cursor、Gemini CLI 等工具长期没修好的报错,先在官方 issue 下发根因分析,再贴一个本机、可逆、有实测数字的小工具。

B 级:打法清楚、成本低、可以换到别的 AI 工具上复用,但 star 天花板只有几百,价值押在厂商一直不修 bug 上,窗口随时会关。 小圈子里在传
数据(每天更新) · 建库 2026-10-24 · 252 星 · 7 天 +129
GitHub · 星数
010020030010-2610-2911-0111-0511-08252
数据 2026-10-26 → 2026-11-08(14 天,14 次观测)。10-28 以前的点来自 deeply / 存档补录,不是每天都有

一个只有这一个仓库、两个粉丝的 GitHub 账号,做了一个本机跑的小中继,专门对付 Codex 那句「Selected model is at capacity」。同一件事至少有十几个人做过,大多 0 到 7 个 star;它 13 天拿到两百多个,没进过一天 trending。差别不在代码,在于它讲清楚了「为什么别人的重试都没用」,并且把这段解释贴在了所有受害者都会去的地方。

凌晨一点的一条评论

2026 年 10 月 24 日 00:57(UTC),NewBeeM4n 建了 codex-overload-fix 这个仓库。19 分钟后,他在 openai/codex 的 #28507 号 issue 下面发了一篇长评论。这个 issue 6 月 16 日开的,标题就是那句报错,61 条评论,到 11 月还开着——被这个错误卡住的人,搜来搜去最后都会落到这里。

他的评论没有先贴链接,先讲原因:这个错误不是 5xx,服务端回的是 HTTP 200,错误藏在 SSE 流里的一个 error 事件中;所以 HTTP 库、代理、Codex 客户端自己按状态码做的重试,全都看不见它。后面附了按请求大小分组的统计。早上 8:10 他又补了一句:我修好了,附上仓库地址。

01:23 他在 X 上用中文发了一条:「被 "Selected model is at capacity" 困扰的朋友,可以看看我的解决方案。我自己这样处理之后已经彻底解决,一整晚没再被它打断过。」配两张前后对比截图,自己在下面补一句「相同的网络环境和设备,同样的 plus 账号」。这条到 11-06 约 6,200 次浏览。10 月 28 日有人在下面回:「200pro 方案每天都是这样 我已经快疯了…..」

它是什么

一个只用 Python 标准库的本机中继,夹在 Codex 和 OpenAI 中间。它盯着返回的流,一旦在开始输出之前看到容量错误,就自己重发,用户这边什么都看不到。安装脚本只改 Codex config.toml 里的两行,改之前先备份,卸载能逐字节还原;Windows、macOS、Linux 都有安装脚本,不需要管理员权限。

README 开头放的是一组实测:一个晚上 71 次请求,中继吸收了 82 次重试,用户看到的失败是 0;「一个 799 KB 的请求连续失败 8 次,第 9 次成功」。紧接着一句免责:它减少中断,但造不出服务器容量,也提升不了模型质量。

13 天里发了 9 个版本:先补 macOS 和 Linux,11-02 出了可以让 Codex 自己安装的 Agent Skill 包,后面加了本地面板,11-05 的 v1.5.1 兼容了新版客户端。所有发布包加起来约 1,300 次下载(GitHub,11-06),和 star 数差不多一个量级——装的人大概真在用。

为什么是这个时候

这个报错从 2026 年年中起就是 Codex 最常见的抱怨之一:#28507 之外,还有「容量满时自动重试」等好几个 issue、OpenAI 社区的帖子、r/codex 的讨论帖。10 月 15 日,OpenAI 的 Codex 负责人 Tibo 在 X 上说已经上线修复、加了算力,「它会自己继续,不会卡住」。用户还在报。9 天后这个仓库出来,接住的正是「官方说修好了,其实还没修好」这段空档。

中文开发者撞得最多。linux.do、nodeseek 上有一串帖子把这个报错和「账号被风控」「重置过的号」联系在一起,有人教改请求头。用 Plus 号、共享号、中转的人频率最高,所以这个项目从第一天起就是双语 README、作者用中文发帖,issue 和 PR 也多来自中文用户。

star 是怎么一天天涨上来的

时间发生了什么star(GitHub,当日)
10-24建库;官方 issue 下发根因分析;中文 X 帖—
10-2625
10-28一家 AI 自动写稿的新闻站发了篇报道,标题复述「71 次容量拒绝变成 0」;几个自动 trending 榜单收录68(当日 +34)
10-30113
11-02平台期;同一天出 Agent Skill 包,后来成了下载最多的版本126
11-03 至 11-05新模型上线后「老是繁忙」的抱怨又来一波;单日最高 +45151 → 223
11-06243(实时约 253),fork 22

没有广告、没有 HN、没有 Product Hunt、没有大号转发。第二波具体是谁带起来的,没找到单一来源;linux.do 上有没有专帖要登录才能看,没核实。

十几个人做了同一件事

项目star(11-06)和它的区别
Codex 官方重试—按状态码重试,抓不到 200 流里的错误;它补的就是这个缺口
codex-never-give-up7在桌面界面层自动重发;它在网络层、输出前重试
Codex-RetryPilot、codex-retry-watcher 等0–3只支持 Mac,模拟点击「重试」按钮
fxxk-u-tibo2名字就是在骂人,只支持 Windows
codex-retry、codex-auto-retry 等十来个0–1单平台,没数据,没讲原理
CLIProxyAPI、gpt-load、axonhub 等网关整库几千到几万10 月前后各自加了过载重试,但那是给号池和中转用的重家伙,不是给「我就一个官方号」的人

它大约是第二名的 35 倍。几个 fork 和移植已经出现:有人给它加了可视化(4 star),有人把它移植成 CLIProxyAPI 插件,致谢里写着「感谢作者的实测沉淀」。

它为什么能从一群同类里冒出来

先讲原因,再给工具。「错误藏在 200 里,所以谁的重试都抓不到」是一句能被转述的话。那家新闻站整篇都在复述这一点。别的项目只说「我能自动重试」,读者没理由信它比别的强。

发在痛点最集中的地方。 不是发广告,而是在 61 条评论的官方 issue 下面写一篇有数据的分析。每一个后来搜到这个 issue 的人,都会看到它。

把「安全」写在最前面。 纯本机、只用标准库、只改两行、能还原、单独一节讲账号风险——中文圈对「中转偷号」很警惕,这一条直接回应了它。

工程上像个正经项目。 三个平台的安装脚本在真实的 macOS、Ubuntu 机器上跑 CI,40 多项测试,13 天 9 个版本,issue 回得快。

天花板在哪

它的价值全押在「OpenAI 一直有容量问题」上。官方哪天真修好了,或者客户端学会识别流里的错误,它就没用了。对被风控的号,重试也救不回来,作者自己在 issue 里承认过。所以它的 star 大概停在几百:受众是「被这个错误卡住、又愿意装个本机中继」的那批人,不会更多。

如果是你

一句判断:别再做一个 Codex 过载重试,这个坑已经有人占了;值得照抄的是它的打法——找一个大厂 AI 工具长期没修好的报错,在官方 issue 下先发一篇有数据的根因分析,再贴一个可信、可逆的小工具。这种项目能稳定拿到几百 star,很难拿到几千。

适合谁:每天重度用 Claude Code、Cursor、Gemini CLI、Codex 这类工具、愿意抓包查原因的开发者;想要一个「能讲清楚自己解决了什么」的开源作品放进履历。

不适合谁:想要几千上万 star 的人;不愿意跟着上游每周发版做兼容的人;只会写包装脚本、讲不出根因的人。

怎么做:

  1. 去各家 AI 编程工具的 GitHub issue 里,按评论数排序,找开了几个月、还没关、官方说过「已修复」但还有人在报的报错(推断:限流、过载、长对话截断、MCP 断连这类最可能有)。
  2. 自己复现,抓包,找出「为什么现有的重试 / 设置救不了它」的那一句话。找不到这句话就别做。
  3. 工具做小:本机、零依赖、只改最少的配置、能一键还原;README 第一屏放前后对比和一晚上的实测数字,第二屏讲风险和局限。
  4. 建库当天在那个 issue 下发分析,结尾再放链接;同时在自己的 X 发一条带截图的短帖,中文用户多就用中文发。
  5. 头两周高频发版,跟上游兼容;做一个能让 agent 自己安装的 Skill 包。

怎么获客:官方 issue 是主场,X 和中文开发者社区是第二场;自动榜单和 AI 写稿的新闻站会自己找上来。

什么时候之前:看报错,不看日历。窗口在「官方说修了但没修好」到「真的修好」之间,通常几周到几个月;发现目标后一周内发出去。

什么情况说明看错了:你在 issue 下的分析发出去一周没人回、没人点赞;同一个报错下已经有过百 star 的工具;或者你还在写的时候,官方发版说明里就出现了对它的专门修复。

GitHub 仓库 ↗

研究底稿:竞品表、获客证据、完整研究报告
竞品
名字在哪上线规模它和这家不同在哪
Codex 官方重试 / 10-15 过载修复大厂功能持续迭代,2026-10-15 宣布修复全部 Codex 用户官方按状态码重试,抓不到 HTTP 200 流里的 error 事件;它补的正是这个缺口
banana2556/codex-never-give-up开源2026-09-087 星在桌面 UI 层自动重发;它在协议层、输出前重试,用户无感
yuxi1989/Codex-RetryPilot、tidingman/codex-retry-watcher 等自动点重试开源2026-09~100–3 星只支持 macOS,模拟点击;它三平台都能用,还讲清了原理
LocusQiang/fxxk-u-tibo开源2026-10-222 星情绪化命名,只支持 Windows;它定位工程上可信
neuroborus/codex-retry、OddlyLabs/codex-longwatch 等十几个小工具开源2026-08~100–1 星没有数据、没讲原理、没去痛点集中的地方分发
CLIProxyAPI / gpt-load / codex-lb / axonhub / OmniRoute 的 overload 重试开源2026-10 前后各自加的 PR3k–58k 星(整个项目)是号池 / 中转网关里的一个功能,太重;它给只有一个官方号的个人用户,纯本机、不碰 token
各种「at capacity 怎么办」教程网页2026-07 起—只教等一下、换模型;它直接给工具
用户从哪来
  • 查实 官方 GitHub issue 种草:建库 19 分钟后在 openai/codex #28507(61 条评论的主帖)发长篇根因分析,08:10 又补「我修复了:<链接>」
  • 查实 X(中文):@NewbeeM4n 2026-10-24 发帖配前后对比图,6,215 次浏览,评论里有 Pro 用户诉苦
  • 查实 AI 新闻站 / 自动榜单:reveneau.com 10-28 发了一篇 AI 写的报道(当天 +34 星);encoreshao/github-trending 10-28~31 的 codex、python 主题榜收录
  • 查实 Agent Skill 包:v1.4.0(11-02)起提供 Skill 包,可以让 Codex 自己装;v1.4.1 Skill 包下载 194 次
  • 推断 中文开发者社区口口相传(linux.do / nodeseek):issue、PR 作者多是中文用户;中文圈普遍认为这个报错和号被风控有关,痛点更重;没找到具体帖子

NewBeeM4n/codex-overload-fix:为什么能跑出来

一句话

一个本机跑的 Python 中继:装在 Codex 和 OpenAI 之间,认出藏在 HTTP 200 流里的「Selected model is at capacity」错误,在开始输出前自动重试。它起来靠的是三样东西:一个持续了好几个月、官方也没修好的痛点;作者在痛点最集中的地方(openai/codex issue #28507、中文 X)直接贴出解决方案;一份数据扎实、写得很好的技术说明(「错误藏在 200 里,所以谁的重试都抓不到它」)。

基本数据(github 库 / GitHub API,2026-11-06)

  • 建库 2026-10-24,13 天。星 243(数据卡,11-06)/ 253(GitHub API 实时),fork 22–24。作者账号 2026-07 注册,只有这一个仓库,2 个粉丝。
  • 每天的星(数据卡 daily):10-26 25 → 10-28 68 → 10-30 113 → 11-02 126(平台期)→ 11-03 151 → 11-04 178 → 11-05 223 → 11-06 243。两波:10-27~29 一波,11-03~05 一波(单日最高 +45)。trending_days_any=0,Trendshift 也说「没进过 top 25」——没靠 trending。
  • 发布节奏很密:13 天发了 9 个版本(v1.0.0 10-24 → v1.5.1 11-05),先后补了 macOS、Linux、可装的 Agent Skill、本地面板。
  • Release 下载数(GitHub API):v1.4.1 zip 465 次 + Skill 包 194 次;v1.2.1 181 次;v1.5.x 合计约 320 次。全部 zip 加起来约 1,300 次,另外还有直接 git clone 的。真实安装量大概是千这个量级,和星数差不多。
  • Issue/PR 一共 6 个,都是真用户(Windows 中文用户名路径的 bug、打包宿主环境、新版桌面客户端兼容),外部贡献者 JSVan32 贡献了 Linux 启动器。

痛点和时机

  • 「Selected model is at capacity. Please try a different model.」从 2026 年中开始就是 Codex 最常见的报错:openai/codex #28507(2026-06-16 开,61 条评论,还开着)、#32020「容量满时自动重试」、#52394、#53594、#55294、#56105「紧急升级」等;OpenAI 社区好几个帖子;r/codex 有专门的讨论帖。OpenAI 状态页 2026-07-17 记过一次「Codex 5.6-sol 服务器过载错误增多」。
  • OpenAI 的 Codex 负责人 Tibo 在 2026-10-15 发帖(x.com/thsottiaux/status/2110750421367287996)说已经上线修复、加了算力,「它会自己继续,不会卡住」——可用户还在报。9 天后这个仓库就出来了,正好接住「官方说修好了,其实没修好」的那段空档。
  • 中文圈的痛更重:linux.do、nodeseek 上一堆帖子说这个报错跟「账号被风控 / 重置后的号」有关(linux.do/t/topic/3005361、2915761;nodeseek post-1007018 教人改请求头 x-openai-account-routing-override)。用共享号、中转、Plus 号的中国开发者撞上的频率最高,所以这个项目的用户明显以中文为主(双语 README、中文 issue、作者用中文发 X)。
  • 11-03~05 第二波,和这几件事时间对得上:GPT-6 Astra / 「codex6.1 老是繁忙」这一波新抱怨(nodeseek 11-03,OpenAI 社区「GPT-6-ASTRA 持续 at capacity」),以及 v1.4.0/1.4.1 出的「免费 Agent Skill」(11-02,下载量最大的一个版本)。

用户从哪来(增长手段)

  1. 在官方 issue 里种草(确认):作者在建库后 19 分钟,也就是 2026-10-24 01:16,在 openai/codex #28507 发了一篇长技术分析(「错误不是 5xx,是 HTTP 200 SSE 流里的 error 事件」+ 按请求大小分组的统计),08:10 又补一句「我修复了:github.com/NewBeeM4n/codex-overload-fix」。那个 issue 是全网被这个错误困住的人都会去的地方。Jina 搜索里这个 issue 的摘要已经带上了这个仓库的链接。
  2. 中文 X(确认):@NewbeeM4n 2026-10-24 01:23 发帖「被 Selected model is at capacity 困扰的朋友,可以看看我的解决方案…一整晚没再被它打断过」,配了前后对比图,6,215 次浏览;评论里有 $200 Pro 用户说「每天都是这样,我已经快疯了」。账号不大,但这条帖子精准打中了人。
  3. AI 自动写的新闻站转载(确认):reveneau.com 在 10-28 发了一篇 AI 写的报道「turns 71 at capacity rejections into zero」,和 10-28 那天 +34 星对得上。encoreshao/github-trending、star-finder、iodevz-news-bot 这些自动榜单在 10-25~31 收录了它(codex、python 主题日榜)。
  4. 中文社区口口相传(推测,未核实):issue 和 PR 作者多是中文用户(zqhehe、QiqiangLi、2310770803);D4wnnn 的移植版致谢里写的是「感谢作者的实测沉淀」。linux.do 上有没有专帖,需要登录看,没核实。
  5. Agent Skill 分发(确认):v1.4.0 起提供 Skill 包,用户可以直接让 Codex「用这个 skill 帮我装中继」。降低了安装门槛,v1.4.1 Skill 包下载 194 次。
  6. 没有发现广告、HN、Product Hunt、大号转发。x-radar 本地语料里查不到相关帖子(搜了 codex-overload-fix、at capacity,0 条)。

竞品

做同一件事的很多,但几乎都没起来:

名字形态上线规模(GitHub,11-06)和它的区别
Codex 官方自带重试 / 10-15 的修复大厂功能持续迭代所有 Codex 用户官方按状态码重试,抓不到 200 流里的 error;它补的正好是这个缺口
banana2556/codex-never-give-up开源,桌面自动重发2026-09-087 星在 UI 层自动重发;它在网络层、输出前重试,用户完全感觉不到
yuxi1989/Codex-RetryPilot、tidingman/codex-retry-watcher、chenjh16/codex-capacity-retry开源,macOS 自动点「重试」按钮2026-09~100–3 星模拟点击,只支持 Mac;它跨三个平台、走协议层
LocusQiang/fxxk-u-tibo开源,Windows 自动重试2026-10-222 星名字是骂人的情绪产品;它定位成「工程上可信」
neuroborus/codex-retry、wzyhn/codex-native-retry、xuanyue202/codex-auto-retry 等十几个开源 CLI 包装2026-08~100–1 星大多是单平台、没有数据、没有讲原理
OddlyLabs/codex-longwatch开源桌面伴侣2026-08-201 星管得更宽(断线、重启);没有传播
CLIProxyAPI(57.8k 星)、gpt-load(7.2k)、codex-lb(3.4k)、axonhub(5.4k)、OmniRoute、cc-switch(152k)、weave-os/router开源,多账号代理 / 中转网关2025~2026大它们在 2026-10 前后各自加了「Codex overload 重试」PR(gpt-load 10-23、axonhub 10-13、codex-lb #1935);但这些是给中转 / 号池用的重家伙,不是给「我就一个官方号」的个人用户的
各种教程文章(whizi、aident、verboo、知乎、B 站)网页2026-07 起—只教你等一下、换模型;它直接给工具

结论:竞品很多,但都是零星的小项目。它是这个细分里唯一一个过百星的独立工具,大约是第二名(7 星)的 35 倍。

差异化

  1. 讲清楚了「为什么别的重试都没用」:错误是 HTTP 200 SSE 流里的 error 事件,所以 HTTP 库、代理、客户端自己的重试都看不到它。这个发现让人信服,是传播的核心素材(reveneau 那篇整篇都在复述这一点)。
  2. 数据说话:「71 次请求,吸收了 82 次重试,0 次失败;一个 799 KB 的请求连挂 8 次,第 9 次成功」,外加请求大小和重试次数的关系、怎么给请求减肥(删掉没用的 skill、开新对话)。
  3. 讲安全和可逆:纯本机、只用标准库、只改 config.toml 里两行、卸载能逐字节还原、单独写了一节谈账号风险。这直接回应了中文圈对「中转 / 反代偷号」的警惕,强调「不是 relay 服务」。
  4. 工程完成度:三个平台都有安装脚本、CI 在真的 macOS / Ubuntu runner 上跑、43 项测试、Agent Skill 包、本地面板、11-05 的 v1.5.1 改用官方 openai_base_url,保留原有聊天的 provider 身份。

这些差异就是它跑出来的原因:同一个点子十几个人都做了,但只有它把「可信 + 能说清楚 + 投到对的地方」三件事凑齐了。

能见度和跟风

  • 能见度:小圈子里在传。没公开收入(开源免费,没有变现);没有大号 X 或主流媒体报道,只有一个 AI 自动写的新闻站(reveneau)和几个自动榜单;作者 X 帖 6.2k 浏览。
  • 跟风已经出现:aiyinsitan520/codex-overload-fix-cockpit(10-25,给 cockpit 网关的分叉,3 星)、jdp22/codex-overload-fix-with-visual(11-04,加了可视化,4 星)、D4wnnn/cpa-plugin-codex-overload-retry(11-06,把它的 relay.py 移植成 CLIProxyAPI 插件,致谢里写明了出处)、williamxhero/CLIProxyAPI-ex 的 PR「preserving Codex overload fix」,还有 JSVan32、ballardmandy69、BronyaDev 等直接 fork。

风险

  • 价值全靠 OpenAI 一直有容量问题;官方一旦修好(Tibo 10-15 已经在修),或者客户端自己学会识别流里的 error,它就没用了。Codex 发版很勤(11-05、11-06 都有新版),兼容性要一直追。
  • 对「被风控的号」来说,重试救不回来(issue #3 作者自己也承认)。
  • 没有变现路径,也没有护城河,代码是 MIT,已经被移植。

能借鉴的

  • 在痛点最集中的官方 issue 下先发一篇有数据的根因分析,再贴工具:这比发广告有效得多,零成本拿到第一批精准用户。
  • 痛点类工具,README 里「为什么别人修不好」的解释和前后对比的数据,比功能列表重要。
  • 碰账号、凭据的工具,把「本机、可逆、不碰 token、账号风险」写在最前面,尤其是面向中文用户的时候。
  • 把工具做成 Agent Skill(「让 Codex 自己装」),下载量最大的就是带 Skill 包的版本。
  • 机会窗口:大厂产品长期没修好的报错 + 官方嘴上说修好了 = 有人会给小工具点星。同一套打法可以用在 Claude Code、Cursor、Gemini CLI 的各种限流 / 过载报错上。

还不确定的

  • linux.do / V2EX 上有没有专帖、带来了多少流量(要登录,没核实);11-03~05 第二波具体是谁带起来的,没找到单一来源。
  • GitHub 访问来源(traffic API)只有仓库管理员能看,没法拿到。
  • 真实在用的人数:下载约 1.3k 次 + clone,留存不知道。

出处

文章由 AI 根据公开数据和我们每天采集的数据写成,数字带出处,推断已标明