- 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.
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
- Consistent Naming: Use predictable thread ID patterns
- Meaningful Tags: Choose tags that aid in filtering and analysis
- Session Management: Tie thread IDs to user sessions
- Unique IDs: Use UUIDs or composite keys to avoid cross-session overlap
Use Cases
Implementation Examples
Session-Based Threading
Assign the samethread.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.