[BUG]

Resolved 💬 2 comments Opened Jun 26, 2026 by lmaoha Closed Jun 30, 2026

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?

Claude Desktop fires a burst of 20–30 concurrent max_tokens: 1 token-counting probe requests to /v1/chat/completions on several routine user actions, even when the underlying prompt fragments (system instructions, skill descriptions, tool definitions) have not changed since the last run.

Each probe carries one prompt fragment — a single skill description, one system-prompt section, or the full tool-definitions JSON — so per-component token usage can be accounted for. The probes are dispatched in parallel within roughly one second.

Triggers I've reproduced:

  1. Starting a new conversation
  2. Closing and reopening the app
  3. Opening the "context window" panel — this one also includes the full current conversation history (largest input I observed was ~13k tokens)
  4. Switching the model

The fragments being probed are overwhelmingly static across sessions and across app restarts, but there appears to be no caching: every trigger re-issues the entire probe set.

(Observed via a local HTTP proxy logging the outbound traffic from the app. Same probe pattern is visible whether the underlying provider is Anthropic's API or a compatible third-party endpoint.)

What Should Happen?

Token counts for static prompt fragments should be cached locally, keyed by a hash of the fragment content, and skipped when unchanged. Specifically:

  1. In-memory cache within a session so repeatedly opening the context-window panel doesn't re-probe.
  2. Persistent cache across app restarts so a fresh launch doesn't re-count every skill description and tool schema from scratch.
  3. Batch unavoidable recomputes into a single request rather than 20–30 concurrent ones.
  4. Lazy compute for the context-window panel — only recount fragments the panel actually needs to display, on demand, instead of refreshing the entire breakdown on every open.

Net effect for the user: faster startup, no stutter when toggling the context panel, and substantially less traffic.

Error Messages/Logs

# Representative request body (one of ~25 dispatched in parallel on "new conversation"):
POST /v1/chat/completions
{
  "max_tokens": 1,
  "messages": [{"role": "user", "content": "<one skill description, ~250 bytes>"}],
  "model": "<model>"
}

# Largest probe observed (on "open context window" panel):
POST /v1/chat/completions
{
  "max_tokens": 1,
  "messages": [{"role": "user", "content": "count"}],
  "tools": [ ... full tool-definitions JSON, ~50 KB ... ]
}
# Response: input_tokens ≈ 12822 — i.e. the entire current conversation re-sent
# only to read back input_tokens from the usage field.

# Burst pattern (timestamps trimmed):
[17:20:24]  20+ POST /v1/chat/completions  max_tokens=1  (within ~1s)
[17:20:26]  all responses 200, ~500–600 bytes each
[17:20:27]  local connection pool saturated:
            "max idle per host for opencode-style endpoint, dropping connection"

Steps to Reproduce

  1. Configure the app to route API traffic through a local logging proxy (or use any tool that captures outbound HTTPS request bodies).
  2. Launch the app and start a new conversation. Observe ~20–30 concurrent POSTs to /v1/chat/completions with max_tokens: 1, each carrying one prompt fragment.
  3. Close and relaunch the app. The same burst recurs — no evidence the prior counts were cached.
  4. Open a conversation, then click the "context window" panel. Another burst fires, this time additionally including the full conversation history.
  5. Switch the active model from the model picker. Another burst fires.

Each step independently triggers a fresh round of probes even though the underlying skill descriptions, system instructions, and tool definitions have not changed.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.15962.0 (039543) 2026-06-25T01:24:19.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Note on repo scope: I observed this in Claude Desktop, which doesn't have a public issue tracker. Filing here because the probe-dispatch logic — enumerating skills, system-prompt sections, and tool definitions into individual max_tokens: 1 calls — appears to be shared client code, so a fix here likely benefits both products. If this is out of scope for claude-code specifically, please let me know where to refile.

User impact (in order of severity):

  • Visible startup latency waiting on dozens of round-trips
  • Noticeable stutter every time the context-window panel is opened
  • Users routing traffic through gateways/proxies see request counts multiplied — max_tokens: 1 is essentially free on Anthropic's first-party API but is not necessarily free on every compatible backend, particularly reasoning models that complete their thinking block before honoring the output cap.

The fix that would help most is the persistent cache (item 2 under "What Should Happen") — that alone would eliminate the launch-time burst, which is the most frequent trigger.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗