Blacksmith vs Namespace: Clock Speed Against Unit Price
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.
Blacksmith vs Namespace
| 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 |
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.
jobs:
build:
runs-on: ubuntu-latest # GitHub-hosted
# runs-on: latchkey-small # Latchkey
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.
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.