claude-code - 💡(How to fix) Fix [Bug] `/context` category breakdown shows double-counted tokens in Messages category [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48269Fetched 2026-04-16 07:04:37
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Timeline (top)
labeled ×4commented ×1

Error Message

[{"error":"MaxFileReadTokenExceededError: File content (13310 tokens) exceeds maximum allowed tokens (10000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\n at HY7 (/$bunfs/root/src/entrypoints/cli.js:4535:12021)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-04-15T02:16:56.943Z"}]

Code Example

/context category breakdown doesn't add up — some context appears to be unaccounted for or double-counted.

Setup: fresh session, turn 0. One user turn ("Doing a quick context check"), one assistant response ("Ready. What would you like to work on?"). I ran /context immediately after.

/context displayed:
  System prompt: 6.3k
  System tools:  8.9k
  Custom agents: 1.5k
  Memory files:  2.3k
  Skills:        2.5k
  Messages:     15.7k
  Total:        37.2k

Cross-checked against assistant.message.usage on the preceding API call in the jsonl transcript: input=6, cache_creation=37,172 — matches the displayed 37.2k total exactly.

I reconstructed the actual message array at that point from the transcript (4 SessionStart hook attachments + deferred_tools_delta + mcp_instructions_delta + skill_listing + 1 user turn + 1 assistant turn, materialized per normalizeAttachmentForAPI) and passed it to the Anthropic count_tokens API (free endpoint):
  Real message content: 6,892 tok
  /context Messages:   15,700 tok
  Unexplained gap:      8,808 tok

Skills category (2.5k) is suspiciously close to the count_tokens value for the skill_listing attachment (2,466 tok) — suggesting that content is present in both the Skills and Messages categories.

The 8.8k gap is close in magnitude to:
  - System tools (8.9k), or
  - System prompt (6.3k) + Memory files (2.3k) = 8.6k

Either way, either (a) Messages is much larger than the actual message array warrants and some other category's content is being double-counted inside it, or (b) there's content in the API request the client-side breakdown isn't exposing. In both cases, /context's category breakdown doesn't accurately describe where the tokens are going, which makes it hard to act on when trying to trim context.

---

[{"error":"MaxFileReadTokenExceededError: File content (13310 tokens) exceeds maximum allowed tokens (10000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\n    at HY7 (/$bunfs/root/src/entrypoints/cli.js:4535:12021)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-15T02:16:56.943Z"}]
RAW_BUFFERClick to expand / collapse

Bug Description

/context category breakdown doesn't add up — some context appears to be unaccounted for or double-counted.

Setup: fresh session, turn 0. One user turn ("Doing a quick context check"), one assistant response ("Ready. What would you like to work on?"). I ran /context immediately after.

/context displayed:
  System prompt: 6.3k
  System tools:  8.9k
  Custom agents: 1.5k
  Memory files:  2.3k
  Skills:        2.5k
  Messages:     15.7k
  Total:        37.2k

Cross-checked against assistant.message.usage on the preceding API call in the jsonl transcript: input=6, cache_creation=37,172 — matches the displayed 37.2k total exactly.

I reconstructed the actual message array at that point from the transcript (4 SessionStart hook attachments + deferred_tools_delta + mcp_instructions_delta + skill_listing + 1 user turn + 1 assistant turn, materialized per normalizeAttachmentForAPI) and passed it to the Anthropic count_tokens API (free endpoint):
  Real message content: 6,892 tok
  /context Messages:   15,700 tok
  Unexplained gap:      8,808 tok

Skills category (2.5k) is suspiciously close to the count_tokens value for the skill_listing attachment (2,466 tok) — suggesting that content is present in both the Skills and Messages categories.

The 8.8k gap is close in magnitude to:
  - System tools (8.9k), or
  - System prompt (6.3k) + Memory files (2.3k) = 8.6k

Either way, either (a) Messages is much larger than the actual message array warrants and some other category's content is being double-counted inside it, or (b) there's content in the API request the client-side breakdown isn't exposing. In both cases, /context's category breakdown doesn't accurately describe where the tokens are going, which makes it hard to act on when trying to trim context.

Environment Info

  • Platform: darwin
  • Terminal: WezTerm
  • Version: 2.1.108
  • Feedback ID: bfe27a60-783d-4d96-af67-b283cc285f65

Errors

[{"error":"MaxFileReadTokenExceededError: File content (13310 tokens) exceeds maximum allowed tokens (10000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\n    at HY7 (/$bunfs/root/src/entrypoints/cli.js:4535:12021)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-15T02:16:56.943Z"}]

extent analysis

TL;DR

The /context category breakdown appears to be inaccurate due to potential double-counting of tokens in the Messages category, which may be caused by overlapping content between categories.

Guidance

  • Investigate the Skills category, as its count is suspiciously close to the skill_listing attachment count, suggesting potential overlap.
  • Verify the Messages category count by comparing it to the actual message array reconstructed from the transcript and counted using the Anthropic count_tokens API.
  • Check for any content in the API request that may not be exposed in the client-side breakdown, which could contribute to the discrepancy.
  • Review the error message MaxFileReadTokenExceededError to ensure it's not related to the token counting issue, although it seems unrelated to the /context breakdown.

Example

No code snippet is provided as the issue is more related to data analysis and category breakdown rather than code implementation.

Notes

The issue seems to be related to data analysis and category breakdown, and the provided information suggests a potential overlap between categories. However, without more information about the implementation of the /context command and the token counting mechanism, it's difficult to provide a definitive solution.

Recommendation

Apply workaround: manually verify the token counts for each category and adjust the /context breakdown accordingly, until the root cause of the discrepancy is identified and fixed. This will help to ensure accurate token counting and category breakdown.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] `/context` category breakdown shows double-counted tokens in Messages category [1 comments, 2 participants]