Log retention

An hourly job prunes the request log: old inference rows, short-lived successful MCP-relay rows, longer-lived relay failures, and stale body/header text. This keeps the SQLite file bounded under high-frequency relay traffic.

The Settings page also exposes immediate request-log pruning and SQLite compaction actions. See Request logging.

Defaults

The default retention policy is:

Successful MCP relay rows are shorter-lived because relays can be high-frequency and metadata-heavy. Failed relay rows are kept longer to preserve debugging context.

Inference request-row retention has a minimum of two days, including for existing one-day settings, so rolling 24-hour usage can be compared with the preceding 24 hours. Body and header retention is independent.

Daily inference usage rollups remain available after request rows are pruned. Session IDs are not rolled up, so session breakdowns are limited to retained request rows. On startup, historical requests are backfilled into rollups one UTC day at a time; inference deletion waits for backfill to finish, while body and MCP relay cleanup can continue. See Usage.

Maintenance schedule

Request-log maintenance starts 60 seconds after process boot, then runs hourly. Each run:

• Deletes old inference rows.
• Deletes old successful MCP relay rows.
• Deletes old failed MCP relay rows.
• Clears request headers, request bodies, response headers, and response bodies from rows older than the body-retention window.
• Evicts matching entries from the in-memory recent-body cache.

Manual maintenance

Use Settings to:

• Change retention windows.
• Apply retention immediately.
• Compact the SQLite database after deletes.

Compaction runs a WAL checkpoint and VACUUM. It can reclaim disk space, but it may briefly add database I/O, so run it during a quiet period if the dashboard is handling active traffic.