[FEATURE] Feature Request: Granular Token Attribution in `/context` (Reveal specific costs for Hooks, MCPs, and Templates)

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

When using Claude Code with a sophisticated setup (multiple MCP servers, custom hooks, and injected templates), the session often starts with significant context usage (e.g., 40k+ tokens) before the user sends a single message.

Currently, the /context command groups usage into broad buckets like System tools and Messages. This creates a "black box" where users cannot easily audit where their context window is being spent.

For example:

• "System tools: 16.3k": A user doesn't know if this is the standard Bash tool or a specific heavy MCP server (like Playwright).
• "Messages: 11.1k": On a fresh session, a user expects this to be near zero. They cannot see that SessionStart hooks have injected 6k tokens via a plan_template.md and 2k via a docs_template.txt.

Without this visibility, users struggle to optimize their environment, debug token limits, or trust that the system isn't "leaking" tokens.

Proposed Solution

I would like the /context command to act as the definitive Source of Truth for token usage by offering a granular breakdown of the high-level categories.

The output should provide an itemized list of "Heavy Hitters" (>500 tokens) within the categories:

1. Break down "System Tools": List the token cost of individual tool definitions.

• e.g., mcp__playwright: 8,400 tokens

1. Break down "Messages": Distinguish between actual conversation history and injected Hook/System outputs.

• e.g., SessionStart (plan_template.md): 6,500 tokens

1. Break down "Memory Files": (Currently partially exists, but should explicitly list all active rule files).

Desired UX:
Running /context --verbose or simply updating the default /context view to include a "Detailed Usage" section.

Alternative Solutions

• Manual Calculation: Currently, I have to manually count tokens of my templates, guess the schema size of MCP tools, and manually sum them up to verify the numbers.
• Asking Claude: I can ask Claude "Why is context usage so high?", but this uses more tokens and relies on the model's estimation rather than the system's actual tokenizer data.
• Disabling Features: I currently have to blindly disable MCP servers or hooks one by one to identify which ones are bloating the context window.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

Scenario: A developer starts a new session to work on a small bug fix.

1. User runs claude (starts fresh session).
2. User immediately runs /context.
3. Current Result: User sees 40k / 200k used. They are confused because they haven't typed anything yet. They don't know if they should restart or if this is normal.
4. Ideal Result: User runs /context and sees:

```text
Context Usage: 40k / 200k (20%)

Top Contributors:
[Tools] mcp__playwright ........ 8.2k
[Hook] plan_template.md ....... 6.5k
[Hook] docs_template.txt ...... 2.0k
[Mem] CLAUDE.md .............. 3.1k
```

1. Action: The user realizes they don't need browser automation for this task. They disable the Playwright MCP plugin to reclaim 8.2k tokens and proceed with a leaner session.

Additional Context

Mockup of Proposed Interface

  ⎿   Context Usage
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   claude-opus-4-5
     ⛁ ⛁ ⛁ ⛁ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶   40.3k / 200k tokens (20.2%)

     Detailed Attribution
     ────────────────────
     ▼ System tools (16.3k)
       └ mcp__playwright: 8.4k
       └ mcp__chrome-devtools: 4.1k
       └ Native Tools (Bash/Edit/etc): 3.8k

     ▼ Messages (11.1k)
       └ Hook: enforce-plan-mode (plan_template.md): 6.5k
       └ Hook: inject-docs (docs_template.txt): 2.0k
       └ System Status Logs: 0.5k
       └ User/Assistant History: 2.1k

     ▼ Memory files (9.9k)
       └ ~/.claude/CLAUDE.md: 3.1k
       └ Rules (14 files): 6.8k

Technical Considerations:
Claude Code already tokenizes these inputs before sending them to the API. This feature request asks to expose those specific counts—which must already exist in memory to calculate the totals—to the user interface.