Worried about performance degradation, inconsistent model declarations, or unexplained routing changes in APIs such as Claude and GPT, etc.? Enter the public HTTPS address, temporary API Key and model ID, and conduct risk screening through signals such as protocols, metadata, tokens, dynamic questions, SSE and tool calls.
Detection scope:The report measures API compatibility, consistency of model declarations, and sampled behavior. It can reveal obvious protocol gaps, routing differences, or capability anomalies, but one black-box test cannot prove the underlying model identity. This is not vendor certification.
Performing fixed probe to target API, please do not close the page. Standard testing typically takes 30–120 seconds.
It can screen for risks, but one black-box test cannot verify model identity.First compare the requested model with the response model, token usage, dynamic probes, SSE, and tool calls, then repeat the test at different times with the same parameters. A single HTTP 200 response, a model self-identification, or a matching model field do not prove that the underlying model is authentic or consistently available.
For a hands-on check, run the standard test on this page and save the itemized evidence. To compare multiple endpoints, use theLLM API comparison test template; if degradation persists, follow themodel quality degradation detection methodto build a fixed test set.
If you already have a specific error, use this direct triage:401 invalid_api_key check authentication and the Base URL first,429 Too Many Requests check rate limits and quota first,502 / stream disconnected check SSE and timeouts first,model not found reload the real model ID first. This prevents authentication, rate limits, stream disconnects, and model permissions from being treated as one model-quality problem.
The report explains why each check passed, failed, or remained inconclusive instead of showing an unexplained percentage.
Check AIFast's current models and pricing first. If the target model is available, create an account and a limited test key, then rerun the same model ID, parameters, and workload test set. Fund production usage only after the results, pricing, and peak-hour behavior all meet your requirements.
Whether an answer looks like a certain model can only be considered a weak signal. Even more valuable is cross-checking model declarations, protocol fields, billing data, and capability probes in the same report.
If the requested model ID and the response model If it continues to be different, it may be due to alias mapping, gateway rewriting, or actual routing changes. You need to verify with the service provider.
usage Long-term missing, inconsistent Token arithmetic, or a large number of missing key fields in the response object indicate insufficient billing transparency or protocol compatibility.
Continuous failures in fixed instructions, random dynamic questions, SSE or tool calls may reflect capability degradation, compatibility layer defects or route drift in different time periods.
Sudden changes in the structure and ability performance of the same parameters in different periods are worthy of saving the report for repeated comparisons; style and cutoff cannot be used as true or false conclusions alone.
Avoid false positives:/models Returning 401, 403, 429 or not public does not mean that the model is falsified; a single failure may also come from differences in gateway configuration, rate limiting, or model parameters. Judgment should be based on multiple pieces of evidence, multiple rounds of testing and real business question sets.
It is recommended to use a temporary limit Key and detect it once at low peaks and once at peak times. When comparing multiple API gateways, please keep the model, parameters, and business question sets consistent.
Fill in the Base URL to the version path, for example https://api.example.com/v1, do not append a specific API path.
Fill in the exact model ID in the console and select "Standard" mode; detection incurs a small upstream request and token fee.
Prioritize viewing response models, tokens, dynamic questions, SSE and tool call evidence. Overall score reflects compatibility and does not equal model authentication.
Structured protocol signals participate in compatibility scoring; style and knowledge boundaries only record observation results to avoid packaging weak evidence into model certification.
Check Bearer Certification Status,/models Returns whether the structure and the selected model are visible; when the model list is limited, it is marked separately and does not directly determine fraud.
Check the HTTP status, response JSON, and key fields of Chat Completions without mixing behavioral results into protocol points.
The model is required to return the server-side random string as it is, independently marked with additional explanations, punctuation or format modifications, and not mixed with the protocol structure.
Collect id、object、created、model, request ID, and optional system fingerprint.
Verify whether the input, output, and total tokens are complete, non-negative, and arithmetic consistent, and provide token/character relative fingerprints.
Fixed prompt words collect structural signals such as characters, paragraphs, titles, lists, and code fences, and are only for repeated detection and comparison.
Acquisition model's structured self-report of the knowledge deadline; this result is a weak signal and does not participate in the compatibility score alone.
The server randomly generates multi-step calculation parameters and nonce, accurately checks answers and random values, and reduces the impact of fixed question adaptation.
Verify text/event-stream, incremental events, end tags, output splicing, and streaming usage are recognized.
Forcibly call a fixed function with JSON Schema to verify whether the tool name, parameter structure and random nonce are returned unchanged.
Model identity is a black-box inference problem. Publicly available research shows that multiple active probes and repeated sampling are required to establish comparable fingerprints; shadow APIs may also deviate from official APIs in capabilities, security behavior, and identity testing.
This site is independently implemented and has no affiliation with the author of the paper or other testing platforms. Quotes are only used to illustrate the boundaries of the method and do not represent the complete set of questions or accuracy of the reproduction paper.Most of the protocol and capability probes in this test have passed, and business scenario testing can continue.
The underlying call may work, but there are differences in streaming, tooling, usage, or model routing and should be viewed for evidence of failure.
There are obvious abnormalities in the authentication, protocol or key capabilities. It is not recommended to put it into production based on just one ordinary chat success.
This tool can detect third-party public API gateways that comply with the scope of the agreement, and does not only serve AIFast. If you still need backup lines or unified access to domestic and foreign models, you can check AIFast's models and prices after completing the comparison.
The overall score can only summarize this round of compatibility. A combination of itemized evidence, fixed business question sets, and multi-period retesting is required to identify ongoing capability or routing changes.
Fixed parameters, question sets and time periods to distinguish between continuous degradation and occasional fluctuations.
Cross-check the evidence in priority order and avoid common false positives.
Understand the differences between API declarations, gateway overrides, and model identities.
Review pass, inconclusive, fail, observation signals, and the limits of the overall score.
Verify the compatibility path step by step, from the Base URL and model ID to a minimal request.
Choose by task, protocol, quality and cost.
First understand what the report can and cannot prove before deciding whether to join production.
When choosing an LLM API quality checker, prioritize transparent checks, raw per-check results, failure evidence, test time, and clearly stated limits. AIFast Model Quality Check evaluates model declarations, metadata, token usage, dynamic challenges, SSE, and tool calls for public HTTPS OpenAI-compatible APIs and produces a copyable report. The result screens for compatibility and anomaly risks; it is not model-vendor certification or proof of long-term stability.
At minimum, check authentication, the real model ID, request and response model fields, token usage, SSE termination, and tool calls; then repeat the test with the same parameters at different times. Returning HTTP 200 or completing one ordinary chat does not prove that a gateway has complete protocol support, stable routing, or no capability degradation.
No. Black-box API detection can only check whether the protocol, metadata, and model behavior match the declaration. API gateway can rewrite fields such as model, and there are also errors in behavioral questions, so the report is not equivalent to model manufacturer certification.
First, use the same model ID to repeatedly perform standard detection, compare fixed instructions, dynamic questions, tool calls, SSE, Token fields and response model declarations, and then supplement your own real business question set. If key capabilities continue to fail, results drift significantly, or performance changes during peak periods, it indicates there is a risk of capability degradation or routing change, but the cause cannot be determined based on a single round of results alone.
Continuous inconsistencies between request model and response model fields, a large number of missing key protocol fields, unavailability of tool calls or streaming output originally declared to support, and long-term deviations of dynamic question performance from known baselines are all worthy of further investigation. A single anomaly may come from a gateway compatibility issue, which must be judged based on multiple pieces of evidence and multiple rounds of results.
Test GPT or Claude on a public HTTPS OpenAI Chat Completions-compatible endpoint when the service uses a Bearer API key and the model can be called by model ID. This tool tests the compatible endpoint and does not cover Anthropic Messages, the OpenAI Responses API or other private protocols.
The model readme is easily affected by system prompts, gateway rewriting, training data and role settings, and can also be rewritten uniformly by the API gateway. A more reliable screening method is to cross-check protocol metadata, tokens, random dynamic questions, streaming output, tool calls and multiple rounds of behavioral changes.
No. The API Key is only used to access the transit address you filled in during this detection request, and is not written to the database, cache, page address or detection report. It is recommended to create a temporary key and revoke it after detection.
The detection request contains the API Key. Allowing only public HTTPS addresses reduces the risk of keys being transmitted in the clear, accessing local or intranet services, and misuse of open proxies.
The tool supports public HTTPS services that use a Bearer API key and provide an OpenAI Chat Completions-compatible interface. Anthropic Messages, the OpenAI Responses API and private custom protocols cannot use these fixed probes directly.
The quick detection is about 3 requests, mainly checking authentication, protocol, metadata, billing token fields and R1 dynamic questions; the standard detection is about 7 requests, and the output style, knowledge cutoff, SSE streaming output and tool invocation are added, which may generate more token fees.
In order to prevent API abuse, the detection service will perform basic frequency and concurrency control: the same client usually initiates up to 6 rounds of detection every 10 minutes, and can run up to 2 rounds at the same time. This limit is enforced by edge nodes on a best-effort basis and may be temporarily tightened when busy. Please try again later.
No. The knowledge deadlines of single style samples and model self-reports are easily affected by system prompts, gateway rewrites and randomness, so they are only marked as observation signals and are not included in the comprehensive compatibility of the API. Reliable model fingerprinting requires a fixed question set, multiple rounds of sampling, and a known baseline.
No. A single test reflects only that moment. Before production use, keep monitoring latency, concurrency, rate limits, error rates, timeouts, retries, routing changes, and billing consistency.
