Concurrent Multi-Session Orchestration

What it is

Omniscio's central idea is that you work with many sessions at once. Instead of a single chat, you spawn a fleet — one session per task — across as many projects as you like, and the app keeps them all running. Each session is a managed child process: Omniscio spawns it, monitors it, streams its output, and reaps it when it finishes.

Sessions are not limited to one engine. You can run Claude, Codex, Gemini and other providers side by side, each isolated from the others, so you can use the right model for each job. When you pick a model once, Omniscio handles the vendor for you: a non-Claude session is served by the first row of its model family's supply list that can serve right now — paid by you (your own key, with the maker or a reseller), by Omniscio credits, or by a company lane — and you order that list under who-pays-and-who-serves in Accounts. Picking a row never changes the engine or model you chose. Claude is not part of that list; it has its own account pool.

Where to find it

The fleet is visible in two places that complement each other. The sidebar lists every session with its live state, and the dashboard (Mission Control) gives a broader view of what is running where. The inbox is the third surface, and the one you actually work from: sessions that need your input are surfaced there so you respond and move on rather than watching each one.

How it behaves

Every session shown has a live state — running, waiting for you, rate-limited, or finished — so the sidebar and inbox give you the fleet's condition at a glance. Each session streams its output into its own panel in real time, so you can watch a specific agent work. Recently-viewed panels are kept mounted in a pool, so switching back to one is instant rather than a reload.

The inbox is attention-first: you deal with the sessions that need a decision and leave the rest running. For the app's own protection, heavy work is admitted and paced box-wide rather than started all at once, so a large fleet cannot overwhelm the machine — and the rule that governs every one of those brakes is that agents may be slowed without limit while the user is not slowed at all.

For agents

• Multi-session recipe mode is handled by src/main/services/recipe/recipe-mode-multi-session.ts.
• Cloud session lifecycle is served by the saas-api routes (src/routes/cloud-sessions.ts and related billing routes in that service).
• Engine isolation and per-vendor routing follow the model registry's supply list; the user-facing control is the who-pays-and-who-serves setting under Accounts.

Related

• alert-session-hub.md — the hub that surfaces sessions needing attention.
• amc-session-awareness.md — how a session knows and reports its own state.
• archive-a-session.md — clearing finished sessions out of the way.
• copy-session-as-markdown.md — taking a session's conversation elsewhere.