Clarify account/usage/read daily bucket timezone and token accounting semantics

Summary

I am investigating a discrepancy between Codex account/usage/read Account Activity and the token totals reconstructed from local rollout token_count events.

After tracing the local accounting pipeline, the original ~30% discrepancy appears to be largely sensitive to the daily bucket boundary rather than a local parser loss. However, the public client code does not document the timezone or accounting semantics of the backend-provided daily buckets.

I would like to clarify the contract of dailyUsageBuckets.startDate and dailyUsageBuckets.tokens.

Reproduction / observed data

Environment:

• Codex Desktop rollout metadata: cli_version = 0.153.4
• Single physical device for the test day
• Date under investigation: 2026-09-06

Backend Account Activity:

startDate: 2026-09-06
tokens: 876,157,313

Local rollout-derived usage for the same data:

Asia/Shanghai bucket: 611,718,836
UTC bucket:           830,567,372

Therefore:

Local-time discrepancy: 264,438,477 (30.18%)
UTC-aligned discrepancy: 45,589,941  (5.20%)

Re-bucketing the exact same local rollout corpus by UTC explains about 82.76% of the original discrepancy.

This strongly suggests a date-boundary mismatch, but I cannot confirm that the backend bucket is actually UTC because the public client only maps the returned startDate string without timezone conversion.

Local accounting validation

I also validated the local side independently:

raw rollout total:              613,008,943
parser-valid local total:       611,718,836
Tokscale result:                611,718,836
Token Monitor durable history:  611,718,836

The ~1.29M raw/parser difference is explained by duplicate cumulative snapshots. I found no local parser/cache/archive loss remotely close to the original 264M discrepancy.

Relevant Codex accounting paths

While reviewing rust-v0.153.4, I noticed that the local rollout token stream is not necessarily a complete representation of every internal/provider accounting path.

In particular:

1. response.completed.usage.codex_rollout_budget_units is parsed into TokenUsage, but the field is marked skip_serializing, so it does not appear in ordinary serialized rollout token records.

2. Rollout budget accounting prefers provider-reported rollout budget units when available.

3. Remote compaction can perform backend model work without following the normal record_token_usage_info → TokenCount path. After compaction, the session may instead recompute context token usage.

4. Retry/failed attempts and separate memory/background requests may also have server-side accounting that is not observable from ordinary successful rollout token_count events.

For the test day there were 37 compaction-related rollout items, but the existing rollout does not expose enough information to attribute the remaining 45.6M tokens to compaction or any other individual mechanism.

Questions

Could you clarify the following?

1. What timezone or boundary does dailyUsageBuckets[].startDate use?

   • UTC?
   • account timezone?
   • device timezone?
   • another server-defined boundary?

2. What exactly does dailyUsageBuckets[].tokens represent?

   • raw Responses API token totals?
   • provider/accounting units?
   • billed or weighted tokens?
   • another server-defined metric?

3. Are codex_rollout_budget_units included in Account Activity?

4. Does Account Activity include usage from requests that may not appear as ordinary rollout TokenCount events, such as:

   • remote compaction;
   • failed/retried sampling attempts;
   • memory/background requests;
   • other auxiliary Codex Desktop surfaces?

5. Is there a supported way for clients to reconcile Account Activity with local rollout token usage, or should these intentionally be treated as separate metrics?

Expected outcome

I am not requesting that the local rollout format necessarily expose all server-side billing/accounting internals.

A documented contract for the daily bucket boundary and the meaning of tokens would be enough to avoid incorrectly treating Account Activity and rollout-derived totals as equivalent.

This matters for third-party local usage tools because a timezone mismatch alone can produce a very large apparent daily discrepancy even when the underlying local rollout accounting is internally consistent.

Relevant source references

The references below were checked against the existing rust-v0.153.4 tag (commit 042fb41b7c813ac7999105e886b2b7aa715b5081):

• account/usage/read method and response mapping:
  • method declaration
  • backend profile fields, including daily buckets
  • token usage profile endpoint
  • app-server response mapping
• TokenUsage.codex_rollout_budget_units
• provider usage parsing
• rollout budget provider-unit logic
• normal record_token_usage_info path
• remote compaction V2
• recompute_token_usage

Start with the account/usage/read response mapping in app-server/src/request_processors/account_processor.rs and the daily bucket types in backend-client/src/types.rs. Compare those paths with the listed token usage, rollout budget, and compaction code. Done means the timezone, token metric, included request types, and reconciliation expectations are documented or answered clearly.