Question: are Codex usage fetches from /api/v1/me/status and the quota-cache background refresh paced by the #6009 throttle?

[MoralStrike]

Hi! I'm working on a few large projects, so I currently run couple paid Codex accounts behind one OmniRoute instance. After reading #6009 and #12209, I've been trying to make sure my setup is respectful and doesn't spam bursts of /wham/usage requests from one IP. While reading the code, I found two paths where I couldn't find any pacing. There may well be a mechanism I'm not seeing, so I wanted to ask rather than assume.

This comes from reading main at a58000c, not from watching live traffic, so please correct me if I've misread something.

What I understand so far

• throttleQuotaFetch() is called from the dedicated fetchers, e.g. codexQuotaFetcher.ts#L240, and from Auto-Ping since fix(providers): gate the Codex auto-ping usage read on the shared quota throttle #12209.
• The bulk provider-limits sync spaces OAuth accounts 1.5 s apart (providerLimits.ts#L645).
• getCodexUsage() calls fetch() directly (usage/codex.ts#L49), and getUsageForProvider() dispatches to it without the throttle (usage.ts#L157). So I believe it's paced only when its caller paces it.

Path 1: /api/v1/me/status with the Shared Account Quota scope

resolveAccountQuotas() runs Promise.all(connections.map(resolveConnectionAccountQuota)) (apiKeySelfService.ts#L353-L360). Each of those calls fetchAndPersistProviderLimits(id, "manual") (L318). If the key isn't restricted to specific connections, it looks like a single /me/status request starts a live usage fetch for every active account at the same time.

Path 2: quota-cache background refresh

backgroundRefreshTick() runs every 60 s and refreshes entries older than 5 min in batches of 5 with Promise.allSettled (quotaCache.ts#L879-L897). refreshEntry() calls getUsageForProvider(connection) (L851). After a bulk sync, the entries' fetchedAt values are about 1.5 s apart. If I'm reading this right, they all go stale in the same tick and are then refreshed up to 5 at a time.

Questions

1. Is there pacing on these paths that I'm missing, for example in the proxy layer or somewhere above getCodexUsage()?
2. If not, is it intentional? For example, maybe the 5-minute refresh is considered low-risk.
3. If it's worth changing, would it make sense to gate inside getCodexUsage() so every caller is covered? Or would that double-gate callers that already throttle, like Auto-Ping after fix(providers): gate the Codex auto-ping usage read on the shared quota throttle #12209?

Thanks for all the work!

[diegosouzapw]

@MoralStrike Your reading is correct, on both paths. I checked each one against the current release/v3.8.51 tip, not just main at a58000c.

What is paced, and what isn't. throttleQuotaFetch() (open-sse/services/quotaFetchThrottle.ts) is a min-interval gate, 250 ms by default, capped at 5 s, tunable with OMNIROUTE_QUOTA_FETCH_MIN_INTERVAL_MS. It's called from the dedicated fetchers (codexQuotaFetcher.ts:240 and the other providers' fetchers) and from Auto-Ping. getCodexUsage() (open-sse/services/usage/codex.ts:49) is a bare fetch(), and getUsageForProvider() reaches it without any gate. Nothing above it, including the proxy layer, adds pacing.

Path 1: /api/v1/me/status (Shared Account Quota scope). Confirmed. resolveAccountQuotas() does Promise.all over the connections (src/lib/usage/apiKeySelfService.ts), and each one calls fetchAndPersistProviderLimits(id, "manual"). The "manual" source sets forceRefresh: true (src/lib/usage/providerLimits.ts). So one /me/status call with that scope, on a key not restricted to specific connections, starts a forced live usage fetch for every active connection at the same moment, with no spacing. Does the limits cache absorb repeat calls? No. fetchLiveProviderLimitsWithOptions goes straight to the upstream fetch, with no cache check ahead of it. Like Path 2, it runs inside the connection's proxy context, so with per-account proxies the burst doesn't share an IP. On one IP it does. This is the clearer bug of the two.

Path 2: the quota-cache background refresh. Real, and milder. backgroundRefreshTick() (src/domain/quotaCache.ts) refreshes entries in batches of MAX_CONCURRENT_REFRESHES = 5 with Promise.allSettled. Entries fetched by one bulk sync are 1.5 s apart, so they do go stale together and get refreshed up to five at a time. One thing in its favor: refreshEntry() runs inside the connection's own proxy context (runWithProxyContext(proxyInfo?.proxy …)), so with per-account proxies those bursts don't share an IP. On a single IP, they do.

Is it intentional? I found no comment or issue saying it was a decision. I read it as a gap: #6009 paced the dedicated fetchers, and these two callers were never routed through them. Nobody is recorded as having judged the 5-minute refresh low-risk.

Question 3: gate inside getCodexUsage()? I'd put the gate there, and Auto-Ping isn't a problem. The throttle is a min-interval gate on start times, so a caller that already calls throttleQuotaFetch() and then getCodexUsage() waits twice at worst, one interval of 250 ms by default. It never deadlocks or drops a call. A cleaner alternative is to call the gate once per connection from refreshEntry() and resolveConnectionAccountQuota(), so the two callers that lack it get it and nothing double-gates. Either works; the first covers every future caller.

Your report also gives a concrete way to check the fix: after it, a /me/status call on a key with N connections should show N usage requests spaced at least the throttle interval apart.

Tracked in #15172, credited to you. Thanks for checking the code before asking.