Live sessions

Open Live sessions in a project to follow tool calls grouped by end user and stored agent session. Direct workspaces show only your own calls. The page is read-only and refreshes every three seconds while Live tail is on.

Each group shows its agent label, execution status, elapsed duration, and tool calls in creation order (with the execution ID breaking ties). View call opens the execution-log details drawer. Arguments, provider responses, compute code and credentials are excluded from both the session list and drawer.

Groups reflect executions within the selected 7-, 30-, or 90-day window. Sessions without a tool execution are absent. An execution without a stored agent-session binding appears as a standalone call; Arc0 does not infer sessions from time gaps or caller IDs. This view does not start or control hosted compute.

The group status is running if any call is running, then pending if any call is pending or awaiting approval, then failed if any call failed, was denied, or has an unknown outcome; otherwise it is succeeded. Each call retains its exact status. Duration runs from the earliest call start (or creation) to the last finish. An unfinished call leaves the group duration unset. These describe the selected calls, not whether a compute session remains open.

API

Business project keys with audit:read can use GET /v1/live-sessions. Like the management execution logs, this rejects user-bound runtime keys. The response is {data: [...groups], nextCursor}. Parameters are range (7d, 30d, 90d, default 30d), optional endUserId (an internal ID or external:<external ID>), limit (1–50, default 20), and cursor.

Groups include id, end_user_id, external_id, nullable session_id and agent, status, created_at, nullable finished_at and duration_ms, call_count, and calls. Calls use the redacted execution-log metadata schema. Each group includes its first 100 calls in order; call_count reports the full in-window count. Use Execution logs for further calls.

Pagination uses a stable end-user/group ID order, not recency. Cursors are bound to the project and filters. Polling is a fresh snapshot, so new activity may appear on a different page. Console endpoints use GET /v1/orgs/:orgId/projects/:projectId/live-sessions and the self-bound GET /v1/orgs/:orgId/direct/live-sessions; these return {items, nextCursor}.