Plans, quotas and retention
What each plan includes, what happens above the trace allowance, and how long runs are kept.
On this page
Two limits shape day-to-day use: how many traces a month your workspace records, and how long they are kept. Everything else is a capability switch.
What each plan includes
Starter
- Traces per month
- 10,000
- Projects
- 3
- Trace retention
- 7 days
- Dashboard
- Yes
- Cost analytics
- Totals only
- Model, tool and span analytics
- —
- Sessions
- Yes
- Trace search and filters
- Yes
- Project API keys and personal tokens
- Yes
Pro
- Traces per month
- Unlimited (metered)
- Projects
- Unlimited
- Trace retention
- 90 days
- Dashboard
- Yes
- Cost analytics
- Full breakdowns
- Model, tool and span analytics
- Yes
- Sessions
- Yes
- Trace search and filters
- Yes
- Project API keys and personal tokens
- Yes
Enterprise
- Traces per month
- Unlimited
- Projects
- Unlimited
- Trace retention
- Unlimited
- Dashboard
- Yes
- Cost analytics
- Full breakdowns
- Model, tool and span analytics
- Yes
- Sessions
- Yes
- Trace search and filters
- Yes
- Project API keys and personal tokens
- Yes
Plan changes and payments are not available in the app yet; a workspace's plan is configured for it. The same comparison, with what each plan costs, is on the pricing page.
The trace allowance
The Free plan records 10,000 traces per calendar month, counted in UTC. Pro and Enterprise are unlimited; Pro is metered.
What counts:
- A trace counts once, when it is first finalised — including runs that end as stale cancellations.
- Development traffic does not count. Nor do sample projects.
- Staging, production and any other environment do count.
Settings → Plan & usage shows the current month against the allowance and explains the policy. A meter appears in the sidebar at 50%, and the workspace owner is emailed at 80% and 100% — once each, honouring usage email preferences, even if you jump straight past both.
Above the allowance
Nothing breaks, and nothing is silently lost.
Sampling
Past the allowance, the ingest worker samples non-failed traces deterministically — the decision is a hash of the trace id, so it is stable across workers, retries and replays. Failed traces are never sampled out. A sampled trace keeps its counters and metrics; it loses its span detail.
| Usage against the allowance | Non-failed traces kept |
|---|---|
| Up to 100% | All |
| 100–150% | 50% |
| 150–200% | 25% |
| Above 200% | 10% |
The POST /ingest response also carries an advisory sampling rate. The SDK
applies it to new runs as head sampling, logs one warning, and returns to your
configured rate as soon as the hint stops.
Hard stop at three times the allowance
From 3× the allowance, batches from every key in the project are rejected with
429 quota_exceeded and a Retry-After, until the UTC month resets. The SDK
retries with backoff and eventually drops those spans.
Your application is unaffected either way: export happens out of band, and a rejected batch never reaches your request path.
Retention
| What | Free | Pro | Enterprise |
|---|---|---|---|
| Runs and their span detail | 7 days | 90 days | No plan expiry |
| Raw ingest payloads | 24 hours | 24 hours | 24 hours |
| Aggregates and usage counters | Kept | Kept | Kept |
Retention runs nightly at 02:00 UTC over finalised runs. Expired trace identities prevent retries and late spans from recreating deleted detail. Prompt version text is cleared once its last call leaves the plan window.
Because aggregates outlive runs, lifetime counters keep telling the truth about volume, failures and cost after the runs behind them are gone. Pages that mix the two say which is which — the difference between "you had 400 runs" and "we can still show you 40 of them" is never hidden.
Per-project retention controls are not built yet.
Query windows
Separate from retention, and a frequent surprise:
| Query | Window |
|---|---|
| Aggregate-backed metrics: dashboard, costs, model and tool comparisons | Up to 90 days |
| Span detail: Spans explorer, recent model and tool calls, expensive traces | Latest 24 hours in range |
Span-detail queries read raw spans rather than aggregates, so they are bounded to the latest 24 hours of whatever range you selected — and, of course, to what retention still holds.
Other limits
| Limit | Value |
|---|---|
| Projects (Free) | 3 active; samples excluded |
| Members (Free) | 1; seats count members plus open invitations |
| Ingest batch | 1–1,000 spans, 5 MB decompressed |
| SDK queue | 10 MB, batches of 100 spans every two seconds |
| Gateway | 600 requests per minute per key, 8 MB request body |
| SDK scores per run | 100 |
| Tools per log event | 100 |
| Trace detail | First 1,000 span summaries, then paging |
| Share link lifetime | 1, 7 or 30 days |
| Saved views | 100 per creator per project; name up to 80 characters |
| Span comments | 4,000 characters; 100 per author per span |
| Open invitations | 50 per workspace; a link lasts 7 days |
Plan-gated capabilities
When a plan does not include a capability, the API answers
403 feature_not_available and the UI shows one explanation instead of an empty
page. On the Free plan that covers the full dashboard cards, cost breakdowns,
Models, Tools, Spans, Prompts, end-user analytics, span comments, share links
and inviting teammates.
Reading the team list stays open to every role on every plan, and role changes and removals stay available after a downgrade, so an oversized workspace can be brought back within its plan.
Not built yet
Budgets, alerting and alert channels, outbound webhooks, data export, service tokens, SSO, SCIM and audit logs appear in the plan matrix as intent. None of them exists in the product today, and no endpoint answers for them.
Self-hosting is a separate case: the software runs on your own infrastructure today — the SDK, the CLI and these docs all take an API origin, and a self-hosted dashboard serves its own matching SDK and CLI archives. What does not exist yet is a packaged, supported distribution with its own installation guide. Treat it as unsupported until then.