A company's agents pushed CI past GitHub's runner limits, so it moved to one rented server

The author says his company opened 694 pull requests in the last week of October, against 42 to 75 a week in June. Most were written by coding agents and opened under staff names. CI minutes billed by GitHub ran 2,500 to 8,000 a month over the summer, then reached 35,870 minutes ($216) in September and 40,001 ($242) in October. The author attributes the jump to a model release on September 22, and says one client project used 60% of CI time, with 79% of that triggered from his own account.

The cost was not the main problem. GitHub's standard private-repo runner has 2 CPUs, the author's biggest Flutter job took a median 23.4 minutes on it, and the Team plan's 60-concurrent-job cap was hit (peak: 70 jobs). In mid-October the company moved nearly all CI to a dedicated server at €99 a month, running GARM, an open-source runner autoscaler, which gives each job a fresh virtual machine from Incus and deletes it afterward. Before choosing hardware, the author had an agent analyze 26,200 jobs; its minute count matched GitHub's bill to 99.4%. It found nothing running 63.5% of the time and 1.4 jobs running on average, which is why one modest box fit.

Weekly figures from the post: GitHub-billed minutes fell from 19,359 (week of October 5) to 12,977, then 4,049, then 611 (week of October 26), while pull requests rose from 476 to 694. From October 19 to November 2 the new runners handled 5,440 jobs, with a median wait of 3 seconds once six VMs were kept warm; one job in ten waited more than about five minutes. The author lists the costs: busy afternoons run the same job two to three times slower because the VMs share one CPU, the server is a single point of failure, GARM is young (v0.2.1) and exposes almost no job metrics, and GitHub's announced-then-paused per-minute fee for self-hosted runners would add about $84 a month at current volume. These are one company's self-reported numbers; we have not checked them.

Why it matters: Agent throughput shows up first as a queue and a bill in CI. The author's practical advice is to look at your usage report by repository and day before buying hardware: if load is bursty, a modest box with a short queue may cost less than per-minute billing. The per-job fresh VM also changes who has root, since a job gets root inside a VM that is deleted afterward and not access to a shared host Docker socket.