Repository navigation
Conversation
…g entries Claude Opus 5 shipped 2026-07-24 and became the default model on Claude Max, but MODEL_PRICING and normalizeModelForPricing had no opus-5 branch, so usage on the new family was silently dropped from cost aggregation. The existing future-model fallback only matched the literal opus-4 family string, so it did not survive the family rename. - store.ts: claude-opus-5 (5/25/0.5/6.25), claude-fable-5 (10/50), claude-sonnet-5 (3/15) plus thinking aliases and opus-5 normalization - commit-message-agent-spec.ts: extend the static Copilot catalog with the 5-series models so users can select what their org enables
📝 WalkthroughWalkthroughClaude 5 pricing entries, normalization rules, thinking aliases, and day-sensitive Sonnet 5 pricing were added to the usage store. Cost calculations now receive local-day information for summaries, model breakdowns, and automation usage. Tests cover Claude 5 model costs and introductory-to-standard Sonnet 5 pricing across the transition date. The Copilot model list and its corresponding test now include four Claude 5 models. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: e2b919c2-5f4d-4957-a86f-a7ef28f77833
📒 Files selected for processing (4)
src/main/claude-usage/store.test.tssrc/main/claude-usage/store.tssrc/shared/commit-message-agent-spec.test.tssrc/shared/commit-message-agent-spec.ts
…y cutover Sonnet 5 introductory pricing ($2/$10) ends 2026-08-31 and standard pricing ($3/$15) starts 2026-09-01, so a single flat rate silently under-reports cost once the cutover passes. Pricing now resolves per usage day: - add SONNET_5_STANDARD_PRICING and SONNET_5_STANDARD_PRICING_START_DAY, and resolve rates through resolvePricingForDay(model, day) - estimateCostUsd takes an optional day; callers that already know the usage day now pass it (daily rows, session totals) - buildBreakdown accumulates cost per daily aggregate instead of pricing the summed totals once, so a model row spanning the cutover is priced correctly on both sides. Null cost semantics are preserved: rows stay null unless at least one daily aggregate produced a billable cost, and project rows stay null - extract formatLocalDay and reuse it in getRangeCutoff and getLocalDay Tests cover pre-cutover, post-cutover, and a row spanning both days.
|
Good catch, and the original scoping note was wrong. I said a date-correct fix would require threading a timestamp through the pricing path, but I only checked Fixed in 02b657c.
Three deterministic tests added, all passing day explicitly rather than depending on the system clock: pre-cutover at introductory rates, post-cutover at standard rates, and a single model row spanning 2026-08-31 and 2026-09-01 that must sum both rates.
|
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/claude-usage/store.ts (1)
834-840: 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy liftPrice automation usage per day, not by session end date.
totalscontains the entire session, butgetLocalDay(session.lastTimestamp)selects one Sonnet 5 rate for all tokens. A session crossing the 2026-08-31 → 2026-09-01 cutoff will therefore misprice part of its usage. Use per-day session attribution, or preserve daily token totals for automation-cost calculation, and add a cross-cutoff regression test.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: c6e70f75-b0ad-456a-9fd0-0475b4e7d36a
📒 Files selected for processing (2)
src/main/claude-usage/store.test.tssrc/main/claude-usage/store.ts
|
Thank you for this — your diagnosis was completely correct, and I'm closing only because the same fix has since landed on main. I verified the bug independently before checking: Claude 5 pricing landed in Sorry you lost the race on this one — the analysis was sound, especially catching that Opus 5 shipped as the Max default and that this was affecting live usage rather than a hypothetical future model. Please do send more PRs. |
Summary
Claude usage on the 5-series models was silently dropped from the cost breakdown.
MODEL_PRICINGandnormalizeModelForPricinghad no entry or branch forclaude-opus-5,claude-fable-5, orclaude-sonnet-5, soestimateCostUsdreturnednullfor any usage on those models. Opus 5 shipped 2026-07-24 and is now the default model on Claude Max, so this affects current usage, not a hypothetical future model.The existing future-proofing did not catch it.
store.tsalready has a fallback that maps unknownopus-4point releases onto current Opus pricing, with a comment explaining that the goal is to avoid silently mis-costing unknown Claude Code model IDs. That guard is keyed on the literalopus-4family string, so it stopped applying the moment the family name becameopus-5.Changes:
store.ts: addclaude-opus-5,claude-fable-5,claude-sonnet-5toMODEL_PRICING, plus their-thinkingaliases andhasClaudeModelVersionbranches innormalizeModelForPricing.commit-message-agent-spec.ts: extend the static Copilot catalog with the 5-series entries so users can select the models their org has enabled. The catalog is intentionally static (per the existing comment, Copilot's picker is policy-filtered per account/org), so new hosted models have to be added by hand.All rates verified against https://platform.claude.com/docs/en/about-claude/pricing on 2026-07-26:
Screenshots
No visual change. This only affects the cost figures already rendered in the usage breakdown.
Testing
pnpm lintpnpm typecheckpnpm testpnpm buildpnpm typecheckpasses clean.pnpm lintandpnpm testfail on this branch, but both failures reproduce identically on a pristineorigin/maincheckout with this branch's commit absent, and neither touches the files in this PR:pnpm lintfails atverify:localization-coverageon unlocalizedGhosttykeyword strings interminal-advanced-platform-search.tsandterminal-pane-appearance-search.ts. Confirmednode config/scripts/audit-localization-coverage.mjs --checkexits 1 on pristineorigin/main.pnpm testreports 20 failing files out of 3437 (3410 passing), concentrated in socket, PTY, and git-integration suites that appear environment-sensitive. Spot-checking four of them on pristineorigin/mainreproduced two of the same failures.The four test files this PR touches or covers all pass: 95 tests green.
pnpm buildpasses clean, exit 0, roughly 93 seconds, including the native and computer-use-macos steps.New test coverage in
store.test.tsasserts the pricing rows and the normalization branches, including aclaude-opus-5-20260724-style dated model ID, so a future family rename regression would be caught.AI Review Report
Reviewed with Claude. Risks checked:
fable/opus/sonnetversion-5 branches are placed ahead of theopus-4andsonnet-4branches, and the review confirmed no earlier substring branch shadows them.claude-fable-5is matched before the opus branches so it cannot be absorbed by a looser match.Flagged and deliberately not changed in this PR, listed under Notes below.
Security Audit
No new input handling, command execution, path handling, auth, secrets, dependency, or IPC surface. The change adds constant numeric rates to an existing in-memory table and adds string-comparison branches to an existing pure function that already receives the same untrusted model string. No new external calls and no new dependencies.
Notes
One follow-up left out to keep this PR scoped to the reported bug. Happy to open a separate PR if you want it.
Sonnet 5 introductory pricing expires.Resolved in 02b657c after review feedback. Pricing now resolves per usage day, andbuildBreakdownaccumulates cost per daily aggregate so a model row spanning 2026-08-31 to 2026-09-01 is priced correctly on both sides rather than approximated with one representative date.The family fallback is still version-specific.
lower.includes('opus-4')mapping to current Opus pricing is exactly the guard that failed here once the family becameopus-5. A version-agnostic form would prevent the next occurrence, but it involves assuming pricing for unreleased models, so it seemed like a maintainer call rather than something to fold into a data fix.Also worth noting: pricing is not machine-readable from any Anthropic API. The Models API returns
max_input_tokens,max_tokens, andcapabilitiesbut no rates, so this table cannot be automated and will need manual updates on each model launch.ELI5
Usage for Claude Opus 5, Fable 5, and Sonnet 5 was ignored in cost estimates because pricing tables had no entries. Those models are priced correctly so usage breakdowns include real spend.