> ## Documentation Index
> Fetch the complete documentation index at: https://docs.compute.prentis.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Data handling

> What a request leaves behind, and what is never written down.

This page describes what the platform records about a call. It is deliberately specific:
everything below is a property of how the system is built, and the boundaries are stated
as plainly as the guarantees.

## Prompts and completions are not stored

A call leaves behind a **request record**, and that record holds metadata only:

| Kept                                                   | Not kept                                        |
| ------------------------------------------------------ | ----------------------------------------------- |
| The request id, and when it arrived, started and ended | The prompt, in any form                         |
| The account, the API key used, the principal           | The completion, in any form                     |
| The model you asked for, as you wrote it               | Message content, system prompts, tool arguments |
| Token counts, status, error code, whether it streamed  | Images or other media you sent                  |
| Whether it was served by a primary or fallback         |                                                 |

Writing a prompt, a completion, or an API key in plaintext to a log is **prohibited in
this codebase and enforced by a linter**, not left to reviewer attention. That is the
mechanism behind the right-hand column.

<Note>
  The consequence worth planning around: we cannot show you the text of an old call,
  because we do not have it. If you need prompt-level history, keep it on your side. What
  we *can* reconstruct from a request id is the route, the timing, the tokens and the
  outcome.
</Note>

## API keys

Created in the console, shown **once**, stored as a hash plus the first eight characters
for display. There is no screen and no support process that can recover one — losing a key
means revoking it and creating another.

Revocation takes effect for new requests within seconds. Requests already accepted are not
cancelled by it, so treat anything already in flight as served.

## Media you send

An [image](/vision) is fetched and normalised so the model can read it. Where a model
cannot accept it, the request is rejected **before** the fetch — a mistaken request does
not cause a transfer or a write.

## What this page does not claim

Being useful here means being clear about the edges:

* **It says nothing about upstream retention.** Your request is served by compute we route
  to, and what any given provider retains is governed by our agreement with them, not by
  this page. If your use has a retention requirement, raise it with us and we will answer
  for your account and your models specifically rather than in general.
* **It states no retention period** for the request records above.
* **It is not a compliance statement.** Contractual data-protection terms are handled
  through your organization's agreement — which is also what `AGREEMENT_REQUIRED` is
  asking for when it appears.

## Next

<CardGroup cols={2}>
  <Card title="Authentication" icon="lock" href="/authentication">
    How keys are issued, scoped and revoked.
  </Card>

  <Card title="Routing and providers" icon="route" href="/routing-and-providers">
    What the response says about who served the call.
  </Card>
</CardGroup>