[BUG] Excessive usage from stalled API streams + silent thinking token consumption

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?

Environment

• Claude Code v2.1.91 (Windows 11, desktop app + VS Code extension)
• Model: claude-opus-4-6[1m] (Opus 4.6 with 1M context)
• Plan: Max 5x
• MAX_THINKING_TOKENS: 20000

Summary

A simple task (transcribe a chord chart from 2 screenshots into text) caused usage to jump from 17% to 30% (13% of Max 5x plan) within ~2 minutes, with zero useful output produced. The API stream started extended thinking but never completed any content blocks, silently consuming tokens until the user cancelled.

Reproduction

1. Start a session with Opus 4.6 on 1M context
2. Provide 2 screenshot images + a reference text file (total context ~21K tokens)
3. Ask the model to produce a text chord chart based on the screenshots
4. Observe: model enters extended thinking, produces no visible output for 30-120+ seconds
5. Cancel the request
6. Check usage: significant tokens consumed despite no output

This reproduced 3 times in a row across separate sessions, same behavior each time.

Key observations:

• Stream DID start (TTFB was 3 seconds)
• message_start event was received
• Model entered thinking mode and stayed there for 33+ seconds
• No content blocks were ever completed — zero usable output
• On abort, client logged "triggering non-streaming fallback" — unclear if this sent ANOTHER full request

Session 374440b7 (previous attempt, no debug log)

Same pattern visible in JSONL:

21:13:54.914  Last tool_result returned
              ... 99 seconds of NOTHING in the JSONL ...
21:15:34.216  User interrupted

Session 9251739f (first attempt)

20:59:15.856  Tool result returned (Read)
              ... 2 minutes 15 seconds, zero log entries ...
21:01:31.121  User interrupted

Usage Impact

Logged usage for the completed responses (the ones that DID return) shows:

• cache_creation_input_tokens: 9,703–21,845 per turn
• cache_read_input_tokens: up to 72,715 per turn
• output_tokens: as low as 2 (tool calls only)

But the stalled request (23b45f49) has no usage logged at all because it aborted before the response completed. The server-side thinking tokens consumed during 33+ seconds of extended thinking are unaccounted for in client logs but clearly billed.

Additional Issues Found

1. Excessive count_tokens API calls

41 count_tokens requests fired in a single session for the /context command or suggestions system. Each sends the full conversation context to the API. For a 21K+ token context with images, this is significant overhead.

2. "Non-streaming fallback" on abort

When the stream is aborted, the error handler says "triggering non-streaming fallback" — does this send a SECOND full API request that also gets billed? If so, that doubles the cost of every cancelled request.

3. OAuth scope errors (minor)

AxiosError: [url=.../overage_credit_grant, status=403, body=OAuth token does not meet scope requirement user:profile]

These fire repeatedly (4+ times per session) but don't seem to affect functionality.

4. IDE MCP server connection instability

MCP server "ide" Failed to fetch tools: MCP error -32000: Connection closed
MCP server "ide": WebSocket transport closed/disconnected, attempting automatic reconnection

The IDE MCP server connects, disconnects, reconnects in a loop during tool execution.

Request IDs for Server-Side Investigation

• Stalled request: x-client-request-id=23b45f49-3036-498c-9238-9136a614ca84
• First successful request (same session): x-client-request-id=91a54f63-06db-40b6-b078-30a779bb082b

Workaround

None reliable. Reducing MAX_THINKING_TOKENS or using a smaller model (Sonnet) may help, but the core issue is the API stream stalling in thinking mode.

What Should Happen?

Expected Behavior

1. If extended thinking exceeds a reasonable timeout with no content blocks started, the client should surface a warning or auto-retry
2. Cancelled/aborted requests should not trigger a "non-streaming fallback" that sends a second full request
3. Thinking tokens consumed during stalled streams should be visible in client-side usage reporting
4. 41 count_tokens calls for a single user action is excessive — these should be batched or debounced

Error Messages/Logs

Steps to Reproduce

Debug Log Evidence

Session 73247f39 (launched with --debug --debug-file)

Timeline:

21:18:07.155  [API REQUEST] /v1/messages x-client-request-id=23b45f49-3036-498c-9238-9136a614ca84
21:18:10.288  "Stream started - received first chunk" (3s TTFB — normal)
              ... 33 seconds, streamMode=thinking, no visible output ...
21:18:46.463  User cancels
21:18:46.465  "Stream completed with message_start but no content blocks completed - triggering non-streaming fallback"
21:18:46.466  "Error streaming, falling back to non-streaming mode: Stream ended without receiving any events"
21:18:46.466  "Error in API request: Request was aborted."

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.91

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_