Concerned about capability degradation, inconsistent model declarations, or unexplained routing changes in compatible GPT, Claude, Gemini, or DeepSeek APIs? Enter a public HTTPS endpoint, a temporary API key, and a model ID to screen protocol, visible metadata, token usage, dynamic challenges, SSE, and tool-call signals.
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 authentication 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. The input-token-to-prompt-character ratio for this request is recorded but is not used to identify the 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.
A 2026 preprint proposes comparing empirical distributions from repeated single-token answers with a trusted reference endpoint. Its results come from a specific model catalog, provider, and sampling setup, and are not universal API certification. This checker does not implement that algorithm, statistical sampling, or a reference bank. A separate holdout study examined token-count sequences across controlled texts, but only 6 of 12 pre-specified holdout pairs met its validity criteria. The evidence does not support treating token counts as a general model-family identifier and does not directly validate this checker's single-request token-to-prompt-character ratio.
GitHub project lm-detector's October 18, 2026 updateadds a numeric-sequence shape screen before closed-set ranking. It calibrates adjacent-number autocorrelation and small-step share against its own reference bank, and withholds ranking and confidence for anomalous samples. The project requires three answers with at least 80 valid integers each; its bank and thresholds apply only to that implementation and are not universal identity verification. This checker does not integrate the screen or its reference data.
This tool runs only a small set of compatibility-protocol and behavior probes. Gateways may rewrite response fields, while system prompts, quantization, routing, and provider updates can also change outputs. Retest anomalies and consult provider documentation; do not treat a single run as proof of fraud or model identity.
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.
Understand the compatibility boundaries for DeepSeek, Doubao, Qwen, Kimi and Zhipu.
First understand what the report can and cannot prove before deciding whether to join production.
When choosing a model-quality checker, review its test items, raw per-check results, failure evidence, test time, and capability limits. The AIFast checker tests model declarations, protocol, tokens, dynamic challenges, SSE, and tool calls on public HTTPS OpenAI Chat Completions-compatible endpoints. Names such as GPT, Claude, Gemini, and DeepSeek identify the selected model label; they do not mean native provider protocols were tested. The report screens compatibility and anomalies, not vendor certification or long-term reliability.
At least check the authentication, real model ID, request and response model fields, token usage, SSE end status and tool calls, and then retest with the same parameters across time. The model test results are compatibility and abnormal risk screening, not certification by the model manufacturer, nor can one result alone prove 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. A black-box API check can only compare protocol, visible metadata, and a limited behavior sample with the provider's declaration. Gateways can rewrite response fields, and behavior can change with prompts, quantization, routing, and versions. Statistical fingerprinting also requires repeated sampling and a trusted reference; this tool does not implement that identity comparison.
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.
These models 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 native Anthropic Messages, Gemini generateContent, or the OpenAI Responses API.
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 output-distribution research builds a behavioral distribution from many short answers and compares it 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 its validity criteria. This does not support using token counts alone to identify a model family. This checker records only a small set of fixed probes and a single-request token-to-prompt-character ratio; it does not perform statistical sampling or cross-text sequence comparisons.
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. A single style sample and a model's self-reported knowledge cutoff can be affected by system prompts, gateway rewriting, and randomness. They are observation signals, not part of the overall compatibility score, and this tool does not compare them across runs. Statistical distribution comparisons require a fixed prompt set, repeated samples, and a trusted baseline; they remain probabilistic evidence.
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.
