AI NewsDev toolsAnnouncement

Codex Overload Fix turns 71 "at capacity" rejections into zero

Codex Overload Fix is a local retry shim. It catches Codex's "Selected model is at capacity" error and retries until the turn succeeds.

AI News

Editorial2 min read

LinkedInX
GitHub social card for the codex-overload-fix repository

Image: GitHub

Why it mattersA long multi-step task no longer breaks every two turns on a crowded account. The fix is a one-file Python relay that keeps running until the model answers.

A developer called NewBeeM4n has released Codex Overload Fix. It is an MIT-licensed Python relay that catches the "Selected model is at capacity. Please try a different model." error inside the Codex stream and retries the turn until it succeeds. The author's own log over one evening shows 71 requests, 82 retries absorbed, and zero failures reaching the user. The repository is four days old and has 92 stars.

Why the error reaches the user at all

The author writes that the capacity rejection is not an HTTP status code. It arrives as an error event inside an HTTP 200 Server-Sent Events stream. The body carries server_is_overloaded or service_unavailable_error. Nothing that retries on status codes sees it: no proxy, no HTTP library, and not Codex's own retry layer. The stream is read to completion, then judged a failure, and the client gives up.

The shim at relay/relay.py is a single file. It parses the SSE stream. It matches six overload codes: server_is_overloaded, server_overloaded, service_unavailable_error, flex_unavailable, queue_full, and HTTP 429 or 5xx. It stops the moment a response.output_text.delta or response.reasoning_summary_text.delta has been emitted. Nothing is generated twice.

What the author measured

Across 71 Codex calls on one account in one evening, the author grouped the request bodies by size. Below 500 KB, every bucket needs about 1.7 to 2.0 attempts on average. The worst case there is 9 tries. Above 500 KB, the mean jumps to 6.75 attempts and the worst case stays at 9. One 799 KB request needed 9 tries. Only four requests in the sample were above 500 KB. The author calls that a signal, not a measurement at scale.

Where does the bulk come from on a fresh desktop conversation of 89 KB? The author lists four parts. Tool definitions take 27.6 KB. Base system instructions take 17.7 KB. A skill manifest with 72 installed skills takes 20.4 KB. A memory block takes 12.8 KB. On a long thread, Codex's own log reported about 724 KB sent every turn.

The second half of the fix is making the request smaller

The author writes that the shim hides the rejection, it does not create capacity. Starting a new conversation is the single biggest lever. The whole thread is resent every turn. Removing 37 unused skills and four non-native plugins took one body from 89 KB to 71 KB. That is a 20 percent cut. The author also recommends trimming the memory block, which is sent every turn. Compressing an attached image is the other fix. A first turn with a reference image can open at over 700 KB.

The shim is reversible by deleting one line from config.toml. It uses only the Python standard library and keeps request bodies, authentication headers and SSE payloads byte-identical in both directions.

Source

Primary source: NewBeeM4n/codex-overload-fix on GitHub.

This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.

Share
LinkedInX
Start a project