# Blacksmith vs Namespace: Clock Speed Against Unit Price

> Blacksmith vs Namespace for GitHub Actions runners. Blacksmith sells single-core speed at a fixed per-minute rate; Namespace sells the cheapest Linux compute through a unit-minute model.

Source: https://latchkey.dev/learn/compare-runners/blacksmith-vs-namespace  
Updated: 2026-08-20

These two optimise opposite things. Blacksmith buys the fastest single core in the category at a flat rate; Namespace buys the cheapest Linux vCPU-minute through a unit model with RAM tied to core count.

Blacksmith runs bare-metal consumer gaming CPUs and charges a fixed rate per runner-minute. Namespace charges per unit-minute, where one unit is 1 vCPU plus 2 GB of RAM, at $0.001/unit-min prepaid, so a 2 vCPU Linux runner is roughly $0.002/min.

On raw Linux price at equal vCPU count Namespace wins clearly. On time-to-finish for a single-threaded critical path Blacksmith wins, because a cheaper slow core that runs for twice as long is not cheaper.

Standard GitHub-hosted runners are free and unlimited on public repositories, and public repos get 4 vCPU and 16 GB rather than the 2 vCPU and 8 GB private repositories receive. No paid runner beats free, so everything below assumes a private repository past its included minutes.

## Comparison

|  | Blacksmith | Namespace |
| --- | --- | --- |
| Pricing unit | Per runner-minute, fixed size | Per unit-minute (1 vCPU + 2 GB) |
| Linux, ~2 vCPU | $0.004/min | ~$0.002/min prepaid |
| Linux arm64, 2 vCPU | $0.0025/min | Covered by the same unit model |
| RAM at 2 vCPU | Fixed by machine size | 4 GB (2 units x 2 GB) |
| Optimised for | Single-thread speed | Cost per vCPU-minute |
| Compute substrate | Bare-metal gaming CPU, Firecracker microVM | Cloud compute, unit-metered |
| Boot time | Under 3 seconds (published) | Not published |
| Plan commitment for best rate | None | Prepaid tier; overage is 50% higher |
| Cache | Co-located, sticky disks available | Volume snapshots at $0.002/GB-hr |

## A cheaper minute is not a cheaper job

The comparison that matters is cost per completed job, not cost per minute. If Blacksmith finishes a compile-bound job in half the wall-clock time, its higher per-minute rate can still produce a lower bill.

| Job | Namespace at ~$0.002/min | Blacksmith at $0.004/min |
| --- | --- | --- |
| Runs 10 min on both | $0.020 | $0.040 |
| 10 min vs 5 min (CPU-bound) | $0.020 | $0.020, and finishes 5 min sooner |
| 10 min vs 4 min (heavily CPU-bound) | $0.020 | $0.016, and finishes 6 min sooner |

> These rows are illustrative arithmetic, not benchmark results. The point is the shape: measure wall-clock on your own pipeline, because the ranking flips depending on how single-threaded your critical path is.

## Watch the RAM ratio on Namespace

Namespace fixes RAM at 2 GB per vCPU. A job that needs 8 GB but only 2 cores has to buy a 4 vCPU shape to get the memory, which erodes the price advantage precisely where memory-bound builds live: Java, Gradle, and large Node or Webpack builds.

## Switching, and switching back

Every managed runner in this category is selected by the `runs-on` label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.

```workflow.yml
jobs:
  build:
    runs-on: ubuntu-latest        # GitHub-hosted
    # runs-on: latchkey-small     # Latchkey
```

> Runner selection is per job, so you do not have to migrate a pipeline to test one. Point the most expensive job at a candidate, compare two weeks of real runs, and expand only if the numbers hold.

## How to evaluate a managed runner honestly

Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.

- Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
- Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
- Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
- Verify the free tier is recurring. A one-time credit is not a free tier.

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

## The verdict

CPU-bound critical path, or ARM builds: Blacksmith. Its bare-metal high-clock architecture targets exactly single-threaded compile and bundle steps, and its published $0.0025/min ARM rate is strong.

Cost-sensitive, well-parallelised, memory-light Linux workloads: Namespace. At equal vCPU count on prepaid pricing it is the cheapest published Linux compute in this category.

Memory-heavy builds: check the 2 GB-per-vCPU ratio carefully. It is the condition under which the Namespace advantage disappears.

Measure cost per completed job rather than per minute. Both of these are cheap enough that wall-clock time, not the rate, decides the bill.

## FAQ

### Blacksmith vs Namespace: Clock Speed Against Unit Price?

Blacksmith runs bare-metal consumer gaming CPUs and charges a fixed rate per runner-minute. Namespace charges per unit-minute, where one unit is 1 vCPU plus 2 GB of RAM, at $0.001/unit-min prepaid, so a 2 vCPU Linux runner is roughly $0.002/min.

### A cheaper minute is not a cheaper job?

The comparison that matters is cost per completed job, not cost per minute. If Blacksmith finishes a compile-bound job in half the wall-clock time, its higher per-minute rate can still produce a lower bill.

### Watch the RAM ratio on Namespace?

Namespace fixes RAM at 2 GB per vCPU. A job that needs 8 GB but only 2 cores has to buy a 4 vCPU shape to get the memory, which erodes the price advantage precisely where memory-bound builds live: Java, Gradle, and large Node or Webpack builds.

### Switching, and switching back?

Every managed runner in this category is selected by the runs-on label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.

### Which should I choose?

CPU-bound critical path, or ARM builds: Blacksmith. Its bare-metal high-clock architecture targets exactly single-threaded compile and bundle steps, and its published $0.0025/min ARM rate is strong.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt