How to run multiple Claude Code sessions at once

Why run more than one at a time

A single agent works in bursts. It reads, it thinks, it writes, and there are long stretches where it is waiting rather than working. Running several in parallel fills those gaps, which is why it feels like an obvious win.

The gain is real, and it is smaller than it first appears, because the cost moves rather than disappearing. With one session you spend your time waiting. With six you spend it triaging: working out which of them is stuck, which is finished, and which has gone wrong without saying so. The techniques below are about keeping that second cost down.

The method

Step 1. Choose independent work

The classic mistake is splitting one task into several sessions. Two agents working on the same feature will overlap, and reconciling the two partial solutions they produce takes longer than the single change would have. Good candidates are things that do not touch the same files: a test suite for one area, a refactor in another, a research question, and a dependency upgrade. Before starting anything, check whether two sessions would edit the same file.

Step 2. Give each session its own worktree

This is the step that makes everything else safe. A git worktree is a second working directory attached to the same repository, checked out on a different branch. Two worktrees share the repository's history, so merging later is ordinary git, but each has its own files on disk. An agent editing src/app.ts in one worktree cannot touch the src/app.ts that another session is holding.

Create one per session and branch it from the point where you want the work to start. From then on each agent is isolated in its own directory, and finishing a session is a normal merge from a normal branch. If you are doing this by hand, this is the step to get right before you add any others.

Step 3. Choose the engine per session, not per habit

Not all of the work deserves the most expensive model. A long mechanical pass does not need frontier reasoning. That means renaming, updating tests, or applying the same change in twenty files, and running work like that on a frontier model is where parallel sessions get expensive fast. Keep the strong model for planning and for hard debugging, and send the rest somewhere cheaper. The parallelism is what makes this worth setting up: with one session, changing the model is a decision about your whole afternoon.

Two things are worth doing here. Decide the engine before you start the session rather than after it has burned an hour, and set a spend cap before the first run. Check where the cap applies, too: on most providers it covers pay-as-you-go API usage and will not limit a flat-rate subscription.

Step 4. Make every session's state visible

This is where hand-rolled setups fall down. Several terminal windows contain the information you need, and none of them tells you that one agent has been waiting on a question for twenty minutes.

What you want is a single view where each session has a status: running, waiting for you, failed, stalled or done. The ones that need a person should be separated from the ones getting on with it. With that, checking on six sessions is one glance. Without it, you are reading six transcripts in turn.

Step 5. Merge one at a time, and only when it is finished

Parallel sessions produce parallel branches, and the temptation is to leave them all open until the end. Resist it. Merge each branch as it completes, verify it, and then start the next piece of work from the updated base. A branch left open for a week will have drifted from the others, and resolving that as one large merge is much harder than resolving four small ones.

Practically: finish, verify, merge, then start the next session from the new base. That keeps each merge as small as the branch behind it.

Where Omniscio fits

Everything above works by hand, and the by-hand version is worth knowing even if you never install anything. Omniscio is the tool we make for people who want the same thing without the bookkeeping. Here is how it covers the list.

• A session can run in its own git branch and worktree, so two agents cannot collide. Worktree isolation is off until you turn it on, per session, per project or for the whole app.
• Sessions carry statuses such as Running, Needs You, Ready, Error and Stalled, and the ones that need you float to the top of the list.
• The AI Manager puts Plain Speak on a finished turn. Plain Speak rewrites a long reply into a card you can read at a glance.
• There is a provider picker, so a session can run on any harness: Claude Code, Codex, OpenCode, Devin, Pi and Hermes among them. The model providers behind them are there too, Gemini, DeepSeek, Kimi, GLM, MiniMax and Cursor included. Every one is in the list from day one; switch on the ones you use in Settings and add the key or sign-in there.
• Daily spend caps on each pay-as-you-go API-key account stop a runaway loop before it becomes a bill.
• Quick Launch (Ctrl+Space) starts a session from wherever you are, and the diff viewer shows the uncommitted changes with an AI summary before you keep them.
• And a phone view over the web, so a session that finishes while you are out reaches you. It is off by default; switch it on in Settings.

It runs on Windows, macOS and Linux and uses the same agents you already use. The features page lists what is in it today.