Bottom line: The total score of the test report is "API comprehensive compatibility", not the model intelligence score, nor the official identity probability. The reading order should be to look at the model statement first, then the failure evidence, and finally the total score.
Open the detection toolFinally, it is recommended to choose standard mode. Standard mode adds SSE, tool invocation, output style, and knowledge boundary sampling, making it more suitable for pre-access checks.
Which protocols does Link's online checker cover?
Link's current web tool runs fixed probes only against public HTTPS OpenAI Chat Completions-compatible endpoints: it reads /models, and calls /chat/completions. It can check GPT, Claude, and Gemini when exposed through this compatible endpoint; this does not test OpenAI Responses, Anthropic Messages, or Gemini generateContent native protocols. Model brand, price, or monthly-plan eligibility does not change the checker's protocol coverage.
Compatibility checks and statistical fingerprinting are different methods
The current web tool screens compatibility with a small set of fixed protocol and behavior probes, including model declarations, visible response fields, tokens, dynamic challenges, and SSE and tool calls in standard mode. The report's "visible metadata cross-check" checks id、object、created、model and request ID fields; they are not cryptographic signatures and may be rewritten by a gateway. The token-to-prompt-character ratio is a single-request observation affected by language, prompt, and serialized text; it does not identify a tokenizer or model. Output style is also limited to the current sample and is not automatically compared across runs.
Single-token output-distribution research builds empirical distributions from repeated short answers and compares them with a trusted reference endpoint, for example using Jensen-Shannon divergence. It requires a trusted reference, sufficient samples, and matched prompts, language, system prompt, and sampling parameters.
A separate holdout study examined prompt-token-count sequences across controlled texts, not a single-request token-to-prompt-character ratio. Only 6 of its 12 pre-specified holdout pairs met the validity criteria, which is too limited to support using token counts as a general model-family identifier. It also does not directly validate this checker's ratio field.
On GitHub, lm-detector uses a different numeric-sequence method. Its October 18, 2026 update added a shape pre-screen before closed-set ranking. It checks lag-1 autocorrelation and the share of adjacent differences no greater than 20, then compares medians from valid answers with thresholds calibrated on that project's reference bank. Its documentation requires three answers with at least 80 valid integers each; flagged samples receive no ranking or confidence. The thresholds apply only to that project's numeric task and reference bank, cannot be transferred to other prompt sets, and do not authenticate model identity. AIFast Link does not integrate this screen, the single-token distribution algorithm, reference data, or thresholds; external papers and tools are not AIFast test results.
If using statistical fingerprints as a supplement, at minimum:
- Record the model provenance, exact ID/version, Base URL, tool version, and sampling time for both the trusted reference and test endpoint.
- Match the prompt set, language, system prompt, temperature, and other conditions; retain valid sample counts, invalid responses, and redacted raw results.
- Compare empirical distributions only under the same protocol and method version. Do not transfer distance thresholds across prompt sets or call a single mismatch fraud.
- Retest at another time and check for other explanations such as model updates, system-prompt injection, quantization, and dynamic routing.
| Interface type | Link online check | Details |
|---|---|---|
| OpenAI Chat Completions-compatible API | Fixed probes supported | The target service must expose GPT, Claude, or Gemini through the compatible API. |
| Native OpenAI Responses API | Not covered | Validate the Responses request and event structures separately. |
| Native Anthropic Messages API | Not covered | A compatibility-layer call does not replace validation against the native Messages protocol. |
Gemini generateContent native APIs |
Not covered | A Gemini-compatible endpoint and Google's native API have different scopes. |
Compare a Link test report with plan usage
Before testing Link, record the selected model, group and billing preference, then run a small sample. Passing protocol checks does not mean the model is covered by your plan. Check the eligible group and use the request log to identify which allowance was charged.
Some plans allow wallet fallback after the daily allowance is exhausted. Token counts and successful requests alone do not prove a call was free or included in a plan. Keep the corresponding charge records when assessing costs.
Review Link funding and monthly-plan rules
In what order should the reports be read?
1. Checked address and request model
First make sure that the Base URL and model ID are filled in correctly. Common errors include appending repeatedly /v1/v1, treat the display name as the model ID, or fill in /chat/completions specific path.
2. Request model and response model
Consistent means that the API declarations in this round are consistent; different means that there may be differences in aliases, version resolution, or routing. Neither can prove the underlying identity alone, and one needs to continue to look at capabilities and metadata.
3. Sub-item status
| Status | meaning | Recommended action |
|---|---|---|
| Pass | This probe met expectations | Join the business question set to continue verification |
| Doubtful | There are results but there are structural or consistency issues | Review the evidence and retest |
| failed | Key protocols or capabilities not met | Check the configuration first, then contact the service provider |
| observe | Weak signal, not counted in compatibility | Only used for multi-round trend comparison |
| No results | The upstream did not return interpretable content | Check permissions, rate limits, timeouts, and protocol coverage |
| Not executed | This item is not running in the current mode | Switch to standard mode when needed |
4. Overall score and business impact
A high score indicates a more complete protocol and key probes, but does not mean a stable production environment. A low score does not necessarily mean that the model is fake, it may be that the target endpoint only implements a partially compatible protocol.
The weight should be determined based on the business: ordinary Q&A pays more attention to basic protocols and streaming output; Agent pays more attention to tool invocation; cost-sensitive projects pay more attention usage Integrity; production systems must also be individually tested for latency, concurrency, error rates, and rate limiting.
What do the ten tests indicate?
- Certifications and model list: Whether the Bearer Key is certified,
/modelsWhether a recognizable directory is returned, and whether the selected model ID is visible; a restricted directory does not mean that the model is fake. - Protocol layer compliance: Whether the Chat Completions status code, response JSON, and key fields are recognized.
- Fixed instructions to follow: Can a random string be returned as-is, independently observing that the constraints are followed.
- Visible metadata cross-check:
id、object、created、modeland whether a request ID is present or consistent; this does not verify signatures. - Billing Token field: Whether the input, output and total tokens are available and arithmetically consistent.
- Output style characteristics: Record weak features of this answer, such as paragraphs, headings, lists, and code fences; the tool does not automatically compare historical samples or a trusted baseline.
- Knowledge cutoff boundaries: The knowledge boundaries described by the model are weak signals that can easily be rewritten.
- R1 dynamic questions: Capability sampling using random parameters and nonces.
- SSE streaming output: Streaming events, incremental content, and closing tags are compatible.
- Tool call: Whether the function name, JSON parameters, and random values are returned as required.
Illustrative example: a short request succeeds, but streaming does not finish cleanly
This hypothetical scenario explains how to read a report. It is not a test result from Link or any provider, and it does not establish model authenticity.
| Evidence in the hypothetical report | Reasonable interpretation | Unsupported conclusion |
|---|---|---|
| Model listing works and a short request returns JSON | These two basic requests work | All clients and advanced capabilities are compatible |
| The request and response model fields match | The API declarations match in this sample | The underlying model must be the official vendor model |
| SSE contains text deltas but lacks the expected completion event | Retest streaming and save the last event and any error | This must be model degradation or impersonation |
| Tool calling is marked not executed | This run provides no evidence for that capability | Tool calling passed or failed |
| The response includes usage, but no billing record is available | Only the usage fields in the response can be checked | The request was free, charged to the wallet or covered by a monthly plan |
Record the client version, model and group, final path and sanitized error. Retest non-streaming and streaming requests with the same input, then check usage logs. If SSE still fails, read the stream-disconnection troubleshooting guide.
How to fairly compare two API gateways
- Create temporary quota API Keys for both sites.
- Select the same model series and the same detection mode.
- Try to execute it at a similar time and in the same network environment.
- Repeat at least three rounds for each endpoint.
- Record model declaration, failure items, tokens, time-consuming and business problem set results.
- Compare evidence, don't just compare total scores once.
If two service providers use different model aliases, you should first confirm the actual mapping with their respective consoles. If it cannot be confirmed, mark it as unknown in the report and do not complete the conclusion on your own.
Under what circumstances should access be stopped immediately?
- API keys or sensitive information may be logged, exposed, or transmitted over non-HTTPS.
- Authentication, model routing, or accounting data continues to be abnormal and the service provider cannot explain it.
- Business-essential tool calls, streaming output, or structured results repeatedly fail.
- Results continue to drift under the same conditions and lack traceable request IDs or after-sales responses.
These conditions focus on usability, transparency, and security boundaries, and do not rely on "100% authenticity."
Reporting cannot replace anything
Test reports cannot replace manufacturer signatures, supply chain audits, contracts and privacy clauses, nor can they predict future stability. Production rollout also requires continuous monitoring of delays, error rates, throttling, routing changes, and billing consistency.
Next step
Read firstRepeatable detection method for model quality degradation, and then supplement the report with a set of fixed business questions. When you find inconsistencies in model declarations, checkModel impersonation and route substitution checks.