The DeepSeek or Claude you bought through a reseller may be quantized down. Same name, same price, a measurably worse model, and nothing on the endpoint says so
Cost-focused API resellers cut precision to fp8 or lower to save on serving. The model keeps its name and its price. The quality drops, and a single response looks identical, so only a benchmark against the reference reveals it.
By Parminder Kumar Sharma · · 6 min read

The other half of yesterday's story
A briefing here yesterday showed that buying model access through a reseller routes your prompt through hops the invoice never names. This is the same betrayal on a different axis. The reseller can also hand you a worse model than the one you paid for, and you cannot tell from the response.
The mechanism is quantization. A frontier model is released at a given numerical precision, commonly bf16. Serving it is expensive, so a cost-focused provider quantizes the weights or activations to fp8, or lower, which is cheaper to run and measurably further from the reference behaviour. The API endpoint keeps the model's name and often the headline price. The output shape is identical. The quality is not.
Same endpoint, thinner model
Why you cannot see it
This is not a hidden flaw a vendor is hiding by accident. It is a design choice with no disclosure convention attached. The response to a single prompt from a quantized model looks exactly like a response from the full one. There is no field in the API that says "served at fp8". The degradation shows up only in aggregate, on hard tasks, against a known reference, which is precisely the measurement a busy team never runs.
The clearest proof that this is routine is the marketing. A handful of providers now advertise "bf16, no quantization, output matches the released weights" as a competitive differentiator. You do not advertise the absence of a corner unless cutting that corner is the norm.
What the invoice implies, and what a quantized endpoint delivers
| The assumption | The reality on a cost-optimised endpoint |
|---|---|
| I am getting the model named on the tin | You may be getting a quantized copy of it, cheaper to serve and further from the reference |
| Same name, same price, same model | Name and price can be unchanged while the precision is not |
| The output tells me the quality | A single response looks identical; degradation is only visible in aggregate against a reference |
| Cheaper access is the same product at a discount | Cheaper access is frequently a cheaper product, and nothing on the endpoint says which |
A concrete way it bites
Consider a team that evaluated a model at full precision, was satisfied, and then moved its production traffic to a cheaper reseller endpoint carrying the same model name to cut the bill by half. Nothing in their dashboards changes. The latency may even improve. But the model now answering hard, multi-step prompts is a quantized copy, and the failures it introduces are subtle: a slightly higher rate of wrong tool calls, a small drop on the reasoning cases that mattered, a few more hallucinated citations. None of it trips an alarm, because there is no alarm for "the weights got lighter". The evaluation that blessed the model was run against a different model than the one in production, and nobody re-ran it after the switch. That is not a hypothetical failure; it is the default outcome of treating an endpoint name as a quality guarantee.
The reason this is worth a briefing rather than a shrug is that the whole value of an evaluation is that the thing you tested is the thing you shipped. Quantization quietly breaks that link, and it breaks it in exactly the place a cost-driven procurement decision is made. The model maker's own endpoint is a known quantity. A reseller's endpoint is a claim about a model, priced to move, with no field asserting the precision behind it.
What to do
Take this with you
If you buy model access to run real work
- Benchmark the endpoint you actually use, not the model in the abstract. Run a fixed set of hard prompts against your reseller and against the model maker direct, and compare. The gap is the quantization tax.
- Treat precision as a contract term. Ask, in writing, whether weights and activations are served at full precision, and whether that can change without notice.
- Re-run the benchmark periodically. A provider can switch to a cheaper precision at any time to protect margin, and the endpoint will not announce it.
- For evaluation-sensitive work, buy direct or self-host the released weights. The discount on resold access can be the difference between the model you tested and the model you deployed.
- Pair this with provenance. Yesterday it was where your prompt went; today it is which model answered. Both are invisible without a test, and both are now testable.
The position
The pattern is the one this site keeps returning to. What you are handed is accurate in a narrow sense, the endpoint really is called what it says, and answers a smaller question than the risk you carry. A reseller endpoint names a model. It does not promise the precision, and precision is most of what you were buying.
Unlike the reseller-routing finding, this one has no single measurement paper behind it yet; it lives in provider disclosures and benchmark trackers, and it deserves the same caveat those carry. But the defensive move is identical and cheap. If quality matters, measure the endpoint you are actually calling, because its name is not a guarantee of its weights.
Sources
- Reported byLLM API providers compared, precision and quantization disclosuresMorphaccessed 2026-08-24
- Reported byBest API providers for DeepSeek V4, on serving precisionDeepInfraaccessed 2026-08-24


