HopBase
The short answer: you can check whether an LLM API provider swaps models or silently degrades quality with reproducible tests rather than promises — and asking the model what it is proves nothing, because one system prompt makes any model claim any name. First, prompt-cache economics: repeat requests with the same long system prompt and look for stable cache_read_input_tokens hits from the second call, since randomly routed traffic shows low or zero hit rates. Second, model-family boundaries: real context limits, tokenizer counts, parameter handling and streaming habits form a fingerprint that is hard to fake. Third, A/B comparison against the vendor's official API to expose injected instructions. Fourth, blind tests on 20-50 objective tasks at temperature 0, repeated across weeks. Fifth, engineering quality: P95 first-token latency, mid-stream truncation and whether error codes such as 429/529 pass through. Any provider that does not welcome these tests has answered your question already.
The biggest anxieties when buying LLM API access from any third-party provider or aggregator: is the model real, is it silently degraded, and where does my data go. The market's usual answer is a promise — "no routing, no degradation, no swapping." Promises are unverifiable; methods are verifiable. We have run these checks continuously for two years; this is the public version of our internal methodology. Use it on any channel — including us.
Step 0: stop asking the model what it is
One system prompt makes any model claim any name — and official models routinely misreport their own version anyway. Identity must be verified by behavior, not self-declaration.
Check 1: prompt-cache economics (hardest to fake)
Claude and GPT prompt caching has an officially defined billing structure: cache writes carry a premium, cache reads are discounted, and cache_read_input_tokens is visible in usage. That is a built-in polygraph:
- Repeat requests with the same long system prompt — from the second call you should see stable cache hits (high read-token share, faster first token);
- Services that randomly route your traffic show dramatically lower or zero hit rates, because your requests land on different accounts and machines;
- Hit rates map to real money. Faking them long-term means the channel subsidizes you — economically unsustainable.
Check 2: model-family hard boundaries
Every model family has boundaries it cannot hide: the real context-window limit (push near-limit inputs and watch truncation behavior), tokenizer differences (token counts for identical text differ systematically across families — compare against usage), parameter surface (unsupported parameters should error or be ignored exactly as the official API does), and stop-sequence / stream-chunking habits. No single item is proof; the combined fingerprint is very hard to fake completely.
Check 3: injection traces
Some channels inject their own instructions around your system prompt — identity rewrites, ads, constraints. Detect by controlled comparison: run the same request set against the vendor's official API and the service under test, and compare obedience details on instruction-recall and role-boundary tasks. We have seen everything from one-line disguises to 4KB injected blocks; all of them show up under A/B contrast.
Check 4: blind degradation testing (sample size matters)
"It feels dumber" is not evidence — output variance is large even on the official API. The credible protocol: fix 20-50 tasks with objective answers (code completion, multi-step reasoning, instruction following), run both channels at temperature 0, compare pass rates, and re-test across weeks to catch time-of-day model swaps. Only a gap that persists beyond noise is a finding.
Check 5: engineering quality
The model can be real while the pipe is bad: look at first-token latency distribution rather than the mean (jittery P95 = unstable path), mid-stream truncation rates on long outputs (silent truncation is the worst failure mode), and whether the model provider's error codes pass through (services that swallow 429/529 into timeouts destroy your retry logic).
Why we publish this
Because this is the bar HopBase holds itself to — every route we offer is tested this way before it goes live, and anything that fails is rejected. And because our pricing page labels each plan's channel attributes in public. Transparent channel provenance plus reproducible verification beats a hundred repetitions of "we never swap." Run every check in this article against us.
For enterprise onboarding evaluation, talk to an advisor; integration details are in the docs.