Interactive Sessions Admin
The /admin/interactive-sessions console: live list, detail, force-stop, grants, quota overrides, stats, relay health.
/admin/interactive-sessions is the operator console for every interactive session across every org - a cross-tenant view that bypasses per-org grants (operator access here is audit-logged as interactive_session.admin_viewed, so viewing a tenant's session is itself a recorded action).
Management list
The landing view lists every live session: org, project, user, harness/model/pool (with provenance - launches never route through the MAB selector, so a session showing mab_routed provenance is flagged for investigation), substrate, duration-vs-cap status, current driver, and connection state.
Viewer count and byte/frame throughput are not shown on the list view - presence is tracked in Redis only and has no durable, queryable source yet. Rather than show a stale or fabricated number, the column reads as empty.
Session detail
Opening a session (/admin/interactive-sessions/{id}) shows presence and the current driver, launch provenance, the recording pointer (if any), byte/sequence watermarks, and - when the relay is reachable - a live peek at the relay's own view of the room (state, viewer count, whether a host is bound, and the current sequence number). If the relay is down, this section degrades gracefully rather than erroring the whole page.
Force-stop
Force-stop is a dry-run-then-confirm flow: you see what will be affected before you commit. It reuses the same teardown path a normal stop uses, and it's race-safe - if the session has already ended by the time you confirm (someone else stopped it, or it hit its quota), the action reports "already terminal" instead of silently double-processing (which would otherwise double-count usage against the org's monthly hours).
For a session running on a local daemon substrate that has stopped responding (a wedged worker rather than a cleanly-running one), force-stop enqueues a kill instruction to the daemon and shows its real state honestly: queued → delivered → applied (or failed). It never claims "stopped" just because the instruction was delivered. As of this page, the daemon-side handler that actually acts on a delivered kill instruction for a wedged local session is not yet built - so a force-stop against a wedged local-substrate session can currently get stuck at "delivered" without the process actually dying. Cloud-substrate sessions (E2B, Vercel Sandbox, etc.) are not affected - their teardown path is a direct provider call and works as described above.
Grants
Grant revocation is a dedicated admin action - pull a specific user's driver or viewer grant on a session - and every revocation is audit-appended.
Quota overrides
The quota panel shows an org's current inflight and monthly-hour usage against its effective limits, with three-way provenance: unset (using the plan default), versus explicitly set to the same value as the default, versus explicitly overridden. That distinction matters when you're trying to tell whether a prior operator deliberately pinned a number or just never touched it.
The override editor writes to the org's features.limits.interactiveSessions block. It's a merge, not a wholesale replace - setting a new duration cap does not clobber an existing concurrency override on the same org. (An earlier version of the plans editor treated the whole limits object as an opaque blob and could silently drop the interactive-sessions block on save; that was fixed with a dedicated sub-panel for this block specifically.)
Stats dashboards
Summary tiles, a substrate/harness breakdown, a session-duration histogram, and a top-N view of which orgs are consuming the most monthly hours, with an org drill-down. These read from persisted hourly rollups, not a live query over raw session rows, computed by a scheduled job - so there's a freshness stamp on the page, and a new session's numbers can take up to an hour to show up here.
Relay health
A relay health panel similarly reads from a persisted rollup, refreshed every 5 minutes from the relay's own health and room-telemetry endpoints - never a live scrape on page load. When the relay is unreachable, the panel shows an explicit degraded state rather than stale numbers presented as current.
Alerting
Two operator-only alerts run off this data: a debounced relay-down alert (fires once per down/up transition, not once per poll) and a quota-exhaustion alert (once per org per billing period). Both use a dedicated operator.system_health notification category that is hidden from tenant-facing preference settings - it is never something a customer sees or configures.
There is currently no persisted audit log of individual quota denials or duration warnings (a write on every check was rejected as write-amplification risk for a high-frequency gate). The stats and quota panels reflect current and rolled-up state, not a denial-by-denial history.
Related Pages
- Interactive Sessions - the user-facing launch/attach/drive flow this console manages
- Quotas & Plans - the plan limits this console's quota panel enforces and overrides
- Notification Preferences - the
operator.system_healthcategory lives outside this list