Your data

Every request you send passes through two systems: the gateway, which authenticates and meters the call and forwards it, and the model provider, which writes the answer. This page describes what each of them receives, what we keep afterwards, and how to remove it.

What the proxy sees

When your client calls the gateway, the proxy reads the full request body: the prompt, the system instruction, the parameters such as model, temperature and max tokens, and any tool definitions you send. It reads the request headers, including your API key.

The key is not stored next to the request. What we keep is a key identifier, a short reference that points at the key record, never the full key. Delete the key and the identifier no longer resolves to anything you can use.

We also see the IP address and the user agent of the machine that made the call. Both are recorded with the request, because they are the first things worth checking when a client behaves differently on one network than another.

That is the whole list. The proxy does not read your database, your files or anything else on your machine. It sees what your HTTP client sends, and nothing more.

What the upstream provider sees

Once the gateway has authenticated the call, it forwards the request to the model provider you selected. The provider receives the prompt and the parameters as your application wrote them, and handles them under its own terms and privacy policy, not ours. Choosing a model also chooses whose policy applies to that request.

Providers commonly keep short-term logs for abuse detection and reliability, for periods they set. We cannot change those periods and we cannot read those logs. If a provider's retention matters for your data, read its policy before you send anything you would not want retained.

One thing we can state plainly: we do not train models on your prompts.

What we store

For each request that reaches the gateway we write a usage record. It holds the key identifier, the model, the timestamp, the input, output and cached token counts, the cost, the latency, and the status or error. It also holds the IP address, the user agent, and a tool class, which is our best guess at the client that made the call, for example Claude Code or Cline.

Three fields are optional and appear only if your client sends them: a session id, taken from the X-Session-Id header or from metadata.user_id; an end-user id, taken from the user field or from metadata.user_id; and call tags, described below. The tool class, the session id and the end-user id are kept for 90 days, and they are visible only in your own Usage views, never to another customer.

Prompt logging is separate and off by default. When a key turns it on, request and reply bodies are stored, with credentials and obvious secrets redacted, up to 64 KB per side, for 7 days. Only the account that owns the key can read them. Turning the setting off deletes the stored bodies. Requests made in chat are never logged, whatever the setting says.

When you ask us to look into a problem, we may capture the traffic involved in that specific case. A troubleshooting capture is kept for 30 days, unless it is needed longer for a legal claim.

Call tags are a small label you attach to a request so it can be grouped in your Usage views: a task label plus an optional X-Tag header. Tags are kept for 90 days. The prompt text is not part of a tag and is not stored with it.

At sign-up we run a short set of checks to keep automated account creation out. The IP address and network, a browser identifier and a device fingerprint are stored as keyed hashes rather than raw values, for up to 400 days. A hash can be compared for a match, but it does not reveal the value it came from.

To spot abuse and to help with support, we also keep behaviour counts per account, visible only to us: when chat was opened, whether a first message was sent, how long the page was in view, the error codes returned, and a category label (for example malware or jailbreak) when a request matches an abuse rule. The text of a message is read in memory to pick the label and is not stored with it.

Retention

Each kind of record has its own clock. There is no single timer for everything.

• Usage record fields: key identifier, model, token counts, cost, latency, status, IP, user agent, tool class.
• Session id and end-user id: 90 days.
• Call tags: 90 days.
• Stored prompt and reply bodies, when a key opts in: 7 days, and removed when the setting is turned off.
• Troubleshooting capture: 30 days, longer only if a legal claim needs it.
• Sign-up checks, as keyed hashes: up to 400 days.
• Behaviour counts: error codes and abuse labels 90 days, chat opens and time in view 365 days.

The binding statement is the privacy policy at /legal/privacy. This page is the plain-English version of it; where the two disagree, the policy decides.

Delete your data

You do not have to email us to have data removed. The account can delete its own data. Deleting a key removes that key and its access; turning prompt logging off deletes the bodies stored under it. If you want the account and everything attached to it gone, do that from the console and confirm the request there.

Deletion cannot bring back a key or a prompt, so take a copy of anything you need first. If you are unsure what a deletion covers, read the policy above before you start, or contact us and we will tell you which records a given action removes.