Amux

Data retention and privacy controls

Last updated September 15, 2026

How long each kind of data is actually kept, how generated artifacts are stored and cleared, and which controls are available to you.

This page describes what the platform actually does with data, so you can assess it against your own compliance requirements. For the legal statement, see the privacy policy.

Call bodies are not recorded

The request and response bodies of text and chat calls are not stored. Prompts and model output are not written to disk once forwarded; the call record holds metadata only: time, model, provider, protocol, token usage, duration, status code, and failure reason.

This means:

  • Prompt content is not visible on the logs page — by design, not for lack of permission
  • We cannot reconstruct for you what a particular call asked
  • We also cannot do anything with that content, including training models

If you need call content retained, record it on your side and correlate it with our records using the x-amux-generation-id response header.

Three kinds of content that are stored

Asynchronous generation tasks

For image, video, and similar asynchronous tasks, the prompt, generation parameters, and material references are stored with the task, outside the rule above.

The reason is that these tasks run asynchronously: results are retrieved minutes to tens of minutes later, and retrieval, retries, and billing disputes all depend on that input.

Retained for 30 days by default, after which the task payload is cleared; the task record itself is kept for reconciliation and audit.

Playground conversations

Messages and model replies in the console playground are stored under your account so that you can pick them up after a refresh or later.

Conversation content is visible only to you and to workspace admins with the relevant permission. You can delete a single turn or an entire conversation at any time, and deletion is not recoverable.

For content you would rather not have retained, call the API directly instead of typing it into the playground.

Tickets and attachments

Ticket content and attachments are stored so that we can handle your request.

⚠️ Do not put anything in a ticket that you would rather we did not see. Attachments are scanned for anything resembling a credential on upload; on detection they are refused and deleted, at which point you should redact, re-upload, and rotate the exposed credential — the file may have been accessed before it was refused.

How generated artifacts are stored

Generated images and video, along with reference material you upload, are stored in publicly readable object storage.

The address contains a random identifier and is unguessable, but anyone with the address can open it without signing in.

⚠️ Do not treat this as private storage. Do not forward artifact addresses to anyone who should not see the content; where access control matters, retrieve the artifact and store it yourself.

Artifacts are cleared on a schedule, after which the address stops working. The artifact section of the log detail page says as much — download anything you need to keep.

This is also a content-responsibility matter: once you have generated something that should not be seen by others, a leaked address cannot be recalled. See the generated content section of the Acceptable Use Policy.

Retention at a glance

DataRetention
Request / response bodies of text and chat callsNot recorded
Call metadata (time, model, usage, status)Long-term, for reconciliation and usage reporting
Aggregated usage and transaction ledgerLong-term (statutory financial record requirements)
Prompts, parameters, and material references for asynchronous tasksCleared after 30 days by default; the task record is kept
Generated artifact filesCleared periodically; no specific period committed
Playground conversationsKept until you delete them
Tickets and attachmentsKept after closure; reviewed and cleared periodically
Audit records2 years
On-site search termsAggregated into daily counts, with no per-query records
Account informationFor the life of the account

Controls available to you

NeedAction
Leave no call content behindUse the API rather than the playground; text call bodies are not recorded in any case
Clear playground historyDelete a single turn or an entire conversation
Keep artifacts from staying publicRetrieve them promptly and store them yourself
Restrict requests to specific providersSet pinned providers on the account or key; see routing and failover
Avoid value-tier supplySet the supply-tier scope to "official quality only"
Delete the accountRequest it through a ticket or by email; see below

Where data is processed

Our own services and storage are located in the United States.

Upstream model providers decide their own processing locations, and we do not make a blanket statement about them. To confirm where a particular model's data is processed, consult that provider's privacy policy — the model catalog states the provider for every model.

Data flowing to upstream providers

Request content is forwarded to the provider you select or that routing lands on, and is subject to that provider's own privacy policy.

Where data flow matters, set pinned providers on the account or key to confine the candidate pool to the ones you have assessed. That constraint is intersected, and a key cannot widen what the account allows — so setting it once at the account level ensures no key beneath it can exceed it.

Deleting an account

Request account deletion through a ticket or by emailing support@amux.ai. Deletion is handled by anonymization: name, email, and avatar are cleared, and source IP addresses are erased from call records.

The transaction ledger and aggregated usage are retained under statutory financial record requirements; once processed, those records no longer point to an identifiable person.