[Feature]: add single-day/custom date filtering and daily model metrics to Usage

Area

Web Dashboard → Usage

Current state

OpenCodex already provides these Usage history ranges:

Available history
30d
7d

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:

Today
Yesterday

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:

Available history
30d
7d

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

feat(usage): add date filters and daily model breakdown in dashboard (#1058) #1079 — closed, unmerged implementation attempt; useful only as prior-art/review context.

_{Automated translation bookkeeping — detected language: English.}

Additional UX Suggestion: Add "1 day" (1d / 24h) quick preset to history timeframe selector

In the current UI selector ("Available history" / "Доступная история"), there are quick toggle buttons for "30 days" (30 дн.) and "7 days" (7 дн.).

Adding a "1 day" (1 дн. / Today) button alongside the existing 30d and 7d options would be a very simple and intuitive UI enhancement. It would allow users to instantly view single-day / today's token usage and request stats per model with one click.

Proposed selector preset layout:
Available history: 30 days | 7 days | 1 day (Today)

Keeping this open — the idea is wanted. The draft PR attached to this campaign was closed with specific technical feedback (see the PR thread); the ideas stay tracked here. What gets a fast review: small, rebased, independently testable slices that wire the runtime/data path first and the UI second, one concern per PR.

Keeping this open — the idea is wanted. The draft PR attached to this campaign was closed with specific technical feedback (see the PR thread); the ideas stay tracked here. What gets a fast review: small, rebased, independently testable slices that wire the runtime/data path first and the UI second, one concern per PR.

Thank you for your answer, I hope you or someone else can implement my idea, I haven’t been able to do it yet (((

Clarification: provider/model cost and cache metrics

Thanks for tracking the single-day and custom-range Usage work in this issue. I would like to clarify the detailed Usage view I am looking for. This is intentionally limited to estimated usage cost, not official provider billing or account balances, and should build on the existing usage-summary data path rather than introduce a separate analytics system.

Required breakdown

For a selected calendar day or date range, the Usage view should provide both provider-level and model-level rows with:

provider
model
request count
input tokens
output tokens
total tokens
cache-read input tokens
cache-creation input tokens
estimated cost in USD
usage/price coverage where applicable

The model rows should be attributable to their provider, and the provider view should support expanding or filtering into its models.

Cache metrics

Cache metrics are especially important for comparing providers and models. Where the provider reports the necessary counters, please expose:

cache-read tokens
cache-creation tokens
cache hit rate
optionally, cache participation rate if that is more meaningful for a provider

The cache-hit-rate denominator should be deterministic and documented. A reasonable default is cache-read input tokens divided by total prompt/input tokens, or cache-read tokens divided by cache-read plus uncached input tokens when the latter is available. If a provider does not report enough information, the UI should show unavailable, not 0%.

Cache read/write pricing should be included in the estimated cost when the configured price data supports it. If a provider or model has no matched price, the row should remain visibly unpriced/unavailable rather than silently contributing $0.

Daily drill-down

For a multi-day selection, users should be able to inspect the same provider/model/token/cache/cost breakdown for an individual calendar day, either by selecting a day in the existing chart or through a daily detail table.

Suggested implementation constraints

Keep the existing 7d/30d/all presets and add Today, Yesterday, explicit date, and bounded date-range selection.
Apply filtering and aggregation in the authoritative usage-summary/API layer; do not parse usage.jsonl in the GUI.
Reuse the existing usage and pricing fields where possible.
This does not require official invoices, provider balances, or a separate analytics database.
Missing cache or pricing data must be represented as unavailable/unknown, not as zero.

Acceptance criteria

A user can select a day or date range and see provider/model request, token, cache, and estimated-cost metrics for that selection.
A user can drill down from a daily view to the provider/model breakdown for that day.
Cache-read and cache-creation tokens are shown separately when available.
Cache hit rate is shown only when its inputs are available and its calculation is documented.
Estimated cost includes cache pricing when available and does not silently treat unresolved prices as $0.
Existing date-boundary, locale, and frontend/API separation requirements in this issue remain satisfied.

This would make the Usage page useful not only for activity volume, but also for understanding where tokens and estimated spend are going and how effectively prompt caching is being used.

리뷰 · 우선순위 48 / 80

현재 dev의 Usage 범위는 all / 30d / 7d입니다. src/usage/summary.ts의 UsageRange와 gui/src/pages/Usage.tsx의 토글이 그 세 값만 받습니다. 일별 행과 일별 모델 누적은 이미 있고, 7일 막대 차트도 있습니다. 이 이슈가 처음 말했던 “날짜 조절이 없다”는 더 이상 사실이 아닙니다.

남은 요청은 달력 하루와 임의 구간입니다. Today/Yesterday는 롤링 24시간이 아니라 로컬 달력 하루여야 하고, 하루 또는 시작/끝을 고르면 Models 집계가 그 창을 따라야 합니다. 지금 Models는 프리셋 창에 묶여 있어 “어제 모델별 토큰”을 usage.jsonl 없이 답할 수 없습니다.

위생적으로 커스텀 구간을 기존 7d/30d 의미에 얹으면 안 됩니다. 대시보드 캐시도 usage-summary-30d 키를 씁니다. 날짜 선택과 프리셋을 같은 타입으로 접으면 캐시와 커버리지 숫자가 섞입니다. 캐시 토큰 귀속도 집계 경계에서 믿을 수 있을 때만 넣어야 하며, GUI에서 재구성하면 안 됩니다.

Windows/서비스보다 대시보드 UX입니다. 다만 달력 경계는 타임존에 민감합니다. 서버가 UTC로 자르고 UI가 서울 하루를 보여 주면 네이티브 신뢰성과 같은 종류의 오해가 납니다. 비용 추정 코멘트는 공식 청구가 아님을 유지한 채 기존 usage-summary 경로를 써야 합니다.

해결방안은 요약 API에 달력 하루/구간 파라미터를 명시적으로 추가하고, Models와 일별 모델 내역이 같은 창을 쓰게 하는 것입니다. 기존 프리셋은 그대로 둡니다. 패치는 추측하지 않으며, 현재 트리에 Today/Yesterday/커스텀 범위 타입은 없습니다.

이 댓글은 grok-bot이 작성했습니다

리뷰 · 우선순위 48 / 80 · 종결

Usage에서 오늘/어제/날짜 골라 모델별 토큰 보자는 요청. 7일/30일은 이미 있음. 어제는 달력 하루여야 함. #1079는 로케일 깨지고 rolling 24h라 머지 안 됨.

지금은 대시보드에 안 넣음. usage.jsonl / ocx CLI로 보면 됨. #1820(예상비용/캐시)은 따로 유지.

이 이슈는 닫음. GUI 날짜 피커 PR은 필수는 아님.

해결방안: 지금은 패치 없음. 일별 합계는 CLI/로그. 나중에 GUI 넣을 때도 달력 경계 테스트부터.

이 댓글은 grok-bot이 작성했습니다

Navigation Menu

Repository navigation

[Feature]: add single-day/custom date filtering and daily model metrics to Usage #1058

Area

Current state

Goal

Remaining scope

1. Single-day ranges

2. Custom date selection

3. Apply the selected timeframe to Models

4. Daily model breakdown

5. Existing visualization

Data-path requirements

Previous implementation attempt

Suggested delivery

Out of scope

Acceptance criteria

Related work

Additional UX Suggestion: Add "1 day" (1d / 24h) quick preset to history timeframe selector

Clarification: provider/model cost and cache metrics

Required breakdown

Cache metrics

Daily drill-down

Suggested implementation constraints

Acceptance criteria

리뷰 · 우선순위 48 / 80

리뷰 · 우선순위 48 / 80 · 종결

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Feature]: add single-day/custom date filtering and daily model metrics to Usage #1058

Description

Area

Current state

Goal

Remaining scope

1. Single-day ranges

2. Custom date selection

3. Apply the selected timeframe to Models

4. Daily model breakdown

5. Existing visualization

Data-path requirements

Previous implementation attempt

Suggested delivery

Out of scope

Acceptance criteria

Related work

Activity

github-actions commented on Aug 5, 2026

agentHits commented on Aug 5, 2026

Additional UX Suggestion: Add "1 day" (1d / 24h) quick preset to history timeframe selector

lidge-jun commented on Aug 6, 2026

agentHits commented on Aug 6, 2026

str0203 commented on Aug 15, 2026

Clarification: provider/model cost and cache metrics

Required breakdown

Cache metrics

Daily drill-down

Suggested implementation constraints

Acceptance criteria

lidge-jun commented on Aug 19, 2026

리뷰 · 우선순위 48 / 80

lidge-jun commented on Aug 19, 2026

리뷰 · 우선순위 48 / 80 · 종결

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions