feat(ui): the cost cards say what kind of money they are, and the plan gets its own meter

[as-koshiyama]

Packs the outstanding cost-monitoring work into one branch, superseding #52, #51 and #49.

What this adds

The Overview's card row becomes five cards that each say what kind of money they are, and the plan's own meter gets a view of its own.

Card	Says
SPEND	Real money — seats, and whether overflow billing is in play
TOKENS	Counts: messages and distinct models
TOKEN COST	The hypothetical, at API list rates
AVG USAGE RATE	How hard the plan is driven — average peak across 5-hour windows
TOOLS & SITES	Detection counts

The SPEND / TOKEN COST split is the point: actual money and list-rate arithmetic are different claims, and neither leaks into the other. [m] on Usage swaps the token table for the plan's own metering windows.

Review it in the same chunks the stacked PRs would have given you

History is left as-is rather than rewritten, so each superseded PR is still a contiguous set of commits:

Supersedes #52 — the card row

• f0ed7e6 feat(ui): the Overview cards say what kind of money they are, in order
• 77938b2 fix: the spend fixtures gain the metering field

Supersedes #51 — the metering view (this carried your approval of Aug 3)

• e09f8c4 feat(usage): [m] swaps the Usage view for the plan's own meter
• 32eb523 fix: main's new fixture gains the metering field

Supersedes #49 — repo aliases

• 54bbe87 feat(usage): [usage.repo_aliases] folds two names for one project

Only on this branch — integration fixes that came out of merging the three together, and exist in none of the PRs above

• c4284a0 fix(integration): the queue's fixtures gain the metering field
• cf88d91 fix(integration): the all-priced token-cost fixture gains cache rates
• 4ecb38a fix(integration): the tools-column fixture gains the plans field
• 3cc6bf4 fix(integration): widen the token-cost card test for the five-card row

Carried over from #49

@kleyt0n, your review on #49 was dismissed before it could be actioned, so restating it here rather than losing it with the PR:

Approved. But make sure that the changes are not generalized and will not provoke any damage to perfomance.

This is not claimed as resolved — [usage.repo_aliases] is opt-in and off unless configured, but the aliasing runs inside the usage fold, so it is worth your eye on the hot path before this merges.

Checks

Run locally on adriano/dev, all green:

cargo fmt --all --check          clean
cargo clippy --workspace --all-targets -- -D warnings    clean
cargo test --workspace           284 passed, 0 failed

Note

Contains one known cosmetic defect, not yet fixed: the TOKEN COST detail line renders over 30 days · ≈ $65.67/ — 27 characters into a 24-column card, so the /day unit is cut. Happy to fix it here or leave it for a follow-up, whichever you prefer.

---

🤖 Generated with Claude Code

[as-koshiyama]

@kleyt0n — correcting something stated when #51 was closed, since it affects how much of this you need to re-read.

I said the metering commits were unchanged since your approval. That is not exactly right. Your approval on #51 was against 95f2152, the tip of origin/feat/metering-view. That branch has three commits; this branch carries only two of them:

Commit	On origin/feat/metering-view	In this PR
e09f8c4 feat(usage): [m] swaps the Usage view for the plan's own meter	yes	yes
32eb523 fix: main's new fixture gains the metering field	yes	yes
95f2152 fix: main's two new spend-card fixtures gain the metering field	yes (approved tip)	no

95f2152 adds two metering: Default::default(), lines to spend-card test fixtures. Its substance is present here — this branch sets that field on 14 fixtures against 11 on the branch you approved, because the integration commits (c4284a0, 77938b2, 4ecb38a) covered the same ground while merging — and cargo test --workspace passes at 284.

So: the feature commits are byte-identical to what you approved, but the approved tip is not an ancestor of this branch. Treat the metering work as needing a fresh look rather than trusting the earlier sign-off.