There is a particular kind of interruption that is worse than an error message: the one that arrives halfway through a debugging thread, a refactor, or a long-running agent task.
For many Codex users, that interruption has a name: the rolling five-hour usage window.
Across Codex discussions, the complaints are remarkably consistent. Developers describe a limit that can be consumed far sooner than a five-hour work block; a short-window meter that has to be watched while they are trying to concentrate; and quota accounting that is difficult to relate to the work visible in the editor. The frustration is not simply that usage is finite. It is that real software work is bursty. A difficult bug may demand an intense, uninterrupted afternoon, then very little usage for the next two days.
The pain is sharper with agentic work. A task that appears small from the outside can involve repository exploration, tool calls, reviews, retries, and subagents. When the short window becomes the binding constraint, the practical question changes from "What is the best next step?" to "Can I afford to let the agent continue?"
That is not a great way to work.
I did not want to treat usage limits as something to defeat. They are part of the service I pay for and use. I wanted a better way to work with the accounts and OpenAI-compatible providers I legitimately use: see their health and remaining quota, choose deliberately, and avoid losing a session to a predictable 401, 429, or exhausted provider.
So I built Codex Conduit.
It is a local desktop gateway for Codex CLI, Codex App, and supported IDE integrations. It routes requests through accounts and providers configured on your own machine, exposes the state that matters, and can fail over to another healthy route when the current one cannot serve a request.
What I wanted from a local gateway
My goal was not another account switcher that rewrites a login file and asks me to restart everything. I wanted a control plane for local Codex traffic:
- Keep ChatGPT subscription accounts, OpenAI API keys, and OpenAI-compatible providers in one place.
- Show five-hour and weekly quota where the upstream exposes it, plus provider balances and account health.
- Switch routes without deliberately interrupting the current Codex workflow.
- Treat
401,429, and quota exhaustion as routing signals, then move to a healthy, permitted route. - Let me control whether free, relay, plan, or third-party routes participate in automatic selection.
- Restore my original Codex configuration when I stop using the gateway.
That is the role of Codex Conduit: a local routing layer, not a claim of unlimited usage. Every route still has its own terms, quota, and cost.
How I set it up
1. Download the desktop app
I downloaded the installer for my platform from the Codex Conduit Releases page. Current release assets include macOS and Windows builds.
Before enabling the proxy for the first time, I quit active Codex CLI and Codex App processes. This makes the configuration handoff predictable.
2. Add accounts I am authorized to use
In the app, I clicked + Sign In and completed the official OpenAI OAuth flow in my browser. Codex Conduit does not ask for an OpenAI password; authentication happens on OpenAI's authorization page.
For an OpenAI-compatible provider that I already use, I clicked + Add Third-Party Provider, selected or entered the provider details, and supplied my own API key. The app supports providers that expose either a /v1/responses or /chat/completions-compatible upstream.
The important rule here is simple: only add accounts and API credentials you own or are explicitly authorized to operate.
3. Check health and remaining capacity
On the Accounts page, I could see the current route, account type, available quota or balance, health state, and last refresh time.
This screen changed my behavior before automation even entered the picture. Instead of discovering that a route is exhausted after committing to a task, I can decide where to start it.
4. Enable the local proxy
Back on the Dashboard, I turned on Local Proxy.
Codex Conduit backs up ~/.codex/config.toml as config.toml.mybak, writes the local proxy configuration, and starts the gateway. Once the UI shows Proxy ON, I restart Codex CLI, Codex App, or the relevant IDE integration so future requests use the local route.
Turning the proxy off later stops the gateway and attempts to restore the previous Codex configuration. I prefer this reversible setup to hand-editing configuration files every time I want to change a route.
5. Choose a routing policy instead of hoping
In Settings > Background Services, I chose which routes could participate in automatic switching.
My conservative starting policy is:
- Keep third-party routes out of automatic selection unless I explicitly accept their cost and data-handling terms.
- Allow fallback to a healthy subscription account when the current third-party route fails.
- Leave free accounts out of the rotation unless I intentionally want to use their quota.
For people who operate a deliberate, approved pool of accounts and providers, the policy can be broader. The point is that it is explicit: cost-sensitive routes do not silently become the default.
What happens when a route fails
Codex Conduit runs locally between Codex and the configured upstreams:
Codex CLI / Codex App / supported IDE
|
v
Codex Conduit local gateway
|
healthy authorized account or provider
When the gateway sees an authentication failure, rate limit, or quota-exhaustion response, it can select the next healthy route allowed by the policy. That does not erase provider limits, and it cannot make an unavailable service available. It does reduce the manual work of diagnosing the failure, choosing a route, changing configuration, and restarting in the middle of a task.
The local dashboard also makes the decision visible. That matters: automated routing should be inspectable, especially when routes have different quotas or prices.
Why this helped me
The five-hour window is still a constraint on any individual subscription route. Codex Conduit does not pretend otherwise.
What changed is the operational experience:
- I see the likely constraint before I start a long task.
- I can keep my own approved routes organized in one desktop app.
- A predictable failure does not have to turn into a configuration emergency.
- I can separate a stability-first policy from a cost-first policy.
- When I no longer need the gateway, I can turn it off and recover the prior Codex configuration.
For me, that means less meter-watching and more time spent on the actual engineering problem.
Try it, and tell me what breaks
Codex Conduit is open source and available on GitHub:
https://github.com/cherrylfrei-max/codex-conduit
If you use Codex heavily, I would especially like feedback on three things: which quota signals are most useful, which provider failover cases need better handling, and how much routing detail should be visible while an agent is running.
What is the most disruptive part of the five-hour window in your workflow: the cap itself, the lack of predictability, or the interruption when a task is already in progress?
Top comments (1)
It very helpful, thank your share