[BUG] "Thought for Ns" thinking-duration timer shows wildly inflated values (hours) on Opus 4.8 in 2.1.210/2.1.211

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The "Thought for Ns" duration label shown above extended-thinking blocks in the transcript displays wildly inflated values. Two consecutive thinking blocks showed "Thought for 16100s" and "Thought for 16087s" (~4.5 hours each), despite being only ~13 seconds apart in wall-clock time based on the interleaved tool calls between them. The thinking-summary content itself renders correctly and reads like a normal short block (a few seconds of reasoning) — only the duration number is wrong.

Reproduced independently on both v2.1.210 and v2.1.211.

Isolated to model: on the same machine/settings, a Sonnet 5 session shows correct short durations (e.g. "Thought for 11s", "Thought for 2s"), while an Opus 4.8 session (effort: Extra high / xhigh, Thinking on) shows the inflated values described above.

What Should Happen?

Each thinking block's duration label should reflect that block's own elapsed time, reset per block, independent of session length or prior tool-call/thinking activity.

Error Messages/Logs

N/A — this is a display-only bug (no crash, no error output, no functional failure).

Steps to Reproduce

Exact minimal trigger conditions are not yet isolated; this was observed during normal agentic use rather than a constructed minimal repro. Observed conditions:

1. Start a Claude Code session in the VS Code native extension (chat panel, not the integrated terminal) on Opus 4.8, with Effort set to Extra high and Thinking enabled.
2. Set "showThinkingSummaries": true in settings.json.
3. Run a multi-step agentic task that interleaves several extended-thinking segments with tool calls (e.g. Read/Bash/Edit), across at least two separate thinking blocks.
4. Observe the "Thought for Ns" label rendered above each thinking block.
5. Compare consecutive thinking blocks: the displayed durations are inflated by orders of magnitude (thousands of seconds) relative to the actual wall-clock gap between them, even though the rendered summary content is short.
6. Re-run the same task/settings on Sonnet 5 in the same project: durations render correctly.

Claude Model

Opus (specifically Opus 4.8; also reported on Fable in a separate session, not independently re-verified by the reporter)

Is this a regression?

I don't know

Last Working Version

Not confirmed — not yet tested against versions prior to 2.1.210.

Claude Code Version

2.1.211 (also reproduced on 2.1.210)

Platform

Anthropic API (Claude Pro/Max subscription auth, not a direct API key)

Operating System

macOS

Terminal/Shell

Other — VS Code native extension (chat sidebar/panel), not a terminal-hosted session.

Additional Information

• showThinkingSummaries: true is set in settings.json; thinking-summary content itself renders correctly — only the duration counter is affected.
• Effort level: Extra high (xhigh); Thinking: on.
• The only timer/counter-related changelog entry in the two most recent releases is from v2.1.210: "Added a live elapsed-time counter to the collapsed tool summary line so long-running tool calls visibly tick instead of looking stuck." This may share code with the thinking-duration display and is a plausible (unconfirmed) root cause given the version correlation.
• Related but distinct (already-fixed) prior reports of the same symptom class: #38547, #42622, #47297. Those described the duration incrementing on manual expand/collapse toggling in the VS Code extension. This report's inflation appears without requiring a toggle interaction, so the trigger differs, but the underlying symptom (a duration label that does not reflect the block's actual elapsed time) is the same family.
• Screenshots of the affected transcript exist and can be attached in a follow-up comment if useful for triage.