Step 7: Run several sessions at once
10 min read
Everything so far has been one agent and one terminal - which is a nicer way to run a coding agent, and not a reason to have built anything. This is the reason. Three sessions working at once is not three times the typing; it is a different job. You stop composing and start deciding: who needs an answer, who can wait, and what to line up next.
The trick is that you never watch three terminals. You watch a list of coloured squares, and you open exactly one card at a time - the one the list sent you to.
Ten minutes. You need DevThrottle open with the session you started earlier, and two more pieces of work you can hand out - ideally in different repositories, for the reason in the warning below.
Start a second session while the first one is still working
Do not wait for anything to finish. With the first agent mid-task, click New Session in the toolbar at the top of the window and set up a second one exactly as you did the first - repository, coding agent, a name that says what the job is. That window is unchanged and taught in Start your first session.
The new card appears at the bottom of the list on the left, and the window switches to it. Look at the card you just left: it is still blue, still working. Nothing paused. Give the new session its first instruction.
Start a third, and give it something slow
Once more, and this time hand out something that will take a while - a test suite, a dependency upgrade, a refactor across a lot of files. You want one session that is genuinely busy for the next few minutes, because the next two things you learn are only useful when something is busy.
Three cards, three colours, three jobs running in parallel on your machine. That is the fleet. Everything from here is how to read it.
Look away from the terminal, deliberately
Click each card in turn. The terminal in the middle of the window shows one session at a time - the selected one - and swapping between them is the whole navigation.
What matters is what does not happen. Looking away does not slow, pause or interrupt the session you looked away from: the window stops drawing that terminal, the session carries on regardless, and when you come back the terminal is rebuilt from what that session recorded while you were elsewhere. A half-written message in the prompt bar goes with it too, so a thought you started for one agent is still there when you return to it.
This is the habit the rest of the step depends on. If you sit and read terminals as they scroll, three sessions will feel like three times the work. They are not meant to be watched.
Read the count above the list
Above the session list is the word SESSIONS, and beside it, in amber, a count: 2 need you. It is hidden when the number is zero, so you never read a zero - it is either there or it is not.
That count is the answer to the only question you have to ask a hundred times a day. Not what are my sessions doing - is anything waiting on me. When it is not there, go and do something else.
Two things it deliberately leaves out, so you do not read it as a health check: a session you have snoozed is not counted, and neither is one whose agent process has died. The second is why the last step of this list exists.
Read the colour, not the words
Every card carries a coloured square on its left edge. Blue means the agent is working - leave it alone. Red means it has stopped and cannot go further without a human, and the label under the name says Needs you.
With three sessions you can afford to read only that. Scan the squares down the left edge in one movement, and you have the state of everything you are running. The other colours - a session on a long background task, one whose agent has died, one being read for you - and every label they carry are on Session cards and states, which is worth ten minutes once. Hovering a square tells you why it is that colour.
Nothing a session does moves its card, and this is the single most important thing to know about reading the list. A card holds the slot you put it in. When a session turns red it changes colour where it stands - it does not rise, and the card at the top is not the one that most needs you. The only thing that ever moves a card is you dragging it.
So do not build the habit the list will not support. You cannot glance at the first card and be told what is urgent; you read the squares, all of them, every time. That is a second of work and it is the whole method - which is exactly why colour is on the outside edge where nothing competes with it. What position means is entirely up to you, and the step below is how to make it mean something.
Let the waiting time choose which one you open
A red card shows how long it has been waiting - waiting 9m, ticking upward, in orange next to the state. Only red cards show it. The clock is stamped once, when the Gateway first sees the session waiting, and held at that moment for as long as it keeps waiting - so it measures the wait rather than the session, and it is cleared the moment the session stops waiting.
Read it as a cost meter rather than a timestamp: it is how much of your day that session has already lost. A session that started three hours ago and has waited two minutes is fine. One that started ten minutes ago and has waited nine is the one to open. When several are red, work down from the longest wait, and the arithmetic takes care of itself.
Notice the badge nobody finds
On the right of a card, an amber badge: 4 chg. There is uncommitted work in that session's repository - real work sitting in a working tree, waiting to be reviewed or lost. It is the quietest useful thing in the window, and it is the one to look for.
Read it as there is something here and no more than that, because the number is smaller than it looks. It counts entries in the repository's status, not files: a file you have staged and then edited again is two of them. So 4 chg is four things to look at, which may be three files or four. What the number is counting, and what to do with it, is See and review what changed.
The badge belongs to the working tree, not to the session. The Director counts a repository once and puts that one answer on every card sharing it. So two sessions in the same repository show the same number, and it is the state of the tree - not a tally of what either of them did, and not a claim about who did it. Your own editor changes it too.
Which means: never read 4 chg on a card as work that agent did. On a repository one session has to itself it usually is. On a shared one it is not, and crediting a session with work it never touched is how you approve a change nobody reviewed. The warning below is the way out of that.
One honest limit, because it decides how far you can lean on the badge. The count is refreshed on a timer for every session, not only the one you are looking at - but a refresh that cannot read the repository leaves the last number it did read sitting on the card. If the folder is renamed, or the repository is mid-rebase, the badge does not go blank or go to zero: it keeps saying what was true the last time anyone could tell. A badge is good evidence that there is work to look at, and it is not proof of what is in the tree right now. A card with no badge at all is a tree nothing has ever successfully read, which is not the same as a clean one.
Queue work for the busy one instead of interrupting it
The slow session from earlier is still working, and you have thought of the next thing you want it to do. Interrupting a working agent to say so is a bad trade, and holding the thought in your head means being at the desk at the moment it finishes.
Select it, write the next instruction in the prompt bar as normal, and press Ctrl+Shift+Enter - or click Queue. The box empties, the button turns red and starts counting, and a red badge appears on that session's card, so from the list alone you can see which sessions have work lined up. Click the badge to read it back.
Nothing in the queue is sent until somebody sends it. No queued item ever leaves on its own - not when the agent finishes, not on a timer. From the Director the queue panel offers exactly five things to do with an item: move it up, move it down, edit it, remove it, and Pop, which takes it out of the queue and drops the text back into the prompt bar for you to send yourself. There is no send button on it at all.
That is deliberate rather than unfinished: a stopped agent has either finished or stopped to ask you something, and from outside those look identical, so firing the next instruction at it would sometimes be answering a question with unrelated text. The queue is an ordered notepad attached to the right session. Popping items, reordering and editing them - and the browser Cockpit, which does have a per-item send you can press - are Line up the next instruction.
Deal with the one that is red
Now the other half. Click the red card, select the Terminal tab if another tab is showing, and read the last thing the agent printed - when a session needs you, that is the question. Answer it in the prompt bar and press Ctrl+Enter.
The square turns blue, the waiting time disappears, and the count above the list drops by one. Then go back to the squares. That loop - read the count, open the longest wait, answer, return - is the whole job of running a fleet, and it does not get more complicated at thirty sessions than it is at three.
When a red card is one you genuinely do not want to deal with now, say so rather than ignoring it: Snooze from the card menu drops it out of the count for a while and brings it back on its own. The safety net around a waiting session - and how it reaches you when you are not at the desk - is Never lose a stuck agent again.
Put the list in the order you work in
Because nothing rearranges the list for you, arranging it is worth doing. Drag a card by its coloured square to move it, and it stays where you put it, including after a restart.
Put the work you care most about at the top and the long-running background jobs at the bottom. The Director reads no meaning into the order at all, which is precisely what leaves it free to carry yours - and why the order still says what you meant a week later.
Before you walk away, scan for the dark red one
One last pass, and it takes a second. A session whose agent process died shows a darker red and reads Crashed. It has no waiting time - there is nothing left to wait - and it is deliberately not in the count at the top.
So it will never come and find you. Scan for it on purpose before you decide the Director is quiet.
Two sessions pointed at the same repository at the same time are writing into one set of files. If they touch different files nothing goes wrong; if they touch the same one, one of them can overwrite the other's work, and neither is told. Nothing in the Director watches for it - the shared changes badge above is the only hint you get, and it says one tree changed, never who changed it. Do not rely on being lucky about which files each one picks. Give each session its own repository for now. The proper fix - a separate checkout per session, from the same repository - is Repositories and worktrees, and it is what makes running several agents on one codebase safe.
The session list can be collapsed to a narrow strip of the same coloured squares, each one clickable and named on hover. It gives the terminal the width back without giving up the one thing you actually watch.
Minimise the Director - do not close it. Your sessions live inside it, so closing the window ends every agent process it is running, all three at once, and it does that to every session whatever state it was in.
There is a confirmation, and it is narrower than it looks: it appears when a session is working or waiting on you, which is what a busy Director usually contains. Do not read its absence as permission. A session that is snoozed, transcribing, or between states does not raise it, so the window can close quietly on sessions you meant to keep. Whatever the sessions already wrote to disk stays exactly where it is; the work in flight stops where it stands.
For one day, refuse to open a terminal that did not ask for you. Act only when the count says something needs you, and go back to the squares afterwards. It feels careless for about an hour, and then it feels like the tool doing its job.
Next
You are running a fleet rather than babysitting a terminal. The next step is where else that fleet turns up - the same sessions, the same colours, in a browser tab and in your pocket: the three ways to work.