z.ai: add 7-day / 30-day ranges to the model-usage chart (needs a daily-granularity fetch)

[LeoLin990405]

Summary

The z.ai Hourly Usage chart (from api/monitor/usage/model-usage) currently offers Today and 24h ranges (hourly bars). The BigModel/z.ai dashboard also offers 近7天 / 近30天 (7-day / 30-day) views. This proposes adding 7-day and 30-day ranges to CodexBar's chart.

Key finding (affects the implementation shape)

The model-usage endpoint returns granularity by span:

• short window (≈1 day) → hourly buckets, xTime like "2026-07-31 14:00";
• 30-day window → daily buckets, xTime like "2026-07-01" (verified live: startTime=2026-07-02 00:00:00&endTime=2026-07-31 23:59:59 → 31 daily points).

So 7d/30d cannot be derived from the existing 1-day/hourly snapshot data — they need a separate daily-granularity fetch (a wider startTime/endTime), and the chart needs to render daily bars (date labels) for those ranges alongside the existing hourly bars.

Proposed shape

• Add a second, daily model-usage fetch (e.g. last 30 days) into the z.ai snapshot, alongside the existing hourly (1-day) fetch.
• Extend ZaiHourlyRange with .last7d / .last30d; render daily bars (parse "yyyy-MM-dd", label MM-dd) for those, hourly bars for Today/24h.
• Add the two range tabs to ZaiHourlyUsageChartMenuView.
• Tests for the daily parse/aggregation + range filtering.

Cost: one extra model-usage request per refresh (the daily window). No new endpoint or auth.

I'll send a PR.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 9:49 PM ET / August 3, 2026, 01:49 UTC.

Summary
Keep this issue open: current main still exposes only Today and 24h hourly chart ranges, and the linked open PR is the existing implementation candidate. The remaining gate is maintainer approval for a new provider-data fetch and chart capability, so a parallel repair PR would duplicate active work.

Reproducibility: not applicable. current source confirms the requested chart ranges are absent, but this is a new capability rather than broken existing behavior.

Root-cause cluster
Relationship: canonical
Canonical: #2523
Summary: This issue is the canonical product request; one open PR directly proposes its implementation.

Members:

• fixed_by_candidate: z.ai: add 7-day / 30-day ranges to the model-usage chart #2524 - The open PR explicitly links to this issue and implements the requested daily chart ranges.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should CodexBar add 7-day and 30-day z.ai chart ranges by making a second, non-fatal daily-granularity API request during each refresh?	Approve bounded daily history: Accept the optional additional request and use #2524 as the single implementation path after it is refreshed.

Why: This is a new user-visible chart feature that changes provider polling behavior, and VISION.md reserves new features and provider-data behavior changes for sign-off.

Next step
An open linked PR already owns the bounded implementation; maintainer sign-off is needed on the added provider polling before it should proceed.

Review details

Best possible solution:

Approve or decline the added polling explicitly; if approved, update and land the linked PR with a non-fatal daily fetch, separate daily timestamp handling, focused parser/range tests, and fresh built-bundle menu proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable: current source confirms the requested chart ranges are absent, but this is a new capability rather than broken existing behavior.

Is this the best way to solve the issue?

Unclear pending product approval: a separate daily fetch is the narrowest technically coherent path because the existing parser and data window are hourly-only, but maintainers must first accept the added provider request.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Adding the long-range views requires one extra z.ai API request on every refresh; maintainers should explicitly accept the polling and optional-data availability tradeoff before merge.
• The paired PR is currently reported as not cleanly mergeable in the supplied context, so it will need a refreshed merge review after product direction is confirmed.

Codex review notes: model internal, reasoning high; reviewed against 0c5255c1838e.

Label changes

Label justifications:

• P3: This is an optional historical-chart enhancement rather than a broken provider workflow or release blocker.
• impact:ux-friction: The current z.ai chart cannot show the longer usage history that users can inspect in the provider dashboard.

Evidence reviewed

What I checked:

• Current chart behavior: The z.ai chart selector contains only Today and 24h, and both routes derive bars from the single hourly model-usage dataset. (Sources/CodexBar/ZaiHourlyUsageChartMenuView.swift:13, 0c5255c1838e)
• Current fetch window: The model-usage fetch is documented as the last 24 hours and calculates its start date by subtracting one day; the optional result is then attached as the sole modelUsage field. (Sources/CodexBarCore/Providers/Zai/ZaiUsageStats.swift:645, 0c5255c1838e)
• Current bucket parser: The bar builder accepts only yyyy-MM-dd HH:mm timestamps and implements only Today and trailing-24-hour filtering, so daily API buckets cannot currently render correctly. (Sources/CodexBarCore/Providers/Zai/ZaiUsageStats.swift:566, 0c5255c1838e)
• Linked implementation candidate: The provided GitHub context shows an open PR that explicitly closes this issue and proposes the separate 30-day daily fetch, daily parsing, range tabs, and focused tests. (3544fe76dceb)
• Repository direction: VISION.md allows small UI/UX work but requires sign-off for new features and provider-data behavior changes; this request falls into both the useful-UX and sign-off-required boundary. (VISION.md:5, 0c5255c1838e)
• History inspection limitation: A read-only git show/log pass for the referenced commit and PR head could not resolve missing local Git objects because network DNS was unavailable; current-main source inspection remains sufficient to establish that the feature is not yet implemented.

Likely related people:

• steipete: The issue timeline records a reference from steipete at commit 1e81741; the historical object was not available locally to establish more specific ownership. (role: recent area contributor; confidence: low; commits: 1e81741e371a; files: Sources/CodexBarCore/Providers/Zai/ZaiUsageStats.swift, Sources/CodexBar/Zai/ZaiHourlyUsageChartMenuView.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.