[FEATURE] Surface detailed token-accounting breakdown in Claude Code sessions

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Today, /cost returns an aggregate number for a Claude Code session. Power users running long-lived automations, CI jobs, and MCP-driven workflows can't tell why a session was expensive. Specifically, the current signal doesn't distinguish:

Tokens spent on cache misses vs. cache hits
Tokens spent on tool-call round-trips vs. model generation
Tokens spent on retries, session resumes, or failed tool invocations
Whether a peak-window multiplier was applied
Without this breakdown, we can't diagnose unexpected token burn, can't tune prompts or tool usage for efficiency, and can't catch regressions quickly. Issue #41930 — a cache-invalidation bug that caused 10–20× token inflation — took days to surface because no one had the per-category signal needed to notice the shift early. The underlying data exists server-side; users just don't see it.

Proposed Solution

Two additions:

/cost --detailed (or a persistent top-line option) returning per-category breakdown for the current session:
Model input — cache hit
Model input — cache miss
Model output
Tool-call round-trips (aggregated per tool)
Retries / session resumes
Peak-window multiplier applied (if any)
The same data exposed in JSON (claude cost --json or equivalent) so wrappers, dashboards, and agent frameworks can consume it programmatically.
Both should reflect live in-session state — no round-trip to the Admin API.

Alternative Solutions

/cost alone — insufficient; single aggregate with no decomposition.
Usage & Cost Admin API — historical only, not in-session, separate auth flow.
anthropic-ratelimit-* response headers — rate-limit state only; no cost decomposition, not accessible inside Claude Code without custom instrumentation.
Third-party wrappers estimating from transcripts — unreliable, can't see cache state.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

Scenario: I run an overnight automation that refactors a codebase across ~200 files. In the morning I find it hit its weekly Sonnet limit halfway through.

Today I check /cost and see a total — no way to tell what drove it.
With /cost --detailed --json I see: 70% of tokens went to cache misses on a repeated file-read pattern I could have batched, 15% were retries on a flaky MCP tool, 5% were peak-multiplier surcharge because the job started at 14:00 UTC.
I rewrite to batch file reads, add retry backoff on the MCP tool, and shift the schedule to 20:00 UTC. Next run uses ~40% of the tokens for the same work.
This turns token usage from a black box into a tunable system property. Today, that tuning is impossible.

Additional Context

Related to #41930 — a cache-invalidation bug caused 10–20× token inflation for paid users in late March 2026. Per-category token accounting would have let users flag the cache-miss spike within minutes instead of days.

Companion feature request filed separately: a public capacity-signal endpoint so automations can self-shift off-peak. Together these form a "transparency primitives for automation" story; each ships independently.