What can and cannot identify a GPT API?
Start with the claim you want to evaluate: which model and version does the provider say it serves? An OpenAI-compatible response format shows protocol behavior. The model field is a label supplied by the service, and self-identification is generated text. Neither independently proves which model processed a request.
Low prices, slow responses or an unexpected answer may motivate an investigation, but they do not establish model substitution. Network distance, load, sampling settings and serving configuration can all affect what you observe.
Step 1: exclude connection and reference mistakes
Confirm the API base, exact model identifier, key access and request protocol against the provider's documentation. Check whether the model is an alias and whether the provider documents a version or routing policy.
If a request returns an HTTP error or a verification run fails at the handshake, model behavior has not been evaluated. Resolve the request failure first. Also verify that the official reference you selected matches the model you intended to investigate.
Step 2: compare behavior with a supported reference
A behavioral verification tool compares endpoint responses with an official reference fingerprint. In ModelVerify, use the supported reference list in the form and review the resulting report. Requests use your API key and may incur charges from your provider.
A match is evidence of consistency under the current checks. A mismatch is evidence of deviation that needs investigation. Neither is cryptographic proof of the backend's identity, and a single mismatch is not proof of fraud.
Step 3: investigate a mismatch without overclaiming
Keep a record you can compare or share safely with the provider. Useful details describe the request and observation without exposing credentials or protected verification assets.
- Record the date, advertised model and exact requested model ID.
- Record the chosen official reference and relevant non-secret settings.
- Distinguish a completed mismatch from a failed or incomplete run.
- Check documented version, caching and routing behavior with the provider.
- Compare your own representative tasks under consistent settings; gather observations over time while respecting rate limits.
Step 4: make a provider decision from several signals
Assess identity evidence alongside workload quality, operational reliability, access terms and cost. A provider can perform poorly for your application even when a behavioral check matches; conversely, one mismatch can have an explanation that does not involve deliberate misrepresentation.
If you discuss a result publicly, state what was observed, the date and the limitations. Avoid turning an uncertain technical observation into an allegation. The practical goal is to choose an API that meets your requirements with evidence you can explain.