claude code 桌面版 疯狂请求token 为 1 的问题。

github.com/anthropics/claude-code[Bug] Anthropic API token counting performance degrades linearly with conversation size

已打开 07:10AM - 03 Dec 25 UTC

已关闭 10:20AM - 03 Feb 26 UTC

mgajda

bug

has repro

platform:linux

area:api

perf:memory

• *Bug Description**

Progressive performance degradation - API token counting sc…ales poorly with conversation size

What's Wrong? Token counting API (/v1/messages/count_tokens) performance degrades dramatically as conversation grows, causing 14.7x slowdown (103ms → 1514ms) over a single session with 73 messages.

Root Cause: • Full conversation history sent with each count_tokens request • Server-side processing time scales linearly (or worse) with message count • No caching or incremental token counting

Evidence: Request# | Server Time | Total Time | Message Count (est) • --------|-------------|------------|-------------------- 5 | 103ms | 260ms | ~10 messages 8 | 566ms | 773ms | ~40 messages 11 | 1391ms | 1622ms | ~70 messages 12 | 1514ms | 1711ms | ~73 messages

Degradation: 14.7x slower server processing

Proposed Solutions: 1. Cache token counts - Only recount new messages since last check 2. Client-side estimation - Use approximate tokenization for UI display 3. Incremental counting - Send only new messages + delta 4. Throttle count_tokens calls - Reduce frequency of token checking

Impact: • Severity: HIGH • Users experience cumulative slowdown in long sessions • 2-second delays make tool feel unresponsive • No workaround except restarting session

• *Environment Info** • Platform: linux • Terminal: gnome-terminal • Version: 2.0.50 • Feedback ID: abdf92bf-68a2-4333-9844-a335d5bf8916

Log Excerpts

Request #5 (early, fast): [log_*, request-id: "req_011CVeKQ5QhucXs6noZ63Zqg"] postapi.anthropic.com/v1/messages/count_tokens succeeded with status 200 in 260ms x-envoy-upstream-service-time: 103ms

Request #11 (later, slow): [log_*, request-id: "req_011CVeKQCgaTLVSRmQgq8D6R"] postapi.anthropic.com/v1/messages/count_tokens succeeded with status 200 in 1622ms x-envoy-upstream-service-time: 1391ms

Request #12 (latest, slowest): [log_a98904, request-id: "req_011CVeKQCnDmjUrUUohkEKgm"] postapi.anthropic.com/v1/messages/count_tokens succeeded with status 200 in 1711ms x-envoy-upstream-service-time: 1514ms

Analysis

The x-envoy-upstream-service-time header shows server-side processing time. This eliminates network latency and client processing as factors.

The degradation is clearly server-side, and correlates with conversation size growth.

Possible fix

since conversation is progressing incrementally, token counting should also take an identifier of previous request and continue from there.

github.com/anthropics/claude-code[BUG] 2.1.111 introduced ~14% context window bloat at session startup (8% → 22%)

已打开 11:19PM - 16 Apr 26 UTC

已关闭 01:42AM - 22 Apr 26 UTC

paulalbert1

bug

has repro

platform:macos

area:core

regression

Preflight Checklist

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

What's Wrong?

Environment

• Claude Code 2.1.112 (also 2.1.111) • Opus 4.6, macOS Darwin 25.3.0 • 200K context window

Summary

Session startup context usage jumped from ~8% to ~22% with no changes to my project, CLAUDE.md files, MCP servers, or plugins. After extensive investigation, the change correlates exactly with the auto-update from 2.1.110 → 2.1.111 on Apr 16 2026.

Evidence

Binary sizes in ~/.local/share/claude/versions/:

• 202,932,416 2.1.110 (Apr 15 — 8% startup) • 203,956,832 2.1.111 (Apr 16 13:35 — 22% startup) • 203,956,832 2.1.112 (Apr 16 15:59 — 22% startup) • 14MB increase between .110 and .111. Timing matches exactly. Nothing else changed in the environment.

Impact

• Startup context floor went from ~16K to ~45K tokens (estimated) • Effective context burn rate ~5x higher during working sessions • All available mitigation (pruning agents, skills, plugins, MCP servers) produced negligible improvement — confirming the bloat is inside Claude Code itself, not user configuration

What Should Happen?

• Identify and revert whatever was added to the system prompt / tool schemas in 2.1.111 that caused this, or provide a config flag to opt out of the expanded content. • Add a /context command showing a per-component breakdown of startup token usage (system prompt, tool schemas, MCP servers, CLAUDE.md, skills list, memory). Without this, users are forced to do blind archaeology when startup bloat occurs. This is the 6th time I've investigated this class of issue; a breakdown command would have resolved it in 60 seconds.

Error Messages/Logs

None

Steps to Reproduce

Pin to 2.1.110: ln -sfn ~/.local/share/claude/versions/2.1.110 ~/.local/bin/claude Start session, run trivial prompt, note context % Update to 2.1.112, repeat

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.112

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

cdn3.ldstatic.com/original/4X/1/7/8/178b1ab0507c6edaea4214e38d1f4171cf1d26ae.png

真就离谱居然不去改。