Running AI Coding Agents on GitHub Actions

Overview

An AI coding agent runs on GitHub Actions the same way a human-triggered build does: a trigger starts a workflow, the job lands on a runner, and the exit code decides whether the change survives. What breaks under agent traffic is the environment, because an agent retries far more often than a person does, and every attempt on a stock runner reinstalls the same toolchain, refetches the same dependencies, and reseeds the same fixtures before it does one second of useful work.

Agent traffic on GitHub Actions arrives in three shapes, and they stress different parts of the setup.

The agent runs inside the job. A workflow_dispatch, an issue_comment, or a label event starts a workflow whose steps invoke an agent CLI on the runner. The agent edits files, runs the test command, reads the failures, and edits again, all inside one job. Environment setup happens once per job, and the agent loop happens inside it.

The agent runs elsewhere and drives workflows. The agent lives in a hosted session or on a developer machine and dispatches workflows through the API, then polls for the result. Each attempt is a fresh job, so environment setup happens on every attempt.

The agent opens pull requests that go through normal checks. The agent produces a branch and the existing pull request workflows grade it. Volume goes up because a machine opens more pull requests than a team does, and each one runs the full check matrix.

The second and third shapes are where per-job setup time turns into the dominant cost. A job that spends 15 minutes installing packages, restoring fixtures, and pulling images before running a 4 minute test suite is spending most of its billed minutes on work that was identical on the previous attempt.

Snapshot runners remove that repetition. A snapshot captures the runner VM disk at a chosen point in a workflow, and later jobs boot from that disk instead of from the base image, so packages, dependency trees, git working trees, and pulled container images are already there. Snapshot runners are supported on WarpBuild Cloud Ubuntu runners only. Putting a snapshot label on a BYOC, Windows, or macOS runner does nothing: the label is silently ignored and the job runs normally. The full behavior is documented on the snapshot runners docs page.

An agent workflow can target any of them; the snapshot path in this page applies to the Ubuntu labels.

Adaptive made WarpBuild snapshot runners the default environment for its AI code agents. The numbers from that deployment are in the Proof section below.

Configuration

The pattern is two workflows. One produces the snapshot from a trusted branch. The other consumes it on every agent attempt.

The workflow that produces the environment

This one runs on main, boots from the base image with snapshot.enabled=true, installs everything an agent attempt would otherwise install, strips credentials, and saves the disk under a stable alias.

name: agent-env
on:
  push:
    branches: [main]
  schedule:
    - cron: "0 6 * * *"

jobs:
  build-agent-env:
    runs-on: warp-ubuntu-latest-x64-4x;snapshot.enabled=true
    steps:
      - uses: actions/checkout@v5

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Build once so the agent starts from a warm tree
        run: npm run build

      - name: Pull service images used by the test suite
        run: |
          docker pull postgres:16
          docker pull redis:7

      - name: Seed test fixtures
        run: ./scripts/seed-fixtures.sh

      - name: Remove credentials before the snapshot is captured
        run: |
          rm -rf $HOME/.ssh $HOME/.aws $HOME/.npmrc
          git clean -ffdx -e node_modules

      - name: Save snapshot
        uses: WarpBuilds/snapshot-save@v1
        with:
          alias: "agent-env"
          fail-on-error: true
          wait-timeout-minutes: 60

Two details in that file matter more than they look. The cleanup step runs before snapshot-save, because anything on disk at capture time is on disk for every job that later boots from the alias. WarpBuild provisions runners at the organization level and GitHub can hand a snapshot-booted runner to a different job in the same organization, so treat a snapshot as shared state and never let a cloud credential into it. On a public repository the alias is reachable from a pull request workflow, which raises the same point with less ambiguity.

The git clean -ffdx -e node_modules line keeps the dependency tree while removing everything else untracked. Drop the exclusion if your agent runs npm ci anyway and you only want system packages and pulled images in the snapshot.

The workflow the agent runs

This one boots from the alias with snapshot.key, so the runner starts with the tree the previous workflow left behind.

name: agent-attempt
on:
  workflow_dispatch:
    inputs:
      task:
        description: Task description for the agent
        required: true
  issue_comment:
    types: [created]

permissions:
  contents: write
  pull-requests: write

jobs:
  agent:
    if: >-
      github.event_name == 'workflow_dispatch'
      || startsWith(github.event.comment.body, '/agent ')
    runs-on: warp-ubuntu-latest-x64-4x;snapshot.key=agent-env
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v5

      - name: Confirm the runner booted from the snapshot
        run: echo "snapshot=${WARPBUILD_SNAPSHOT_KEY:-none}"

      - name: Refresh anything that drifted since the snapshot
        run: npm ci --prefer-offline

      - name: Run the agent
        env:
          AGENT_API_KEY: ${{ secrets.AGENT_API_KEY }}
        run: ./scripts/run-agent.sh "${{ inputs.task || github.event.comment.body }}"

      - name: Test the agent output
        run: npm test

      - name: Open a pull request with the result
        if: success()
        run: ./scripts/open-pr.sh

The runs-on value is a single string: the runner label, a semicolon, then the snapshot directive. snapshot.enabled=true turns the feature on and always boots from the base image, which is what the producer workflow wants. snapshot.key=<alias> turns the feature on and boots from the existing snapshot for that alias, falling back to the base image when no snapshot exists yet. A runner booted from a snapshot exports WARPBUILD_SNAPSHOT_KEY with the alias, which is the cheapest way to assert in the job that the fast path actually happened.

Two limits belong in the design rather than in a postmortem. Snapshots are deleted after 15 days, so the producer workflow needs a schedule that fires more often than that; the daily cron above is deliberate. And /tmp does not survive, because the directory is cleaned on reboot and a snapshot boot is a reboot. Keep anything the agent should find under $HOME or inside the workspace.

Giving the agent a read path into the fleet

An agent that opens pull requests eventually needs to answer questions about its own jobs: which attempt failed, which runner label it used, how long the queue was. WarpBuild hosts a Model Context Protocol server at https://mcp.warpbuild.com/mcp. Generate an API key with the CI scope from the dashboard API keys page, then point the MCP host at the server:

{
  "mcpServers": {
    "warpbuild": {
      "url": "https://mcp.warpbuild.com/mcp",
      "headers": {
        "Authorization": "Bearer <API KEY>"
      }
    }
  }
}

The setup steps are in the MCP support docs. Scope the key to CI, keep it in the secret store the agent already uses, and rotate it on the same schedule as the rest of the agent's credentials.

Sizing

Agent loops produce many short jobs rather than a few long ones, so the sizing question is per-job overhead rather than peak throughput. Start from the Linux x64 catalog, taken from the WarpBuild pricing page and checked on 2026-08-13.

Linux ARM64 labels carry the same vCPU and RAM shapes at $0.003, $0.006, $0.012, $0.024, and $0.048 per minute. Runners bill per minute, so a shorter job is a smaller bill with no rounding surprise at the tail.

Against GitHub-hosted list prices

Every row below states both per-minute prices and the computed difference. GitHub rates come from the published Actions minute multipliers reference and the shapes from the GitHub-hosted runners reference, both checked on 2026-08-13.

GitHub gives public repositories a 4 vCPU, 16 GB shape at no charge, so the first row compares the private-repository shape that paying teams actually run.

Where the snapshot fee breaks even

Snapshots carry two line items on top of runner minutes. A restore bills $0.04 for each job that boots from a snapshot. Storage bills $0.025 per snapshot-hour, which is $0.60 per day and $18.00 per 30-day month for one alias kept alive continuously.

The restore fee is a fixed amount, so its break-even point moves with the runner label. Divide $0.04 by the per-minute rate to get the setup time a snapshot has to remove before it pays for itself.

Read that table the practical way. On a 2 vCPU label, a snapshot that saves 3 minutes of npm ci costs more than it returns. On a 16 vCPU label running a fixture-heavy suite, the same 3 minutes clears the bar with room to spare. The bigger the label, the smaller the setup time a snapshot needs to remove.

A worked monthly model

Take an agent loop that dispatches 3,000 attempts a month, on warp-ubuntu-latest-x64-4x at $0.008 per minute. Assume 15 minutes of environment setup on a base-image boot, 4 minutes of agent and test work, and 1 minute budgeted for the snapshot boot, which the docs put at 45 to 60 seconds. One alias stays alive for the whole month.

At these inputs the snapshot column lands $198.00 lower per month. Substitute your own setup time and attempt volume before deciding anything; the arithmetic is the point, and the shape of the answer flips when setup is short or volume is low.

Every cost figure on this page carries the per-minute rate it came from, a source, and the date it was checked.

Bottlenecks

Environment setup

This is the one that matters for agent traffic, and it is the reason the snapshot pattern exists. Setup work is identical across attempts by construction, so paying for it on every attempt is paying for a constant.

The failure mode to watch is a producer workflow that stops running. Snapshots are deleted after 15 days, so an alias whose producer broke three weeks ago is quietly falling back to base-image boots at full setup cost, and nothing in the job output announces it. The WARPBUILD_SNAPSHOT_KEY echo in the consumer workflow above turns that into a visible line in the log.

Snapshot drift

A snapshot is a point in time. A lockfile change on main after the snapshot was captured means the boot disk carries a stale dependency tree, and the agent works against the wrong versions until the next producer run. Two habits keep that under control: run the producer on every push to main plus a daily cron, and keep a cheap refresh step such as npm ci --prefer-offline in the consumer workflow so a drifted tree corrects itself instead of failing strangely.

State that does not survive a boot

The snapshot supplies a disk. It does not supply running processes. No service from the producer job is up, no port is listening, and no container is running when the consumer job starts, so anything the agent depends on has to be started by the job itself. /tmp is cleaned on reboot, and the job's GitHub identity is fresh on every run: new registration, new token, new secrets from the workflow.

Credentials inside the snapshot

An agent job usually carries more credentials than a normal build, because it writes branches and opens pull requests. Every one of those is a reason to keep the cleanup step in the producer workflow. Capture the snapshot after removing $HOME/.ssh, $HOME/.aws, registry tokens, and untracked files, and let the consumer job receive its credentials from GitHub secrets at run time.

Platform limits

Snapshot runners are supported on WarpBuild Cloud Ubuntu runners only. BYOC runs on AWS, GCP, and Azure, and BYOC runners are the right choice when agent jobs need to sit inside your own account and network, but snapshot labels there are silently ignored. The same applies to Windows and macOS labels. If an agent workflow spans platforms, keep the snapshot path on the Ubuntu jobs and size the others normally.

Reading what the agent actually did

Once attempts are running at volume, the interesting questions are aggregate: which job regressed, which label queues, which attempt burned 30 minutes before timing out. CI observability collects per-runner utilization and correlates it with GitHub Actions logs, and GitHub Actions observability and runner metrics covers what it records and how to query it. Pair that with the MCP server above and the agent can answer those questions in its own session rather than waiting for a person to open a dashboard.

Proof

Adaptive builds financial infrastructure for construction, and it made WarpBuild snapshot runners the default environment for its AI code agents, with tests, packages, integrations, and secrets pre-loaded in each environment. Adaptive reports a 60 percent reduction in manual engineering intervention per feature after that change. The full write-up is on the Adaptive case study.

That deployment is the reference implementation for everything above: a prepared environment produced once, consumed by every agent attempt, with the engineering time that used to go into per-attempt scaffolding going somewhere else.

Agents run with credentials and touch source code, so the compliance question arrives early. SSO is available for a flat $250 per month, whatever the user count, listed on the pricing page.

Three companion pages go deeper than this one does:

• Snapshot runners for GitHub Actions covers the label syntax, what a snapshot holds, and the storage and restore line items in detail.
• Connect the WarpBuild MCP server to an AI assistant covers the full MCP host setup.
• Can AI agents run GitHub Actions jobs? is the short answer version of this page.

FAQ

Can an AI coding agent run its own GitHub Actions jobs?

Yes. An agent job is an ordinary GitHub Actions job: a trigger such as workflow_dispatch, issue_comment, or a label event starts it, the job runs on a runner label you choose, and the exit code is the signal the agent reads. On WarpBuild the label is a warp- label, and the agent process runs as a step inside that job with whatever credentials the workflow grants it.

How do I stop an agent from reinstalling the toolchain on every attempt?

Boot the job from a snapshot. Add snapshot.key=<alias> to the runs-on label and the runner starts from a disk captured by an earlier job, with packages, dependency trees, checkouts, and pulled container images already present. Snapshot runners are supported on WarpBuild Cloud Ubuntu runners only, so BYOC, Windows, and macOS labels ignore the snapshot label silently and the job runs normally without it.

What does the snapshot restore fee mean for short agent jobs?

A restore bills $0.04 for each job that boots from a snapshot, and snapshot storage bills $0.025 per snapshot-hour. At $0.008 per minute on warp-ubuntu-latest-x64-4x, $0.04 is the price of 5 minutes of runner time, so the fee pays for itself once the snapshot removes more than 5 minutes of setup from the job. On warp-ubuntu-latest-x64-2x at $0.004 per minute the same fee is 10 minutes of runner time.

How does an agent query the WarpBuild runner fleet directly?

WarpBuild hosts a Model Context Protocol server at https://mcp.warpbuild.com/mcp. Generate an API key with the CI scope from the dashboard, add the server URL to your MCP host with an Authorization Bearer header carrying that key, and the agent can drive the WarpBuild API from its own session.