# Agent-written pull requests turn CI into a metered dependency

> Agentic development turns CI from a final check into a feedback loop. Runnerhut replaces the runner with one runs-on label. Measure the result.

- Source: https://jays.fyi/blog/agent-written-pull-requests-turn-ci-into-a-metered-dependency
- Author: Jay Derinbogaz
- Published: 2026-08-25
- Language: en
- Tags: tooling, pricing, ai
- Reading time: 6 min

---

An agent can write a patch while you sleep. That is the part everybody wants to
talk about. The patch still needs dependencies installed, a test matrix run,
containers built, artifacts stored, and a green check before it can touch the
branch you care about. All of that is metered compute.

The CI bill has become a dependency of software creation. It sits inside the
feedback loop between an agent's proposed change and its next attempt, where a
slow job means an idle agent and an expensive job means a machine can iterate
only until someone notices the invoice.

<figure>
  <img src="/images/github-public-activity-2024-2025.png" alt="Two bar charts show GitHub public and open-source contributions rising from about 1 billion in 2024 to 1.128 billion in 2025, and merged pull requests rising from 402.7 million to 518.7 million." width="1200" height="675" decoding="async" />
  <figcaption>Public GitHub activity in 2024 and 2025. <a href="https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/">GitHub Octoverse</a> counts contributions and merged pull requests, not lines of code.</figcaption>
</figure>

GitHub already documents the mechanism in plain language. On private
repositories, [Copilot code review consumes GitHub Actions
minutes](https://docs.github.com/en/billing/concepts/product-billing/github-actions#copilot-code-review-and-github-actions-minutes).
Anyone with write access can trigger an Action, and usage above an included
allowance is charged to the repository owner. An agent loop merely makes that
meter run more often.

This matters to us at [TextCortex](https://textcortex.com/). We build and run
agentic workflows. More proposed changes mean more test runs, more cache
restores, and more failed attempts that have to be made green. The old picture
of CI as a final tollbooth underestimates the load. It is now part of the
factory floor.

## The claim that agents write more tests has not earned its number.

Code generation can create a great deal of test code. It can also create a
patch with no useful test at all, or a test that asserts the implementation's
mistake. I do not have a public corpus that proves an average agent produces
more tests than a human, and I will not manufacture one for a marketing
sentence.

<figure>
  <img src="/images/ai-development-use-and-distrust-2024-2025.png" alt="Two bar charts show the share of Stack Overflow respondents using or planning to use AI tools rising from 76% in 2024 to 84% in 2025, while the share who do not trust AI output accuracy rose from 31% to 46%." width="1200" height="675" decoding="async" loading="lazy" />
  <figcaption><a href="https://survey.stackoverflow.co/2025/ai">Stack Overflow's 2025 survey</a> shows AI use rising with distrust. It is a survey of developers, not a measure of generated code.</figcaption>
</figure>

The operational conclusion survives without that statistic. Every proposed
change needs evidence before merge. An agent that can propose changes quickly
turns CI duration, capacity and cost into constraints on how quickly it can
learn. That is enough reason to care about runners.

<figure>
  <img src="/images/copilot-productivity-study-speed-index.png" alt="A bar chart shows a task-completion speed index of 100 for a control group and 155.8 for a GitHub Copilot group. The study involved 95 professional programmers completing one JavaScript HTTP-server task." width="1200" height="675" decoding="async" loading="lazy" />
  <figcaption>A <a href="https://arxiv.org/abs/2302.06590">controlled GitHub Copilot study</a> reported 55.8% faster completion on one task. That is evidence of capacity, not a forecast for every repository.</figcaption>
</figure>

## Runnerhut makes the price-performance case in plain numbers.

[Runnerhut](https://runnerhut.com/) is a managed GitHub Actions runner service.
You authorise its GitHub App, replace a job's `runs-on` label, then keep the
Actions, secrets and permissions already in your workflow. Its
[documentation shows the one-line migration](https://runnerhut.com/docs).
Managed caching, persistent Docker builders, per-workflow analytics and
EU-hosted compute arrive with it.

Runnerhut publishes a [2-vCPU price comparison](https://runnerhut.com/pricing)
against GitHub-hosted runners. These are the prices on its rate card in August
2026. Windows and macOS are half the listed GitHub-hosted rate. Linux x64 is
half the price and Linux arm64 is 36% lower.

| Runner type | GitHub-hosted / min | Runnerhut / min | You save |
| --- | ---: | ---: | ---: |
| Linux x64 | $0.0080 | $0.0040 | 50% |
| Linux arm64 | $0.0050 | $0.0032 | 36% |
| Windows | $0.0160 | $0.0080 | 50% |
| macOS | $0.0800 | $0.0400 | 50% |

Runnerhut adds fast starts, 1 GB/s cache restore and persistent Docker builders
to those lower rates. Its [product page](https://runnerhut.com/) lists a
3-second runner start and twice-faster pipelines. Lower runner rates make every
CI minute cheaper. Faster builds consume fewer of those minutes in the first
place.

Runnerhut also bills per second after a one-minute minimum, with no cache,
egress, queue-time or concurrency charge. The free tier includes 3,000 Linux
minutes a month, enough to move a real workflow and watch the numbers before
you commit to a new CI bill.

## Runnerhut turns faster CI into a smaller bill.

The price and duration multiply. A runner at half the per-minute rate that
finishes the pipeline in half the time cuts compute spend by four. Runnerhut
optimises cache throughput, runner start time and Docker layers alongside the
per-minute price because a green pipeline matters more than an inexpensive slow
minute.

The service keeps GitHub Actions familiar. Install the GitHub App, swap the
`runs-on` label, then keep your actions, secrets and permissions exactly as
they are. Runnerhut adds managed caching, persistent Docker builders,
per-workflow cost analytics and EU-hosted compute without forcing a separate CI
product into the team.

## Your agent loop needs CI that keeps up.

There is no mystery in the compounding. A pull request produced by an agent
needs a test run. A failure leads to another patch and another test run. A
matrix multiplies the work. A flaky test adds a rerun. The bill follows the
loop, and so does the time between useful decisions.

Reliable CI has a boring job: start predictably, restore what the job needs,
run the same workflow it ran yesterday, report the cost, and get out of the
way. Runnerhut's one-line migration keeps that job small. Teams can trial it
without rewriting their pipeline or moving their deployment process to a new
control plane.

At [TextCortex](https://textcortex.com/), the bill made the case for us. In the
billing period immediately before we migrated our CI workflows to Runnerhut, we
paid about **€3,000** for GitHub Actions.

Runnerhut cut that spend drastically for us and made the CI/CD pipeline faster
and easier to operate. Runners start predictably, caches stay warm, and the
team can see what each workflow costs instead of treating the CI bill as a
monthly surprise.

Agentic development will keep increasing the code and test work flowing through
CI. Runnerhut gives that workload a simple home: the same GitHub Actions
workflow, faster runners, lower compute rates and a bill that stays legible as
the number of jobs grows.

That is why we moved TextCortex. CI had become production infrastructure for
our agents. Runnerhut made it cheaper and faster without turning migration into
another engineering project.
