Infer — Privacy & Data Retention Policy
Summary
Infer operates zero data retention for all user content: prompts, completions, and any other content submitted for inference are processed entirely in volatile memory and are never written to disk, never logged, and never used for model training, sharing, or resale. The only information Infer retains is operational metadata — timestamps, token counts, latency, and similar figures — which by design contains no user content. Infer's infrastructure and personnel have no mechanism to capture, inspect, or export customer prompts or completions at any point in the processing pipeline.
What we process
Infer serves GLM-5.3-Flash inference requests routed to us exclusively by OpenRouter. For each request, we process:
- Prompt content (text and, where applicable, multimodal input)
- Model completions (including streamed output)
- Sampling and request parameters (e.g., temperature, max tokens, tool definitions)
- Session/conversation continuity signals used to route follow-up turns to the same replica
All of the above is handled in volatile (RAM/GPU memory) form only, for the duration required to generate and return a response.
What we never do
- Never write prompts or completions to disk. Content does not touch durable storage — no databases, no object storage, no swap-backed persistence.
- Never log content. Application and diagnostic logs are structured to exclude prompt/completion payloads by construction, not by redaction after the fact.
- Never use content for model training or fine-tuning.
- Never share or sell content to any third party, including subprocessors.
- Never grant employee access to content. There is no internal tool, console, or export path that surfaces customer prompts or completions — see No content-based debugging below.
What we retain
| Data class | Contents | Where | Retention |
|---|---|---|---|
| Diagnostic logs | Timestamps, model id, latency/throughput measurements, HTTP status codes, sampling parameters (not content), hashed session/API-key identifiers | Log storage, access-restricted | 30 days |
| Billing / usage records | Token counts (prompt, cached, completion), amounts, model id, timestamps — no content | Accounting database | As long as required for invoicing and applicable financial/tax obligations |
| Transient inference cache | Content-derived prefix/KV cache (see Caching) | GPU/host memory only, never durable storage | Minutes to hours; evicted automatically |
No table row above includes prompt or completion content. Operational metadata is retained solely for troubleshooting, capacity planning, and billing accuracy.
Caching
To serve multi-turn sessions efficiently, Infer maintains a transient prefix/KV inference cache in GPU and host memory. This cache:
- Is content-derived (it holds intermediate model state, not raw text) and exists only to accelerate a session's next turn on the same replica (session affinity).
- Is evicted automatically within minutes to hours, under memory pressure or when a session ends — whichever comes first.
- Is never persisted to durable storage and never survives a replica restart.
- Is never accessible outside the inference process that produced it.
Security
- Transport encryption: All traffic from OpenRouter to Infer's gateway is TLS-encrypted. Traffic from the gateway to compute nodes runs over an encrypted overlay network.
- Sole authorized caller: OpenRouter is the only party authorized to call Infer's API. Access is controlled via a static, issued API credential and, optionally, IP allowlisting of OpenRouter's egress addresses. End users never connect to Infer's infrastructure directly.
- No content-based debugging: Incidents and performance regressions are reproduced and diagnosed using synthetic traffic. There is no mechanism — support tool, admin console, or ad hoc access — by which Infer personnel can capture, view, or export a customer's actual prompts or completions.
Subprocessors
Infer's inference workloads run on third-party GPU/compute infrastructure providers. These subprocessors host the volatile compute on which requests are processed; consistent with the policy above, they do not receive durable copies of content, as none is ever written to disk.
Current subprocessors:
- [GPU/compute infrastructure provider name(s) — kept current]
This list is reviewed and updated as Infer's compute footprint changes.
Your choices & contact
Because Infer retains no user content, there is no content to access, export, or delete on request — by design, none exists after a response completes. Questions about this policy, operational metadata retention, or data handling generally can be directed to:
contact@infer.industries
Changes to this policy
Infer may update this policy from time to time. Material changes will be published at this document's canonical location with an updated effective date, with at least 30 days' notice before the changes take effect.