Turn on request logging for your workspace

By default Tokios stores no request or response bodies. The request log records token counts, latency, status, and a correlation id for each call — enough to see usage, not enough to see what was asked. Request logging changes that for 1 workspace at a time: when a workspace admin turns it on, Tokios also keeps the request body of each API call so you can open it later. Use it to debug what a coding agent actually sent, to review the system prompt and tool definitions a client attaches, or to check a teammate’s report of a bad answer. It stays off until you turn it on.

​

What is stored

For each request to /v1/chat/completions, /v1/messages, or /v1/responses that reaches your model, Tokios stores:

• The request body as your client sent it, in the client’s own dialect (OpenAI Chat Completions, Anthropic Messages, or OpenAI Responses), before Tokios translates it for your backend.
• The public model name, the API key that sent it, the endpoint, the final HTTP status, and the correlation id (cid) that also appears in the request log.

Before storing a body, Tokios sanitizes it: Tokios never stores response bodies. It also never stores requests turned away at the gateway for a bad key, a rate limit, or an unknown model, or requests made from the dashboard’s Playground and health check.

​

Turn it on

​

Who can read stored prompts

• Workspace admins can read every stored prompt in the workspace.
• Members can read only the prompts sent with API keys they own.
• People you share a key with see a notice on their usage page that request logging is on. They can read the prompts sent with their own key there only if you allow it for that key — see Let a key holder read their own prompts.
• Tokios cannot read stored prompts through the product. They are encrypted at rest, and Tokios’s own tools show only that logging is on and how much is stored.

​

Let a key holder read their own prompts

The usage page at tokios.com/usage authenticates with the API key itself, so a key that can read prompts turns a leaked key into a leak of 7 days of prompts, not just usage counts. Prompt reads are therefore off for every key until you allow them, 1 key at a time.

• When sharing a key: in the Share a key by email dialog, tick Let them read their stored prompts there too under the usage-visibility option.
• For an existing key: on the Keys tab, edit the key, tick Let whoever holds this key read its stored prompts there too, and save.

The holder can then open a request on their usage page and read it under Prompt — only requests sent with that key, never another key’s. Untick the option to withdraw access; the next read is refused immediately. Reads also need Let them check this key’s usage to stay on, since they happen on that page.

​

Retention and deletion

• Each stored prompt is deleted 7 days after the request.
• A workspace can hold about 1 GB of stored prompts. Past that, the oldest are deleted first.
• Turning request logging off stops storing new requests at once. Prompts already stored remain until they expire.
• To remove everything now, click Delete all stored prompts in Settings. This cannot be undone.

​

When you do not need it

If you want full traces with latencies and scores, or you need to keep prompts longer than 7 days, use an observability tool instead — see Trace your local model calls with Langfuse. Request logging is the low-setup option for reading what was sent.