Skip to main content
When you turn on request-log capture for troubleshooting, you are storing prompt and response bodies — exactly the data a privacy regulation asks you to keep no longer than you need it. OrcaRouter gives you a single per-workspace dial for that: a retention window with a sane default and a hard ceiling the server enforces, so a capture you forget about ages out instead of accumulating forever. This page covers how that dial works and how it ties into erasure. For the broader evidence story, start at the Compliance overview.

​
1. Why llm log retention matters on a gateway

Request-log capture is opt-in, off until you explicitly enable it, and gated behind a recorded consent acknowledgment — because turning it on persists full prompt and response text. Once it is on, the question auditors ask is not whether you log, but how long you keep it. A 30-day default keeps a useful troubleshooting trail; a server-enforced 180-day ceiling means no client request, however tampered, can keep bodies past your compliance cap.
Retention applies to captured request logs (the opt-in prompt/response bodies). Metering and billing records, and the signed compliance reports described in Signed report, follow their own lifecycles — this page is about the captured-log clock.

​
2. The two numbers

Default: 30 days

A freshly enabled capture retains bodies for 30 days. Leave the retention field unset and every workspace inherits this.

Hard max: 180 days

The server clamps any requested retention to 180 days. Ask for more and the value is silently reduced to the cap — it is not an error, it is a ceiling.
The hard ceiling is 180 days: a value above 180 caps at 180, and a value of 0 (or unset) means inherit the default — which resolves to 30 days. The defaults and the live ceiling are readable from the public status payload so a settings panel can render the right bounds: 
GET /api/status
The response carries request_log_default_retention_days, request_log_max_retention_days, and request_log_default_enabled — the effective bounds your console reads before showing the input.

​
3. Setting retention (one concrete flow)

Retention is a workspace setting, configured from the console under Settings → Privacy. Any member can read it; changing it requires the workspace Admin role. The console drives this management route with your session (a UserAuth route — not a relay key), so you never put an sk-orca-... key in a settings call: 
PUT /api/workspaces/:id/request-log-settings
Authorization: Bearer <your console session>

{
  "request_log_enabled": true,
  "request_log_retention_days": 60
}
A few rules the server enforces on this call:
request_log_enabled is a pointer toggle. Omit it and the stored value is left untouched; send true/false to transition it. Turning capture on requires a current, non-revoked consent acknowledgment — the consent record is server-authoritative and is never read from client JSON. See Consent.
request_log_retention_days is a whole-day integer, clamped to [1, 180]. A 0 means “leave the existing value” (or inherit the system default downstream); 200 becomes 180.
There is nothing to run on a schedule. Captured bodies past the retention window are removed by the gateway; you configure the window, the gateway enforces it.
The lowest-risk posture is the obvious one: leave capture off unless you are actively troubleshooting, and when you do enable it, set the shortest retention that still covers your debugging loop. The 30-day default is already conservative.

​
4. Retention vs. erasure

Retention ages out captured logs in the ordinary course. Erasure is the on-demand path for a data-subject request (DSAR) or an account closure — and it reaches further than the log clock:
TriggerWindowThen
Captured log past retentionup to 180 dayslog removed
Account self-delete30-day gracePII scrub + cascade purge
A self-delete soft-deletes the account immediately and schedules an irreversible PII scrub for 30 days later. During that grace window the account can still be restored and its data exported; once the window closes, the scrub runs and the cascade purges request logs, guardrail matches, firewall events, and agent trace nodes tied to the subject. Right-to-erasure is therefore not a separate retention setting — it is a stronger, subject-initiated purge that supersedes the time-based window.
The 30-day deletion grace is a recovery window, not extra log retention. Data inside it is soft-deleted and exportable, but it is on a one-way path to the scrub. Plan exports before the window closes.
See Right to erasure for the full DSAR mechanics — grace, scrub, and what the cascade touches.

​
5. How this satisfies a framework

Most privacy regimes ask for two demonstrable things: a defined retention period and a working erasure path. The retention dial and the deletion cascade are exactly those two controls, and a compliance pack maps them into the framework’s evidence so a report can read their state. Install a pack and the same retention and erasure behavior is referenced in your readiness view — no separate configuration.

Install a pack

Materialize a framework’s controls; retention and erasure are part of the privacy story it expects.

Frameworks

The live catalog — GDPR, CCPA, HIPAA, and the regional privacy regimes that pin retention.

​
6. Where this fits

Right to erasure

Self-delete, the 30-day grace, the PII scrub, and the purge cascade.

Consent

The recorded acknowledgment required before request-log capture turns on.

Data residency

Where signed compliance evidence is stored and served — a separate region control from retention.

Shared responsibility

The gateway enforces the retention you set; choosing the window and the erasure cadence stays yours.
Retention on OrcaRouter is one honest dial with a default and a hard ceiling: enable capture only when you need it, keep the window short, and let the gateway age the bodies out — with erasure standing by for the moment a subject asks you to forget them entirely.