Two numbers bound how much this Station runs at once, and they work at different levels.
| Setting | Scope | Where | Default |
|---|---|---|---|
| Max concurrent | one agent, in one project | project detail panel, per agent | 1 |
| Concurrent sessions | the whole Station, across every agent and every project | Settings → Concurrent sessions | 4 |
Max concurrent is counted per (project, agent) — not per agent across the fleet. One agent can hold a session in several projects at the same time, which is what Build has always allowed and what Build Station now matches. Before 1.4.0 the count was per agent across the whole fleet, so an agent busy in one project could not start in a second one no matter how idle that project was.
Concurrent sessions is the ceiling over all of it. Because max concurrent is per (project, agent), a Station serving dozens of projects is bounded by nothing station-wide without it — one agent could hold a session in every project at once, and each session is a full model process. Per-project limits sit under this one; once they stop binding, this is the number that does.
What the setting does
If max concurrent is 1 (default):
- Agent X is working on Task A → Task B for agent X arrives.
- Build Station queues Task B locally.
- Task A finishes → Task B spawns immediately.
If max concurrent is 2:
- Agent X is working on Task A → Task B arrives → Build Station spawns it in parallel.
- Task C arrives while A and B are running → Build Station queues C.
- A finishes → C spawns. Now B and C run in parallel.
Why 1 is usually right
Most agent tasks are non-trivial — they take minutes to tens of minutes, they touch git, they run tests. Two parallel tasks for the same agent in the same project would step on each other (unless you have worktree mode on). And even with worktree mode, parallel tasks for the same agent identity hit the server-side "one task In Progress per agent" constraint and one will block.
Practical guidance:
| Setting | When to use it |
|---|---|
| 1 (default) | Almost always. Safe, predictable, no risk of agents stepping on each other or hitting server-side conflicts. |
| 2+ | Only if you've also enabled worktree mode on this agent AND the backend supports per-session In Progress tracking for your agent. Niche. |
Interaction with the project lock
Build Station also serializes per project: at most one non-worktree coding spawn at a time across ALL agents in a project. So even if you set max concurrent to 5 on agent X in a project with worktree mode off, the project-level lock will queue everything except the first one anyway.
Max concurrent only kicks in beyond the project lock when:
- Worktree mode is on (project lock bypassed), AND
- Max concurrent is >1.
In any other configuration the project lock is the binding constraint and the per-agent number doesn't really matter.
Reviews are outside the lock entirely. Since 1.4.0 a reviewer neither waits for the checkout nor holds it against anyone else — it reads a diff and writes nothing — so a review can run alongside the coding session it is reviewing, and two reviewers can run in one project at once. They still count against Concurrent sessions. See One task at a time per project.
See One task at a time per project for the project lock semantics.
Changing the settings
Max concurrent: project detail panel → find the agent → adjust the number. Takes effect immediately for new spawns; in-flight tasks finish as configured.
Concurrent sessions: Settings → Concurrent sessions. Minimum 1; the field shows the value actually in force rather than what was typed. Raising it raises cost and machine load in proportion, because each session is a full model process. Lowering it never stops sessions already running — it stops new ones starting until the count drops below the new ceiling.
Warning: The setting is local to this machine
Like all per-project settings on Build Station, max concurrent is per-machine. Changing it here doesn't affect other Build Stations you're signed in to. Each machine controls its own concurrency.
When you'd want to LOWER concurrency
The setting can't go below 1 in the UI (1 is the minimum). If you want an agent to not run at all on this machine, disable it instead — that's the right tool. See Enabling and disabling agents.