GitHub Actions cost with AI coding agents: the duplicate runs behind the bill, and cheaper runners

When a GitHub Actions bill jumps after coding agents start opening pull requests, the most likely cause is the same commit being tested more than once: every agent push runs the full suite, superseded runs keep going, and push, pull_request and merge_group triggers fire on one SHA. Count workflow runs per commit before changing anything else: one per workflow is healthy, and public issues from October 2026 show two or three, and one Camunda pull request put the waste at about 80 runner-minutes per merge. Switching runners comes second; Blacksmith, Namespace and Ubicloud list a minute at 33% to 79% less than GitHub.

Why did my GitHub Actions bill triple after coding agents? #

A GitHub Actions bill triples with agents because agents push more often than people, and CI runs on every push. On 23 October 2026, a developer running two private web apps posted on Reddit that "my September Actions bill was about $738, and my October usage was heading towards roughly $2,300–$2,450. Almost all of that is Linux runner time".

At GitHub's $0.006 per Linux minute, that is about 123,000 minutes in September and 383,000 to 408,000 projected for October, a 3.1x to 3.3x jump (my arithmetic, before included minutes). The poster runs unit, database and browser tests through a Mergify merge queue, and works with coding agents, "so there can be quite a lot of changes and test runs". One commenter: "My bill roughly tripled when I started letting an agent run CI on every commit it pushed." The previous Stackness post on CI covered queue time; this one covers the invoice, most common cause first.

Agent pushes run the full suite and superseded runs keep going #

An agent that pushes three commits in a minute starts three full runs, and without a concurrency block all three finish, though only the last commit will ever merge. In one repository, "Agents push to branches about every 25 minutes", and another found "Every force-push during review costs a full wasted run."

To check, list a pull request's runs: successful runs on commits that were later replaced should show as cancelled. The fix, from GitHub's docs, cancels in-progress runs for pull requests only, and keys the group on the workflow name so two workflows do not cancel each other:

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

The same commit runs twice from push plus pull_request #

A workflow with both on: push and on: pull_request runs every commit on a pull request branch twice, once per event. One issue from 23 October describes it: "Every update to a branch with an open pull request therefore launches two identical full matrices for the same commit." Another repository counted about 157 runner-minutes for one change across its pull request and post-merge runs, and "about half of it re-tests a tree that has already passed".

To check, group recent runs by commit and workflow. This reads the last 100 runs from the runs API and prints every commit that ran one workflow more than once (add an Authorization: Bearer header for a private repository):

curl -s "https://api.github.com/repos/OWNER/REPO/actions/runs?per_page=100" | jq -r '.workflow_runs
  | map(select(.event == "push" or .event == "pull_request" or .event == "merge_group"))
  | group_by(.head_sha + .path) | map(select(length > 1))[]
  | "\(.[0].head_sha[0:7])  \(.[0].path)  \(map(.event) | join(" + "))"'

Run against redhat-et/ProtoBot on the morning of 25 October 2026, it printed the lines below; the last 100 runs change within hours, so yours will differ:

4da0533  .github/workflows/ci-workflow.yaml  push + push + merge_group
a3d744f  .github/workflows/ci-workflow.yaml  pull_request + push

The fix is to limit push to the default branch and let pull_request cover branches. Drop the post-merge push run too only if what merges is the tree that was tested.

Merge queues test the same change again, and rebuild after failures #

A merge queue reruns CI on every entry by design, and adds two kinds of waste on top: duplicate triggers on the queue branch, and rebuilds after a failure.

First, GitHub's queue builds on branches named gh-readonly-queue/..., so an unfiltered push trigger runs alongside merge_group on the same commit; one such issue estimates about 10 runner-minutes wasted per queue attempt. The run after merging can repeat it again: at Camunda, the merge_group run and the post-merge push run tested the same SHA, "about 80 runner-minutes wasted per merge", until it dropped one of the two triggers on 19 October. Second, a failure throws away work: when an entry fails, GitHub's queue rebuilds the entries behind it, and Mergify cancels later batches and puts their pull requests back in the queue.

To check, count merge_group runs per merged pull request; a ratio well above one means rebuilds. Look for runs with event: push on gh-readonly-queue/ branches. The fix for the duplicate is one line:

on:
  push:
    branches-ignore: ["gh-readonly-queue/**"]
  merge_group:

The fix for rebuilds is fewer failures in the queue, which leads to the next cause.

Flaky tests, re-runs, rounding and missing timeouts all bill again #

Every re-run is billed again; re-running only the failed jobs bills only those jobs. GitHub's own example: a 10-minute workflow that fails at minute 5 and is re-run costs 15 minutes. Each job is also rounded up to a whole minute, so ten 10-second gate jobs bill 10 minutes, and a job with no timeout-minutes can run for the default 360 minutes before GitHub cancels it.

To check, look for run_attempt above 1 in the runs API, and for job durations near 360 minutes or under 60 seconds. Read a failure before pressing re-run; fix or quarantine the flaky test; set timeout-minutes on every job; merge tiny jobs into one.

Copilot and claude-code-action spend minutes on the agent's own work #

Some agents run on Actions themselves, so they bill minutes before any CI starts. GitHub Copilot's cloud agent sessions use "both GitHub Actions minutes and premium requests", Copilot code review has used Actions minutes on private repositories since 1 June 2026, and the GitHub Action for Claude Code "runs on GitHub-hosted runners, which consume your GitHub Actions minutes". Codex cloud and Cursor's cloud agents run on their own machines; only the CI their pull requests trigger is yours.

To check, group the detailed usage report by workflow_path, the only report that has it. Group by sku first to confirm the money is Linux minutes, not storage or larger runners:

The Actions usage chart grouped by SKU, with GitHub's example data. Screenshot from GitHub Docs by GitHub, CC BY 4.0.

The fix is to cap turns and timeouts for Claude Code runs, and to keep GitHub Copilot's default, where its pushes run no workflows until someone clicks "Approve and run workflows".

What does a GitHub Actions minute cost against Blacksmith, Depot and Namespace? #

A 2-vCPU Linux minute on GitHub Actions costs $0.006 since GitHub's price cut of 1 January 2026, down from $0.008. Third-party runners run the same workflows after a change to the runs-on: label, and most charge less per minute; Depot now charges the same. List prices for a 2-vCPU Linux runner, read on 25 October 2026:

Priced at these rates, the Reddit poster's projected October minutes would cost about $1,530 to $1,630 on Blacksmith, $770 to $820 on Ubicloud premium and the same as GitHub on Depot, before any speed-up (my arithmetic, list prices, no free tier). The poster is moving jobs to Ubicloud and reported a pilot "51% lower", without showing the numbers. A cheaper minute does nothing about minutes that should not run.

On Stackness, GitHub Actions is on 6 public stacks as of 25 October 2026, bots removed (how I count), and none lists Blacksmith or Depot yet; the DevOps and infrastructure tools developers use show the rest of the CI picture.

Are self-hosted runners worth it for an agent-heavy repo? #

Self-hosted runners cost nothing per minute on GitHub as of 25 October 2026: the $0.002 platform charge announced for March 2026 was postponed, not cancelled. You pay in upkeep instead. GitHub stops queuing jobs on a runner that misses an update for 30 days, recommends ephemeral autoscaled runners, and warns that anyone who can open a pull request can compromise a self-hosted runner.

Agent-written code is untrusted in the same way, so a reused machine on a desk is the riskiest setup. RunsOn is the middle ground: fresh machines in your own AWS account, with the lifecycle managed. And on a single self-hosted runner, duplicate runs stop costing dollars and start costing queue time, 47 minutes in one of the issues above.

Move the browser suite to the merge queue, keep lint and unit tests on every push #

The checks that can leave every push are the slow ones the merge queue repeats anyway: browser tests, end-to-end suites with a database, long integration matrices. Lint, type checks and unit tests stay on every push; the full suite runs once, on merge_group. The Reddit poster split CI this way. The commenter whose bill tripled split the pipeline and added concurrency groups, and reported "Cut minutes by about 60% without losing the safety net", an unmeasured figure from one repo.

Two GitHub rules decide whether the split keeps the safety net. A workflow skipped by a paths filter leaves its required check "Pending" and blocks the merge; a job skipped by if reports "Success", even when it is a required check. Mergify can batch several pull requests into one run, at a price it names itself: "hidden failures inside a passing batch can land on main".

GitHub Actions bill: symptom, check, fix #

New posts by email #

About one email a week with what we published. No account needed.

Which of these do you use? #

Nobody on Stackness runs Blacksmith yet. Tick what you use and be the first.

Play Lonny Eagle Amateur Skater 4A pixel art skateboarding game. Signing up opens it straight away.Sign up to play