---
title: 'In the News: November 2, 2026 (Extra)'
description: 'A company reports 694 agent-written pull requests in one week and moved CI to a €99 server, cutting its GitHub-billed minutes from 19,359 to 611.'
canonical_url: 'https://darkfactory.dev/news/2026-11-02-extra'
markdown_url: 'https://darkfactory.dev/news/2026-11-02-extra.md'
collection: news
date_published: '2026-11-02T10:20:00-05:00'
date_modified: '2026-11-02T10:20:00-05:00'
---

# In the News: November 2, 2026 (Extra)


When coding agents open pull requests at volume, CI becomes a cost and capacity problem before it becomes a quality problem. One company's account of that shift leads this edition, followed by a young open-source tool that checks agent database writes against what the database actually did.

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

**[Our Coding Agents Outgrew GitHub's Runners](https://brunoj.com/our-coding-agents-outgrew-githubs-runners/)** · Author of brunoj.com (name not given on the page) · brunoj.com, November 2, 2026

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.

## 2. A new open-source gate compares what an agent says it changed with what Postgres recorded

**[deedglass/deedglass](https://github.com/deedglass/deedglass)** · Arjun Prabhakaran · GitHub, README read November 2, 2026

The README describes a tool that sits between an agent and a database. Rules allow, deny or require approval for each tool call, and Deedglass then compares the agent's report with a read-back from the target. For Postgres it uses the database's change log, and it seals each result as a signed record. Its sample scene: an agent was told to mark one order shipped, its tool reported 1 row updated, and a legacy trigger shipped 300 more in the same transaction. The README says Deedglass reported "Postgres changed 301 rows" and planned an undo that waits for a person's countersignature.

The project labels how sure each check is: Claimed, Checked or Proven, with "Can't check" when it cannot tell whether a tool ran. It lists what the Proven level cannot see, including schema changes and anything outside that database's change log. The README also says the project is pre-1.0, has one maintainer and no outside penetration test, and the repository showed 2 stars when we read it. We read the README only and did not run it, so the 301-row result is the author's demonstration.

**Why it matters:** An agent's own log cannot show a side effect it did not know about. If agents write to production databases in your factory, the useful idea here is independent read-back after each write, whether you adopt this tool or build that check yourself.