feat(usage): add account usage filter and indicators in provider workspace (#1063) - #1083
feat(usage): add account usage filter and indicators in provider workspace (#1063)#1083agentHits wants to merge 1 commit into
Conversation
|
Review readiness checklistThis PR is kept in draft until every requirement below is fulfilled. The tickable checklist has been added to your PR description — tick all four boxes there.
3/4 boxes ticked. This PR stays in draft until every box above is ticked. |
📝 WalkthroughWalkthroughThe Usage tab now passes OAuth accounts to ChangesProvider usage account filtering
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@gui/src/components/provider-workspace/ProviderUsage.tsx`:
- Around line 24-31: Update ProviderUsage so selecting an individual account
does not display provider-wide usage under an account-specific badge: either
wire per-account usage/model data from ProviderDetails and derive the metrics
and sortedModels from the selected account, falling back to usageTotals only for
“all,” or hide those numeric sections and show an explicit
unavailable-per-account message when data is not provided. Ensure the UI clearly
identifies whether statistics represent overall provider usage or the selected
account.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: f9a6d906-efdd-46b9-970c-4e339d886891
📒 Files selected for processing (8)
gui/src/components/provider-workspace/ProviderDetails.tsxgui/src/components/provider-workspace/ProviderUsage.tsxgui/src/i18n/de.tsgui/src/i18n/en.tsgui/src/i18n/ja.tsgui/src/i18n/ko.tsgui/src/i18n/ru.tsgui/src/i18n/zh.ts
| const quota = accountQuotaFromReport(quotaReport); | ||
| const [expandedModel, setExpandedModel] = useState<string | null>(null); | ||
| const [selectedAccountId, setSelectedAccountId] = useState<string>("all"); | ||
|
|
||
| const selectedAccount = useMemo(() => { | ||
| if (!accounts?.length || selectedAccountId === "all") return null; | ||
| return accounts.find(a => a.id === selectedAccountId) ?? null; | ||
| }, [accounts, selectedAccountId]); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Account selector changes the badge but not the displayed usage numbers.
selectedAccountId and selectedAccount (lines 26-31) are only read to render the badge (lines 78-85). The cost/requests/tokens metrics (lines 88-101) and the model breakdown table use providerCost and sortedModels, both derived solely from the usageTotals/modelUsage props, which stay fixed at the combined provider totals regardless of selectedAccountId.
Concretely: pick an individual account from the dropdown, and the badge shows that account's email, but "Estimated cost", "requests", "tokens", and the "Model breakdown" table below are unchanged — they still show the provider-wide combined figures. This means the selector currently misleads users into thinking they are looking at per-account numbers.
Issue #1063 (linked in the PR objectives) explicitly requires that selecting an account shows "30-day request count, token usage, and estimated cost" for that account, and that "The interface should clearly indicate whether displayed statistics represent overall provider usage or the selected account's usage." As implemented, the interface never shows account-specific statistics — only account-specific identity.
Since OAuthAccountRow (in types.ts) carries no usage/cost fields, the fix needs either:
- A new prop such as
accountUsageTotals?: Record<string, ProviderUsageTotals>(or similar) passed down fromProviderDetails, keyed by account id, so the metrics block can pickaccountUsageTotals[selectedAccountId] ?? usageTotalsandsortedModelscan filter/aggregate model usage per account, or - If per-account usage isn't available yet from the management API, disable/hide the numeric metrics when a specific account is selected and show an explicit "not yet available per account" message instead of silently showing combined totals under a misleading badge.
🐛 Minimal fix if per-account data is not yet wired
{hasUsage ? (
<>
- <div className="pws-usage-metrics pws-usage-metrics-3" role="group" aria-label={t("pws.usageLast30d")}>
+ <div className="pws-usage-metrics pws-usage-metrics-3" role="group" aria-label={t("pws.usageLast30d")}>
+ {selectedAccount && (
+ <p className="muted pws-cost-disclaimer">{t("pws.accountUsageUnavailable")}</p>
+ )}
<div className="pws-usage-metric">Do you want me to draft the per-account data plumbing through ProviderDetails if the management API already exposes per-account usage?
Also applies to: 55-106
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@gui/src/components/provider-workspace/ProviderUsage.tsx` around lines 24 -
31, Update ProviderUsage so selecting an individual account does not display
provider-wide usage under an account-specific badge: either wire per-account
usage/model data from ProviderDetails and derive the metrics and sortedModels
from the selected account, falling back to usageTotals only for “all,” or hide
those numeric sections and show an explicit unavailable-per-account message when
data is not provided. Ensure the UI clearly identifies whether statistics
represent overall provider usage or the selected account.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 87428d30fd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| id="pws-account-filter" | ||
| className="select select-sm" | ||
| value={selectedAccountId} | ||
| onChange={e => setSelectedAccountId(e.target.value)} |
There was a problem hiding this comment.
Make the account selector filter the displayed usage
When a multi-account provider user selects an individual account, this handler only changes selectedAccountId, which controls the badge; usageTotals, sortedModels, providerCost, and quota remain derived from the same provider-wide props. Consequently, costs, requests, tokens, model rows, and rate-limit bars stay unchanged and misleadingly appear to belong to the selected account. Pass account-scoped usage and quota data through the management API and derive each display section from the selection, or do not expose individual account options.
AGENTS.md reference: gui/AGENTS.md:L9-L10
Useful? React with 👍 / 👎.
| <option value="all">{t("pws.allAccountsCombined")}</option> | ||
| {accounts.map(acc => ( | ||
| <option key={acc.id} value={acc.id}> | ||
| {acc.email ?? acc.alias ?? acc.id} {acc.active ? `(${t("prov.accountActive")})` : ""} |
There was a problem hiding this comment.
Keep opaque account IDs out of visible labels
When an OAuth account has neither an email nor an alias, this option renders the complete raw acc.id, and the selected-account badge repeats it. The existing dashboard privacy contract uses oauthAccountDisplayLabel or displayAccountId specifically so opaque storage IDs never become user-visible; this regression exposes the identifier in the UI and in screenshots. Build both labels with the existing safe helper instead of falling back to acc.id.
AGENTS.md reference: gui/AGENTS.md:L9-L9
Useful? React with 👍 / 👎.
| {accounts && accounts.length > 0 && ( | ||
| <div style={{ display: "flex", alignItems: "center", gap: 8 }}> | ||
| <label htmlFor="pws-account-filter" className="muted faint" style={{ fontSize: 13 }}> | ||
| {t("pws.usageAccountSelector")}: |
There was a problem hiding this comment.
Update the dashboard guide for the account filter
This introduces a new user-facing workflow under Providers → Usage, but the commit does not update docs-site/; a repository-wide search shows the existing web-dashboard guide still describes provider account and quota management without the new combined-versus-individual usage selector. Document the selector's behavior and scope in the dashboard guide so the shipped UI and user documentation remain synchronized.
AGENTS.md reference: gui/AGENTS.md:L36-L36
Useful? React with 👍 / 👎.
|
Maintainer triage (code-level, against
Minor: prefer the existing |
|
Closing this draft — the account filter currently changes the badge only; every metric underneath remains provider-aggregated, so the feature it advertises (#1063, per-account usage) is not delivered by this diff. The missing piece is the data path: per-account usage attribution at write time, then a filtered read. Please reopen once the selector actually filters the aggregation; the UI shell here can come along with it. |
Summary
Fixes #1063.
Adds an Account Usage Filter dropdown and indicator badges in the Provider Workspace (
Providers -> [Provider] -> Usage) for multi-account providers such as Google Antigravity / Gemini.UI Screenshots
Key Changes
Provider Usage UI Account Filter (
ProviderUsage.tsx&ProviderDetails.tsx):accountsprop fromProviderDetailsdown intoProviderUsage.Internationalization (
gui/src/i18n/*.ts):pws.usageAccountSelectorandpws.allAccountsCombinedkeys across all 6 supported locales (en,ru,zh,de,ja,ko).Readiness Checklist
Review readiness checklist
This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:
Verification
Ran
bun run typecheckandbun test tests/provider-workspace-data.test.ts tests/provider-workspace-auth.test.ts:61 pass, 0 failtsc --noEmitpassed with 0 errors.Summary by CodeRabbit
New Features
Localization