Trace content and retention

A trace represents one application request or agent execution. Its spans represent individual operations, such as model calls, tools, or retrieval. An optional session ID groups related executions, such as a multi-turn conversation.

Structure an execution

Use an execution span as the root, and associate child spans with the same trace and root span IDs. Give each child its own span ID and the ID of its parent. Preserve that context when work crosses services.

Each ingestion event is a complete snapshot of a span. Send a running snapshot when work starts and a later revision with the final status when it ends. Missing final events can leave a trace incomplete; late events can complete it. The ingestion reference defines the fields and revision rules.

Choose what content to send

The first-trace example sends operation metadata without prompts or outputs. In a native HTTP integration, you choose whether to include content fields. Redact sensitive values before sending them.

Everyone in the organization can read captured content. Ingestion keys can submit traces but cannot read them or manage organization resources. Keep keys on your application's server; administrators can revoke them.

Interpret usage and cost

Token usage and cost are shown when available. A missing price does not mean a call was free. Cost metadata distinguishes provider-reported amounts from catalog estimates; preserve that distinction when exporting data from your application.

Retention and access

Traces are retained for 14 days from first acceptance. Administrators can delete them earlier. Sending later span revisions does not restart that retention period.

Billing read-only restrictions stop new ingestion. Existing traces remain readable, and administrators can still revoke keys or delete trace data.