[Bug]: Usage View shows total usage cost without splitting off the cache savings

[JDeffner]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Start Nightly Version of the app
2. go to usage

Expected behavior

show the cost (the large number being the actual api cost)

Actual behavior

shows the cost as if caching was not a thing

Impact

Cosmetic issue

Version or commit

0.0.36-nightly.20260828.1209

Environment

Desktop Nightly

Logs or stack traces

Screenshots, recordings, or supporting files

Screenshot 2026-08-28 153200.png

Workaround

No response

[derektrimm]

I dug into this and can reproduce the root cause. It is not a display issue - the estimate itself is computed cache-blind for most Claude models, and the screenshot's own numbers prove it.

Root cause: parseRateTable (apps/server/src/usage/usagePricing.ts) normalizes LiteLLM keys by stripping everything through the last / and inserts into a Map, so later entries overwrite earlier ones. The LiteLLM document lists the canonical claude-fable-5 entry (cache reads at $1/M) and, tens of thousands of lines later, deepinfra/anthropic/claude-fable-5 - which has input/output rates but no cache_read_input_token_cost. Both normalize to claude-fable-5; the deepinfra entry wins; the ?? input fallback then prices every cache read at full input rate, and cacheSavingsUsd computes cached * (input - input) = 0.

Against today's table, the losers are exactly the models in the screenshot: claude-fable-5, claude-opus-5, claude-opus-4-8, claude-sonnet-5 (all shadowed by cache-less deepinfra/anthropic/* entries), plus gpt-5/gpt-5-mini/gpt-5-nano (shadowed by replicate/openai/*). claude-haiku-4-5-20251001 and gpt-5.6-terra survive only by JSON ordering luck - and those are precisely the two models still capable of producing the tiny $9.45 savings shown.

The screenshot arithmetic confirms it: fable-5 averages $10.14 per 1M tokens - full input rate for a 3.08B-token bucket that is overwhelmingly cache reads; opus-5 averages $5.05/M against a $5/M input rate. The implied per-model output tokens under cache-blind pricing sum to ~25.7M against the displayed 25.3M, and the six model costs sum to the $62,540.18 headline exactly. With correct rates this view would show roughly a tenth of that headline and ~$54k of cache savings.

Side effect worth knowing: the same collision also corrupts base rates for other models today - e.g. gemini-2.5-pro is priced at 2x from a vercel_ai_gateway/ shadow entry - so fixing the precedence repairs more than the cache column.

Fix incoming as a PR: slash-free (canonical) keys take precedence over prefix-stripped ones in parseRateTable, with regression tests. The ?? input fallback itself is left alone - it is correct for models that genuinely have no cache pricing; the bug is only who wins the slot.

[andersryanc]

Seems like this was introduced by the most recent build 0.0.35. The claude usage number was showing correctly right before I updated. I'm not running the nightly build.

[andersryanc]

Not sure if it's related, probably not since the info above says it's effecting other providers as well, but I also recently updated claude code cli around the same time and may not have noticed until after I updated the app. I'm running v2.1.250 of claude code. I'm not using any other providers on this machine.

[derektrimm]

@andersryanc Good eye on the timing - it really did start for everyone right around 0.0.35. It's a coincidence, though, and a provable one. The pricing code (usagePricing.ts) hasn't changed since Aug 8, so 0.0.34 and 0.0.35 ship identical pricing logic. The rate table isn't bundled with the app either - the server pulls LiteLLM's model_prices_and_context_window.json straight from their GitHub main branch and caches it on disk for 24 hours.

What actually changed is the upstream data. LiteLLM added the shadowing deepinfra/anthropic/claude-* rows on Aug 26-27, and the moment your 24h snapshot refreshed past that point, those cache-less deepinfra entries started winning the rate-table collisions and cache savings dropped to zero. For most people that landed right around when 0.0.35 shipped on Aug 27, which makes the update look guilty. The collision bug was latent all along; the new rows just lit it up. And no worries about your Claude Code CLI version - pricing is computed server-side from the transcripts plus this rate table, so that update is unrelated.

#8548 fixes the precedence so canonical slash-free keys always beat prefixed reseller rows, with regression tests for this exact scenario. Once that lands, the numbers should snap back without touching your setup.