Limits and queues
Numbers first. These are the limits a standard Pod and each plan work within today.
Per Pod
| Limit | Value |
|---|---|
| Active agents, guaranteed | 2 to 3 |
Concurrent xcodebuild runs |
2 |
| Simulators in the pool | 3 to 4 devices |
| Idle timeout | 10 minutes after the last session ends |
| Longest session | 8 hours, then the agent is asked to wrap up and push |
More agents than the guarantee are allowed. They queue for builds and Simulators rather than being refused.
Per plan
| Plan | Pods at a time | Pod-hours included | Beyond the included hours |
|---|---|---|---|
| Free | 1 | 3, once | Sessions stop when the hours are used up |
| Pro | 4 | 300 a month | $0.40 per Pod-hour |
| Team | 10 | 1,500 a month | $0.30 per Pod-hour |
| Enterprise | By contract | A dedicated pool | Not metered |
A session that needs a Pod when the plan’s Pods are all busy waits for the next free one. The dashboard shows the queue.
How the build queue works
Two xcodebuild runs per Pod, scheduled fairly between agents: the agent that has waited longest goes next. Incremental builds are fast because the worktree keeps its derived data for the session. Clean builds of large apps take as long as they take on a Mac mini; plan the number of Pods around that, not around agent count.
How Simulators are leased
An agent leases a Simulator when it launches the app or starts UI tests, and returns it when done. Leases are short, so three to four devices serve more than three to four agents in practice. A lease that is idle for five minutes is released.
Usage and caps
Usage is metered per second while a Pod runs. Set a monthly spend cap on Pro and Team; when it is reached, new sessions wait for your approval. Usage by developer is listed on Team.
Next: Security.