Area
Web Dashboard → Usage
Current state
OpenCodex already provides these Usage history ranges:
The Usage data model also already contains per-day rows and per-day model totals, and the Dashboard can visualize daily activity.
So this issue no longer tracks the original broad claim that Usage has no date controls or daily data.
The remaining gap is selecting an exact calendar day or custom date range and applying that selection to the model-level statistics.
Goal
Allow operators to answer questions such as:
- How much did each model consume today?
- How much did each model consume yesterday?
- What were model totals on a particular calendar date?
- What were model totals between two selected dates?
- How did one day's model mix differ from another?
without manually processing usage.jsonl.
Remaining scope
1. Single-day ranges
Add explicit calendar-day selections for:
These must use calendar-day semantics, not rolling 24-hour windows.
For example, Yesterday should cover the previous local calendar day and exclude entries from today.
2. Custom date selection
Allow selecting either:
- one explicit date; or
- a bounded start/end date range.
Existing presets must remain available:
A custom selection should be represented explicitly rather than overloaded onto the existing preset semantics.
3. Apply the selected timeframe to Models
The Models report should reflect the selected date/range rather than always being limited to the existing preset windows.
For every model in the selected timeframe, retain the existing useful aggregates and expose the model-level token fields required for day-by-day consumption analysis.
At minimum:
- model;
- provider;
- requests;
- measured/reported coverage where applicable;
- input tokens;
- output tokens;
- total tokens;
- share of usage in the selected timeframe.
If cache-token model attribution is available reliably at the aggregation boundary, include it as well rather than reconstructing it in the GUI.
4. Daily model breakdown
For a multi-day selection, users should be able to inspect model usage by calendar day.
The implementation may use either:
- a dedicated daily-model table;
- drill-down from the existing daily visualization;
- selecting/clicking a day to filter the Models report.
The important contract is that the user can obtain the model breakdown for an individual day, not merely the aggregate total for the entire 7d/30d window.
5. Existing visualization
The existing daily Usage visualization should be preserved.
If practical, selecting a day in that visualization may become the entry point for exact-day filtering.
Do not create a second unrelated chart solely to satisfy this issue if the existing visualization can provide the interaction cleanly.
Data-path requirements
The date boundary must be implemented in the usage summary/data path first.
The GUI should consume the filtered/aggregated result rather than:
- downloading an unnecessarily large history and filtering it independently;
- parsing
usage.jsonl directly;
- reconstructing authoritative model totals from chart data.
Date semantics must be deterministic and covered by tests.
For calendar-day ranges, boundary tests should cover entries:
- immediately before the selected day;
- exactly at the start boundary;
- during the selected day;
- exactly at the next-day boundary.
Previous implementation attempt
PR #1079 attempted to add Today and Yesterday, but it was closed unmerged.
That draft should not be treated as an implementation of this issue.
Its maintainer review identified three important problems:
- the changed locale files did not compile;
- the promised daily model breakdown was not implemented;
Yesterday used a rolling 24-hour window rather than calendar-day semantics.
The server-side range-extension idea may be reused, but those problems must not be carried forward.
Suggested delivery
This can be delivered in small independently testable slices.
A sensible order is:
- usage-summary/API support for calendar-day and explicit date bounds;
- regression tests for boundary semantics;
- Dashboard Today/Yesterday controls;
- custom date/range selection;
- model/day drill-down or equivalent daily-model presentation.
Do not require all UI work to be bundled into one large PR if smaller slices preserve the final contract.
Out of scope
This issue does not require:
- changing usage retention policy;
- changing pricing semantics;
- changing account quota/reset tracking;
- replacing the existing Usage workspace;
- introducing a separate analytics database.
Acceptance criteria
Related work
Area
Web Dashboard → Usage
Current state
OpenCodex already provides these Usage history ranges:
The Usage data model also already contains per-day rows and per-day model totals, and the Dashboard can visualize daily activity.
So this issue no longer tracks the original broad claim that Usage has no date controls or daily data.
The remaining gap is selecting an exact calendar day or custom date range and applying that selection to the model-level statistics.
Goal
Allow operators to answer questions such as:
without manually processing
usage.jsonl.Remaining scope
1. Single-day ranges
Add explicit calendar-day selections for:
These must use calendar-day semantics, not rolling 24-hour windows.
For example,
Yesterdayshould cover the previous local calendar day and exclude entries from today.2. Custom date selection
Allow selecting either:
Existing presets must remain available:
A custom selection should be represented explicitly rather than overloaded onto the existing preset semantics.
3. Apply the selected timeframe to Models
The Models report should reflect the selected date/range rather than always being limited to the existing preset windows.
For every model in the selected timeframe, retain the existing useful aggregates and expose the model-level token fields required for day-by-day consumption analysis.
At minimum:
If cache-token model attribution is available reliably at the aggregation boundary, include it as well rather than reconstructing it in the GUI.
4. Daily model breakdown
For a multi-day selection, users should be able to inspect model usage by calendar day.
The implementation may use either:
The important contract is that the user can obtain the model breakdown for an individual day, not merely the aggregate total for the entire 7d/30d window.
5. Existing visualization
The existing daily Usage visualization should be preserved.
If practical, selecting a day in that visualization may become the entry point for exact-day filtering.
Do not create a second unrelated chart solely to satisfy this issue if the existing visualization can provide the interaction cleanly.
Data-path requirements
The date boundary must be implemented in the usage summary/data path first.
The GUI should consume the filtered/aggregated result rather than:
usage.jsonldirectly;Date semantics must be deterministic and covered by tests.
For calendar-day ranges, boundary tests should cover entries:
Previous implementation attempt
PR #1079 attempted to add
TodayandYesterday, but it was closed unmerged.That draft should not be treated as an implementation of this issue.
Its maintainer review identified three important problems:
Yesterdayused a rolling 24-hour window rather than calendar-day semantics.The server-side range-extension idea may be reused, but those problems must not be carried forward.
Suggested delivery
This can be delivered in small independently testable slices.
A sensible order is:
Do not require all UI work to be bundled into one large PR if smaller slices preserve the final contract.
Out of scope
This issue does not require:
Acceptance criteria
Available history,30d, and7dpresets continue to work.Todayfilters to the current local calendar day.Yesterdayfilters to the previous local calendar day, not a rolling 24-hour period.usage.jsonlis introduced.dev.Related work