Fix OpenAI Admin usage pagination#1465
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed June 12, 2026, 9:26 AM ET / 13:26 UTC. Summary Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Risk before merge
Maintainer options:
Next step before merge
Review detailsBest possible solution: Retry the Codex review after fixing the execution failure. Do we have a high-confidence way to reproduce the issue? Unclear. The review failed before ClawSweeper could establish a reproduction path. Is this the best way to solve the issue? Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction. AGENTS.md: unclear because the file could not be read completely. Codex review notes: model internal, reasoning high; reviewed against 186c6de6678a. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
a95e657 to
d91a5db
Compare
Co-authored-by: Rohit <[email protected]>
d91a5db to
3b2e89e
Compare
|
Added redacted live Admin API pagination proof to the PR body. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Landed as b9a22ef. Proof:
Thanks @rohitjavvadi! |
Summary
OpenAI Admin usage responses can be paginated, but CodexBar was only reading the first page for both costs and completions usage. That could undercount organization usage whenever the API returned
has_more: true.This updates the OpenAI API usage fetcher to follow
next_pagecursors for both endpoints, preserve the existing range/project/group query parameters on each page request, and fail closed on malformed pagination state instead of silently returning partial totals.What changed
has_more/next_pagepagination for OpenAI Admin costs and completions usage.project_ids,group_by, time range, bucket width, and limit query params across page requests.has_moreis true, and excessive pagination.dataandhas_morein Admin usage page responses so malformed pages do not look like empty successful usage.Live behavior proof
I verified the pagination path against a real OpenAI Admin API response with keys, cursors, project/org identifiers, and model names redacted. The probe used the same Admin costs and completions endpoints with
bucket_width=1dandlimit=1to force cursor traversal.That shows the old first-page-only behavior would report zero completions usage for this range, while following all pages finds the later usage buckets.
Testing
swift test --filter OpenAIAPIUsageFetcherTests --filter OpenAIAPICreditBalanceTests --filter OpenAIAPIMenuCardModelTestsmake checkI also tried an aggregate
swift test --disable-sandboxrun after rebasing on latestupstream/main; it hit a timing-sensitiveMainThreadHangWatchdogTestsfailure during the full run, and that same suite passed when rerun directly withswift test --disable-sandbox --filter MainThreadHangWatchdogTests.