Skip to content

fix(claude-usage): price Claude Opus 5, Fable 5, and Sonnet 5 usage - #10739

Closed
MadKangYu wants to merge 2 commits into
stablyai:mainfrom
MadKangYu:fix/claude-usage-claude-5-model-pricing
Closed

MadKangYu wants to merge 2 commits into
stablyai:mainfrom
MadKangYu:fix/claude-usage-claude-5-model-pricing

Conversation

@MadKangYu

@MadKangYu MadKangYu commented Jul 26, 2026 •

Copy link
Copy Markdown

Summary

Claude usage on the 5-series models was silently dropped from the cost breakdown.

MODEL_PRICING and normalizeModelForPricing had no entry or branch for claude-opus-5, claude-fable-5, or claude-sonnet-5, so estimateCostUsd returned null for 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.ts already has a fallback that maps unknown opus-4 point 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 literal opus-4 family string, so it stopped applying the moment the family name became opus-5.

Changes:

  • store.ts: add claude-opus-5, claude-fable-5, claude-sonnet-5 to MODEL_PRICING, plus their -thinking aliases and hasClaudeModelVersion branches in normalizeModelForPricing.
  • 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:

Model Input Output Cache read Cache write (5m)
Claude Opus 5 $5 $25 $0.50 $6.25
Claude Fable 5 $10 $50 $1 $12.50
Claude Sonnet 5 $2 $10 $0.20 $2.50

Screenshots

No visual change. This only affects the cost figures already rendered in the usage breakdown.

Testing

  • pnpm lint
  • pnpm typecheck
  • pnpm test
  • pnpm build
  • Added or updated high-quality tests that would catch regressions, or explained why tests were not needed

pnpm typecheck passes clean.

pnpm lint and pnpm test fail on this branch, but both failures reproduce identically on a pristine origin/main checkout with this branch's commit absent, and neither touches the files in this PR:

  • pnpm lint fails at verify:localization-coverage on unlocalized Ghostty keyword strings in terminal-advanced-platform-search.ts and terminal-pane-appearance-search.ts. Confirmed node config/scripts/audit-localization-coverage.mjs --check exits 1 on pristine origin/main.
  • pnpm test reports 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 pristine origin/main reproduced two of the same failures.

The four test files this PR touches or covers all pass: 95 tests green.

pnpm build passes clean, exit 0, roughly 93 seconds, including the native and computer-use-macos steps.

New test coverage in store.test.ts asserts the pricing rows and the normalization branches, including a claude-opus-5-20260724-style dated model ID, so a future family rename regression would be caught.

AI Review Report

Reviewed with Claude. Risks checked:

  • Rate accuracy. Every added rate was cross-checked line by line against the official Anthropic pricing table rather than copied from memory or a secondary source. Cache-write values use the 5-minute multiplier, consistent with the surrounding rows.
  • Normalization ordering. The new fable/opus/sonnet version-5 branches are placed ahead of the opus-4 and sonnet-4 branches, and the review confirmed no earlier substring branch shadows them. claude-fable-5 is matched before the opus branches so it cannot be absorbed by a looser match.
  • Cross-platform. No platform-specific behavior. This is a pure data table plus string normalization in main-process code, with no path handling, shell invocation, shortcut, or label surface. Nothing here differs on macOS, Linux, or Windows.
  • Provider neutrality. The Copilot catalog addition stays inside the existing Copilot-specific block and does not change behavior for other agents.

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.

  1. Sonnet 5 introductory pricing expires. Resolved in 02b657c after review feedback. Pricing now resolves per usage day, and buildBreakdown accumulates 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.

  2. 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 became opus-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, and capabilities but 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.

…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
@MadKangYu
MadKangYu marked this pull request as ready for review July 26, 2026 11:53
@coderabbitai

coderabbitai Bot commented Jul 26, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Claude 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)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly summarizes the main change: adding pricing for Claude Opus 5, Fable 5, and Sonnet 5 usage.
Description check ✅ Passed The description matches the template well, with complete summary, screenshots, testing, AI review, security audit, and notes sections.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between f5f0266 and c445f43.

📒 Files selected for processing (4)
  • src/main/claude-usage/store.test.ts
  • src/main/claude-usage/store.ts
  • src/shared/commit-message-agent-spec.test.ts
  • src/shared/commit-message-agent-spec.ts

Comment thread src/main/claude-usage/store.ts Resolved
…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.
@MadKangYu

Copy link
Copy Markdown
Author

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 estimateCostUsd's signature and never checked whether the callers already had a date. They did: daily aggregates carry day, and the session path has lastTimestamp.

Fixed in 02b657c.

  • resolvePricingForDay(model, day) resolves rates per usage day, with SONNET_5_STANDARD_PRICING_START_DAY = '2026-09-01'.
  • estimateCostUsd takes an optional day; callers that already know the usage day now pass it.
  • buildBreakdown accumulates cost per daily aggregate instead of pricing the summed totals once. This is the part that actually mattered: a model row spans many days, so pricing the aggregate with a single representative date would still be wrong for any row crossing the cutover. Pricing per day and summing avoids the approximation entirely.
  • Null cost semantics preserved. A model row stays null unless at least one daily aggregate produced a billable cost, and project rows stay null.
  • Incidental cleanup: extracted formatLocalDay and reused it in getRangeCutoff and getLocalDay, which were duplicating the same formatting.

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.

store.test.ts 13/13 pass and pnpm typecheck exits 0.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 lift

Price automation usage per day, not by session end date.

totals contains the entire session, but getLocalDay(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

📥 Commits

Reviewing files that changed from the base of the PR and between c445f43 and 02b657c.

📒 Files selected for processing (2)
  • src/main/claude-usage/store.test.ts
  • src/main/claude-usage/store.ts

@nwparker nwparker added the bug Something isn't working label Jul 27, 2026
@OrcaWin

OrcaWin commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

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: MODEL_PRICING and normalizeModelForPricing had no branch for claude-opus-5, claude-fable-5, or claude-sonnet-5, so estimateCostUsd returned null and all 5-series usage was silently dropped from the cost breakdown. Your observation that the existing future-proofing didn't catch it was also right — the unknown-model fallback is keyed on the literal opus-4 string, so it could never match a 5-series id.

Claude 5 pricing landed in cf513addd (#10822) with the same rates you proposed. Current main has the entries at src/main/claude-usage/store.ts:62-66 and the normalizer branches at :165-194, so git diff origin/main on this branch is now effectively empty.

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.

@OrcaWin OrcaWin closed this Jul 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants