Warm pools

Even a create from a prebuilt image boots a VM and runs setup. A pool holds sessions that already did: parked, setup-complete sessions waiting to be claimed. Baked repos keep a pool of one by default (the Fast profile). The pool fills in the background as soon as it can be: after pier setup in a baked repo, after every bake (recycling members built on the old image), after every claim, and whenever its size changes.

pier pool               this repo's pool: ready, filling, what it costs
pier pool set 2         keep two ready (0 turns the pool off and drains it)
pier pool fill          top it up now, e.g. after a drain (-d in the background)
pier pool drain [repo]  destroy a repo's pooled sessions, from anywhere

Claiming

The next pier <branch> claims one instead of creating: resume, check out your branch, re-push secrets, apply your dirty edits. Setup doesn’t run again. The pool refills in the background.

An empty pool just means a normal create: the pool accelerates, never gates, and --no-pool skips it for one create.

Cost and recycling

Pooled sessions are stopped instances, so each costs disk only (~$3-4/mo at 40 GiB). They recycle themselves when they go stale: after a re-bake, a setup-script change, or 14 days (pool.max_age). Upgrading pier doesn’t stale them: a claim installs the current pier’s in-VM supervisor.

Nothing is left behind. Any listing (pier ls, the app) also removes pooled sessions nothing would claim: a repo whose pool is off or has no image, a dead member, a fill that never parked. It also removes bake instances whose bake died, from every repo, wherever you run it. Pool counts show only sessions that can actually be claimed.

In the app

The app’s Repos tab shows every repo’s pool with its cost:

Key	Action
+ / -	set the pool size
f	fill it now
x	drain it

pier repos prints the same view for every repo: session image, pool, idle cost, and any rebake reminders. pier repos --json is the automation form.