Logs & conversations
What is recorded for every request, how conversation history differs from a request log, and how long either is kept.
This page answers two questions that turn out to be the same one: how to investigate a request that went wrong, and what Salyro keeps of the data you send through it.
What you can see, and what you cannot
Your gateway keeps two things you can read: a request log, which is one row per request with the facts about it, and conversation history, which is the prompt and the response themselves. Both are yours, both are in the dashboard, and the rest of this page is about them.
Salyro also keeps operational records of its own — the measurements it needs to run the service, such as system errors and response times. You do not see those, they are not where your requests are recorded, and they carry no prompt, no response and no credential: that content is removed before an operational record is written, so what leaves Salyro's own systems cannot contain yours.
What a request log records
One row per request that went through a gateway:
| Field | What it holds |
|---|---|
| Time | When the request was made |
| Gateway | The gateway that served it |
| Provider | The provider the request went to |
| Model | The model named in the request |
| Tokens | Input and output token counts |
| Cost | The cost computed from those tokens |
| Status | Whether it succeeded, and how it failed if not |
| Latency | How long it took |
This is the view to filter when something is not behaving — by gateway, provider, model, status or time range — and it is the starting point for Errors and for Usage & costs, both of which are derived from the same requests.
Conversations are a separate record
A request log row describes a request. Conversation history holds the content of it: the prompt and the response themselves.
Reach for them for different reasons. The log is how you find a request; the conversation is how you see what the model was actually asked and what it actually said — which is what a quality investigation needs and what a row of figures cannot give you.
Conversations are grouped by the correlation id your own code sends. Requests sent without one appear as conversations of a single request.
A new request takes a moment to appear
Your record is written just after the response reaches you, rather than as part of it. Two things follow:
- Recording never slows a request down, and a problem writing a record never turns a successful request into a failed one.
- A very recent request may take a few seconds to appear. If you are reading the log while something is going wrong rather than afterwards, this is the difference between "not recorded" and "not recorded yet". Both list screens have a Refresh control, and they check for new activity on their own while you are looking at them.
How long records are kept
Salyro does not delete request logs or conversations on a schedule. There is no automatic expiry, and nothing removes a record because it has reached an age.
There is also no published retention schedule, so this is a description of how the product behaves today rather than a commitment about how long anything will be held. Salyro is in active development and this may change; if a retention policy is introduced it will be documented here before it takes effect.
What is bounded is a single view. Logs, conversations and usage each read one time range at a time, at most 30 days wide. Older records are still there — you reach them by moving the range further back rather than by widening it.
Isolation
Logs and conversations belong to the gateway that produced them, like every other resource a gateway owns. You read a gateway's records inside that gateway, and one gateway's traffic never appears in another's view.
That is the practical benefit of splitting traffic across gateways — see Gateways.