Recent dealings with some upstream API suppliers have left me frustrated.
Competing on procurement costs, stable infrastructure, and good support is reasonable. But some suppliers substitute models or alter usage records, then use a low advertised price to attract customers. Users end up paying more, while providers doing the work properly lose business.
The following examples draw on my own testing of upstream channels. I hope they help readers check an API reseller more carefully. The observations apply to the channels and request conditions I tested; this article does not identify specific services.
1. Substituting a cheaper model
The method is straightforward: the user selects an expensive model, the backend calls a cheaper one, and the response still displays the requested model’s name.
Consider gpt-6-astra and gpt-6.1-sol. As checked on November 5, 2026, their official model pages list the following standard text token rates, in USD per million tokens.
| Model | Uncached input | Cached input | Output |
|---|---|---|---|
| GPT-6 Astra | 10 | 1 | 50 |
| GPT-6.1 Sol | 2 | 0.10 | 10 |
These are the listed standard rates only. They exclude long-context adjustments, cache writes, accelerated modes, tools, regional pricing, and other modifiers. Check current official prices before calculating costs.
Sol is positioned to handle complex work at a lower cost, with performance approaching Astra on some workloads. When the difference on a particular task is hard to notice, a user may not discover within a few conversations that the supplier is serving Sol under Astra’s name.
The user requests Astra, the gateway actually calls Sol, and the service still charges for Astra. This differs from automatic routing or fallback that the user has been told about and agreed to.
Model aliases are a standard gateway feature. Gateways such as LiteLLM allow the user-facing model name and the actual upstream model to be configured separately. A response containing model: "gpt-6-astra" is therefore not independent proof that Astra handled the request.
How to check
Use the same set of difficult tasks, with the same context and reasoning settings, to compare the official API and the reseller. Persistent differences in quality and latency deserve investigation.
However, Astra does not necessarily take longer than Sol on every request. The official model pages do not disclose full parameter counts, and latency also depends on reasoning effort, output length, caching, queueing, hardware, network conditions, and service tier.
Compare time to first meaningful output, sustained generation speed, total completion time, and task success separately. Low latency can reflect optimization; high latency can simply reflect queueing or gateway buffering.
A service can also delay delivery deliberately, so latency alone cannot establish model identity.
Encrypted reasoning verification
Encrypted reasoning items in the OpenAI Responses API primarily support preserving and continuing reasoning context, including in stateless workflows. Reuse depends on model-family and context compatibility. Receiving an encrypted item does not let the customer independently verify which model executed the request.
Neither the presence of an encrypted item nor its acceptance by a subsequent request proves that the specified model generated the current answer.
In my own channel tests, Astra and Sol reasoning items were interoperable under the request conditions used. I also tested cases involving reuse of encrypted reasoning from previously generated content and repackaging of returned content. These were results on particular channels; other versions and interfaces need separate testing.
When checking encrypted reasoning, compare its origin, the corresponding request, subsequent continuation behavior, and the final answer together. A simple pass result is not enough.
Reducing exposure
Stop adding funds, retain the original requests, responses, and billing records, compare several task types under fixed settings, and ask the service to explain its actual routing and fallback rules.
If a small balance remains and a refund is unavailable, using an explicitly priced cheaper model for low-risk tasks may reduce losses. But changing models will not fix a service whose usage accounting and channels are also untrustworthy.
2. Altering reported usage
Some channels serve the correct model but inflate the returned usage and the amount deducted from the user’s balance.
The advertised credit price looks inexpensive, yet the balance disappears quickly. If a task that should consume one credit unit is charged ten units, a low price per credit does not mean the task was inexpensive.
Check later turns
Agent workflows and long conversations include previous messages, tool definitions, tool results, and new input on later turns. Some problems only become visible there.
A normal first request does not establish that subsequent charges are correct. Test fresh conversations, repeated prefixes, long histories, tool loops, and failed-request retries, checking usage and deductions separately.
Reclassifying cache reads as cache writes
A subtler issue than multiplying token counts is changing billing categories while keeping the total input count unchanged. Tokens that should be charged at the cheaper cache-read rate are instead recorded as more expensive cache writes.
The following hypothetical bill illustrates this. To avoid mixing different providers’ field definitions, input has first been normalized into three non-overlapping billing categories.
| Input category | Actual usage | Incorrectly recorded usage |
|---|---|---|
| Uncached input | 10,000 | 10,000 |
| Cache reads | 80,000 | 40,000 |
| Cache writes | 10,000 | 50,000 |
| Total | 100,000 | 100,000 |
The totals match. But suppose the agreed relative rates for uncached input, cache reads, and cache writes are 1, 0.1, and 1.25. Using the same billing unit:
- Correct weighted charge:
10,000 × 1 + 80,000 × 0.1 + 10,000 × 1.25 = 30,500. - Altered weighted charge:
10,000 × 1 + 40,000 × 0.1 + 50,000 × 1.25 = 76,500.
The input token totals are identical, but the input charge differs by approximately 2.51 times. This is an illustrative calculation, not a record of an actual request. Output and tool charges are excluded.
Cache rates depend on the model and cache lifetime, so these example multipliers are not universal. The same tokens also must not be charged twice as both uncached input and cache writes.
Cache expiration, prefix changes, reasoning-setting changes, and routing changes can legitimately cause misses and new writes. If writes increase, inspect the corresponding requests before drawing a conclusion.
Reconciling charges
At a minimum, reconcile uncached input, cache reads, cache writes, output, internal reasoning, and tool fees. Additional service charges and the treatment of failed retries should also be clear.
APIs differ in how input_tokens, cached tokens, and reasoning tokens relate. Some report cached usage as a subset of total input; others report input categories separately. Do not add every field together. Reasoning already included in output must not be added a second time.
A reseller’s response usage and its dashboard bill often come from the same accounting system. Agreement between them establishes internal consistency, not independent verification. Corresponding upstream request records and billing details provide stronger evidence.
3. Editing returned content
Some services edit the model’s returned text to conceal the actual channel.
With a channel based on Kiro, the underlying model, the access channel, and Kiro’s added instructions and tools can all affect the result.
Kiro provides access to models from OpenAI, Anthropic, and other suppliers. Using Claude through Kiro does not necessarily mean the underlying model is not Claude. But that access is not automatically equivalent to calling Anthropic’s first-party API directly.
If a reseller advertises one channel but forwards through another product and replaces product names in the response, the source is being concealed and the content is being modified without disclosure.
I have personally tested cases where Kiro-channel response content was replaced: an answer originally identifying itself as Kiro was changed to Claude before delivery. The user-facing self-description had been edited; the underlying access channel had not changed.
To examine such a case, compare the original and final responses for the same request. A screenshot in which the assistant says it is Claude does not, on its own, show where editing took place.
How to check
A model’s self-description can be affected by system instructions, product configuration, and conversation history. Calling itself Claude does not prove the channel; calling itself Kiro does not independently identify the precise model either.
In the Kiro access methods I tested, the caller could not freely control the product-added system constraints as they could with a direct first-party API call, and answers could include Kiro identity markers. Other versions and integrations may behave differently. Check whether your instructions take effect, what extra constraints the product adds, and whether the service explains those differences.
Sales labels such as CC Max, “official relay,” or “clean” also need verifiable definitions. A label alone does not establish account type, interface origin, or service limitations.
Effects of global text replacement
Blindly replacing a word in returned content can affect code, file paths, product documentation, quoted material, and tool arguments. A technical article about Kiro could itself be rewritten into something inconsistent.
4. Problems with multiple resale layers
An API service can have several supply layers: the customer-facing site buys from an upstream provider, which in turn depends on another aggregator. Model names, settings, caching, and pricing rules may be transformed at each layer.
A particularly frustrating situation is when one supplier has already applied a model mapping or accounting change but fails to communicate it downstream. The final reseller has not checked the details and continues to repeat the upstream sales claims to customers.
Customers pay the service they deal with. “That is what our supplier told us” is not an adequate response to a billing or delivery problem.
A service taking payment should be able to explain model and version, channel limitations, fallback behavior, capability limits, the billing formula, and how anomalies will be investigated. Upstream commercial information may reasonably need redaction, but confidentiality cannot replace every explanation.
These expectations should apply to UnifyLLM as well. When customers check model prices or contact us about a request, they have a reasonable expectation that delivery and charges can be explained.
5. Limits of model detection sites
Model detection tools generally inspect a small number of requests. They cannot guarantee that later requests use the same model and configuration.
Check what a test actually measures: response format, tool support, behavioral similarity, fixed benchmark questions, or origin supported by independent evidence. These are different things. A failure may reflect a version, parameter, load, or compatibility issue; a pass establishes only that the endpoint met that test’s rules at that time.
Fixed rules and limited samples leave room for targeted adaptation. A service might also route detected test requests differently. Testing should account for that risk, but it does not establish that all detection sites are colluding with suppliers.
Research such as the GhostPrint preprint has demonstrated that weaker models can be fine-tuned to imitate stronger models’ fingerprints and evade some detection methods. Those experimental results do not automatically extend to every detection site.
If a detection page also sells placement, uses referral links, or charges for verification labels, check whether it discloses commercial relationships, methods, and error rates. Advertising interests do not automatically make a result false, but readers should understand how they may affect recommendations.
Read the test method, original samples, and error explanation alongside the score.
6. Practical advice
- Add funds in small stages. Check real tasks, costs, and support before increasing usage. Stop adding funds if the channel is in doubt.
- Keep comparisons controlled. Use the same model version, context, tools, reasoning settings, and output limit when comparing quality and cost.
- Include later turns. Test repeated prefixes, long conversations, tool loops, and failed retries; examine cache categories and total deductions separately.
- Retain original records. Keep requests, responses or SSE, timestamps, finish reasons, usage, and bills linked together. Redact sensitive data before sharing evidence.
- Measure cost per successful task. Include retries, failures, and manual rework instead of comparing only the number on the top-up page.
- Ask specific questions. “Why was this prefix written again?”, “Was this parameter ignored?”, and “Which model handled the fallback?” are easier to investigate than a general accusation of fraud.
If the service repeatedly fails to explain model origin and deductions, stop adding funds and use another channel. Do not keep topping up just to use the remaining balance.