Four ways to check a "direct official connection" or "pure resale" claim

First, be clear about how far this can be verified

Whether it really uses official keys cannot be proven 100% from the outside.

Any external test can only produce a judgement of "consistent with official behaviour" or "inconsistent with official behaviour". So the four methods below serve to raise confidence, not to produce a definitive conclusion.

There is one exception: disproof is effective. Finding a single item inconsistent with the official behaviour is enough to reject a "pure official resale" claim. So all four methods are for ruling out, not for confirming.

Method one: capability completeness testing, the most reliable

The principle: reverse-engineered subscription services, and some mixed-sourcing ones, are incapable of what an official API can do. Testing those capabilities therefore reveals the source.

Test four things in order:

Criteria:

• Failing either item 1 or item 2 → the "pure official resale" claim can effectively be rejected.
• Passing all five → reaches "consistent with official behaviour", a substantial increase in confidence, though still not 100% proof.

This is the most reliable of the four, because it tests capability boundaries, and a missing capability is much harder to fake than a difference in behaviour.

Note the value of item 5: official APIs produce well-formed error structures with error.type and error.code. An intermediate layer at a reverse-engineered site tends to generate its own error text. Send an obviously illegal parameter and look at what the error looks like. It is a very cheap test with a lot of information in it.

Method two: how well price matches the cost structure

The principle: price is determined by cost. If the cost structure a site claims contradicts its pricing, the claim is not credible.

Check three things:

1. The price floor. Reselling official quota reasonably lands between 30% and 70% of official price. A quote below 30% while claiming pure official resale is a contradiction.
2. Breadth of model coverage. For pure official resale, the model list equals whichever official providers it connects to. If it lists many models it could not possibly have official access to, such as models only available in certain regions, the claim is doubtful.
3. Pricing of cache_control. Official providers discount cache reads heavily, around 0.1x. If the bill shows no cache discount at all while the site claims official resale, that is a contradiction, because official providers do support caching.

Item 3 is a neat cross-check: official resale can necessarily use caching, and caching necessarily shows up in the bill.

Method three: response consistency

The principle: if the backend reliably comes from the official provider, the same request should produce consistent response characteristics over time.

Method:

1. Fix the prompt and the parameters: temperature: 0, a fixed max_tokens.
2. Run three to five times at several different moments, hours or days apart.
3. Compare output content, usage structure and response headers.

Criteria:

• Output identical or highly consistent → the backend is stable, which supports the official resale claim.
• Output differs noticeably, usage structure differs across time points → the backend is changing, a channel pool or routing.

Why this matters: with temperature: 0, an official API's output is usually highly reproducible. If a site produces different output every time at temperature: 0, either an intermediate layer is rewriting requests, possibly changing parameters, or the backend is not fixed.

Note: some models are not fully deterministic even at temperature: 0, because of floating point and batching. So the criterion is "highly consistent", not "identical", and several samples are needed.

Method four: tracing error messages

The principle: official errors are traceable, with fixed patterns in structure, field names and wording.

Method: manufacture several kinds of error and watch the responses.

Criterion: across the four error types, the more responses whose body structure matches the official format you know, the higher the confidence.

One clearly inconsistent item means there is more than one layer in the middle.

The four methods ranked by reliability

Used together: one plus two usually yields a usable conclusion; three and four cover edge cases.

A pragmatic inversion

Rather than spending time verifying whether it is pure official resale, ask a different question:

"Can it meet my needs?"

• If it supports the capabilities you need — caching, Batch, structured output — at a reasonable price, you do not really need to know where its keys come from, as long as it keeps delivering those capabilities reliably.
• If it cannot do those things, then whether or not it is official resale, it does not meet your needs.

So capability verification is mandatory and provenance verification is optional.

Only two situations genuinely call for provenance work: you are making a procurement decision and need to justify it upwards, or you have found anomalies — quality problems, inconsistent behaviour — and need to locate the cause.

One last note: the credibility of a marketing claim should be tied to verifiable evidence. A site that gives concrete grounds for its "direct official connection" claim — channel type, testable capabilities, a clear baseline price — is more credible than one that simply repeats the claim.