You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code Usage area currently follows the selected authentication vault. Switching profiles therefore replaces the usage shown at the bottom, making it difficult to compare remaining capacity across the profiles available before launch.
This is distinct from atyrode/dotfiles#220, which investigates usage inside a running OMP session, and from #4, which owns the shared-width layout regression. This issue changes the pre-launch code Usage information architecture while reusing the responsive measurement rules from #4.
Goal
Show usage for every configured, selectable vault at the same time. Organize each vault's provider usage under or beside the code profile or profiles that reference it, instead of filtering the entire Usage surface to the currently selected vault.
The selected profile should remain visually identifiable, but selection must not hide the other profiles' usage.
UX contract
Render one stable usage group per configured vault, labeled by its correlated profile name(s) and a redacted vault identity.
Within each group, show the vault's provider rows, quota windows, percentages, reset countdowns, and freshness state using the existing usage vocabulary.
Display all groups simultaneously when space permits; responsive stacking may change geometry, but must not require switching vaults to inspect another profile.
Preserve deterministic profile/vault ordering across refreshes and selection changes.
If several profiles reference one vault, make that relationship clear without duplicating network fetches or presenting conflicting usage values.
A missing provider, unavailable quota endpoint, stale response, or refresh error affects only that vault/provider group. Other groups remain visible and usable.
Keep primary quota data ahead of optional identity/status detail when space is constrained.
Never render bearer tokens, credentials, broker ports, raw API responses, or unredacted provider secrets. Use only the existing broker-redacted identity fields.
Do not preallocate unexplained blank height; the surface grows or stacks according to the groups actually present.
Responsive behavior
Measure each provider and vault/profile group independently. Do not allow one vault's longest optional label or unavailable-state message to inflate every sibling group. Reuse the fixed-viewport, asymmetric-content, and state-transition verification discipline documented by #4 and docs/tui-verification.md.
Acceptance criteria
With profiles mine and mum mapped to different vaults, both profiles' Codex/Claude usage groups are visible concurrently; changing the selected profile only moves the selected treatment.
With two profiles sharing one vault, the UI communicates the shared mapping and performs one usage fetch per vault/provider rather than duplicating requests.
A vault with missing or unknown usage renders an explicit local unavailable/unknown state while other vaults continue showing fresh data.
Asymmetric emails, provider notes, reset windows, and available/unavailable transitions do not move unrelated sibling groups unnecessarily.
Wide, medium, narrow, and boundary viewports remain within the terminal with stable footer/control placement and no unexplained empty region.
Character-exact TUI fixtures cover multiple vaults, shared-vault mapping, partial failure, stale refresh, and selection changes at fixed dimensions.
Usage refresh, caching, rate limiting, and privacy behavior remain bounded per vault and do not expose secret material.
Existing single-vault configurations remain clear without empty duplicate sections.
Likely ownership
pkgs/code-tui/
pkgs/cli-kit/ only if a genuinely application-neutral grouped usage/table primitive emerges
Context
The
codeUsage area currently follows the selected authentication vault. Switching profiles therefore replaces the usage shown at the bottom, making it difficult to compare remaining capacity across the profiles available before launch.This is distinct from atyrode/dotfiles#220, which investigates usage inside a running OMP session, and from #4, which owns the shared-width layout regression. This issue changes the pre-launch
codeUsage information architecture while reusing the responsive measurement rules from #4.Goal
Show usage for every configured, selectable vault at the same time. Organize each vault's provider usage under or beside the
codeprofile or profiles that reference it, instead of filtering the entire Usage surface to the currently selected vault.The selected profile should remain visually identifiable, but selection must not hide the other profiles' usage.
UX contract
Responsive behavior
Measure each provider and vault/profile group independently. Do not allow one vault's longest optional label or unavailable-state message to inflate every sibling group. Reuse the fixed-viewport, asymmetric-content, and state-transition verification discipline documented by #4 and
docs/tui-verification.md.Acceptance criteria
mineandmummapped to different vaults, both profiles' Codex/Claude usage groups are visible concurrently; changing the selected profile only moves the selected treatment.Likely ownership
pkgs/code-tui/pkgs/cli-kit/only if a genuinely application-neutral grouped usage/table primitive emergesRefs atyrode/dotfiles#212, atyrode/dotfiles#220, #4.