LiteLLM spend log retention and prompt storage

The cleanup job deletes spend log rows once they are older than the period set in maximum_spend_logs_retention_period under general_settings. If store_prompts_in_spend_logs is enabled, those rows can hold request and response content, so expiry also ends the stored prompt exposure for those records. Confirm with the vendor exactly which columns and related records the job removes, whether any data is kept for billing or reporting, and how the job interacts with database backups and replicas, which it does not manage. The docs state that retention and cleanup are open source and need no Enterprise license, so the decision sits with your team and your database operators.

The optional cleanup interval and cron schedule control when the job runs, and batch limits cap how many rows each pass removes. Together they spread deletes over time so the job does not hold long locks or generate a large write burst on a table that receives a write for every request. Choose the schedule with your DBA, ideally in a window with lower traffic. Then test on a copy of production-scale data and measure run duration, lock waits, replication lag and whether each run finishes before the next one starts. Do not carry values over from another environment without measuring them against your own write rate.

When more than one proxy instance runs, each instance can trigger the cleanup on its own schedule. Without coordination, instances can attempt the same deletes, contend for locks or interfere with each other's batches. The docs say Redis is needed for cleanup only when multiple instances require distributed locking. Confirm with the vendor how the lock is acquired and released, what happens if the lock holder fails partway through a batch, and how the cleanup behaves if Redis is unavailable. Also plan Redis as a dependency for this job, since the production guide already requires Redis 7.0 or newer once more than one instance runs.

The upgrade guide says the LiteLLM_SpendLogs table gains roughly 3 billion rows a year at 100 requests per second. A retention period keeps that table from growing forever, but the table still takes heavy inserts and deletes at steady state. At high volume, the guide recommends table partitioning. Partitioning is a database design decision, not a switch in the proxy configuration. Your PostgreSQL team must decide the partition key and interval, how partitions are created and dropped, how the cleanup job's delete path fits, the index strategy, backup and restore impact, and how future LiteLLM upgrades handle the partitioned table. Plan it, then test it on realistic data before go-live.

Before go-live, put specific questions to the vendor and your DBA. For the vendor: which data the cleanup removes when prompt storage is on, whether partitioned tables are supported in the release you will run, how the job behaves with multiple instances and Redis failures, and how upgrades treat the table. For the DBA: the expected row growth at your actual request rate, the partition interval, the index plan, autovacuum settings for a high-churn table, the effect of deletes on replica lag, and whether a restore from backup has been tested with the retained data. Record the answers in the design so the retention period is an agreed control, not a default.

Deleting rows from the LiteLLM_SpendLogs table removes only the live copy of what the gateway recorded. If store_prompts_in_spend_logs was enabled at any point, prompt and response content can also sit in database backups, streaming replicas, point-in-time recovery archives, log shipping pipelines, observability tools that received the same callback data, and any logging integration the gateway forwards to. Each of these has its own schedule and its own owner, and none of them is cleared by the cleanup job. Before you rely on maximum_spend_logs_retention_period as a privacy control, list every place the data could have gone.

Build a copy inventory with one row per location. For each, record the system, the team that owns it, the data it holds (prompt text, response text, metadata only), the retention period that applies, and where that period is configured. Map the spend log window to each row. A copy should not be kept longer than the spend log policy allows unless someone has documented and approved the exception. Ask the PostgreSQL database owner for the actual backup retention, replica lag, and point-in-time recovery window. Ask the owners of each callback destination the same questions. Do not assume any of these values from the gateway settings alone.

Test the deletion path end to end in a non-production environment. Send a synthetic request containing a unique marker string with prompt storage enabled, then wait past the retention window and let the cleanup job run. Confirm the marker is gone from the live table, the replica, and each observability destination. Then restore a backup taken before the window and a point-in-time recovery to a time after the window, and search both for the marker. The time between the deletion and the point where the marker disappears from backups is the effective exposure window. Compare it with the window your policy states, and record the test date and the results.

Two settings need attention during this review. The Admin UI can change store_prompts_in_spend_logs and the retention period without a restart, and UI values take precedence over the config file, so audit both sources and the running state. Also check whether the callback payloads sent to other systems include prompt content regardless of the spend log setting. At high request volume, the spend log table grows quickly, so the cleanup batch limits also affect how large the backups become. Assign one owner for the inventory, and review it whenever the storage setting, the backup schedule, or a callback destination changes.