Quotas & Plans
Interactive session concurrency, duration, and monthly-hour limits by plan.
Interactive sessions run real workers for as long as they're attached, so they're metered separately from ordinary agent dispatch. Three limits apply per organization, all enforced server-side at launch time and continuously while a session runs.
The three limits
| Limit | What it means |
|---|---|
| Concurrent sessions | How many interactive sessions your org can have live at once. Launching a new one past the cap is rejected until an existing one ends. |
| Per-session duration | The wall-clock cap on a single session, from launch to stop. |
| Monthly attached hours | The total wall-clock time your org's sessions have been open this calendar month, summed across all sessions. |
Plan defaults
| Plan | Concurrent | Per-session duration | Monthly attached hours |
|---|---|---|---|
| Free | 1 | 2 hours | 10 hours |
| Pro | 5 | 8 hours | 80 hours |
| Enterprise | Plan-set (configured per contract) | Plan-set | Plan-set |
The monthly counter resets on the calendar month boundary in UTC - not your local timezone, and not a rolling 30 days. An org's monthly usage is the sum of every second an interactive session was attached and running that month, across all its sessions - not just the sessions running right now.
Enterprise limits are not a single fixed number - they're configured per organization (see Interactive Sessions Admin for the override editor operators use). An org with no interactive-sessions entitlement at all cannot launch one regardless of plan.
What happens when you hit a limit
Concurrent cap or monthly hours exhausted: launching a new session is rejected immediately, before a worker ever spins up. No partial session is created.
Per-session duration works differently, since a session is already running when it approaches its cap:
At 90% of the session's duration cap, you get a duration-warning notification (see Notification Preferences) and the terminal's quota clock reflects it - time to wrap up or save your work.
At 100% of the cap, the session enters a grace window - 5 minutes - rather than stopping instantly. This exists so a session doesn't get cut off mid-command the moment the clock ticks over.
Once the grace window elapses, the session is stopped automatically, the same as if you'd stopped it yourself.
The web terminal's own duration-warning indicator is calculated client-side from an 80%-of-cap estimate as a stopgap; the number above (90%, with a 5-minute grace) is the actual server-enforced threshold that determines when your session is really at risk. If the two ever disagree, trust the server behavior described here.
Checking quota from a workflow
The interactive.session.under_quota condition node lets a workflow check "does this org still have room to launch an interactive session" before it tries - useful for an escalate-to-live-session automation that shouldn't fire a gate.human_query approval it can't actually honor.
Related Pages
- Interactive Sessions - launch, attach, and drive
- Notification Preferences - duration-warning and session-ended notifications
- Interactive Sessions Admin - the operator view of quota usage and the override editor