Sessions and end users

A run is one turn. A session is the conversation, and an end user is whoever was having it. Both are recorded without you writing anything — see Automatic capture.

#Sessions

The session list shows conversations for the selected environment and range, most recently active first, with the end user, the number of turns, when it started and whether anything failed. Filter by end user, by failures, by environment and by time.

Open a session to read its transcript: the conversation turns in order, paged, each one linking into the run behind it. When retention has already removed some of the conversation, the page says so rather than presenting a partial conversation as the whole thing.

#Where the session id comes from

In order of precedence:

1. The x-tracehatch-session-id request header, or setSession().
2. The OpenAI Responses conversation id or previous_response_id.
3. A fingerprint of the system prompt and the first user message, which every later turn resends.

Derived ids look like auto- followed by 32 hex characters and are identical across processes, restarts, the SDK and the gateway — so a conversation handled by two services still lands in one session.

#End users Pro

An end user is named by the x-tracehatch-user-id header, setUser(), the OpenAI user field or Anthropic metadata.user_id. They are not Tracehatch accounts.

From the session list or a session header, open a user page:

• Sessions, lifetime runs, retained runs, failed runs, failure rate and recorded cost.
• That user's sessions, and that user's runs — including runs recorded outside any session.

Each table pages on its own cursor. Lifetime counters are kept separate from what retention still holds, and the page names the difference explicitly, so a user with 400 lifetime runs and 40 retained ones does not look like a user who lost 360 runs.

Free plans get the explanation instead of the page. Exports, per-user scores and a user search outside the session list are not built yet.

#Identifiers and privacy

Session and user ids are pseudonymised rather than masked when redaction would otherwise break them, because a broken id cannot group. The pseudonyms are unkeyed SHA-256 hashes, so a guessable id — an email address, a sequential number — can be checked against one.

Use opaque identifiers. See Privacy and data handling.

#Retention

Sessions follow the runs inside them. When a run expires under your plan's retention window, its turn leaves the transcript; the session's lifetime counters remain. See Plans, quotas and retention.