Zero prompt retention
A zero prompt retention API does not keep the prompt after the request has been served. The text goes in, the completion comes out, and the prompt is not stored as a record you or the host can read later. Refuseless states that position on the homepage: zero prompt retention. This page explains the phrase, because vendors use three similar ones for three different promises, and mixing them up is how a security review goes wrong.
Three phrases that are not synonyms
| Phrase | What it should mean | What it does not mean |
|---|---|---|
| Zero prompt retention | The prompt and, on a strict reading, the completion are not kept after the response. | It does not, by itself, describe billing records, account email, or abuse metadata. |
| No training | Your prompts are not used to update model weights. | The host can still store the text in a log. Training and storage are different. |
| Ephemeral processing | The text lives in memory only as long as the worker needs it, then is dropped. | It says nothing about a gateway, a support tool, or a debug capture in front of that worker. |
You can have all three, or only one. A host can refuse to train on your data and still keep ninety days of prompts for "quality." A host can drop the prompt and still train on something else. When you compare APIs, quote the sentence they wrote. abliteration.ai's llms.txt, dated 2026-10-01, says zero prompt retention by default. Adverserial's homepage says no GPU request logs and no training on customer prompts, and their docs say no inference logs and no chat session logs. Those are their sentences, not ours.
What Refuseless claims
Zero prompt retention. The prompt is not kept after the request is served. The API key, the account, and the token counts required to bill the call are a different matter: a usage charge cannot exist with no record that a call happened. This page does not describe disk layout, regions, or a deletion timer, because the product has not published those. Inventing them would make the promise less true, not more.
What to ask any API, including this one
- Do you store the prompt body after the response is sent?
- Do you store the completion?
- Do you train on either?
- What non-content metadata do you keep in order to bill and to investigate abuse?
- Is there a second product, such as an audit log, that keeps the text on purpose?
If your program needs a signed DPA, a region pin, or a customer-managed key, that is a procurement document, not a blog post. We have not published one here. The operational fact you can use today is the retention line above, plus the request shape on the API page.
