account/getQuota is served from a process-lifetime cache; reset_date is the fetch timestamp

[aweussom]

SDK: github-copilot-sdk 1.0.8 (Python) · CLI/runtime: GitHub Copilot CLI 1.0.83 · Windows 11

Summary

client.rpc.account.get_quota() returns the same answer for the lifetime of the runtime
process. A long-lived client that polls it to show live usage never sees the figure move.
Separately, reset_date on each snapshot is the runtime's fetch timestamp, not a reset
instant.

What I observed (2026-09-11)

• A client started 2026-09-08 09:32 read premium_interactions.used_requests = 190
  (of 5000) at startup. It re-called get_quota every 120 s for three days and got 190
  every time. Meanwhile the account went to 5000/5000 (copilot-cli statusline:
  Plan: 100% used; the runtime's own session-store.db ledger: 4,922 credits this
  month on this machine). A fresh process, started at that point, read 5000/5000 on its
  first call.
• Two calls 40 s apart in ONE fresh process returned byte-identical snapshots, including
  reset_date (2026-09-11T05:03:07.217Z both times). A new process a minute later
  stamped 05:04:32Z. So reset_date records when the runtime fetched, and identical
  stamps mean "served from cache".
• Passing git_hub_token in AccountGetQuotaRequest does bypass the cache (fresh stamp
  5 s later), but that needs the Copilot OAuth token itself, which the SDK does not expose.

Why it matters

Agents that run for days (batch relays, always-on assistants) are exactly the ones that
need to watch the allowance. Mine drained a month's credits overnight while its status
line still said 4,810 left.

Ask

Either of:

1. A TTL or a force_refresh flag on account/getQuota, or
2. Document the caching and the actual semantics of reset_date, so clients know to
   combine the snapshot with the local usage ledger (which is what I ended up doing).

Repro

_bench/quota_cache_probe.py in https://github.com/aweussom/agentry calls get_quota
twice in one process 40 s apart, then once from a fresh process. Same-process stamps
are byte-identical; the fresh process carries its own. Re-verified today at 0/30/60/120 s:
fresh processes always fetch, so the cache is per process, not server-side.