Skip to main content
The request log tells you what a request cost and which model served it. Message recording tells you what was actually said: the body Manifest sent to the provider, and the body that came back. It’s one toggle per agent.

​
What gets recorded

Recording happens per provider attempt, not per request. A request that falls back twice before succeeding produces three recordings, each with its own body pair, so you can see how the conversation was reshaped for each provider. An Auto-fix retry is its own attempt too, which is how you compare the request that failed against the patched one that worked. A request Manifest blocked itself, on a hard limit or a malformed body, has zero provider attempts and so no recording. There was no exchange to record.

​
Reading it back

Open any request in the dashboard’s Requests log. When recordings exist, the drawer has a Messages tab next to Attempts. The tab renders the exchange as a conversation, with a rail down the side listing every turn. Search the rail or filter it by role, and click any row to jump to that turn in the main pane. Assistant turns show the tool calls the model actually made, not the tool definitions your client offered it.

​
Turning it on

The toggle lives on each agent’s Settings page, under Message recording. New agents have it on. Older agents keep whatever they were set to, because only the default changed, so an agent from before the feature shipped probably needs the toggle flipped once.
Recording stores your prompts and completions. Everything else Manifest keeps is metadata (Data and telemetry covers the distinction). If an agent handles data you’d rather Manifest never hold onto, leave recording off for that agent.

​
Retention

Recordings are deleted on a schedule. The metadata row in the request log stays; only the stored body pair goes away. Self-hosted installs can override this with REQUEST_RECORDING_RETENTION_DAYS. Setting it also overrides the per-plan split, so every recording on the instance expires on the same schedule.

​
Self-hosted storage

Recordings don’t live in Postgres. They’re gzipped and written to object storage, which you pick per instance.
The bundled compose file mounts a named volume manifest_request_recordings at /data/request-recordings and points Manifest at it. Nothing to configure. The volume survives docker compose down the same way the Postgres volume does.
REQUEST_RECORDING_STORAGE defaults to auto, which picks the backend by what you’ve configured: any S3 setting present means S3, otherwise the mounted filesystem path. Set it to s3, filesystem, or disabled to decide explicitly.
Under auto, setting some S3 variables commits Manifest to S3. A bucket without a region, or one access-key half without the other, leaves recording with no working backend instead of falling back to local disk. Configure it fully or not at all.
Full variable list: Environment variables.

​
Platforms without a persistent disk

Railway, Render, Fly, Heroku, and Koyeb all give you an ephemeral filesystem, so local recordings there are wiped on every redeploy and every container restart. Point those deploys at S3-compatible storage, or accept that recordings only survive until the next deploy.