Feature request: include thinking_tokens in API usage response

Summary

The API usage response object includes input_tokens, output_tokens, cache_read_input_tokens, and cache_creation_input_tokens — but does not include thinking tokens as a separate field. With Opus 4.7's shift to mandatory adaptive thinking, this gap has become a measurable cost transparency issue.

The problem

Our metered telemetry (claude-code-meter) shows that Opus 4.7 consumes Q5h quota at 2.4x the rate of Opus 4.6 for equivalent visible token counts:

| Metric | Opus 4.6 | Opus 4.7 |
|---|---|---|
| Avg Q5h per turn | ~0.3% | ~0.73% |
| Ratio | 1x | 2.4x |

The visible token counts don't account for this difference. The gap is consistent with invisible thinking token overhead being charged against quota but not reported in the usage response.

Users cannot:

• See how many thinking tokens were consumed per call
• Distinguish thinking cost from inference cost
• Optimize their thinking budget (manual control was removed in 4.7)
• Verify that quota charges match visible usage

Under the new per-token enterprise billing, this is an invisible line item on the invoice.

Request

Add thinking_tokens (or adaptive_thinking_tokens) to the usage response object:

{
  "usage": {
    "input_tokens": 6,
    "output_tokens": 490,
    "cache_read_input_tokens": 67450,
    "cache_creation_input_tokens": 541,
    "thinking_tokens": 12500
  }
}

The data exists server-side — it's computed for billing. Exposing it is a documentation decision, not an engineering project.

Related

• anthropics/claude-code#42796 — Opus 4.7 quality regressions, adaptive thinking discussion
• @ArkNill's thinking token blind spot analysis
• claude-code-cache-fix Discussion #25 — first metered 4.7 session data