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 in the API. GET /v1/models includes a quantization field on every entry.
On our own hardware, changing it creates a new variant. We will not silently re-quantise a model you are already using on capacity we operate. 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.
Where we buy capacity, we say “undisclosed”. Some models are served on capacity we buy wholesale rather than hardware we run. We cannot observe the precision there, so the catalogue says so plainly instead of printing a number we would be guessing at. An honest gap is worth more to you than a confident figure we cannot stand behind.

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.

The one exception: opt-in training contribution

Workspaces can choose to contribute their sports-model traffic (Sports-1 and Sports-2 requests, including betslip images) to improve those models. It is off by default, never required, scoped to those models only, and honest about its shape:

Anonymous by schema, not policy. The table these samples land in has no workspace, key or user column, and records only the day — not the time — a sample arrived. There is nowhere to write who a sample came from.
The trade-off is stated up front. Because a contribution cannot be traced back to a workspace, it also cannot be found and deleted later. Turning the setting off stops future contributions immediately; it cannot recall past ones.
Consent is audited. Every change to the setting is recorded with who flipped it and when.

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. 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.