Copilot premium usage should use calendar-month pace under a single row

[coygeek]

Summary

Copilot should keep its simple single-row presentation, but the monthly pace shown under that row needs to follow GitHub's premium-request calendar month, not the subscription assignment date.

Confirmed behavior

GitHub's premium request analytics are calendar-month based and reset on the 1st of each month at 00:00:00 UTC.

Live API investigation

Using the same authenticated endpoint CodexBar calls (/copilot_internal/user), a live response returned:

• assigned_date: 2026-03-22T16:03:34-07:00
• quota_reset_date: 2026-05-01
• premium_interactions.entitlement: 1500
• premium_interactions.remaining: 1139
• premium_interactions.percent_remaining: 75.9

That payload mixes a subscription-assignment date with a calendar-month reset date.

Root cause

CodexBar was deriving the pace window as:

• assigned_date -> quota_reset_date

For the live payload above, that means pacing over roughly Mar 22 -> May 1, which inflates the reserve/deficit output.

Expected behavior

For Copilot premium requests, the pace window should be:

• start: first day of the current calendar month in UTC
• end: quota_reset_date

Example:

• if quota_reset_date is 2026-05-01, the pace window should be 2026-04-01 00:00:00 UTC -> 2026-05-01 00:00:00 UTC

UI behavior

• Keep a single visible Copilot Premium row.
• Show monthly pace text underneath it using existing in deficit / in reserve wording.
• Continue to show reset timing on the right.

Proposed fix

1. Ignore assigned_date when deriving the premium-request pacing window.
2. Derive the Copilot window from the calendar month ending at quota_reset_date.
3. Keep the single-row Copilot UI and attach the pace annotation under that row.
4. Add regression tests for the live payload shape and the corrected calendar-month reserve math.

Notes

If GitHub omits the reset fields, Copilot should keep the simple percent-only row.