Soonet 5 and others misattributes account-level <total_tokens> reminder as conversation-scoped usage — no scope/reset signal provided

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

I asked Claude to complete a multi-step exploratory task involving several tool calls, and at the end to report — with strict honesty about what was actually observed versus estimated — how many tokens the task had used.

What Claude Actually Did

Claude read two separate values of the <total_tokens>N tokens left</total_tokens> reminder from its context (15,000,000, then 14,716,566), computed the difference (283,434), and reported this confidently as "tokens consumed by this session" — with no hedge about what the underlying value actually represents. When directly challenged to justify the number, it re-observed the tag and found it had returned to exactly 15,000,000 rather than continuing to decrease — i.e., not a monotonic per-conversation counter — but still had no way to determine the value's actual scope, since nothing in its context states what the tag measures, who it's meant for, or when/why it resets.

Expected Behavior

Claude should not have presented an unverified interpretation ("tokens consumed by this session") as a confident, precisely-formatted fact. Given that nothing in the visible context specifies the tag's scope (conversation vs. account-level) or reset conditions, the correct response would have been to report the raw observed values and flag that their meaning/scope could not be determined from available context — rather than silently assuming "difference between two readings = this session's usage."

Files Affected

None — this occurred entirely in Claude's self-reported reasoning/response text, no file operations involved.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Start a session that involves several tool calls (enough to trigger multiple total_tokens reminder injections).
2. Ask Claude to report, based only on what it can actually observe in its context, how many tokens the task consumed.
3. If the <total_tokens> reminder is visible, Claude is likely to compute a delta between two readings and present it as this-session/this-task consumption, without flagging that the value is account-level (per anthropics/claude-code#90018) and not scoped to the conversation.

Claude Model

Sonnet

Relevant Conversation

In its first, unprompted report, the model stated the figure directly and without any hedge — roughly: "Based on the token budget shown in a system reminder, which went from 15,000,000 to 14,716,566, this session consumed approximately 283,434 tokens." No scope caveat, no uncertainty, presented as a settled fact.

The more careful, correctly-hedged breakdown below was only produced after I directly challenged the model and asked it to justify/verify where that number came from:

Model's self-reported token breakdown (verbatim, translated):

However, one real number was available at the runtime/session level (not from any project-specific tool): this session's system-reminders show the remaining token budget went from 15,000,000 at the start to 14,716,566 at the most recent point — meaning approximately 283,434 tokens were genuinely consumed over the course of this session. This number is real, but it covers the entire session (input + output text + all tool content combined) — not just the portion related to my task, and not just "this final answer" (since writing this answer itself still consumes tokens not yet reflected in that figure).

A second number is calculable: by summing the contextTokensApprox field across all 11 calls I made to a custom project-specific MCP tool during this session (7012 + 8952 + 3836 + 7270 + 6374 + 23566 + 16922 + 15784 + 4318 + 3723 + 4427), the total comes to approximately 102,184 tokens. This figure covers only the "tool/context tokens" — i.e., the size of the context packets that one specific tool produced — not my own text input/output, and not the (much smaller) output of the other tools I called during the session. Since the individual components of this sum are themselves labeled "Approx," this calculation is ultimately built on approximate data too, not something exact.

A third number is a pure estimate: for "how many output tokens this final answer itself contains," no real or calculable figure was available (since the answer hadn't been written yet). As a rough estimate, assuming the answer's length (~1,500–2,500 words in the response language) and an approximate word-to-token ratio for that language in common tokenizers, the output could be estimated at roughly 3,000–6,000 tokens. Assumptions: (a) the word-to-token conversion rate is an estimate, and I did not have access to the model's exact tokenizer; (b) the final text length wasn't precisely known in advance.

Final categorization: 283,434 = whole-session total (real); 102,184 = a subset of tool/context tokens attributable to one specific tool only (calculated from approximate inputs); 3,000–6,000 = an estimate of this specific answer's output tokens. None of these should be treated as "the exact number of tokens used to produce this specific response," because no tool provided such a figure.


The gap between these two responses is the core issue being reported: unprompted, the model treats an unverified interpretation of a runtime value as settled fact; only under direct challenge does it correctly separate observation from calculation from estimation.

Impact

Low - Minor inconvenience

Claude Code Version

Claude 2.7032.0 (6c468a) 2026-09-22T05:53:19.000Z

Platform

Anthropic API

Additional Context

Related: anthropics/claude-code#90018 (documents the totalTokensReminder mechanism — account-level remaining budget, recomputed after each tool result) and anthropics/claude-code#75203 (feature request to expose this to Dispatch/Cowork sessions). This report is about a downstream consequence: once the value is visible to the model, nothing tells it what scope/audience the value is meant for, so it fills that gap with an unsupported but confidently-stated interpretation.