Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1
In plain terms. Do you want to pay for more test machines, or have tests wait their turn on busy nights? Tonight AWS capped how many machines we can run at once, we asked for more than that, and some tests failed before they even started. A bigger cap doubles our ceiling on runner spend; waiting keeps spend where it is but busy nights run slower.
The full question, as raised
CI runners are hitting the AWS EC2 vCPU quota (256) for the RunsOn spot fleet — jobs queue 40 min then fail with LaunchError VcpuLimitExceeded (18 CI runs in progress, ~144 8-core jobs wanted vs 32 slots, measured 03:42Z 2026-09-29; run 36515223223 jobs 109236086862/109236086907, run 36515212819 jobs 109236058969/109236058906). Raise the quota, cap concurrency, or let it drain?
The session raising this recommends: Keep the cap and make tests wait their turn instead of failing The cap is the only spend ceiling on the fleet right now (Fede 2026-09-28: never move to a more expensive shape during an incident without asking). A quota raise doubles the ceiling for every future burst; a concurrency cap turns tonight's launch failures back into plain queueing at zero extra spend, and a raise can still be requested later with a measured backlog number. Tried first, unsuccessfully: Read both failed jobs' annotations (LaunchError VcpuLimitExceeded, 256 cap) and counted the live fleet: 18 CI runs in progress + 25 queued at 03:42Z. Re-ran the LaunchError jobs on #13480 (retry 1 of 3) — that re-queues them but cannot add capacity. Could not re-run #13483's yet (its run is still queued). Raising the AWS quota myself is a spend decision I am not allowed to take during an incident, and I did not want to edit the workflow concurrency without a human picking the ceiling.