Data storage
Storage is off by default. With it off, a request's prompt and response exist while it runs and are gone when it finishes. This page is what is kept in every state, for how long, and every control you have over it.
What is kept
| Data | Storage off | Storage on | Control |
|---|---|---|---|
| Prompt and response of a request | Kept in memory while the request runs, then discarded. | Kept for your storage period, up to 30 days, as the stored result and, when logging is on, the request log. | Settings, per account. store: false or retention_days on a request keeps less. |
| The result of a detached request | Never stored; the result URL answers 410 once the order finishes. | Kept for the storage period. Read as often as you like until it expires. | As above, plus DELETE /v1/orders/{id}/result. |
| The result a replay returns | A replay after completion answers 410. | The stored result, for the storage period. | As above. |
| Batch input file | Kept at least a day after upload. | Kept for the storage period after upload. | Settings. The expiry is fixed when the file is written. |
| Batch output and error files | Kept at least 1 day after the batch completes, then deleted. | Kept for the storage period after the batch completes. | Settings. x_retention.output_expires_at on the batch is the instant. |
| The order row and usage record | Kept: id, model, token counts, the level at execution, the charge, timestamps and status. This is the billing record. | The same. | Account deletion. |
Nothing sent to the API is used to train anything. The Data Policy is the document behind this page; where the two differ, the policy governs.
The account setting
On Settings you choose what to keep (nothing, results, or results and request logs) and for how many days, up to 30 days. The setting is read at the moment a request finishes, so turning storage off while a request is queued means its result is never stored, and lowering the period shortens data already stored.
Stored data is capped at 100 GB per account. Past it, the oldest stored bodies are deleted to make room; nothing is refused.
| Field on GET /v1/limits | Meaning |
|---|---|
| retention_days_max | The longest storage period you can set. |
| stored_bytes_per_account | The cap on stored bodies. |
| batch.min_retention_days | The floor under batch files. |
| payload_logging_available | Whether request logs can be kept at all on this deployment. |
Per-request controls
Two fields on any chat or completion request, and on any batch line. Both can only keep less than the account setting.
| Field | Effect |
|---|---|
| store: false | Nothing durable for this request: no result, no request log. The order row and its charge remain. |
| retention_days: N | Keep this request's data for N days, clamped down to the account setting. 0 is the same as store: false. |
{"model": "...", "messages": [...], "max_price": 0.10, "store": false}A detached 202 reports what it did: result_stored and result_retention_days, plus a warning when nothing is kept. GET /v1/orders?include=storage reports result_stored and log_stored per order afterwards.
Deleting early
One result
DELETE /v1/orders/{id}/result removes a stored body ahead of the period. It is refused while the body is still being written, and while the order is a line of a batch that is still running.
Everything
Settings has a purge that deletes every stored body on the account at once. Deleting the account, also in Settings, removes what it holds; the Data Policy says what survives and for how long.
Batch output is the one thing that cannot be deleted below its floor: the file is kept at least 1 day whatever the setting, and the completion email says when it goes.