Daily canary test finds some LLM API routes adding thousands of hidden input tokens

A 90-token canary across 107 routes

UplinkSwitch, a service that lists and routes requests to LLM APIs, sends one fixed prompt of roughly 90 tokens to every route of every model in its catalog each day, then records the usage.prompt_tokens figure each route returns. According to the company's post on dev.to, a clean route reports between 76 and 127 input tokens for that prompt, covering the message itself plus chat-template overhead. A route that answers with hundreds or thousands is counting text the caller never sent.

On 12 October 2026 the check covered 107 routes across four unnamed hosts, and at least 30 of them reported more than 200 input tokens. The spread was wide. On the largest host, 17 of 66 routes exceeded the threshold, with GPT routes reporting about 4,469, Gemini routes 352, and one Gemini route 2,213. On a second host, 11 of 32 routes were over, including GPT routes between 4,280 and 4,469, Claude routes at 380 and 540, a Grok route at 289, and a Grok 4.7 route at 1,325. Two GLM routes on that host, which the post says serve third-party modified builds rather than the developer's own weights, each reported 14,111 input tokens, the highest count in the sample. An eight-route host had one GPT route at 8,938, and a single-route host reported 1,171.

UplinkSwitch notes that the same models reached through other routes report around 89 tokens, and that the GPT counts cluster near 4,469 on two separate hosts.

A prefix you pay for

The simplest explanation, the post argues, is that the host prepends its own system prompt to every request before it reaches the model. The model's tokenizer then counts that text, and on a per-token API the customer pays for it on every call. The arithmetic is stark: a 4,400-token prefix attached to a 300-token request makes up 93 percent of the input bill, and for shorter requests the added text dwarfs the actual payload.

Such a practice would change model behaviour, not just billing. A caller's system prompt would no longer be the first thing in the context window, and the instructions ahead of it would belong to someone else.

The post is deliberately cautious: no host is named, the author frames the findings as something other than an accusation, and other causes for an inflated count are possible. The central claim is that the effect is measurable and that measuring it costs almost nothing.

How to test your own provider

The suggested procedure needs one request. Send a minimal prompt with max_tokens set to 1 and read usage.prompt_tokens from the response. A handful of tokens is the prompt plus the chat template; hundreds or thousands indicates the host added something. Running the same call against a first-party endpoint for the same model gives a baseline. Repeating the check daily and keeping the numbers reveals when a route changes.

UplinkSwitch says it has also adjusted its own service in response: customers are billed no more input tokens than their request could hold regardless of what a route reports, the daily verdicts are published through a public proof endpoint, and requests smaller than a route's own prompt are now sent to a cleaner route first.

Limits of the measurement

The post lists its own caveats. A count is only what the route chooses to report, so a clean count does not prove the route runs the model it names; a smaller model from the same family, or quantized weights, would not show up this way. One sample per route per day also misses anything that changes between samples. The author concludes that the results amount to evidence rather than proof.

It is also worth noting that the publisher both runs the measurement and operates the routing service that mitigates the problem, so the numbers come from an interested party. The method, however, is simple enough for anyone to reproduce independently.

Why it matters

Per-token pricing only means what the token counts mean. If a route can quietly attach thousands of tokens of its own text, headline rates become almost meaningless: a cheap per-token price on a route that bills 4,500 input tokens for a 90-token prompt can cost far more than a dearer route that counts honestly. Hidden prefixes also consume context window space and displace a developer's carefully ordered instructions, which can shift model output in ways that are hard to debug. The broader takeaway is that token accounting is auditable with a single request, and developers using budget or third-party API hosts should make that check routine.