Data handling

This page states plainly what happens to data you send us. It describes how the platform behaves today, and deliberately avoids anything we cannot back.

Prompts and completions

We do not store your prompts or model outputs.

When you call the inference API, your request is passed to the model, the response is streamed back to you, and the content is not written to our database. There is no prompt log, and no request or response body is captured for the inference endpoints.

We also do not send prompts or completions to any third-party observability or analytics service, and we do not use your inputs or outputs to train models.

What we do retain

To bill accurately, show you your usage, and operate the service, each request writes a metadata record:

Retained	Example
Which model was called	zai/glm-5.2
Token counts	input, output, cached
Calculated cost and the rates applied
Timing	total latency, time to first token
Outcome	success, or the error class
Which workspace and API key	for attribution and billing
Client IP address and user agent
Timestamp

This is the data behind Usage and your invoices. It describes that a request happened and what it cost — not what it said.

Be precise with us about retention requirements

Request metadata, including client IP, is retained as billing and operational records rather than deleted on a fixed schedule. If you have a specific retention or deletion requirement, raise it with us directly so it can be handled contractually rather than assumed.

The playground

Playground conversations are held in your browser only. They are not saved server-side, and refreshing or leaving the page clears them. The underlying model call is handled exactly like an API call, so the same “no prompt storage” statement applies.

Support requests

Anything you paste into a support request — including prompts and model outputs you are asking us about — is stored, and is shared with the support tooling our team uses to respond.

That is the intended behaviour of a support ticket, but it means the inference guarantee above does not extend to text you deliberately send us for help. Redact anything sensitive before pasting it into a ticket.

Credentials and account data

• API keys are stored only as a hash. We keep a short prefix for identification, and the full key is shown once, at creation. We cannot recover it for you.
• Passwords are stored using a one-way hash, never in recoverable form.
• Authenticator secrets are encrypted at rest.
• Recovery codes are stored hashed and are single-use.

See Account security for what you control.

Access to your account

• Sessions are individually listed and revocable, so you can end access from a device you no longer control.
• Sign-in supports multi-factor authentication and passkeys.
• Email addresses must be verified.
• Access within a workspace is governed by roles.

Administrative actions in the platform are recorded in an internal audit log used by our operations team. This log is not currently exposed to customers — if you need an exportable access trail for your own compliance evidence, talk to us about what you need rather than assuming it is available.

Where it runs

Our inference infrastructure is operated in Australia.

If you have a formal data residency requirement — one you need to state in a contract or an audit — please raise it with us directly so we can tell you precisely what applies to your workload, rather than relying on a general statement here.

Reporting a security issue

If you believe you have found a vulnerability, contact us directly rather than filing it in a public channel. If you think an API key has been exposed, revoke it immediately from API keys — that is the fastest way to limit impact, and you can investigate afterwards.