Statusline cost display inconsistent with /cost command

Issue

The statusline shows a different (lower) cost value than the /cost command for the same session, leading to inaccurate real-time cost monitoring.

Expected Behavior

The statusline should display the same total session cost that /cost shows, including:

• Cache read/write costs
• Background agent costs
• Subprocess and async operation costs
• All API calls (main conversation + background)

Current Behavior

Example from actual session:

• /cost command shows: $92.58
• Sonnet: $91.54 (654.8k output, 109.7m cache reads)
• Haiku: $1.04 (background agents)
• Statusline shows: Significantly lower value (appears to exclude cache reads and background agent costs)

Why This Matters

1. Cost visibility: Users rely on the statusline for real-time cost monitoring during active work
2. Budget surprises: Underreporting can lead to unexpected billing when the actual cost is much higher
3. Inconsistent UX: Having two different cost displays for the same data is confusing
4. Cache costs hidden: Cache read/write operations can be a significant portion of costs (109.7m cache reads in the example above), but aren't reflected in statusline

Impact

In sessions with heavy cache usage or background agents, the statusline can underreport costs by 10x or more, making it unreliable for cost tracking.

Suggested Fix

Option 1 (Preferred): Update statusline to use the same comprehensive cost calculation as /cost command

Option 2: Add a tooltip or indicator showing that statusline excludes certain costs, with a note to run /cost for accurate totals

Option 3: Show two values: Session: $X.XX (Total: $Y.YY) where Total includes all costs

Environment

• Claude Code version: Latest (as of 2025-03-12)
• Session type: Long conversation with context compaction, background agents, and heavy cache usage
• Models used: Claude Sonnet 4.5 + Haiku (for background tasks)

Additional Context

This inconsistency becomes especially problematic in:

• Long-running sessions with multiple context compactions
• Sessions using background Task agents (which spawn haiku instances)
• Projects with large codebases (high cache read costs)
• Sessions with many file reads/writes

Thank you for considering this improvement! Accurate cost visibility is crucial for managing API usage effectively.