Transparency

Inference is unusually easy to be dishonest about. The same model name can mean wildly different things depending on precision, context limit and batching, and almost none of that is visible from the outside. These are the things we commit to publishing, and the mechanisms that make each one checkable rather than trusted.

Quantisation disclosure

Quantisation is the biggest hidden variable in commercial inference. A model served at 4-bit behaves measurably differently from the same weights at FP16 — worse at long-chain reasoning, more prone to formatting drift, and cheaper to run. Providers rarely say which they serve, which makes benchmark numbers from one provider unusable at another.

What we commit to

Every variant states its precision. It is a required, non-null column in our catalogue — a model cannot be published without one.
It is on every response. The x-infersia-quantization header returns the precision that served your request, so you can assert on it in your own test suite instead of taking our word for it.
It is in the API. GET /v1/models includes a quantization field on every entry.
Changing it creates a new variant. We will not silently re-quantise a model you are already using. A different precision is a different row with a different price, and the old one is deprecated on a notice period rather than swapped underneath you.

Zero prompt retention

We do not store your prompts or the model’s completions. That is a common claim, so here is the specific reason it holds rather than depending on us remembering.

Enforced by construction

There is no column for it. Our usage table records tokens, timings, cost and status. It has no field a prompt or a completion could be written into, so storing one would require a schema migration, not a mistake.
The logger uses an allowlist. Our structured logger reduces every object to a fixed set of permitted fields before formatting. An engineer who writes log.info({ request }) while debugging gets an empty object, not a leaked conversation — including for objects nested inside other objects.
The proxy streams, it doesn’t collect. Completions are forwarded to you as bytes arrive. The gateway reads token counts out of the stream without ever assembling the text.
Opt-in, never opt-out. If you want request logging for your own debugging, it is a per-organisation setting that is off unless you turn it on.

We do retain metadata: which model, how many tokens, how long it took, what it cost, and whether it succeeded. That is what your invoice and your activity log are made of, and there is no way to bill accurately without it.

How the numbers are measured

Published performance figures are worth exactly as much as their methodology, so here is ours.

Latency and throughput

Taken from real production requests over the trailing 24 hours, not from a benchmark harness. Time to first token is measured from when we dispatch to the GPU to the first content token arriving. We publish the median rather than the mean, because a handful of cold starts would otherwise flatter or ruin the number depending on which way you round.

Uptime

Computed from health probes against every endpoint every 15 seconds, rolled up daily and averaged over 30 days weighted by probe count. It is derived from stored probe results, so it can be recomputed from source — it is not a counter we increment and could quietly reset.

Token counts

Read from the inference engine’s own usage report on every request. When an engine fails to report them, we fall back to an estimate and flag that row as inexact — you can see the flag in your activity log, and we track the proportion of revenue resting on estimates internally because it should be approximately zero.

What we run on

Our endpoints run on GPUs rented from marketplace providers rather than on hardware we own. That is a real trade-off and we’d rather state it than have you find out: it makes us cheaper, and it means individual hosts occasionally disappear without notice.

We handle that with multi-host pools, health checks every 15 seconds, and automatic failover between hosts within a request. The hardware class behind each model is published in the catalogue. When a pool loses all its capacity, it shows on the status page — including retrospectively.

Incidents

We publish incidents on the status page as they happen, and we do not remove them afterwards. A provider with no incident history either has no traffic or is not telling you about them.

Found something on this page that doesn’t match what the platform actually does? That’s a bug and we want to hear about it — transparency@infersia.com.