How can you check which LLM an API actually uses?
Compare the endpoint's observed behavior with a supported official reference for the model you intend to use. In ModelVerify, this comparison produces a behavioral verdict with stability and latency context. It provides evidence about a particular run, not an unconditional certificate of model identity.
The response model field, a gateway's advertised name and an answer to ‘what model are you?’ are provider-controlled labels or generated text. A valid OpenAI-compatible response establishes request compatibility; it does not independently authenticate the model behind it.
What is an LLM behavioral fingerprint?
A behavioral fingerprint is a reference pattern of responses collected from an official model endpoint under diagnostic checks. ModelVerify compares the target endpoint's observations with that reference. A useful comparison needs the intended model and reference version to be aligned.
A fingerprint is not a cryptographic signature or a secret phrase that every genuine model must repeat. Gateway transformations, routing, caching, serving settings and model updates can change observed behavior. The public report explains the outcome without publishing protected probes, expected answers or decision thresholds.
Separate the requested model ID from the selected reference
The model ID is the identifier sent to your provider. It may be an alias. The claimed model or selected reference is what you want to compare that endpoint against; choosing it does not prove the provider resolved the alias to that model.
Record the run date, exact requested identifier and selected reference. Confirm key access and the documented API root before starting. If there is no suitable supported reference, leave identity unresolved rather than treating a different version as an exact substitute.
An annotated verification report example
The example below uses the public report's status, model ID, claimed model, verdict, stability and latency fields. All identifiers and values are illustrative. It is not a customer report, a provider assessment or a live verification, and no API request is made by viewing it.
| Report field | Example value | How to read it |
|---|---|---|
| Run status | completed | Completed describes the run lifecycle. It does not mean the model matched. |
| Requested model ID | example-model-alias | The identifier sent to the provider. An alias does not independently identify the backend. |
| Claimed model / selected reference | example-reference-version | The intended comparison target, not a confirmed upstream identity. |
| Verdict | Mismatch | Behavior deviated from the selected reference. Review versions and routing before drawing a conclusion. |
| Success rate | 100% | Observed requests succeeded in this example. Reliability and model identity are separate questions. |
| TTFT (P50) | 450 ms | Median time to first token is performance context, not an identity test. |
| Total latency (P50) | 1800 ms | Median request latency is distinct from the elapsed time of the whole verification run. |
A completed run with successful requests can still report a mismatch. These example values do not define scoring thresholds or demonstrate any provider's behavior.
What should you do with match, mismatch or uncertain?
Match: the observed behavior agrees with the selected reference under the current checks. Combine that evidence with your own workload evaluation; it does not guarantee that every future request uses the same backend.
Mismatch: the observation deviates from the reference. Confirm the requested alias, selected model version and documented routing behavior, then investigate with the provider. A completed mismatch is not the same as an HTTP failure and does not establish fraud.
Uncertain or insufficient baseline: the available evidence does not resolve model identity. Failed or incomplete requests can also prevent a useful conclusion. Where the report warns about connection stability, resolve that issue before interpreting a low match score. A successful connection alone is not an identity match.
Use dated evidence, not a permanent authenticity label
Keep the date and configuration with a result so you can compare like with like after a provider or model changes. Public provider pages aggregate observed samples; sample counts, model identifiers and the latest observation matter alongside the displayed match rate.
Assess identity evidence separately from capability, cost and reliability. A fast response cannot identify a model, a match is not a guarantee of task quality, and one report cannot describe an entire provider. Use representative non-sensitive tasks and respect rate limits when collecting further evidence.