Data handling

The exchange does not store the text of your requests or answers. It stores a prompt and its inputs only when you save them in a workload. This page lists what it stores, where text is held for a short time, and who can see it.

Keep a request private

To tell providers not to keep your prompt, set exchange.privacy.retention to none. The exchange then offers the request only to providers whose offers promise not to retain it.

{
  "model": "gpt-oss-120b",
  "messages": [{ "role": "user", "content": "Summarize this contract." }],
  "exchange": { "privacy": { "retention": "none" } }
}

A client that cannot send the exchange block can send the header x-liquid-retention: none. To set the rule for a whole workspace, choose Zero data retention only in a guardrail.

A provider makes the none promise itself, and the exchange does not check it. For a promise that the exchange checked, require the zero_retention claim as well:

{
  "exchange": {
    "privacy": {
      "retention": "none",
      "requirements": { "require": ["zero_retention", "no_training"], "checked_only": true }
    }
  }
}

See Provider claims for what "checked" means.

What the exchange stores

For each job, the exchange stores the facts that it needs to charge you and to show you why it chose an offer. It does not store the prompt or the answer.

Record	What it holds	How long
Job	The job id, workspace, API key, model name, status, cost tag and times. For the first turn of a chat, hashes of the system messages, the answer format and the settings.	No deletion date.
Decision	The rules that applied, the offers that it ranked, the reason for each exclusion, the price cap, and hashes of the prompt start.	No deletion date.
Receipt	Token counts, price cap, charges, timing, the claims of the provider at award time, and the name of the program that sent the job.	No deletion date.
Content finding	The job id, API key, detector name, action and number of matches. Never the matched text.	See the note below.
Idempotency key	The `idempotency-key` that you sent, and a hash of the request body.	30 days.
Key address	The IP addresses that used an API key. The API keys page shows the three most recent.	30 days.
Audit log	Who issued or revoked a key, changed a member, or changed a guardrail. See Audit log.	No deletion date.
Workload	The name, model, messages, message template, settings and answer format of each version of a workload that you save. The input and the expected answer of each case of the workload. The answer of each take of a run, which the exchange keeps to score it again. A job stores only the name of the version.	Until you delete the workload, or until a closed workspace is purged.

A project can also hold prompts. See Project prompts.

A hash of the prompt start does not give back the text. If a job fails at the provider, the receipt keeps the error message of the provider.

The exchange does not state a deletion date for content findings. The Guardrails page shows only the last 7 days.

Where text is held for a short time

Place	What it holds	How long	How to avoid it
Response cache	The whole answer to one request, for the API key that sent it.	The TTL that you set, from 1 to 86400 seconds. The default is 300.	Do not turn the cache on. It is off unless you ask for it.
Provider	The request that it runs.	Set by the provider. See its claims.	Send `exchange.privacy.retention: "none"`.
Auto classifier	The system prompt and your messages, for a request that uses Auto.	Set by the classifier vendor. The exchange does not control it.	Send `exchange.privacy.retention: "none"`. Auto then ranks without the classifier.
Your browser	The chats that you hold on the Chat page of the console.	Until you clear the browser storage. The exchange does not store them.	Use the API instead of the Chat page.

Response cache

The cache is in the memory of the router. It also writes to a shared store, if the exchange runs one, but only for a request with exchange.privacy.retention: "allowed".
A restart empties the memory.
The cache drops the oldest entries when it is full. It does not store an answer larger than 4 MiB.
Send x-liquid-cache-clear: true to delete an entry.

See Response caching.

Prompt caching

Prompt caching can keep the start of a prompt at the upstream of the provider, so that a repeat request costs less. Set exchange.cache.mode to off to send no cache breakpoints and no cache key. See Prompt caching.

The responses endpoint

The /v1/responses endpoint stores nothing. It ignores store and refuses previous_response_id, conversation and background: true.

Who can see what

The winning provider sees the request that it runs. The request has no workspace name, API key or email address. A provider that does not win never sees the prompt.
A provider that served a job can read the receipt of that job. The receipt does not show your identity, your budget or the competing offers.
Your workspace can read its receipts and decisions: members in the console, and API keys with the read scope or higher.
Exchange operators can read every receipt and decision. These records hold no prompt text.
The classifier vendor sees the text of an Auto request, as the table above says.

Retention policy

exchange.privacy.retention is a data rule on each request. It has two values.

Value	Effect
`none`	Only offers that promise not to retain the request can compete.
`allowed`	Any offer can compete, also an offer that promises `none`. Providers can keep the request.

If you set nothing, the exchange treats the request as none. The exception is the Auto classifier: it reads your messages unless you set none yourself.

If no offer meets the rule, the receipt names the reason retention_policy for each excluded offer. A guardrail or a preset on your key can make the rule stricter, but not weaker.

Reference

Content rules

A guardrail can find personal data, secrets and prompt injections in a request. A match stores the detector name and a count. It never stores the matched text. A blocked request is not charged.

Logs

The router writes log lines about each prompt. A line holds the job id, counts of messages and tokens, message roles, and hashes. It does not hold the text.

Videos

A provider keeps the file of a video job. The exchange does not store the file. It fetches the file from the provider when you download it.

Project prompts

A project can show the prompts that built it. This is the one case where the exchange keeps prompts of a project, and only if you ask for it.

liquid record --prompts shows a notice. You must type yes. A script or a coding agent cannot give consent.
The CLI queues the prompts that you type on your computer. It does not collect answers, tool output, files, file names, system prompts or keys.
The CLI also counts, for each prompt, the requests, the tool calls, the seconds of work and the tool name. It never keeps a tool result. A public page says that your CLI reported these counts.
The exchange adds facts from the receipt of each job: the model that served it, the tokens, the charge and the times. The switches of the project apply to a public page.
liquid record review shows each prompt. You keep it, drop it, redact it, or mark it public. The CLI flags text that looks like a secret.
liquid record publish shows what it will send, and sends it only after you type yes.
The exchange stores each prompt encrypted with AES-256-GCM, with a key made for that one row. A copy of the database holds no readable prompt.
A prompt is private by default. You and the operators who review the project can read it. A visitor reads it only if you marked it public and the project is on show.
You can delete one prompt, or delete all of them and withdraw consent, on the project page. The exchange also deletes them with the project. An owner or admin can delete a draft or withdrawn project on its page. Withdraw a project first if it is under review or on show.
The exchange keeps a prompt until you delete it or delete the project.
A prompt can hold a secret. Read each one before you keep it.