Trust & data

What crosses our servers, and what we keep

Selan is a proxy, so it receives the full request body: your prompts, the file contents Claude Code attaches, all of it. It streams through us to the provider. No request body is logged or stored anywhere. What we keep is metadata about the call, listed in full below. There is one exception, and it is ours to name: when the provider rejects a request, up to 2 KB of the provider's reply is written to our request log.

Secret scanning off by default · turned on per company

The key is in the body, so it goes where the body goes, to the provider. The key is replaced before the body leaves Warsaw. The request still goes, and the developer sees nothing.

AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEX AWS_SECRET_ACCESS_KEY=[REDACTED: aws-access-token]

What one request does. The wide lane is the body and it does not terminate with us; the narrow one is the metadata, and the ledger it ends in is the only thing we write. The four accounts on the right are the ones your company connects: two you sign in to, two you bring a key for, and the key is the difference in who gets billed. Scanning holds the body long enough to read it, which is the latency, and is why it is off until you turn it on. How it works, in detail →

One request, more than one account

The picture above draws one body going to one account. That is the usual case and not the only one. When an account refuses a request, because its credential was rejected, or it is rate limited, or the provider itself is overloaded, Selan takes a different credential and sends the same body again. That second account can be a different company of yours, a different vendor, and a different region: a Vertex retry can land in a US or a global tier rather than an EU one. It can also happen after the answer has begun, in which case the resend is spliced into the stream the developer is already reading.

This is the failover the rest of the site sells as work carrying on through an outage, and it is the same mechanism. It is worth saying in the same breath: if the set of places your requests may go matters to you, it is the set of accounts you connected, not the one that served the first attempt. Every request records which credential served it and whether it failed over.

How long a sign-in lasts

A selan login session is good for thirty days of not being used, and every request resets that clock. So a developer who works every week is not asked to sign in again, and a laptop that goes quiet stops working within the month. Revoking a member ends their sessions immediately, and takes every access token they created with it.

What we store

input tokens
output tokens
cache-read tokens
cache-write tokens
model asked for
model served
cost, in nano-dollars
user email
company
session id
request path
upstream status
user agent
repository name
rate-limit headroom
whether it failed over
time we received it

The repository name is the one that may surprise you: your CLI reports it so spend can be grouped by project, and it is the name only, never a path, never the contents. Secret detections add the rule that fired, how many distinct matches it found, and a SHA-256 hash of each match truncated to twelve hex characters: enough to notice the same secret twice, not enough to reconstruct it.

What we never store

prompt text
your source code
request bodies, anywhere

The meter that counts tokens is a stream transform: it forwards each chunk before it parses a copy, so there is no point at which a whole body exists to be saved. Nothing about a call's content reaches the usage record.

The exception, stated exactly: on a reply that is not a success (and not an authentication failure, which is stripped) the first 2 KB of the provider's own response is written to our request log, so that we can tell you why a call failed. On a malformed request the provider's message can quote the part of your request it objected to. That is response content, in a log we can read, and a page that said never would be wrong.

The 2 KB is the cap on a reply that failed before it started. A reply that fails during a stream is different: there the provider's error message is written down whole, and the same providers quote your request in those messages too. Beside it we write the shape of what we had sent, for the last forty items of the conversation: how many there were, what kind each one was, and how many bytes. That is a description of your request in our log. It holds no words from it.