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.
Response fields counted toward this score:id、object、created、model、choices[0].index、choices[0].message.role、choices[0].finish_reason; it also compares whether the requested and returned model names match. Request ID and system_fingerprint are for troubleshooting only and are not scored. Any of these fields can be rewritten by a gateway, and none alone proves the underlying model identity.
Check that input, output, and total token counts are complete, non-negative, and arithmetically consistent. Record this request's token-to-prompt-character ratio; it is affected by input text and is not used to identify a model.
A fixed prompt records this output's structure, including characters, paragraphs, headings, lists, and code fences. The tool does not automatically compare it with historical samples or a trusted baseline.
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. In addition to protocol and capability probes, recent public research explores "single-token output-distribution fingerprints": repeatedly sampling short answers in multiple languages and comparing their distribution with a trusted endpoint. This method needs enough samples and matched prompts, language, and sampling conditions. The online checker does not implement distribution sampling or reference-fingerprint comparisons, so its reports must not be read as this kind of identity verification.
A separate holdout study of token-count sequencesThe study prespecified tests for 24 endpoint pairs; only 6 of 12 holdout pairs met the validity criteria. It examines usage sequences across controlled texts, not this checker’s single-request token-to-prompt-character ratio. The sample and eligible cases are limited and do not support using the ratio to identify a model family.
GitHub project lm-detector's October 18, 2026 updateadds a shape screen before closed-set ranking and withholds ranking and confidence for anomalous samples. The project requires three answers with at least 80 valid integers each; thresholds are calibrated against its own reference bank and cannot be applied directly to other datasets. AIFast Link does not integrate this method or its reference data.
Regardless of method, a single black-box result is not model-vendor certification. Gateways may rewrite response fields, and system prompts, quantization, routing, or provider updates can change behavior. Retest anomalies and check the provider's documentation.
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 checks third-party public gateways within its supported protocol scope, as well as AIFast. If you need a backup route or GPT, Claude and Gemini access, compare your results before reviewing AIFast models and prices.
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 the tests performed, itemized results, failure evidence, test time, and clearly stated limits. AIFast Link checks public HTTPS OpenAI-compatible APIs for model declarations, visible response fields, token usage, dynamic challenges, SSE, and tool calls, and generates a shareable report. Results screen for compatibility and anomaly risks; they are not vendor certification or proof of long-term reliability.
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.
GPT, Claude, or Gemini can be checked when exposed through a public HTTPS OpenAI Chat Completions-compatible endpoint using a Bearer API key and callable model ID. A model brand does not imply protocol coverage; this tool does not test Anthropic Messages, Gemini generateContent, 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.
Single-token fingerprinting builds behavioral distributions from repeated short answers and compares them with a trusted reference endpoint; it requires matched prompts, language, and sampling conditions. A separate holdout study examined token-count sequences across controlled texts, but only 6 of 12 holdout pairs met the validity criteria. This does not support using token counts alone to identify a model family. A GitHub numeric-sequence detector also adds a shape pre-screen before closed-set ranking, but its thresholds apply only to its reference bank. This checker integrates none of these algorithms, their reference data, or identity classification.
The current tool calls public HTTPS OpenAI Chat Completions-compatible endpoints with a Bearer API key and checks /models and /chat/completions. These fixed probes do not directly support Anthropic Messages, Gemini generateContent, the OpenAI Responses API, or private custom protocols.
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.
