Why Is My LLM Token Count Higher Than My Prompt? We Measured the Hidden Tokens on 25 Models

You send a short prompt, get a one-word answer, and are billed for hundreds of tokens.

To measure this we used a control. We sent the same ten-word prompt, "Reply with only the word OK and nothing else, please.", three times to each of 25 model configurations and recorded the raw usage object every time. Almost every answer was OK. The token counts were nowhere near each other:

• Prompt tokens ranged from 12 to 1,254 for the same ten words.
• Total tokens ranged from 13 to 1,729 for the same two-letter answer.

Three mechanisms account for the gap. Each shows up in a different field, and one of them makes cost dashboards wrong. It made ours wrong until 2026-10-22.

The measurement

Median of three runs per configuration, run 2026-10-19 through our own provider handlers, temperature 0.7, max_tokens 1500 (each field is a median on its own, so columns may not add up exactly).

A dash means the provider's usage object had no such field for this call.

Cause 1: Text you didn't send, counted as input

Symptom: prompt_tokens far above what your own prompt could tokenize to, and roughly the same overhead on every request.

Most configurations counted our ten words as 12–25 tokens. Others reported 42 (DeepSeek), 83 (gpt-oss-120b on Groq), around 100 (Kimi K3) and 1,254 (Grok 4.7).

The cause is text the host or provider adds before your prompt reaches the model, such as a chat template or a system prompt. The usage object does not break it down.

xAI is the clearest case. We covered it in detail in our Grok 4.7 vs 4.5 test. Across four unrelated prompts, Grok 4.7 always reported exactly 748 more prompt tokens than Grok 4.5. On the very first call, 1,152 of Grok 4.7's 1,254 prompt tokens were already reported as cached, which only makes sense if the bulk of them is a prefix shared across requests.

One case we can't explain from the data: Gemini 4 Argon counted 43 prompt tokens for the same text that Gemini 3.8 Flash and 3.6 Flash counted as 12. The API response gives no reason.

The tell: send a trivial prompt and check prompt_tokens. Whatever is left after subtracting your own text is a fixed cost on every call. It matters most for short prompts, such as classifiers and routers.

Cause 2: Reasoning tokens you never see

Symptom: a short visible answer, a large total, and the gap is not in the input.

Reasoning models think before they answer, and you pay for the thinking. Gemini 3.6 Flash produced 1 visible token (OK) and 135 thinking tokens. Grok 4.7's second probe run produced 8 visible tokens and 991 reasoning tokens. We broke down the economics of this in Reasoning Tokens Aren't Free. What is new here is that providers report those tokens in three different ways, and code written for one way miscounts the others.

Inside the completion count, broken out in a sub-field. OpenAI, DeepSeek, Groq, Together and Fireworks. GPT-6 Luna's probe:

"prompt_tokens": 18, "completion_tokens": 15, "total_tokens": 33,
"completion_tokens_details": { "reasoning_tokens": 5 }

The 5 reasoning tokens are part of the 15. prompt + completion = total.

Inside the output count, Anthropic style. Claude Opus 5.5 on our arithmetic task:

"input_tokens": 167, "output_tokens": 305,
"output_tokens_details": { "thinking_tokens": 89 }

Again the thinking is part of the 305. There is no total_tokens field.

Outside the completion count. Google and xAI. Gemini 3.6 Flash, first probe run:

"promptTokenCount": 12, "candidatesTokenCount": 1,
"totalTokenCount": 162, "thoughtsTokenCount": 149

Grok 4.7, first probe run:

"prompt_tokens": 1254, "completion_tokens": 18, "total_tokens": 1601,
"completion_tokens_details": { "reasoning_tokens": 329 }

Here prompt + completion does not equal the total. The reasoning sits on top: 12 + 1 + 149 = 162, and 1,254 + 18 + 329 = 1,601. If your code prices candidatesTokenCount or completion_tokens as the output, you miss every reasoning token on these two providers.

Thinking also varies from call to call. Gemini 4 Argon reported no thoughtsTokenCount on our JSON and arithmetic tasks, but the three-bullet prompt, sent five times, gave 0, 767, 799, 401 and 447 thinking tokens. One test call tells you little about the next.

Cause 3: Cached tokens, counted but discounted

Symptom: a cached_tokens value inside your prompt count.

Cached tokens are included in the prompt count, not added to it: Grok 4.7's 1,152 cached tokens are part of its 1,254. Caching doesn't inflate the count, but it makes the count a poor cost signal, because cached input is usually billed at a lower rate.

Field names from our run files:

• prompt_tokens_details.cached_tokens: OpenAI, xAI, DeepSeek, Together, Fireworks
• prompt_cache_hit_tokens / prompt_cache_miss_tokens: DeepSeek (alongside the above)
• cache_read_input_tokens / cache_creation_input_tokens: Anthropic

In the probe, only xAI reported a nonzero cache hit, on its own prefix.

Where Promptster got this wrong, and what changed

Until 2026-10-22, our provider handlers mapped Gemini's output to candidatesTokenCount and xAI's output to completion_tokens. Both left out the reasoning tokens shown above, so the cost Promptster displayed for Gemini thinking models and Grok was too low.

The fix shipped on 2026-10-22. The Google handler now prices thoughtsTokenCount as output. The xAI handler reads reasoning_tokens and cached_tokens, and Promptster shows the exact bill xAI returns in cost_in_usd_ticks. That bill prices Grok's cached prefix (1,152 tokens on the probe) at a quarter of the input rate, so short Grok prompts cost less than the headline rate suggests. Perplexity was wrong in a way the token counts can't show: its usage.cost.total_cost includes a flat per-request search fee and search-context tokens that prompt_tokens leaves out, and Promptster now displays that figure.

Here is how large the error was, using median costs from our battery:

For every other provider in the table, the old and new figures match, because reasoning is already inside the count we price.

A 30-second diagnostic

The provider-independent way to get billed output is total − prompt. It is correct for all three reporting styles:

const u = r.usage ?? r.usageMetadata;
const prompt = u.prompt_tokens ?? u.input_tokens ?? u.promptTokenCount;
const total  = u.total_tokens ?? u.totalTokenCount
            ?? (u.input_tokens + u.output_tokens);           // Anthropic has no total
const billedOutput = total - prompt;
const cached = u.prompt_tokens_details?.cached_tokens
            ?? u.cache_read_input_tokens ?? 0;

Then run the control: send a ten-word prompt to each model you use. If prompt comes back in the hundreds, that overhead is on every call.

Your token count is the text you sent, plus the text the provider added, plus the thinking it did. It is not a count of your prompt. The same reasoning-model changes that hide tokens can also hide answers: see Why Your LLM Returns an Empty Response.

Try it yourself

• Run the ten-word token probe — then compare the prompt and total tokens each model reports

No account and no API key needed. To run it across several providers at once and see the token breakdown, use Promptster.

Probe run 2026-10-19: one ten-word prompt, three runs per configuration, 25 configurations that returned results, through Promptster's provider handlers (the battery harness calls callProvider() directly). Temperature 0.7 where the model accepts one; OpenAI GPT-5+ and Claude 5+ models drop it. max_tokens 1500, except Groq Qwen 3.8 27B at 900. Cerebras, Mistral and Together's Qwen3-235B returned errors and are excluded. The corrected costs are what Promptster displays since 2026-10-22, repriced from the stored usage objects: hidden reasoning at the output list rate from shared/pricing.ts, cached input at the cached rate, and the provider's own reported cost where xAI and Perplexity return one. Raw usage objects for every call are in content/blog/data/q4-2026-token-overhead/ and content/blog/data/q4-2026-battery/.