Contradictory Usage API snapshot masks fresh runtime quota evidence

[bvdcode]

Summary

After a provider-side usage incident, Codex Pooler can keep presenting an account as having 0% weekly quota remaining while fresh runtime response headers report substantial quota remaining and requests continue to succeed.

This is a conflict between current provider surfaces. The Usage API observation is the newest observation; it is not stale. The defect is that Pooler presents the pessimistic value as an unqualified current fact despite contradictory fresh evidence.

Observed behavior

Codex Pooler version: 0.7.5

Two fresh observations for the same account-level secondary/weekly window and reset cycle were retained:

• Usage API: 100% used / 0% remaining, observed at 2026-09-10T05:52:00Z — newest and selected for display.
• Response headers: 37% used / 63% remaining, observed at 2026-09-10T05:50:48Z — fresh and not selected.

A rate-limit event also previously reported 63% remaining, but had become stale by the time of the snapshot above.

The scheduled account reconciliation continued to refresh the contradictory Usage API value every minute. The upstream account remained usable and successful runtime traffic kept reporting 63% remaining, but the account card and cockpit continued to show Weekly 0%.

This occurred after the provider temporarily showed the included quota as exhausted and later restored it in the user-facing subscription UI.

Impact

• Operators cannot tell that current provider surfaces disagree.
• A healthy account may appear exhausted even while it successfully serves requests.
• Operators may unnecessarily pause/relink the account or redeem a saved reset.
• Presentation asserts certainty where the retained evidence is contradictory.

Relevant selection behavior

CodexPooler.Quotas.Evidence assigns higher merge precedence to runtime rate-limit events and response headers than to the Usage API (90/80 vs 60). However, CodexPooler.Upstreams.Quota.WindowSelector.logical_selection_score/2 ranks pressure_rank before merge_precedence and observation timestamp.

Consequently, a 100% used Usage API observation beats a fresh 37% used runtime-header observation for the same cycle because it is more pessimistic. In the observed snapshot, the Usage API row was also newer.

Expected behavior

Contradictory fresh quota observations for the same reset cycle should not be collapsed into an unqualified 0% remaining display.

One acceptable behavior would be to select the stronger runtime evidence. Another would be to expose an explicit conflicted/uncertain state while retaining fail-closed routing behavior. The operator must be able to distinguish confirmed exhaustion from disagreement between provider surfaces.

Suggested acceptance coverage

• A fresh Usage API 100% used snapshot conflicts with fresh response headers reporting lower usage in the same reset cycle.
• The UI exposes the conflict instead of asserting an unqualified authoritative zero.
• Routing and operator presentation expose consistent semantics.
• A later converged observation clears the conflict automatically.

[bvdcode]

@masterkain Fixed in 0.7.6, thank you!

[bvdcode]

Small correction: I may have confirmed the fix too early. At the same time, the provider recovered and all three evidence sources converged at 56%.

So the current result confirms provider recovery, but does not independently verify the originally reported conflict: a fresh exhausted Usage API reading masking fresh usable runtime/header evidence.

No need to reopen the issue for now—I just wanted to clarify that my confirmation was inconclusive. If the conflict appears again, I’ll provide a new snapshot from 0.7.6.

[masterkain]

Your correction matches what I found, thanks for flagging it: the convergence at 56% was the provider's Usage API returning to the real percentage, not the Pooler resolving the conflict. 0.7.6 covers the neighbouring shapes (a header exhaustion superseded by confirmed Usage API readings, and no automatic saved-reset spend on an unexplained 100% flash), but the exact shape you reported, Usage API stuck at 100% every minute while fresh response headers report 37% in the same cycle, still selected the Usage API row when I reproduced it on main this afternoon, so your original report stands.

821bafe adds the mirror rule for your shape: runtime readings (response headers, rate-limit events) carry their own coherence marker, and two adopted readings below 100% without a denial fact in the same reset cycle supersede a fresh exhausted Usage API row observed at most five minutes after the last runtime confirmation. A runtime denial or exhausted reading clears the marker, so a genuine exhaustion re-establishes the Usage API row on the first denied request; routing permission logic and saved-reset fences are unchanged, and the retained exhausted usage row stays visible in the quota observations dialog. Covered by an end-to-end test of your snapshot (runtime_coherence_store_test.exs) plus a WindowSelector mirror test. It is in 0.7.8 (published a few minutes ago), so if the provider flashes 100% again the card will follow the successful traffic instead.