Data retention, exports, and usage accounting.

Data retention and usage

Each organization keeps completed run details for 90 days by default. An owner or admin can choose 30–365 days in Settings. A worker poll starts at most one cleanup batch per organization per hour and removes up to 25 runs whose last update is older than the chosen period. Cleanup skips unfinished runs, runs with queued or leased durable work, and runs referenced by an active recovery job. If no worker polls, cleanup waits; this is not a precise deletion deadline.

Deleting a run also removes its steps, attempts, encrypted durable input, encrypted idempotent result, and idempotency lookup. After deletion, duplicate keys for that run no longer deduplicate, and replay is unavailable. Export needed history before it expires. Audit events, operational incidents, published contracts, accounts, keys, and aggregate monthly usage remain. Incident links to expired runs may no longer resolve. Changing retention to a shorter period takes effect at the next sweep and is irreversible after deletion. No unfinished work is removed by retention.

Monthly usage is kept separately from run history, in UTC calendar months. Units are runs (accepted non-synthetic agent executions), steps (accepted non-synthetic logical tool calls, including calls blocked by a circuit), attempts (actual non-synthetic invocations), and synthetic runs (test executions). A retry or reclaimed lease adds an attempt; a deduplicated request adds nothing. Counts are incremented in the same transaction as the related record. The migration backfills counts for existing rows. These totals are for future billing and capacity planning; no prices are defined.

The Settings page shows the most recent 12 months. GET /api/console/data-lifecycle returns the same organization-scoped data; owners and admins can PUT {"retentionDays":90} with a same-origin session. The sweep audit record stores only the number of runs purged, with no payload data.