What every trace stores

Every request writes one trace row: which model was requested and which actually served it, the routing reason and predicted difficulty/task type, token counts, cost breakdown (provider cost vs. our fee), routing and upstream latency, fallback path, cache hit/miss, and status. This is what backs /logs and /usage, visible to your own account.

Your prompts and outputs are stored too

Traces keep a copy of your request content. For chat requests that is the full message array and the model's reply (size-bounded: a very large request has long messages truncated). For image, video, audio and other media requests it is the request parameters you sent, including the prompt and reference-file URLs, with very long values truncated. The Prompt and Completion views in /logs read from this. It is visible to your own account and to our staff for support, billing and safety review.

Separately, the prefix_hash field is a one-way SHA-256 hash of your multi-turn prefix, used only for cache/sticky-routing analytics. It can't be reversed back into your text.

How long things are kept

• Trace rows (metadata plus the prompt, reply and request parameters above): kept while your account is active. There is no automatic deletion schedule yet; email contact@zeus.rocks to have them deleted.
• Generated images and videos we host: deleted 30 days after generation, and the link we return stops working at the same time. You can delete them sooner, see Data retention.
• Audio on /v1/audio/* (speech-to-text input, text-to-speech, music and sound-effect output): kept 30 days for debugging, then deleted. Send "store": false to keep it 24 hours instead (never sooner).
• Image- and video-request input references: kept 30 days for debugging, then deleted. store: false applies to generated outputs only, not to these.
• Reference files uploaded for one generation call: the uploaded file is deleted after 30 minutes. When you use it in an image or video request, the request's own debugging copy (above) is kept 30 days.
• Assets you save (Studio uploads, elements, voices), review attachments and community posts: kept until you delete them or ask us to delete your account.

Every lifetime in one place, with the delete and expiry controls: Data retention. The full policy is on the Privacy Policy page.

Deleting generated outputs

Every finished image and video is copied into our storage so we can hand you a stable link. You control how long that copy lives (examples and every status code are on Data retention):

• Delete a video now: DELETE /v1/videos/{id} permanently removes the stored file and the job then answers 404. It returns 409 while the video is still rendering, and 403 (delete_not_allowed_yet) during the first 24 hours after the video was generated. It needs a key with the video scope.
• Short lifetime per request: send "store": false to POST /v1/videos or POST /v1/images and the output is deleted 24 hours after the job completes, or set "output_ttl_secs" (24 hours to 30 days; a shorter value is raised to 24 hours, because a video can't be deleted sooner). The finished job reports output_expires_at, and after expiry it answers 410. A result must be stored briefly so we can deliver it, so store: false means a short lifetime, not never stored. The timer starts when completion is first observed, either by your poll or our background check.
• Bulk delete: in the request log, tick the image or video rows and choose Delete outputs. Images and videos generated in the last 24 hours are skipped.

Deleting removes the stored file and makes its link stop working. It does not remove the request-log entry (prompt, settings, cost), which we keep for billing; email contact@zeus.rocks to have that erased. We have no delete call to the model provider that generated the output, so any copy that provider holds follows its own terms. Links already issued can be opened by anyone who has them until the file is deleted, so treat them as secrets.

Attribution fields are the exception

If you send app-attribution headers or the user field, those exact strings (your app name, referrer, end-user id) are stored as given, since that's the point of sending them — don't put anything in them you wouldn't want stored plainly.

The response cache

The response cache is a separate, opt-in store: it holds the full request/response body only for that entry, is always namespaced to your own org (never shared across tenants), skips tool/function-calling requests entirely, and expires on a TTL (default 5 minutes, capped at 24 hours). If you never send the opt-in header, none of this applies to you.

What the upstream provider sees

Your prompt is, of course, sent to whichever provider serves the request — that's inherent to getting a completion back. What that provider retains is governed by their own terms, not ours; the periods above apply only to the copies we hold.