Check whether you're getting the real model
Think your relay swapped in a cheaper model, or quietly downgraded the version? Enter the endpoint and a temporary key, and we'll fire a real request on the spot to check the model-name echo, billing metadata, and response structure — the hard-to-fake signals that give away a swap.
Key used once only · never saved · never logged · use a temporary key and delete it afterward
How do we tell what's genuine? See our verification methodology →
How common is this problem
45.83%
of fingerprint tests showed a model identity verification failure
47.21%
highest performance deviation
17
relay services involved
187
academic papers citing it
The figures above are from an independent third-party study, not our own statistics. Source: CISPA Helmholtz Center for Information Security, "Real Money, Fake Models: Deceptive Model Claims in Shadow APIs" (March 2026),arxiv.org/abs/2603.01919. See ourverification methodologyfor details.
Model pass rates (demo data)Sample data · switches automatically once 1,000 real samples are collected
Real samples collected: 0 / 1,000The figures above are demo data shown purely to illustrate what the chart means, and don't reflect real community check results. Once real samples reach 1,000, the chart switches automatically to this site's real statistics.
What this tool checks
Connectivity
Whether the endpoint responds at all, and whether the key has access to that model.
Model name echo
Whether the model field in the response matches what you requested — a mismatched name is the most direct sign of a swap.
Billing metadata
Whether the usage token counts follow the standard format. Missing or malformed usage data is a common tell for a disguised third-party model.
Response structure
Whether the choices/message fields required by the official protocol are all present.
Model self-reported identity
We ask the model to state who it is — requesting Claude but getting a self-reported GPT, Qwen, etc. is direct evidence of a swap.
Precise calculation (dynamic)
A random arithmetic problem with a single verifiable answer, generated fresh each time. A weaker substitute model is more likely to get it wrong.
Context integrity
We plant a random verification code at the start of a long prompt and ask for it back at the end — failing to recall it suggests the context may have been silently truncated.
Token-count sanity
Compares the actual input length against the reported prompt_tokens — a large mismatch can indicate irregular billing.
Knowledge cutoff self-report
We ask the model for its own training data cutoff. Requesting the latest version but getting a much older cutoff can mean it's been swapped for an older model.
Instruction-following precision
A strictly formatted instruction — whether the model follows it exactly is an objective signal of capability.
Cache-hit behavior
We send the same request twice and check for a cache hit. A cache hit is usually a good sign (genuine pass-through); no cache doesn't necessarily mean a problem.
These checks catch obvious impersonation, but they can't catch subtler issues like "intermittent swapping" (switching backends only during peak hours) or a model's capability quietly degrading over time. For a more complete picture, pair this with ourmanual verification checklist.
Frequently asked questions
Is my API key safe?
Your key is used only for this one verification request — it's never written to a log or a database, and is discarded the moment the request completes. Even so, we still recommend creating a temporary key just for this test and deleting it from your relay's dashboard afterward — that's the safest approach.
How much of my quota will this use up?
A full check sends 5 requests (identity, arithmetic, two context-integrity probes, and format compliance), each capped at 32 output tokens. The context-integrity probe sends roughly two thousand words of filler text to test for truncation, so its input token count is a bit higher. At Claude Opus pricing, a full check costs a few cents at most — safe to run freely.
Does a "suspect" result mean the relay is faking things?
Not necessarily. A single check carries noise — network jitter or a temporary hiccup at the relay can cause one metric to come back off. "Suspect" just means one indicator looked off on this particular call; run it again at a different time and look at the trend before drawing a conclusion.
It says "no issues found," but the model still feels weaker to me — why?
Of the 11 checks we run, precise-calculation and instruction-following are the two that partly reflect model capability, but even they can't catch "intermittent swapping" (switching backends only during peak hours). If that's what you're noticing, try running the check again at different times of day, and pair it with the fixed-prompt comparison method from our manual verification checklist.