Run history

Stored inference runs: what gets recorded, the transcript viewer, and retention.

When an endpoint's run retention is enabled, chat completion requests against it are recorded as runs: the full request input (messages and inference parameters) and the full response (including streamed tool calls and reasoning). A run is stored once a request actually reaches a model server and starts producing a response — requests rejected before that point (auth failures, invalid bodies, rate limiting, or a dispatch that fails outright) do not appear in run history, so it is not an audit log of every attempt. Requests served by an external third-party provider (for example Gemini or Claude models on a multi-model endpoint) are never recorded regardless of the retention setting — no run is stored and no X-Arkor-Run-Id header is returned, so third-party-served prompts and completions never enter Arkor's transcript stores; only the aggregate Usage row is written. The endpoint detail page lists runs; clicking one opens the transcript viewer.

What is stored

• Input — the messages array and the model-input parameters (temperature, sampling params, tools, response format, reasoning settings), normalized to their internal camelCase names; max_completion_tokens is folded into the single stored maxTokens. Transport and routing fields are not part of the stored input: the selected model, stream / stream_options, and the user / attribution ids (the attribution ids are kept as run metadata instead). Run history is therefore not a byte-exact record of the request you sent.
• Output — the response. Streaming responses are stored byte-faithful to what the client received. Non-streaming responses are stored too, normalized: the JSON body is re-serialized compactly into a single stored event, so it is semantically identical but not byte-identical to the wire response.
• Metadata — status (completed, failed, or cancelled; streaming and finalizing appear transiently while a run is in flight), timestamps, and the ids used for Usage attribution.

Storage is verbatim. Arkor does not redact prompts or completions, so anything your users send (including personal data or secrets) lands in the transcript as-is. Choose retention accordingly, and prefer Don't store for endpoints handling sensitive traffic.

The transcript viewer

For each run the viewer shows:

• Input — the recorded request messages and parameters.
• Output — the assistant response reconstructed from the stream, with tool calls rendered separately.
• Reasoning — a collapsible section, present only when the model emitted reasoning content.
• Raw SSE — an on-demand toggle that loads the exact bytes of the stored stream.

Individual runs can be deleted from the viewer.

Replay over the API

Each stored run can also be replayed straight from the endpoint itself via GET /v1/chat/completions/runs/{id}. The route follows the endpoint's configured auth mode: fixed-key endpoints require an API key, open (no-auth) endpoints replay without one. See the Chat Completions API reference. The run id is returned on the original response in the X-Arkor-Run-Id header.

Retention

Retention is configured per endpoint (see Managing endpoints):

• Keep for N days — runs expire N days after the request. Expired runs disappear from lists and return 410 on replay, then are deleted by a background sweeper.
• Unlimited — runs are kept until you delete them or the endpoint.
• Don't store — nothing is recorded and no X-Arkor-Run-Id header is returned.

Retention changes apply to future requests only. Switching an endpoint to Don't store stops new recordings but does not purge what was already stored: existing runs stay listed and replayable until their original expiry or manual deletion. To clear prior history, delete the runs (or the endpoint — deleting an endpoint deletes its stored runs).