How to read an LLM API gateway check report

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 tool and select standard mode for pre-integration checks. It adds SSE, tool calls, output-style sampling and self-reported knowledge-cutoff sampling.

Reproduce and retain a report with AIFast HK

First, follow the HK quick start to create a separate capped key and copy the full model ID from the same account's catalog. Set the test Base URL to https://www.aifast.hk/v1; do not enter the homepage, a full/chat/completions endpoint path, or another site's address. When testing another provider, change both the Base URL and key to that provider's values.

After a standard check, retain the fields below and interpret them using this guide. Mark missing fields as unavailable; do not fill them with marketing figures.

This report covers only probes against public HTTPS OpenAI Chat Completions-compatible endpoints, including GET /models with POST /chat/completions probes; it does not cover OpenAI Responses, Anthropic Messages, or Gemini generateContent is not a full validation, nor does it prove long-term availability for AIFast or any other platform. GPT, Claude, Gemini, and DeepSeek name labels only identify the selected model label; they do not mean the provider's native protocol was tested. Redact keys, authorization headers, and business data before sharing screenshots or text.

Compatibility checks and statistical fingerprinting are different methods

The online tool on this page runs a small set of fixed protocol and behavior probes and reports /models visibility, Chat Completions response structure, model declaration, tokens, randomized challenges, and SSE and tool calls in standard mode. The "visible metadata cross-check" checks only the response-visible id、object、created、model, request ID, and other 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, and does not identify a tokenizer or model. This label change does not alter probes, scoring weights, or API behavior.

Statistical fingerprinting is a different method: it builds empirical distributions from repeated short answers and compares a test endpoint with a trusted reference, for example using Jensen-Shannon divergence. It requires repeated sampling, a trusted reference, and matched prompts, language, system prompt, and sampling conditions; its cost and evidence differ from this checker’s approximately 3/7-request quick/standard modes.

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 method: its October 18, 2026 update added a shape pre-screen before closed-set ranking for numeric sequences. It checks lag-1 autocorrelation and the share of adjacent differences no greater than 20, then compares medians from valid answers against thresholds calibrated on that project's reference bank. Its documentation requires three valid answers with at least 80 valid integers each; a flagged sample receives no candidate ranking or confidence. This applies to that numeric task and reference bank only; its thresholds cannot be transferred to other prompt sets or prove a vendor model's identity. The AIFast checker does not integrate this algorithm, reference data, or thresholds. GitHub and paper results are not AIFast test results.

For this supplemental verification, preserve evidence in this order:

1. Choose a trusted reference endpoint with documented provenance and a test endpoint. Record the provider, model ID/version, Base URL, and sampling date. Do not claim an identity match without a trusted reference.
2. Use the same prompt set, language, system prompt, temperature, and other controllable parameters at both endpoints. Record valid sample counts and unsupported capabilities for each.
3. Compare empirical distributions and distance metrics using the research implementation, and retain redacted raw results, tool version, and reference-data date. Do not apply one distance threshold across different prompt sets or protocols.
4. Retest at another time and check for changes to routing, system prompts, quantization, or provider versions. A single mismatch is a statistical signal to investigate, not proof of fraud or underlying identity.

How are AIFast HK model-check scores calculated?

The following describes the implementation used by the HK checker on October 24, 2026; it is not a model-vendor scoring standard. Overall compatibility includes only checks with a positive weight and numeric score: multiply each score by its weight, divide the sum by the total participating weight, convert to a 100-point scale, and round to the nearest integer.

The scoring weights total 80 in quick mode and 100 in standard mode. Skipped checks do not count as failures, so a quick-mode score of 100 does not mean SSE or tool calls passed and cannot be compared directly with a standard-mode score. Instruction and behavior match is the average of the two numeric scores for instruction following and the dynamic challenge, not a probability of model authenticity.

For example, if only the tool-call check scores zero in standard mode and all other scored checks receive full marks, the total is still 90. This is an arithmetic example, not a measured result for any platform. An agent that depends on tool calls must still resolve that failure regardless of the total score.

What do the summary, report ID and token totals establish?

• Copy Report Summary includes model declarations, check statuses and summaries, but not all raw evidence, complete token details or the test time. Also preserve the test time and evidence shown on the page; the clipboard summary is not a complete test archive.
• MC- identifies this check report, not an upstream request or a publicly retrievable report. For provider support, check the request ID actually returned in the metadata evidence; record it as unavailable if missing.
• The displayed token count aggregates multiple probe responses. Unavailable, partially estimated or partially reported usage cannot establish an exact bill. Even complete fields must be reconciled with the HK account's group and charge records for that run.
• Report duration measures the entire probe round executed by the edge service. It is neither a single chat's time to first token nor the latency from the user's browser to the target API.

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

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?

• Authentication and model listing: Whether the Bearer key passes authentication,/models Whether 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、model and 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: Weak features such as paragraphs, headings, lists, and code fences are only used for comparison.
• 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.

How to fairly compare two API gateways

1. Create temporary quota API Keys for both sites.
2. Select the same model series and the same detection mode.
3. Try to execute it at a similar time and in the same network environment.
4. Repeat at least three rounds for each endpoint.
5. Record model declaration, failure items, tokens, time-consuming and business problem set results.
6. 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."

What a report cannot establish

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.