[FEATURE] Per-request latency breakdown (network vs inference timing)

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 from regions far from Anthropic's servers (e.g., South Africa), network round-trip latency dominates wall-clock time. Each sequential tool call adds ~200-300ms of pure network overhead before inference even begins. A response chain with 5-10 tool calls can add 1-3 seconds of dead time from RTT alone.

Currently there's no way to tell whether a slow interaction is caused by network latency, inference time, or output token generation. This makes it impossible to:

• Know whether "fast mode" would actually help your use case
• Diagnose whether a slow response is a network issue or a model issue
• Make informed decisions about workflow optimisation (e.g., preferring parallel tool calls)

Proposed Solution

Expose a per-request timing breakdown, either as:

• A debug/verbose flag (e.g., --timing or CLAUDE_CODE_TIMING=1) that logs per-call metrics inline or to stderr
• A summary at the end of each response showing: total wall time, total network time (TCP + TTFB), total inference time, total streaming time
• Data in /cost or a new /timing command for the current session

Example output:

Timing: 4.2s wall | 1.8s network (6 round trips) | 1.9s inference | 0.5s streaming

Alternative Solutions

• Manually running curl -w against api.anthropic.com to estimate RTT — but this doesn't capture real per-tool-call timing within Claude Code
• Eyeballing response speed — unreliable and doesn't separate the components

Use Case Example

1. I'm working on a Laravel + React project from South Africa
2. Claude Code makes 6 sequential tool calls (reads, greps, edits)
3. The interaction takes 12 seconds wall-clock
4. I don't know if fast mode, reducing tool calls, or a VPN closer to US servers would help most
5. With timing data, I'd see "7.2s is network latency" and know that reducing round trips (parallel tool calls) or routing through a closer region would have the biggest impact

Additional Context

This would be especially valuable for users outside the US/EU where RTT to Anthropic's API is 150-300ms. It would also help the Claude Code team understand real-world performance characteristics across their user base.