Summary of Changes

Hello @holstein13, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the application's cost calculation logic to ensure consistency and accuracy across all user interfaces. By centralizing pricing data and calculation functions into a single shared module, it eliminates discrepancies that previously existed between different parts of the application. The update also enhances transparency regarding pricing for unknown models and provides a clearer user experience for understanding session costs, especially in scenarios involving subagents.

Highlights

• Unified Cost Calculation: Replaced two disparate cost calculation systems (one in the main process, one in the renderer) with a single, shared pricing module. This ensures consistent cost reporting across the application.
• Enhanced Pricing Accuracy: The new shared module leverages the comprehensive pricing.json data, supporting 206 LiteLLM models with accurate tiered pricing based on token usage, significantly improving accuracy compared to the previous hardcoded 6-model lookup table.
• Improved Error Handling for Unknown Models: Instead of silently guessing rates for unknown models, the system now explicitly returns $0 cost and logs a console warning, making pricing gaps transparent.
• User Experience Update for Session Costs: Added a '(parent only · view full cost)' disclaimer to the Visible Context panel's session cost display. The 'view full cost' portion is a clickable link that opens the detailed Session Report, clarifying that the displayed cost pertains only to the parent session and allowing users to access a complete breakdown including subagent costs.
• Refactored Pricing Data Loading: Switched from runtime fs.readFileSync for pricing data to a static import of pricing.json using resolveJsonModule, simplifying the architecture and improving performance.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Well I though subagents session are stored in a separate jsonl files and are shown separately in the sidebar / tab. My initial implementation was based on this assumption, but I could be wrong though.

Edit: You are right, in that case the cost usage shown will be incorrect (we show sub agent trace in same session - which makes sense). I think a new PR with this fix would be great.

Well I though subagents session are stored in a separate jsonl files and are shown separately in the sidebar / tab. My initial implementation was based on this assumption, but I could be wrong though.

Edit: You are right, in that case the cost usage shown will be incorrect (we show sub agent trace in same session - which makes sense). I think a new PR with this fix would be great.

Awesome. The data is already available, and no new IPC is needed. I'll go ahead and make the change to this PR so that our numbers match exactly.

On Edit: Done. @matt1398, the new commits address this issue, and everything should align now.

Great catch — you were right that subagent sessions are stored in separate JSONL files ({sessionId}/subagents/agent-{id}.jsonl), each parsed independently with their own metrics. That's why calculateMetrics() in jsonl.ts only returns the parent cost.

But as you noted, since subagent traces are displayed in the same session view (as SubagentItem cards in the timeline), showing only the parent cost is misleading.

Good news: the fix was straightforward since the data was already available. SessionDetail.processes[].metrics.costUsd already contains each subagent's cost (computed in the main process). I just added a useMemo in ChatHistory.tsx to sum them up and pass the total through to the header.

Pushed in 56dc860 — the Visible Context panel now shows:

• Total cost (parent + subagents) as the headline number
• Breakdown when subagents exist, e.g. $24.70 ($16.85 parent + $7.84 subagents · details)
• "details" link to the Session Report for the full per-model breakdown

For sessions without subagents, it just shows the cost with no annotation — same as before.

A note here, I was also experimenting with subagents and costing. It seems the cost from /cost for subagents vs the new approach where you will parse every subagents jsonl is very different.

I ran a session with claude code with 2 subagents and the total cost with /cost was $3.6 but with the new approach it was $6, which is around twice as what it showed. It seems claude code cli or the sub agent costing is slightly different than main session?

• Claude code

• Devtools

Edit: I also looked at ccusage tool and it also shows incorrect cost.

Great finding @KaustubhPatange — I dug into this and here's what I found:

There's no server-reported cost in the JSONL files

The JSONL usage object only contains token counts (input_tokens, output_tokens, cache_read_input_tokens, cache_creation_input_tokens). There's no cost, billing, or price field anywhere. All cost is computed client-side from token counts × pricing rates — by us, by ccusage, and presumably by any similar tool.

The ~2x discrepancy is most likely cache creation double-counting

When a parent session creates a prompt cache and a subagent reuses it, both JSONL files report cache_creation_input_tokens. When we sum costs from both files, we charge for creating the same cache twice.

Cache creation is expensive — typically 25% more than regular input tokens (e.g., $3.75/MTok vs $3.00/MTok for Sonnet). Double-counting it across parent + 2 subagents could easily account for the $2.40 difference ($6 vs $3.6).

Other findings from the raw JSONL data

The usage object also contains fields we're not using:

• cache_creation sub-object with ephemeral_5m_input_tokens and ephemeral_1h_input_tokens — tracks cache lifecycle/duration. This metadata could potentially help deduplicate cache charges across sessions.
• service_tier (e.g., "standard") — completely ignored by our cost calculation. Different tiers might have different pricing.

Our UsageMetadata TypeScript type doesn't even define these fields.

What Claude Code's /cost likely does differently

• Uses actual API billing data or applies cache deduplication logic
• May account for service tier pricing
• Doesn't double-count cache tokens across parent/subagent boundaries

This is a systemic issue, not specific to our PR

As you confirmed, ccusage shows the same inflated number — any tool computing cost from JSONL token counts + pricing tables will have this problem. The fix would need to deduplicate cache creation tokens across parent/subagent boundaries, which is a deeper change.

Worth tracking as a separate issue — happy to investigate cache deduplication strategies if you're interested.

@holstein13 I think once your PR is merged, it would be better to open a issue and track this.

Relevant issue with ccusage for tracking sub agents (sidechains): ryoppippi/ccusage#313 (comment)

Edit: We need to account for duplicate token tracking. There is a similar PR opened in ccusage ryoppippi/ccusage#835 (comment) but looks like this is not merged. We can use it to fix the double accounting problem.

Merged. Thanks @holstein13 for the refactor and @KaustubhPatange for catching the subagent cost bug. Let's track the cache issue in a separate ticket.