Is it possible to set up flexible warm-up policies for Codex accounts with individual custom schedule?

[MoralStrike]

Hi, Is it possible to set up flexible warm-up policies for Codex accounts with individual custom schedule?
The warm-up, if implemented, should respect proxy settings.

If something like that already exists, could you please point me -- I'm not seeing any warm-up settings for Codex.

Thank You!

[MoralStrike]

I found this setting:
Opt-in per connection: sends a tiny request right after a Codex session window resets so it isn't cold when you need it.

Could somebody please chime in:

• If it's activated for all accounts at the same time and, therefore, pings/pre-warms them all at the same time from the same IP, can it cause issues?
• How many tokens does the pre-warm ping use?
• Does the ping embed the codex prompt and fingerprint in the ping request? If not, can it cause issues (by showing up as a non-codex client)?
• If the pre-warm is left 24/7, can it cause any issues other than quota exhaustion?
• If a proxy goes down, will the ping go out over direct connection anyway?

Thanks

[diegosouzapw]

@MoralStrike You found the right setting. It's the only warm-up there is, and it isn't schedule-based. Answers from the code (src/lib/services/quotaAutoPing.ts, src/shared/constants/quotaAutoPing.ts):

When it fires. Not on a timer you set. Once a minute it checks each opted-in Codex connection's session window, and it pings only when the window has rolled over while nobody was using it. It skips a connection that was pinged in the last 10 minutes, that is rate-limited, whose provider circuit is open, whose weekly quota is already used up, or that failed a ping in the last 15 minutes. On an idle account that works out to roughly one ping per 5-hour window. Kept on 24/7, it uses a little quota each time a window rolls idle, and nothing else.

All accounts at once. They're checked in one pass, one after another, not in parallel. But accounts whose windows roll in the same minute do get pinged back to back, and there's no jitter between them. A custom per-account schedule doesn't exist.

Size. The request is the prompt hi with the instruction Reply with OK., reasoning effort none, store: false. That's a few dozen tokens in and a couple out.

Fingerprint. It goes through the same Codex executor as your normal Codex traffic, so it's shaped and headed like any other Codex request from OmniRoute, not a bare API call. It does not replay your own coding prompt.

Proxy: it does not respect it today. That's a bug, and your question is what surfaced it. The ping and the usage read that triggers it are sent without the connection's proxy context, so they leave through the global HTTP(S)_PROXY if you set one, or directly from the server's IP if you didn't. Token refresh and the dashboard's quota reads do use the connection's proxy; only the warm-up doesn't. So the "proxy down" case doesn't even come up yet: it never uses the proxy in the first place.

Until that's fixed, if the per-account proxy matters to you, leave the warm-up off for those accounts. Tracked in #14997, together with the option to spread pings out instead of bursting them.

[MoralStrike]

You found the right setting.

BTW, I had hard time finding it because the search has issues - it's failing to find the settings by their strings:

Here it's failing to find Auto and cold in:

Codex Quota Auto-Ping
Consumes a small amount of real Codex quota on every ping. Off by default — enable only for connections you actively rely on.
Opt-in per connection: sends a tiny request right after a Codex session window resets so it isn't cold when you need it.

[MoralStrike]

Thank you for your reply @diegosouzapw

All accounts at once. They're checked in one pass, one after another, not in parallel. But accounts whose windows roll in the same minute do get pinged back to back, and there's no jitter between them. A custom per-account schedule doesn't exist.

Is it possible to introduce throttle delay to spread out the warm-up pings? A burst of request by multiple accounts at the same time (when, for example, you turn on your laptop and all accounts are cold) can cause token revocation.

Proxy: it does not respect it today. That's a bug, and your question is what surfaced it. The ping and the usage read that triggers it are sent without the connection's proxy context, so they leave through the global HTTP(S)_PROXY if you set one, or directly from the server's IP if you didn't. Token refresh and the dashboard's quota reads do use the connection's proxy; only the warm-up doesn't. So the "proxy down" case doesn't even come up yet: it never uses the proxy in the first place.

Oh, I'm glad we caught it. That's sounds like a good way to nuke the tokens. :)

It does not replay your own coding prompt.

Is that considered normal looking traffic to OAI? Is that shaped as a codex exec call?
I use several paid accounts for personal work because one is not enough for me, but I am wary of OAI mistakenly thinking I'm a bunch of people behind sub2api. I'm just a regular person pooling my accounts to get stuff done. So, can regular automated prompt-less pings trigger a false positive of any kind?

Thanks

[diegosouzapw]

@MoralStrike Taking these in order.

Spreading the pings out. Not possible today. Adding a per-connection delay (jitter) so connections that go cold together don't all fire at once is already part of #14997, alongside the proxy fix. The two belong together: once the ping goes through each account's own proxy, spacing the pings out is the other half.

Does it look like normal Codex traffic? Some of it I can answer from the code. The rest I can't. It goes through the same Codex executor as your real Codex requests, so its request shape and headers match OmniRoute's normal Codex traffic. It isn't an exec session, though. It's one short request (hi, "Reply with OK.", reasoning off) sent at the moment a window rolls over. How OpenAI's systems classify that pattern, I can't tell you. They don't publish it, and I won't guess. If a false positive is the risk you care about most, the conservative choice is to leave the warm-up off: the only cost is that the first request after an idle window starts cold.

Finding the setting. The sidebar search only matches the names of sidebar items (src/shared/utils/sidebarSearch.ts), not the text inside settings pages. So "auto" and "cold" come up empty even though the card is there. The card is under Settings → AI → Codex Quota Auto-Ping. Searching the text of settings pages would be a separate feature. That's a fair request; open it as an issue if you'd like it tracked.

[MoralStrike]

Finding the setting. The sidebar search only matches the names of sidebar items (src/shared/utils/sidebarSearch.ts), not the text inside settings pages. So "auto" and "cold" come up empty even though the card is there. The card is under Settings → AI → Codex Quota Auto-Ping. Searching the text of settings pages would be a separate feature. That's a fair request; open it as an issue if you'd like it tracked.

done:

#15079