Payload Sampling
Control what percentage of prompt and response payloads are stored. Available on the Growth plan.
Guardrails always run on every request regardless of the sampling rate — only payload storage is affected. A blocked request is still blocked even if its payload is not stored.
What sampling affects
| Always stored | Affected by sampling |
|---|---|
| Event type, timestamp, environment | Encrypted prompt text |
| Model, provider, request ID | Encrypted response text |
| Token usage and cost | Raw message payload |
| Decision (allow / warn / block) | |
| Policy violations |
How it works
The sampling rate is a percentage (1–100). A value of 100 stores every payload (default).
A value of 10 stores roughly 1 in 10 request/response pairs.
The sampling decision is made once per ai.request event.
If a request is sampled out, its corresponding ai.response is also sampled out —
the pair is always consistent.
Sampled-out events appear in the event list and analytics normally but show no payload in the detail view.
Configuration
Go to App Settings → General → Request sampling and enter a value between 1 and 100. Changes take effect immediately for new requests.
When to use sampling
- High-volume apps — storing every prompt is expensive or unnecessary at scale.
- Cost-sensitive tiers — reduce storage growth without losing audit coverage.
- Privacy-first deployments — set to
1to retain cost and decision records without persisting raw prompts.
Caveats
- Sampled-out payloads cannot be recovered retroactively.
- Cost and token analytics are unaffected — usage data is always stored.
- Sampling requires the Growth plan. On other plans, all payloads are stored.