Promigence blog: Guides

Best CI runner for GitHub Actions in 2026: hosted and self-hosted alternatives

Harshraj — Sun, 25 Oct 2026 12:00:00 GMT

Most GitHub Actions workflows start on ubuntu-latest and stay there until a job runs out of memory, the bill climbs or the queue grows. On a private repository that runner has 2 CPUs and 8 GB of memory, and GitHub rounds every job up to the whole minute. Five ways to run the same jobs are compared here: the change each one needs in the workflow, the sizes it offers, how it bills, how you control spend and what you have to maintain. Our own product, Promigence, comes first; every fact about the others comes from that vendor's own pages, listed under Sources.

Key takeaways

Workflow change: every hosted option here moves a job by changing its runs-on label. Promigence's hosted runners also need the repository added under Runners in the console, and Blacksmith and Depot need their GitHub App installed on an organization.
Billing unit: Promigence bills each job for the seconds it runs. GitHub rounds each job up to the whole minute, Blacksmith prices by the minute, and Depot tracks runner time by the second with no one-minute minimum per run.
Spend control: with the Promigence runner command, --cap sets the most one job may cost. GitHub's budgets, Blacksmith's spending alert and Depot's usage caps cover an account's spend or minutes over a period.
Sizes and systems: GitHub runs Linux, Windows or macOS jobs, with Linux and Windows sizes up to 96 vCPU and a GPU size. Blacksmith runs Ubuntu on x64 and Arm up to 32 vCPU, Windows in public beta and macOS on Apple M4. Depot goes up to 64 vCPU on Intel or Arm and also runs Windows and macOS, with GPUs on its Business plan.
Public repositories: GitHub's standard runners are free and unlimited there.
Upkeep: self-hosted runners give the most control and leave every update with you, and on GitHub Enterprise Server they are the only runners GitHub supports.

The best CI runners for GitHub Actions in 2026

1. Promigence

Here, every GitHub Actions or GitLab CI job gets its own sandbox. One line of the workflow changes, runs-on: promigence, and the steps and caches stay where they are, as do the repository secrets. The runners are hosted by Promigence AI once the repository is added in the console, or you start your own with one command on a machine of yours.

Key features

Hosted runners: open Runners in the console, choose Add a repository and pick it from a GitHub account you connected. Its jobs then run on runners we host, each in a fresh sandbox, with nothing to keep running on your side. Up to 10 of the repository's jobs run at once unless you change it there.
Sizes by label: promigence-small (2 vCPU, 4 GiB), promigence-medium (4 vCPU, 16 GiB) and promigence-large (8 vCPU, 32 GiB). A job that says only promigence gets medium on hosted runners, or the size you set for the repository in the console.
Your own runners: promigence runners github --repo OWNER/REPO takes queued jobs with a matching label until you press Ctrl-C. --org ORG covers every repository in an organization, --runner-group NAME places the runners in a group, and --github-api URL points the command at GitHub Enterprise Server.
Per second, with limits per job: every job is billed for the seconds it runs. With the command, --cap sets the most one job may cost, --timeout the longest it may run and --max how many sandboxes run at once.
Queue time is your choice: runners start on demand when a job is queued, and --warm N keeps N runners waiting so a job starts the moment it is queued. Waiting runners are billed while idle.
GitLab CI from the same tool: a project runner tagged promigence on hosted runners, or promigence runners gitlab with the docker executor (the default) or shell. A self-managed GitLab takes --url.

Where it fits

It suits teams whose jobs have outgrown the default runner or whose bill comes from many short jobs. A job that needs more memory names a bigger size in its label, and per-second billing means a short job pays for its seconds instead of a rounded-up minute. Moving one workflow is a one-line change you can undo, since the steps and the cache actions stay as they were.

Platform teams that want a ceiling on CI spend get one per job. With the runner command, every job has a cap, by default what its full timeout costs at its size, and --max holds how many sandboxes run at once, so a large matrix runs inside limits you set. Capacity follows the plan: 20 sandboxes at once on Free, up to 100 on Pro and up to 500 or 1,000 on Max.

It also fits teams that run more than one CI system or already use Promigence for agents. The same CLI takes GitHub Actions jobs, GitLab CI jobs and jobs from GitHub Enterprise Server, and teams running coding agents or evals on Promigence keep CI on the same account and the same bill. The runner image carries git and Python plus a compiler toolchain, so a job adds its language runtime with the usual setup step, such as actions/setup-node. Job logs stay in GitHub or GitLab, where your team already reads them.

Ideal for

Repositories whose jobs run out of memory on ubuntu-latest and need a bigger size for some jobs only.
Projects with many short jobs, where rounding every job up to a minute adds up.
Platform teams that want a limit on what one CI job may cost.
Companies on both GitHub Actions and GitLab CI, or on GitHub Enterprise Server, that want one runner tool.
Coding-agent and eval teams already on Promigence that want CI on the same account.
Engineers who want to start and stop their own runners with one command and a token they control.

2. GitHub-hosted runners

GitHub's own runners are the default for GitHub Actions: virtual machines GitHub hosts, with the runner application and other tools preinstalled, and machine maintenance and upgrades taken care of for you. A job picks one by label, such as ubuntu-latest, and apart from the single-CPU runners each job gets a new virtual machine.

Key features

Standard runners on Linux, Windows or macOS, on x64 and arm64. On a private repository the Linux and Windows runners have 2 CPUs and 8 GB of memory, and on a public one 4 CPUs and 16 GB.
Free and unlimited standard runners on public repositories. Private repositories get included minutes each month: 2,000 on Free, 3,000 on Pro or Team, and 50,000 on Enterprise Cloud.
Per-minute rates, with each job rounded up to the whole minute: $0.006 for 2-core Linux x64, $0.005 for 2-core Linux arm64, $0.010 for 2-core Windows and $0.062 for macOS.
Larger runners on the Team and Enterprise Cloud plans: Linux and Windows up to 96 vCPU and 384 GB, arm64 up to 64 vCPU, a GPU size with one Tesla T4, and larger macOS sizes. Enterprise Cloud customers can give larger runners static IP addresses.
A single-CPU ubuntu-slim runner for light tasks, with a 15-minute job limit.
Concurrent jobs by plan: 20 on Free, 40 on Pro, 60 on Team and 500 on Enterprise. A job can run for up to 6 hours.

Where it fits

GitHub-hosted runners are the place to start, and for many repositories the place to stay. There is nothing to install, no extra account and no token to manage, and GitHub keeps the machines and the images current. Open-source projects get standard runners free and without limit, which none of the other options here offers.

They also cover the widest range of systems and sizes on this list: Linux, Windows or macOS, x64 or arm64, a GPU size, and larger runners up to 96 vCPU. Workflows that build for several platforms can keep every job on one provider and one bill.

The cost grows with size and length. Each job is rounded up to the whole minute, larger runners are always billed (included minutes never cover them), and GitHub notes that a larger runner may not have a warm machine ready on the first request. Budgets can limit what the account spends. There are no GitHub-hosted runners on GitHub Enterprise Server, so teams there run their own.

Ideal for

Public repositories and open-source projects, where standard runners are free and unlimited.
Small teams whose private repositories fit inside the included minutes.
Workflows that need macOS, Windows or a GPU size.
Very large jobs that need more than 64 vCPU, up to 96.
Organizations on Enterprise Cloud that need static IP addresses for larger runners.
Anyone who wants nothing outside GitHub to set up or pay for.

3. Blacksmith

Blacksmith is a hosted runner service for GitHub Actions. An organization installs the Blacksmith GitHub App, then points runs-on at a Blacksmith tag such as blacksmith-2vcpu-ubuntu-2404, by hand or with its Migration Wizard. The runners boot from the same images as GitHub's runners, so the preinstalled software matches.

Key features

Ubuntu on x64 and Arm from 2 to 32 vCPU (up to 128 GB of memory on x64), Windows Server 2025 in public beta, and macOS on Apple M4 with 6 or 12 vCPU.
Per-minute rates: $0.004 for 2 vCPU Ubuntu x64, doubling with each size up to $0.064 at 32 vCPU; $0.0025 for 2 vCPU Arm, $0.008 for 2 vCPU Windows and $0.08 for 6 vCPU macOS, with 3,000 free minutes a month.
Every size available on demand, with no concurrency limits; Linux and Windows jobs run on ephemeral machines.
A cache that the official GitHub and popular third-party cache actions use as they are, with 25 GB of free storage per repository each week. Docker layer caching and sticky disks are $0.50 per GB a month.
Run history, log search, test analytics and CI analytics, plus SSH into a running job, which an admin turns on and which costs nothing extra.
Static IP addresses at $100 per IP a month, a monthly spending alert by email, and GitHub Enterprise Server or Enterprise Cloud with data residency, set up through Blacksmith's support team.

Where it fits

It suits teams that want hosted runners with the same software as GitHub's on different hardware. Because its runners start from GitHub's own images, a workflow that relies on a preinstalled tool keeps working after the label changes, and the Migration Wizard updates the labels in your workflow files. According to Blacksmith, its jobs run on gaming CPUs with higher single-thread performance.

It also sells the tools around CI. The standard cache actions use its cache unchanged, Docker builds can reuse cached layers, and run history, log search and test analytics show where time goes. When a job misbehaves, an admin can turn on SSH into the running job to inspect it.

Setup leaves no standing credentials: the GitHub App registers runners as they are needed, and the docs say no personal access tokens or deploy keys are involved. It serves GitHub organizations, not personal repositories, and Windows runners are still a public beta. The Enterprise plan adds a 99.9% SLA, 24/7 priority support and a dedicated Slack channel.

Ideal for

Organizations on GitHub that want hosted runners with the same preinstalled software as GitHub's.
Heavy Docker builds that gain from Docker layer caching.
Engineering teams that want CI observability: log search, test analytics and SSH into a running job.
Arm and Windows workflows that want a lower per-minute rate than GitHub's standard runners.
macOS jobs that should run on Apple M4.
Enterprises that want an SLA and GitHub Enterprise Server support.

4. Depot

Depot sells GitHub Actions runners alongside its container builds. An organization owner connects the Depot organization to GitHub and installs the Depot GitHub App, and from then on switching a job is one label, such as runs-on: depot-ubuntu-24.04.

Key features

Ubuntu from 2 vCPU and 8 GB up to 64 vCPU and 256 GB, on Intel or Arm at the same prices; Windows from 2 to 64 vCPU; macOS on M2 and M4 with 8 vCPU and 24 GB; GPU runners on the Business plan.
Runner time tracked by the second, with no one-minute minimum per run, and the minutes added up at the end of the billing period.
Plans: Developer at $20 a month with 2,000 GitHub Actions minutes and one user, Startup at $200 a month with 20,000 minutes and unlimited users, and Business on custom pricing. Past the included minutes, a 2 vCPU Linux runner is $0.006 a minute, and each size up doubles the rate.
No concurrency limits, cache size limits or network limits.
A cache built into the runners with no configuration, and container builds that run next to the runner.
Ephemeral machines that are never reused, monthly usage caps on GitHub Actions minutes, and egress filtering to control which services a runner can reach.

Where it fits

It fits teams whose CI is mostly short jobs and container builds. Runner time is tracked by the second with no one-minute minimum per run, so a pile of small jobs is not rounded up job by job, and a container build sent to Depot runs on a builder next to the runner.

Its plans bundle minutes. The $20 Developer plan includes 2,000 a month for one user, the $200 Startup plan 20,000 for unlimited users, and every plan has unlimited concurrency. Intel and Arm runners cost the same at every size, which suits teams that build for both.

Control comes from the account: a monthly cap on minutes, egress filtering for the runners, and machines that are never reused. Two limits come from its own pages: the runners serve repositories owned by GitHub organizations only, which Depot puts down to a GitHub limitation, and macOS jobs can wait longer at times of high demand.

Ideal for

Short-job pipelines that want runner time tracked by the second.
Teams that also build container images and want those builds next to the runner.
Companies that want unlimited concurrency on a fixed monthly plan.
Arm workloads that should cost the same as Intel.
Builds that need GPU runners or 64 vCPU sizes.
Security-minded teams that want egress filtering on their runners.

5. Self-hosted runners

Self-hosted runners are GitHub's runner application on machines of your own, for one repository, an organization or a whole enterprise. Actions usage is free on them, and you pay for the machines and keep them running.

Key features

More control of hardware, operating system and software tools than GitHub-hosted runners provide.
No minutes billed by GitHub; the cost is the machines and their upkeep.
A job can run for up to 5 days and can wait in the queue for up to 24 hours.
Ephemeral, just-in-time runners take at most one job before they are removed.
Machines register with a time-limited token that expires after one hour.
The only runners GitHub supports on GitHub Enterprise Server.

Where it fits

Self-hosting fits companies that already run machines and want CI on them: special hardware, a private network, or software that has to be installed a certain way. Jobs can run for days, well past the 6-hour limit on GitHub's runners.

The work is yours. According to GitHub, you are responsible for updating the operating system and all other software, and a self-hosted runner need not have a clean instance for every job. Adding runners as the queue grows is yours to automate.

Self-hosted runners should almost never be used for public repositories, GitHub's security guide says, so this option is for private code. It is also the only option GitHub offers on GitHub Enterprise Server.

Ideal for

Anyone on GitHub Enterprise Server.
Jobs that need special hardware or access to a private network.
Long jobs, up to 5 days.
Operations teams that already maintain machines.
Private repositories whose CI must stay on company machines.

What sets Promigence apart

A cap on each job

The promigence runners command gives every job a limit on what it may cost. --cap sets it, and by default it is what the job's full timeout costs at its size, so no single job can run up the bill past that. --max holds how many sandboxes run at once. Budgets on GitHub, Blacksmith's spending alert and Depot's usage caps limit an account's spend or minutes over a period, never one job.

Billed for the seconds a job runs

Every job is billed for the seconds it runs, on hosted runners and with the command. By comparison, GitHub rounds every job up to the whole minute and Blacksmith prices by the minute, while Depot tracks time by the second and totals the minutes at the end of the billing period. For GitHub Actions jobs, waiting runners (--warm) are the one setting billed while nothing runs, and they stay off unless you ask for them.

One runner for GitHub Actions and GitLab CI

The same CLI runs GitHub Actions and GitLab CI jobs, on runners Promigence AI hosts or on runners you start yourself, and the command serves GitHub Enterprise Server with --github-api. Each job gets a fresh sandbox, and its log stays in GitHub or GitLab, where your team already reads it.

Frequently asked questions

What is the best CI runner for GitHub Actions in 2026?

It depends on the problem. Keep public repositories on GitHub's standard runners, which are free and unlimited there. For private repositories where job size, short-job billing or spend control is the problem, Promigence runners take one label, bill per second and, with the runner command, put a cap on each job. Among the others, Blacksmith runs GitHub's own runner images on its hardware, Depot bundles minutes with container builds, and self-hosted runners suit GitHub Enterprise Server.

What are cheaper GitHub Actions runners?

Compare the rate at the size your jobs need and how each service counts time. At 2 vCPU on Linux, GitHub lists $0.006 a minute with each job rounded up, Blacksmith $0.004 a minute for Ubuntu x64, and Depot $0.006 a minute with time tracked by the second. Our runners bill each job per second at the rates on the pricing page. Because GitHub bills no Actions minutes for jobs on self-hosted runners, which is how these services register theirs, only the runner service bills those jobs.

Blacksmith vs Depot vs other GitHub Actions runners: how do they compare?

All three move a job with a one-line runs-on change. Blacksmith's runners cover Ubuntu on x64 and Arm up to 32 vCPU, Windows in public beta and macOS on M4, from GitHub's own images, with 3,000 free minutes a month, log search and SSH into a running job. Depot's runners go up to 64 vCPU on Intel or Arm, with Windows and macOS and GPUs on Business, track time by the second and start at $20 a month for 2,000 minutes. Promigence's runners give each job a fresh sandbox, bill per second with a cap per job on the runner command, and take GitLab CI jobs with the same tool.

How do I compare runner speed?

Speed depends on the job: how much it downloads, how well it caches and how many cores it can use. Vendors publish their own claims, so measure on your own workflow. Run the same job on each runner for a week, then compare the job durations in the Actions tab and the bills.

Can one runner service handle both GitHub Actions and GitLab CI?

Yes, on Promigence: runs-on: promigence in GitHub Actions and a runner tagged promigence in GitLab CI, on hosted runners or with promigence runners gitlab. The runners GitHub hosts serve GitHub Actions only. Blacksmith's documentation covers GitHub Actions, and Depot's GitLab CI integration is for its container builds.

Try Promigence free

All plans start with $50 of free credit. Create an account and follow the quickstart, then move one workflow with the GitHub Actions runner guide: change runs-on to promigence, add the repository under Runners in the console, and compare the job log and the bill with the original over a week.

Sources

These vendor pages were read on 25 Oct 2026. Prices and limits change, and each vendor's own page is the authority.

Platform	Pages	Checked
Promigence	GitHub Actions runner guide, CI runners, Pricing	25 Oct 2026
GitHub	GitHub-hosted runners, GitHub-hosted runners reference, Larger runners, Larger runners reference, Actions runner pricing, GitHub Actions billing, Actions limits, Secure use reference, Self-hosted runners, Adding self-hosted runners, Runner groups, GitHub Actions for GitHub Enterprise Server	25 Oct 2026
Blacksmith	Quickstart, Instance types, Pricing, GitHub App, GitHub Enterprise, Settings, Sticky disks, SSH access, Static IP	25 Oct 2026
Depot	GitHub Actions runners, Quickstart, Runner types, Pricing, Usage caps, Egress filtering	25 Oct 2026

If anything on this page is out of date or wrong, write to support@promigence.ai and we will correct it and note the date.

Time to feedback: the delay that matters for coding agents

Harshraj — Mon, 19 Oct 2026 12:00:00 GMT

Does sandbox start time matter for AI coding agents?

For a coding agent, the delay that decides how long a task takes is the edit-then-check loop: change a file, run the type-checker or the tests, read the result, go again. One task repeats that loop dozens of times. The sandbox starts once. So a check that runs a few seconds slower than it should can cost more over a task than a slow start, and the loop is the thing to measure first.

What one step of the loop is

A coding agent works in steps. The model reads the code and decides on a change, the agent applies it, and then it runs a check to learn whether the change worked. The check is whatever your project uses to tell right from wrong: a type-check, a build, a test file or a linter. Its output goes back to the model, which plans the next edit.

Reading and deciding belong to the model. Applying the edit and running the check happen in the environment, and that half is what your infrastructure decides. Promigence's own site states the belief behind this post plainly: time to feedback is the delay that matters in an agent loop, and cold start is a small part of it.

The arithmetic

Here is a worked example. The step count and the slow check time are example inputs, so put in your own; the other figures are measured numbers from the Promigence home page.

One task, 40 edit-then-check steps (example count)

Measured step, warm repository:   40 × 0.66 s  = 26.4 s
Example slow check:               40 × 30 s    = 1,200 s, or 20 minutes
Sandbox ready, paid once:         8 ms         = 0.008 s

The measured step is an edit followed by a type-check on a warm repository, with 4 vCPU: 0.66 s at the median, 0.80 s under load (n = 30). The ready time is from create to first command at 2 vCPU / 4 GiB: 8 ms at the median, unloaded (n = 100).

Put those side by side. At the measured step time, 40 steps spend 26.4 seconds in the environment, and the start is about 0.03% of that. At 30 seconds a check, the same task waits 20 minutes on checks. No start time gets that back.

The model's own thinking time comes on top in both cases. It does not change with the environment, which is why the environment's half of the step is the part worth working on.

The home page also times a whole task: 20 steps on a 3 GB repository, 43.7 s at the median, 58.0 s under load (n = 30).

Why the loop gets slow

From where you sit, a slow check usually has one of a few causes.

Setup is inside the loop. If the environment does not already have the project installed and built, the first check pays for the install and the build. If every step gets a fresh environment, every check pays it.

The check runs somewhere else. An agent that pushes a branch and waits for a CI run, or copies the repository to another machine to test it, pays the queue and the transfer on every step.

The check does more than the step needs. Running the whole suite after a one-line change is slower than running the tests that cover it, and that part is yours to tune whatever environment you use.

What keeps the loop short

Start the agent on a project that is already installed and checked. Build a snapshot once: your repository at a pinned commit, the install and the build as setup steps, and your own test command as the verify step. A snapshot whose verify command fails is never stored, so an agent never starts on a broken environment. Every sandbox started from a good snapshot opens with that work done, and the agent's first check runs against a project that is ready.

Run the check where the code is. The agent edits files in the sandbox and runs the check in the same sandbox, on the same files, with no push and no queue in between. From the command line that is promigence exec --sandbox <id> -- <your check command>, and the SDKs have the same call.

Keep one sandbox for the whole task. A fresh environment per step brings setup back into the loop. If the task waits on a person between sessions, pause the sandbox: paused time is not billed, and waking a paused sandbox took 104 ms at the median from resume to the first database query (n = 100), 127 ms under load.

Size it for the check. The measured step above ran on 4 vCPU, and a new account can use sizes up to large, with 8 vCPU.

How to measure your own

Time the edit-then-check step where the agent runs it, enough times to get a median:

# in the environment your agent uses: one small edit, then your check, 20 times
TIMEFORMAT=%R
for i in $(seq 1 20); do
  { time sh -c '<apply one small edit> && <your check command>' >/dev/null 2>&1 ; } 2>&1
done | sort -n

With 20 sorted times, the median sits between the 10th and the 11th line. Then do three more things with it.

Measure the first check apart from the rest. A first check far slower than the others means setup is leaking into the loop.

If your agent drives the environment over the network, time the step from the agent's side too. Each call adds your network's round trip, and the agent feels that as part of the step.

Count the steps in a real task from your agent's logs and multiply. That product is your time to feedback per task. Put the start time you were worried about next to it.

To try the same loop on Promigence, build a snapshot of your project, start one sandbox from it, and run the loop above inside it with promigence exec. The quickstart covers the snapshot, and running a coding agent in a sandbox covers the agent. To get started, leave your work email on www.promigence.ai or write to support@promigence.ai.

FAQ

What is time to feedback for a coding agent?

It is how long the agent waits between making a change and learning whether it worked: applying the edit, running the check and getting the result back. The agent pays it on every step of a task, so it adds up fast.

Does sandbox start time matter for coding agents?

Less than the loop does. A start is paid once per task and a check on every step. On Promigence's measured numbers a sandbox is ready in 8 ms and one edit-then-check step on a warm repository takes 0.66 s, so over 40 steps the start is about 0.03% of the time spent checking.

How do I measure my agent's time to feedback?

Run one small edit and your check command 20 times where the agent works, take the median, and multiply it by the number of steps in a real task from your agent's logs. Time the first check on its own as well, because a slow first check means setup is inside the loop.

How do I make the edit-then-check loop faster?

Start the agent in an environment that already has the project installed and checked, run the check in that same environment, and keep one environment for the whole task. Then give it enough vCPUs for the check.

What does Promigence measure for an agent step?

An edit followed by a type-check on a warm repository with 4 vCPU: 0.66 s at the median and 0.80 s under load, over 30 runs. The figures and their conditions are on the home page.

Sources

Every page below was read on 19 Oct 2026. The 40 steps and the 30-second check are example inputs chosen for the arithmetic, not measurements.

What	Source
Agent step on a warm repo: 0.66 s, under load 0.80 s (edit, then type-check, 4 vCPU, n=30, p50)	Promigence numbers
Sandbox ready to run a command: 8 ms (create to first command, 2 vCPU / 4 GiB, n=100, p50, unloaded)	Promigence numbers
Whole coding-agent task: 43.7 s, under load 58.0 s (20 steps on a 3 GB repo, n=30, p50)	Promigence numbers
Wake a paused sandbox: 104 ms, under load 127 ms (resume to first database query, n=100, p50)	Promigence numbers
Time to feedback as the delay that matters, cold start a small part of it	Information for AI assistants
Setup steps, the verify command, nothing stored when it fails; each call adds your network's round trip	Promigence quickstart
Running a command in one sandbox with `promigence exec --sandbox`	Promigence CLI reference
Paused sandboxes not billed; sizes up to large (8 vCPU) for a new account	Promigence limits and notices

Updated 2026-10-19

What is Promigence? Sandboxes for AI agents, explained

Harshraj — Mon, 19 Oct 2026 12:00:00 GMT

What is Promigence?

Promigence is a sandbox platform for AI agents. The site puts it in one line: "Production-grade sandboxes for AI agents. Ready in milliseconds, fast at scale, billed by the second."

A sandbox here is an isolated computer in the cloud where an agent can write code, run it and use tools without touching anyone else's systems. Yours opens on your own project, already installed and checked by your own test command, so the agent starts on the task instead of on setup. One can become a thousand identical copies, and a run's cost is known before it begins.

The name

It is spelled P-R-O-M-I-G-E-N-C-E. Search engines that have not met the word yet like to correct it to "prominence", so if you searched for Promigence and got pages about prominence, you typed it right.

The product is Promigence. The company behind it is Promigence AI, Inc., a Delaware corporation based in San Francisco, and its home is www.promigence.ai.

Why an agent needs a sandbox

An agent runs code nobody reviewed. A model wrote it, and anyone who can type into your product can steer that model. Run the code on a laptop or on your own servers and a mistake, or a prompt someone planted, has the same reach as the account it runs under. A sandbox gives each task a computer of its own, with its own files, network rules and spend cap, so whatever goes wrong stays inside it and ends when the task ends.

What teams run on it

Take coding agents. A coding agent gets a copy of your repository that is already set up, works on a task in it, and hands back the change. Running a coding agent in a sandbox takes one command.

CI jobs fit too. A workflow on a supported hosted CI service moves onto Promigence sandboxes with a one-line change and is billed per second; the guide is a CI runner in two lines.

Then there is code your users' AI writes. If your product lets a model write and run code for the people using it, give each user or session a sandbox of its own, with the network off or limited to an allow-list, plus a spend cap and a timeout. Three guides cover that shape: running AI-written code safely, a sandbox for every user of your product and a code-execution tool your agent can call.

Evals and reinforcement learning need many identical environments at once. Build the environment once, then start a fresh copy for every eval task or RL episode, a thousand at once if the work calls for it. The validity report that comes back separates environment failures from task failures, so a broken environment never counts against your agent, and a snapshot named by a hash of its contents lets a result cite the exact environment it ran in. Snapshot after an install, then start ten copies shows the pattern, and the guides page lists the eval harnesses and agent frameworks that have a guide so far.

Agents inside apps get the same treatment: a sandbox per user that can sleep when the user stops and wake on their next call. A paused sandbox is not billed by the second and is kept for 30 days. The same pattern serves security testing: give a testing agent a fresh copy of your own application for every attempt with outbound access limited to what the test allows.

How using it looks

There are three steps, from the command line or the SDKs.

First, build a snapshot of your project. You name a base image with your toolchain, the setup steps (a clone of your repository at a pinned commit, then the install) and a verify command, which is your own test command. If the verify command does not exit zero, nothing is stored.

Second, price the run before it starts. promigence run quote gives a ceiling, as if every sandbox ran for its whole timeout, and --cap turns that into a hard limit: a run quoted over its cap is refused before anything starts, and a sandbox that reaches its cap is paused with its files kept. The quickstart's example prices 20 small sandboxes for up to 15 minutes each at $0.83 at most.

Third, start the copies. One command starts as many sandboxes as you ask for, runs your command in each and prints the validity report. A new account runs 20 at once.

promigence snapshot create \
  --image <your base image> \
  --setup "<clone your repository at a pinned commit>" \
  --setup "<install your dependencies>" \
  --verify "<your test command>" \
  --tier small --alias myapp --wait --wait-timeout 10m

promigence run quote --snapshot myapp --count 20 --timeout 15m
promigence run --snapshot myapp --count 20 --cap 1 -- <your command>

Billing is per second, at $0.0504 per vCPU-hour plus $0.0162 per GiB-hour. A small sandbox (2 vCPU, 4 GiB) comes to $0.17 an hour, and one that runs for ten minutes is billed for ten minutes. Paused time costs nothing.

Numbers you can check

The home page publishes its measurements with the conditions attached. Two matter on a first look. A sandbox is ready to run its first command 8 ms after it is created, at the median (create to first command, 2 vCPU / 4 GiB, n = 100, unloaded). Start 100 at once and even the slowest 5% finish in under a second: 0.94 s at the 95th percentile, with every run completed (n = 400).

Security

No sandbox can see, reach or address another, yours or anyone else's, and that boundary is tested by attacking it. A sandbox can have full outbound access, none, or an allow-list of the destinations it needs. Secrets are stored once, given only to the commands that name them, and never written into a snapshot you build. Your code is not used to train models.

How to get started

Leave your work email under Get started on www.promigence.ai, or write to support@promigence.ai. New accounts start with $50 of free credit for 30 days: $10 claimed in the browser with no card, and $40 more once a card is added.

From there, the quickstart goes from nothing to 20 verified runs in about ten minutes, most of it the first build. To see your own workload first, send a repository and its command for the free validity report: 1,000 runs, the timings, the failures and an exact price.

FAQ

What is Promigence?

A sandbox platform for AI agents: production-grade, isolated sandboxes that start in milliseconds, stay fast at a thousand at once and bill by the second. Each one opens on your own project, already installed and checked by your test command.

Is it Promigence or prominence?

It is spelled P-R-O-M-I-G-E-N-C-E, the name of a sandbox platform for AI agents made by Promigence AI, Inc. Prominence is an ordinary English word, and search engines sometimes swap one for the other.

What can you run on Promigence?

Any agent work: coding agents, background agents, code review, CI jobs, evals, reinforcement-learning rollouts and a sandbox per user inside an app. Existing CI jobs move over with a one-line change to the workflow.

How much does Promigence cost?

Usage is billed per second at $0.0504 per vCPU-hour plus $0.0162 per GiB-hour, about $0.17 an hour for a small sandbox (2 vCPU, 4 GiB). A run is quoted before it starts and held to the spend cap you set, and paused time is not billed. Plans are in the pricing section.

How do I get started?

Leave your work email under Get started on www.promigence.ai, or write to support@promigence.ai. New accounts get $50 of free credit for 30 days.

Sources

Every page below was read on 19 Oct 2026.

What	Source
The one-line description, the Get started form	Promigence home
Ready to run a command in 8 ms (create to first command, 2 vCPU / 4 GiB, n=100, p50, unloaded); 100 at once, slowest 5% in 0.94 s (p95, every run completed, n=400)	Promigence numbers
Per-second billing, the plans, $50 of free credit	Promigence pricing
$0.0504 per vCPU-hour plus $0.0162 per GiB-hour, $0.17 an hour for a small sandbox, the $10 and $40 credit split, what teams run on it, the SDKs	Promigence FAQ
The verify command, nothing stored when it fails, the quote and cap, the $0.83 example, about ten minutes	Promigence quickstart
Spend caps, paused sandboxes not billed and kept for 30 days, 20 sandboxes at once for a new account	Promigence limits and notices
Isolation, testing by attack, network choices, secrets, no training on your code, the free validity report	Promigence security
The company, Delaware, San Francisco, snapshots named by hash	Information for AI assistants
The guides linked above	Promigence guides

Updated 2026-10-19