How the check works. One fixed prompt, every model, every day. What it shows, and what it cannot.

What is sent

Once a UTC day, every model UplinkSwitch sells gets the same test prompt on every route that serves it, asking for a one-word answer. The request is built by the same code that builds a customer request for that route, so it reaches the model the way your requests do.

The prompt mixes plain English, Greek, Japanese, accented Latin, a line of code and some numbers, so that different tokenizers split it differently. It never changes: every count on record was measured against the same bytes. The exact text is public in the canary field of GET https://api.uplinkswitch.com/v1/proof.

Why a token count is a fingerprint

Every response reports how many input tokens the request used. That number is set by the model developer's tokenizer and chat template, not by the host. The same model, given the same prompt, reports the same count every day.

A different model usually has a different tokenizer, so its count for the same prompt is different. A host that quietly adds its own instructions to every request also changes the count, by the size of what it added. Either way, the number moves.

Each route is compared with its own history, day by day, and the model's result follows the route whose count has held the longest. The check watches for change over time, which is what a swap looks like. Routes that add a fixed prompt of their own carry a steady extra count; those tokens are paid for by UplinkSwitch, not by you, and the router sends small requests to cleaner routes first.

Some readings say nothing about the model, so they are left out: a count smaller than any tokenizer gives the prompt (a host that miscounted), and, on a route that has reported the model's own count, a larger one carrying the host's added instructions. A route that starts or stops serving the model is not a change, and neither is a count that returns to one the model already gave.

What each result means

Same fingerprint since <date>: The model’s steadiest route has reported the same input token count for the test prompt on each day back to that date.
Fingerprint changed <date>: Within the past seven days the model’s count moved to a value it had not given before, on its steadiest route. A swapped model would show up this way. It is a reason to look, not a finding that the model was swapped.
No answer at the last check: No route answered the test prompt with a usable token count at the latest run.
Not checked yet: The model has no check in the 45 days of history kept.

What it cannot detect

A smaller or older model from the same family that shares the tokenizer. Its count for the prompt can be identical.
The same weights served at lower precision (quantized). The tokenizer, and so the count, does not change.
A change between two daily runs that is reversed before the next one.
A change on one route while another route keeps the model's count. The result follows the steadiest route; the other routes are watched by our team.
Answer quality. The check asks for one word and judges only the count, not what the model says.

So a steady fingerprint is evidence, not proof. It rules out the common swap, a different model family behind the same name, and it makes any change visible with a date.

Check it yourself

Send the canary text from /v1/proof to a model through UplinkSwitch and through the developer's own API, and compare usage input tokens. A few tokens apart is the chat template. Hundreds more means instructions you did not send. What we found when we ran this across hosts.

The verdicts are public JSON at https://api.uplinkswitch.com/v1/proof: no key, readable from any origin, cached for five minutes. Hosts are not named; the check runs on all of them, and each model gets one result.

Every request you make also has a signed receipt with the model, tokens and charge.

Who runs the check and the service: about UplinkSwitch.