Skip to main content
Use Cases
  • Viewing all turns of a multi-turn conversation as a single trace in observability.
  • Debugging agent workflows by inspecting the full request sequence end-to-end.
  • Organizing support conversations to analyze resolution patterns across sessions.
  • Separating concurrent conversations from the same user to avoid mixing traces.
For the full set of ways to attach context to a request, including app name, identity, and custom metadata, see Request Metadata.
Group related requests into conversation Threads so they appear together in observability. Threads are a labeling mechanism and do not store or inject message history. Grouping is manual and opt-in: pass the same thread.id on every request that belongs to a conversation. API requests without a thread ID appear as individual traces and are never grouped automatically, with one exception: Claude Code and Codex send their own session identifiers, which are detected and grouped automatically.

Quick Start

Configuration

Best Practices

  1. Consistent Naming: Use predictable thread ID patterns
  2. Meaningful Tags: Choose tags that aid in filtering and analysis
  3. Session Management: Tie thread IDs to user sessions
  4. Unique IDs: Use UUIDs or composite keys to avoid cross-session overlap

Use Cases

Implementation Examples

Session-Based Threading

Assign the same thread.id to all requests in a session to group them together in observability. Your application manages the messages array for each request. thread.id groups the turns of a single conversation. orq.session_id groups requests across conversations for broader session tracking; when a request carries both, the thread ID determines the grouping. See Orq span attributes.

Multi-Language Support

Advanced Patterns

Dynamic Thread Management

Batch Thread Processing

Conversation Flow Tracking

Troubleshooting