Agent Sessions is in private preview. The feature is enabled per workspace by the Orq.ai team and the API is not part of the public SDKs yet. Behavior and field names can still change.
Using sessions
Create a session, chat with the agent, review changes, open a pull request, and drive sessions through the API.
Factories and connections
Governance: session defaults, policies, egress, budgets, project access, and GitHub connections.
Session identity
Use short-lived OIDC tokens for keyless access to cloud services and Vault.
Agents
A session runs one agent. The agent is chosen when the session is created and can be overridden per run.
Any model available through the AI Gateway can be used, referenced by its gateway id (for example
anthropic/claude-sonnet-4-6 or openai/gpt-4o). When no model is given, the factory default applies, then the runtime default anthropic/claude-sonnet-5.
How it works
Computers and isolation
A computer is the isolated machine a session runs on. A computer template configures that machine and is backed by a KubernetesSandboxTemplate custom resource.
Which computer templates are available depends on the cluster; list them with
GET /v2/computer-templates. Inside the computer the agent runs as a non-root user on a read-only root filesystem, with the repository cloned to /workspace/repo on a persistent volume. Tool-call approvals follow the factory policy; see Approvals.
Network egress from the computer is limited to DNS, the AI Gateway, and the public internet (private address ranges are always blocked). A factory can narrow this further to an allowlist of CIDRs; see Egress.
LLM calls go through the gateway
Every session gets its own API key, minted when the session is created and revoked when the session is deleted. The key is scoped to the session’s project, namedagent-session:<session_id>, and labelled with the session’s factory. The agent inside the computer receives that key and the gateway URL in memory only; credentials are never written to the pod specification.
As a result every LLM call made by the agent shows up in Traces and Logs under that key, and factory budgets are enforced by the gateway like any other budget.
Repository access
Repositories are cloned over HTTPS. For private repositories the clone token comes from a GitHub connection of the workspace (a short-lived installation token of the Orq.ai GitHub App, resolved from the repository owner), or from a personal access token passed when the session is created. Tokens are handed to the computer at attach time and are never logged or exposed to the model. Clones keep the full history with lazily fetched file contents, sogit log and git blame work inside the session. A shallow clone depth can be requested per session.
Lifecycle
State changes are published as session events (
session.provisioning, session.ready, repo.cloning, repo.cloned, run.queued, run.started, run.finished, session.pausing, session.paused, session.resuming, session.resumed, session.failed, session.deleted) and are shown as the status line of the session page.
Idle auto-pause. A ready session that receives no message for its idle timeout (default 30 minutes, minimum 60 seconds, configurable per session and per factory) is paused automatically. Ready sessions older than a factory’s maximum session hours are paused as well.
Auto-resume. Sending a message to a paused session resumes it first (typically a few seconds) and then starts the run. There is no need to resume explicitly.
Conversation continuity
Every message continues the agent’s previous conversation in that session, including after a pause and resume: the agent remembers earlier turns, the repository state, and its own notes on the persistent volume. Start a fresh conversation on the same computer with the New conversation toggle in the composer (new_conversation: true in the API).
Limits
Get started
Using sessions
Open Managed Agents > Factories, select a factory, then open its Sessions tab.