Root-cause analysis under an official issue: a small tool that fixes a Codex error, 13 days, 250 stars
What it is A small local Python relay that sits between Codex and OpenAI. When it sees the "at capacity" error, it retries automatically before any output is shown, so the user never notices the interruption.
Why it blew up The bug dragged on for months, and the official October update said it was fixed when it wasn't. The author posted a data-backed root-cause analysis under the official issue, with 61 comments, then took almost all the attention in its category with a Chinese X thread and a three-platform engineering breakdown that was safe and reproducible.
BHow you could follow it Don't build another Codex retry tool. Use the same playbook on errors that Claude Code, Cursor, Gemini CLI, and similar tools have left unfixed for a long time: first post a root-cause analysis under the official issue, then ship a small local, reversible tool with measured numbers.
- Data (updated daily) · Repo created 2026-10-24 · 252 stars · 7 days +129
GitHub · stars Data 2026-10-26 → 2026-11-08 (14 days, 14 observations). Points before 10-28 come from deeply / archive backfill, not every day has one
A GitHub account with only this one repo and two followers built a small local relay aimed at Codex's "Selected model is at capacity" error. At least a dozen people had built something similar, most with 0 to 7 stars. This one hit over two hundred in 13 days and never made it onto trending. The difference wasn't the code. It explained clearly why everyone else's retries didn't work, and posted that explanation where every affected user would see it.
A comment at 1 a.m.
On 2026 Oct 24 00:57 (UTC), NewBeeM4n created the codex-overload-fix repo. 19 minutes later, he posted a long comment under issue #28507 in openai/codex. The issue was opened in Jun 16 with the title of that exact error message, has 61 comments, and was still open as of November. Anyone stuck on this error who searches for it ends up here in the end.
His comment didn't lead with a link. It explained the cause first: the error isn't 5xx. The server returns HTTP 200, and the error is hidden in an error event inside the SSE stream. That means HTTP libraries, proxies, and Codex's own status-code retry logic can't see it. He attached statistics grouped by request size. The next morning, 8:10, he added: I fixed it, here's the repo.
01:23 He posted on X in Chinese: "Friends bugged by 'Selected model is at capacity,' check out my fix. I've fully solved it on my end, and it hasn't interrupted me once all night." He attached two before-and-after screenshots and added below: "Same network, same device, same Plus account." The post got about 6,200 views by 11-06. On Oct 28, someone replied: "200pro plan gets this every day, I'm about to lose it…"
What it is
A local relay built with only the Python standard library, sitting between Codex and OpenAI. It watches the response stream, and if it sees a capacity error before any output starts, it retries on its own, invisible to the user. The install script changes just two lines in Codex's config.toml, backs up the file first, and uninstall restores it byte for byte. There are install scripts for Windows, macOS, and Linux, and no admin rights are needed.
The README opens with measured results: over one night, 71 requests, the relay absorbed 82 retries, and the failure the user saw was 0. "A 799 KB request failed 8 times in a row, then succeeded on attempt 9." Right after, a disclaimer: it reduces interruptions, but it can't create server capacity or improve model quality.
In 13 days it shipped 9 versions. First macOS and Linux support, then 11-02 an Agent Skill package that Codex can install itself, then a local dashboard, and 11-05 v1.5.1 compatibility with the newer client. Combined downloads across all release packages come to about 1,300 (GitHub, 11-06), roughly the same order of magnitude as the star count, so people are likely actually using it.
Why now
This error has been one of Codex's most common complaints since mid-2026. Beyond #28507, there are several other issues about automatic retry on capacity, OpenAI community posts, and r/codex threads. In Oct 15, Tibo, the Codex lead at OpenAI, said on X that a fix had shipped and more compute was added, and "it will keep going on its own, it won't get stuck." Users kept reporting it. 9 days later this repo appeared, filling the gap between "officially fixed" and "not actually fixed yet."
Chinese developers hit this the hardest. Threads on linux.do and NodeSeek tie the error to "account flagged for risk control" and "reset accounts," and some people share header tweaks. Users of Plus accounts, shared accounts, and relays hit it most often, so from day one the project has had a bilingual README, its author posted in Chinese, and many issues and PRs come from Chinese users.
How the stars climbed day by day
| Timeline | What happened | Stars (GitHub, daily) |
|---|---|---|
| 10-24 | Repo created; root-cause analysis posted under the official issue; Chinese X post | — |
| 10-26 | 25 | |
| 10-28 | An AI-written news site ran a story restating the headline "71 capacity rejections turn into 0"; several automated trending lists picked it up | 68 (+34 that day) |
| 10-30 | 113 | |
| 11-02 | Plateau; an Agent Skill package shipped the same day and later became the most downloaded version | 126 |
| 11-03 to 11-05 | After a new model launch, complaints about it "always being busy" came back; single-day peak +45 | 151 → 223 |
| 11-06 | 243 (currently about 253), 22 forks |
No ads, no HN, no Product Hunt, no big-account retweets. I couldn't find a single source for the second wave; whether there's a dedicated linux.do thread is behind a login, so I haven't verified it.
A dozen people built the same thing
| Project | star(11-06) | How it differs |
|---|---|---|
| Codex official retry | — | Retries on status codes and can't catch errors inside the 200 stream; this project fills that gap |
| codex-never-give-up | 7 | Auto-resends at the desktop UI layer; this one retries at the network layer, before any output |
| Codex-RetryPilot, codex-retry-watcher, and others | 0–3 | Mac only, simulates clicking the "Retry" button |
| fxxk-u-tibo | 2 | The name is an insult, Windows only |
| codex-retry, codex-auto-retry, and about ten more | 0–1 | Single platform, no data, no explanation of the mechanism |
| Gateways like CLIProxyAPI, gpt-load, and axonhub | Whole repos of several thousand to tens of thousands of lines | Each added overload retry around October, but that was for account pools and relays, heavy machinery, not for "I have one official account" users |
It has roughly 35 times the stars of second place. Several forks and ports have appeared: someone added a visualization (4 stars), and someone ported it to a CLIProxyAPI plugin, crediting "the author's hands-on work" in the acknowledgments.
Why it stood out from the pack
Explain the cause first, then give the tool. "The error is hidden inside 200, so nobody's retry catches it" is a line people can repeat. The news site built its whole piece on that point. Other projects only said "I auto-retry," which gave readers no reason to trust it more than the rest.
Post where the pain is concentrated. Not an ad, but a data-backed analysis under the official issue with 61 comments. Everyone who later searches for this issue sees it.
Lead with safety. Purely local, standard library only, changes two lines, reversible, with a separate section on account risk. The Chinese community is wary of "relays that steal accounts," and this answers that directly.
Engineered like a real project. Install scripts for three platforms run in CI on real macOS and Ubuntu machines, 40 test cases, 13 days and 9 versions, and issues get fast replies.
Where the ceiling is
Its value rests entirely on "OpenAI keeps having capacity problems." If the official side fixes it for real, or the client learns to detect errors in the stream, it becomes useless. Retries also can't rescue flagged accounts, which the author admits in the issue. So stars will probably stall in the hundreds: the audience is people stuck on this error who are willing to run a local relay, and that group won't grow much.
If it were you
The takeaway: don't build another Codex overload retry, that spot is taken. What's worth copying is the playbook: find an error a big AI tool vendor has left unfixed for a long time, post a data-backed root-cause analysis under the official issue, then attach a credible, reversible small tool. Projects like this reliably get a few hundred stars, and rarely a few thousand.
Who it's for: developers who use Claude Code, Cursor, Gemini CLI, or Codex heavily every day and are willing to capture traffic to find causes; people who want an open-source piece on their resume that can clearly explain what it solved.
Who it's not for: people who want thousands or tens of thousands of stars; people unwilling to keep up with upstream weekly releases; people who can only write wrapper scripts and can't explain root causes.
How to do it:
- Go to the GitHub issues of each AI coding tool, sort by comment count, and look for errors open for months that are still unresolved, where the vendor has said "fixed" but people keep reporting them (my guess: rate limits, overload, long-conversation truncation, and MCP disconnects are the likeliest).
- Reproduce it yourself, capture traffic, and find the one sentence explaining why existing retries or settings can't fix it. If you can't find that sentence, don't build it.
- Keep the tool small: local, zero dependencies, minimal config changes, one-command revert. Put before-and-after comparisons and an evening's worth of test numbers on the first screen of the README, and risks and limitations on the second.
- On the day you create the repo, post the analysis under that issue and link back to it; at the same time, post a short X thread with a screenshot on your own account, in Chinese if your audience is mostly Chinese-speaking.
- Release at high frequency for the first two weeks and keep up with upstream compatibility; build an Agent Skill package so agents can install it themselves.
How to get users: the official issue is the home turf, X and Chinese developer communities are the second front; automated lists and AI-written news sites will find you on their own.
When to move: watch the error, not the calendar. The window runs from "vendor says it's fixed but it isn't" to "actually fixed," usually a few weeks to a few months. Ship within a week of spotting the target.
Signs you misread the situation: your analysis under the issue gets no replies or likes for a week; a tool for the same error already has hundreds of stars; or the vendor's release notes add a dedicated fix for it while you're still writing.
Research notes: competitor table, acquisition evidence, full research report
- Competitors
Name Where Launched Scale How it differs from this one Codex official retry / 10-15 overload fix Big-company features Ongoing iteration; 2026-10-15 announces a fix All Codex users Official retry works on status codes and can't catch the error event inside the HTTP 200 stream; this fills exactly that gap banana2556/codex-never-give-up Open source 2026-09-08 7 stars Auto-resends at the desktop UI layer; this one retries at the protocol layer, before output, invisible to the user yuxi1989/Codex-RetryPilot, tidingman/codex-retry-watcher, and other auto-click retry tools Open source 2026-09~10 0–3 stars macOS only, simulates clicks; this one works on all three platforms and explains the mechanism LocusQiang/fxxk-u-tibo Open source 2026-10-22 2 stars Emotionally charged name, Windows only; this one is positioned as engineering you can trust neuroborus/codex-retry, OddlyLabs/codex-longwatch, and a dozen-plus small tools Open source 2026-08~10 0–1 stars No data, no explanation of the mechanism, no distribution where the pain is concentrated Overload retries in CLIProxyAPI / gpt-load / codex-lb / axonhub / OmniRoute Open source PRs added around 2026-10, before and after 3k–58k stars (whole project) Only a feature inside account-pool and relay gateways, too heavy; this one targets individuals with a single official account, is purely local, and never touches tokens Various "what to do at capacity" tutorials Web From ¥2026-07 — They just say wait it out or switch models; this one gives you a tool - Where users come from
- Verified Seeded on the official GitHub issue: 19 minutes after creating the repo, a long root-cause analysis was posted on openai/codex #28507 (main thread with 61 comments), and 08:10 later added "I fixed it: <link>"
- Verified X (Chinese): @NewbeeM4n posted with a before-and-after image, 2026-10-24 views (6,215 views in total), with Pro users complaining in the comments
- Verified AI news sites / auto-generated charts: reveneau.com published an AI-written report on 10-28 (+34 stars that day); encoreshao/github-trending charted 10-28–31 in the codex and python topic lists
- Verified Agent Skill package: from v1.4.0 (11-02) it ships a Skill package that lets Codex install it itself; the v1.4.1 Skill package has 194 downloads
- Inferred word of mouth in Chinese developer communities (linux.do / NodeSeek): the issue and PR authors are mostly Chinese-speaking users. Chinese forums widely believe this error is tied to account risk controls, so the pain is sharper there. No specific thread found.
NewBeeM4n/codex-overload-fix: why it works
One line
A local Python relay that sits between Codex and OpenAI, detects the "Selected model is at capacity" error hidden inside the HTTP 200 stream, and retries automatically before any output starts. It took off for three reasons: a pain point that lasted months and that OpenAI still hadn't fixed; the author posted the fix directly where the pain was concentrated (openai/codex issue #28507, Chinese X); and a well-sourced, well-written technical explanation ("the error is buried in 200, so no one's retry logic can catch it").
Basic data (GitHub repo / GitHub API, 2026-11-06)
- Repo age: 2026-10-24,13 days. Stars 243 (data card, 11-06) / 253 (GitHub API, live), forks 22–24. Author account registered 2026-07, this is their only repo, 2 followers.
- Daily stars (data card): 10-26 25 → 10-28 68 → 10-30 113 → 11-02 126 (plateau) → 11-03 151 → 11-04 178 → 11-05 223 → 11-06 243. Two waves: 10-27~29, then 11-03~05 (single-day peak +45). trending_days_any=0, and Trendshift says it never made the top 25: it did not ride trending.
- Very dense release cadence: 13 days, 9 versions (v1.0.0 10-24 → v1.5.1 11-05), adding macOS, Linux, an installable Agent Skill, and a local dashboard in turn.
- Release download counts (GitHub API): v1.4.1 zip 465 times + Skill package 194 times; v1.2.1 181 times; v1.5.x about 320 in total. All zips combined come to about 1,300, plus direct git clones. Real installs are probably in the thousands, roughly on par with the star count.
- 6 issues and PRs in total, all from real users (a bug with Chinese-character usernames in Windows paths, bundling into host environments, compatibility with new desktop clients). External contributor JSVan32 contributed the Linux launcher.
Pain point and timing
- "Selected model is at capacity. Please try a different model." has been Codex's most common error since mid-2026: openai/codex #28507 (opened 2026-06-16, 61 comments, still open), #32020 "auto-retry when at capacity", #52394, #53594, #55294, #56105 "urgent upgrade", and more; several threads in the OpenAI community; a dedicated discussion on r/codex. The OpenAI status page logged "increased Codex 5.6-sol server overload errors" once: 2026-07-17.
- OpenAI's Codex lead Tibo posted on 2026-10-15 (x.com/thsottiaux/status/2110750421367287996) saying a fix had shipped, compute had been added, and "it will keep going on its own, it won't get stuck." Users kept reporting the error anyway. 9 days later this repo appeared, right in the gap between "OpenAI says it's fixed" and "it isn't."
- The pain is sharper in the Chinese community: many linux.do and NodeSeek threads claim this error is tied to "account risk control / reset accounts" (linux.do/t/topic/3005361, 2915761; NodeSeek post-1007018 tells people to change the request header
x-openai-account-routing-override). Chinese developers using shared accounts, relays, or Plus accounts hit it most often, which is why the project's users are mostly Chinese-speaking (bilingual README, Chinese issues, the author posting on X in Chinese). - A second wave, 11-03~05, lines up with these events: new complaints about GPT-6 Astra and "codex6.1 constantly busy" (NodeSeek 11-03; OpenAI community "GPT-6-ASTRA persistently at capacity"), plus the "free Agent Skill" release in v1.4.0/1.4.1 (11-02, the most-downloaded version).
Where users come from (growth levers)
- Seeding in the official issue (confirmed): the author posted a long technical analysis on openai/codex #28507 19 minutes after building the repo, on 2026-10-24 01:16 ("the error isn't 5xx, it's the error event in the HTTP 200 SSE stream", plus stats grouped by request size). Then 08:10 they added: "I fixed it: github.com/NewBeeM4n/codex-overload-fix". That issue is where everyone stuck on this error ends up. In Jina search, the issue's summary already includes a link to the repo.
- Chinese X (confirmed): @NewbeeM4n posted on 2026-10-24 01:23: "For friends bothered by Selected model is at capacity, check out my fix… haven't been interrupted by it all night," with a before/after image, 6,215 views. In the replies, a $200 Pro user said "it's like this every day, I'm nearly losing my mind." The account isn't big, but the post hit the target precisely.
- Reprinted by an AI-written news site (confirmed): reveneau.com published an AI-written piece on 10-28, "turns 71 at capacity rejections into zero," which matches the +10-28 stars that day 34. Automated trending aggregators encoreshao/github-trending, star-finder and iodevz-news-bot picked it up on 10-25~31 (codex and python topic daily lists).
- Chinese community word of mouth (inferred, unverified): the issue and PR authors are mostly Chinese-speaking (zqhehe, QiqiangLi, 2310770803); D4wnnn's port credits the author with "hands-on findings." Whether there's a dedicated linux.do thread needs a login to check; not verified.
- Agent Skill distribution (confirmed): from v1.4.0 onward it ships a Skill package, so users can simply tell Codex "use this skill to install the relay for me." That lowered the install barrier; the v1.4.1 Skill package had 194 downloads.
- No ads, HN, Product Hunt, or big-account reposts found. The local x-radar corpus has no matching posts (searched codex-overload-fix and at capacity, 0 results).
Competitors
Many projects do the same thing, but almost none took off:
| Name | Form | Launched | Scale (GitHub, 11-06) | How it differs |
|---|---|---|---|---|
| Built-in Codex retry / 10-15 fixes | Big-company features | Ongoing iteration | All Codex users | The official one retries by status code, so it can't catch the error inside the 200 stream. That's the gap this fills. |
| banana2556/codex-never-give-up | Open source, auto-resend in the desktop app | 2026-09-08 | 7 stars | Auto-resends at the UI layer; this retries at the network layer, before any output, invisible to the user |
| yuxi1989/Codex-RetryPilot, tidingman/codex-retry-watcher, chenjh16/codex-capacity-retry | Open source, auto-clicks the "retry" button on macOS | 2026-09~10 | 0–3 stars | Simulates clicks, Mac only; this works across three platforms at the protocol layer |
| LocusQiang/fxxk-u-tibo | Open source, Windows auto-retry | 2026-10-22 | 2 stars | The name is a rage-bait emotional product; this positions itself as "engineering you can trust" |
| neuroborus/codex-retry, wzyhn/codex-native-retry, xuanyue202/codex-auto-retry and a dozen more | Open source CLI wrappers | 2026-08~10 | 0–1 stars | Mostly single-platform, no data, no explanation of how it works |
| OddlyLabs/codex-longwatch | Open source desktop companion | 2026-08-20 | 1 stars | Covers more ground (disconnects, restarts); no spread |
| CLIProxyAPI (57.8k stars), gpt-load (7.2k), codex-lb (3.4k), axonhub (5.4k), OmniRoute, cc-switch (152k), weave-os/router | Open source, multi-account proxies / relay gateways | 2025~2026 | Big | Around 2026-10 they each added "Codex overload retry" PRs (gpt-load 10-23, axonhub 10-13, codex-lb #1935). But those are heavy tools for relays and account pools, not for individual users who have just one official account. |
| Various tutorial articles (whizi, aident, verboo, Zhihu, Bilibili) | Web | From ¥2026-07 | — | They just tell you to wait or switch models; this hands you a tool |
Verdict: lots of competitors, but they're all scattered small projects. This is the only standalone tool in the niche past 100 stars, roughly 35× the runner-up (7 stars).
Differentiation
- Explains clearly why other retries don't work: the error is an
errorevent in an HTTP 200 SSE stream, so HTTP libraries, proxies, and the client's own retry logic can't see it. That finding is convincing and it's the core of the spread (the reveneau article restates it throughout). - Data-driven: "71 requests, absorbed 82 retries, 0 failures; a 799 KB request failed 8 times in a row and succeeded on attempt 9," plus the relationship between request size and retry count, and how to shrink requests (delete unused skills, start a new conversation).
- Addresses safety and reversibility: purely local, standard library only, changes just two lines in
config.toml, uninstall restores it byte for byte, and a dedicated section on account risk. This speaks directly to Chinese users' wariness of "relays / reverse proxies stealing accounts," stressing that it "is not a relay service." - Engineering polish: install scripts for all three platforms, CI running on real macOS / Ubuntu runners, 43 tests, an Agent Skill package, a local dashboard, and in v1.5.1 (11-05) it switched to the official
openai_base_urlto preserve the existing chat provider identity.
These differences are why it took off: many people built the same idea, but only this one combined "trustworthy + explainable + posted in the right place."
Visibility and copycats
- Visibility: spreading in small circles. No public revenue (open source, free, no monetization). No big-account X posts or mainstream coverage, just one AI-written news site (reveneau) and a few automated trending lists. The author's X post has 6.2k views.
- Copycats already exist: aiyinsitan520/codex-overload-fix-cockpit (10-25, a fork for the cockpit gateway, 3 stars), jdp22/codex-overload-fix-with-visual (11-04, adds visualization, 4 stars), D4wnnn/cpa-plugin-codex-overload-retry (11-06, ports its relay.py into a CLIProxyAPI plugin with credit to the source), a PR on williamxhero/CLIProxyAPI-ex titled "preserving Codex overload fix," plus direct forks by JSVan32, ballardmandy69, BronyaDev and others.
Risks
- Its value rests entirely on OpenAI having ongoing capacity problems. Once the official side is fixed (Tibo 10-15 is already working on it), or the client itself learns to recognize errors in the stream, it becomes useless. Codex ships releases often (11-05 and 11-06 both had new versions), so compatibility has to be kept up constantly.
- For a "risk-controlled account," retries can't rescue it (the author of issue #3 admits as much).
- No monetization path and no moat: the code is MIT-licensed and already being ported.
What to borrow
- Post a data-backed root-cause analysis on the official issue where the pain is concentrated, then share the tool: far more effective than advertising, and it gets the first precise users at zero cost.
- For pain-point tools, the README's explanation of "why others haven't fixed it" and the before/after data matter more than the feature list.
- For tools that touch accounts or credentials, lead with "local, reversible, never touches tokens, account risk", especially when targeting Chinese users.
- Ship the tool as an Agent Skill ("let Codex install it itself"). The most-downloaded version was the one with the Skill package.
- Window of opportunity: a bug a big company hasn't fixed for months + the official line that it's already fixed = people will star small tools. The same playbook works for rate-limit and overload errors in Claude Code, Cursor, and Gemini CLI.
Still unclear
- Whether there are dedicated threads on linux.do / V2EX or how much traffic they brought (login required, not verified); 11-03~05 who specifically pushed the second wave, no single source found.
- GitHub traffic sources (traffic API) are only visible to repo admins, so no access.
- Actual active users: about 1.3k downloads plus clones, retention unknown.
Sources
- Data card /home/ljr/fanout/why/cards/gh_NewBeeM4n__codex-overload-fix.json; GitHub API (repo, release download counts, issues, 2026-11-06)
- github.com/openai/codex/issues/28507 (author 2026-10-24 01:16, 08:10 two comments)
- x.com/NewbeeM4n/status/2113803613500023034 (6,215 views)
- x.com/thsottiaux/status/2110750421367287996 (OpenAI 10-15 said it's fixed)
- reveneau.com/ainews/codex-overload-fix-local-retry-shim-newb…(10-28)
- trendshift.io/repositories/318136 (never made the top 25)
- www.nodeseek.com/post-1007018-1, linux.do/t/topic/3005361 (the Chinese-community risk-control theory)
- github.com/D4wnnn/cpa-plugin-codex-overload-retry (port, credits the original project)
- Competitor star counts: GitHub search/repos API, 2026-11-06