Forge cloned the same 327 MiB repository in 39 seconds versus GitHub's 97. A warm Forge Actions job later finished within 12% of GitHub. Then a cold new-commit build took 791 seconds on Forge versus 257 seconds on GitHub, including 463 seconds of source checkout.

Those results do not conflict. They measure three different paths through Forge: Git transport, warm continuous integration (CI), and cold source preparation. Forge Git is fast. Forge's warm build path is competitive. Its cold checkout path is not.

That boundary is now the performance story—and the next engineering target.

Git transport is fast

We first tested Forge and GitHub as Git servers. A disposable swyxdotio mirror contained nine refs, 9,467 reachable objects, and about 327 MiB of packed data. From the same Apple M4 Pro client, the harness alternated providers for six operations and collected five samples for every provider-operation pair.

Forge's median bare-mirror clone was 39 seconds versus GitHub's 97, a 60% reduction. Shallow clone took 2.0 seconds versus 19.5. Partial clone and incremental fetch also favored Forge. GitHub's one win was ls-remote: 0.43 seconds versus Forge's 0.63.

All 60 measured Git operations succeeded. Both providers advertised the same nine-ref digest. Partial clones proved that filtering was active, and the final Forge mirror passed strict fsck. This is strong evidence for this repository shape, not a universal claim about every repository or network.

Forge made that path fast with immutable pack snapshots. The repository remains authoritative as individual Git objects, but Forge can serve a verified content-addressed pack when the requested ref generation matches. If that acceleration artifact is absent or invalid, Forge falls back to authoritative objects without changing repository semantics.

Warm CI is competitive

Git transport is only part of a build. We also ran the same AIE monorepo commands on GitHub Actions and Forge Actions: locked dependency installation, Next.js compilation, and the OpenNext build.

On the clean replacement warm pair, Forge checked out the exact source in 22 seconds versus GitHub's 13. Forge restored dependencies faster—12 seconds versus 29—but built the application more slowly—200 seconds versus 159. Complete runner occupancy was 271 seconds on Forge and 242 on GitHub.

That leaves Forge about 12% behind for this warm pair. The providers use different hardware, so this is a service comparison rather than a normalized CPU benchmark. Still, it rules out the earlier picture of every Forge checkout carrying a five-to-nine-minute tax.

Cold checkout is not competitive

The post-fix cold pair changed one benchmark marker, preserved the lockfile, and built the same exact commit on both providers:

Stage	GitHub	Forge
Queue	~2 s	1.7 s
Source checkout	12 s	463 s
Locked dependency install	23 s	53 s
Application build	197 s	267 s
Creation to completion	~257 s	791 s

This is one pair, not a median or p95 series. We stopped rather than rerun an unfavorable result.

The result is nevertheless decisive about this run's critical path. Forge spent 124 seconds traversing 4,537 Git objects, 305 seconds transferring a 482 MB archive, and another 10 seconds materializing it. Exact HEAD verification took only 36 milliseconds. The build was already far behind before its first repository command began.

The cold install also missed both dependency caches and encountered two package-registry resets. Forge's application build remained slower, but its final resource probe was interrupted during a sandbox-runtime update. This sample cannot tell us whether that smaller build-stage gap came from CPU, throttling, memory, disk, or ordinary variance. It does not need to: source checkout accounts for almost the entire overall loss.

Admission was fixed; source staging was not

Earlier new-commit builds had a reliability defect before checkout. Forge had durably stored the received Git objects, but workflow discovery still waited for a current monolithic snapshot. A slow or failed snapshot could therefore stop an exact commit from entering CI.

We changed admission to read workflow and configuration files directly from Forge's content-addressed object store. In the cold pair above, the repository event entered CI on its first delivery attempt while the next snapshot was still running. That snapshot later failed during a Durable Object code update, but the exact build completed successfully. Acceleration state no longer controlled repository authority.

The runner then chose the safe fallback and hydrated almost the full repository closure. Correctness survived; performance did not. Forge already has a contract for projected, layered source checkpoints. The production cold path now needs to select it for ordinary depth-one builds, stream it directly into the sandbox, preserve a valid Git repository with exact HEAD, and retain full history only when requested.

The next target is narrow

We do not need a broader claim or another round of undirected optimization. Git transport is solved for this measured repository. Workflow admission no longer waits for a snapshot. Warm CI is close. Cold source staging is the bottleneck.

The next benchmark should test one change: whether a new commit can reach its first repository command without transferring hundreds of megabytes of unrelated history. It must keep exact-SHA verification and Git semantics intact. If that path becomes as efficient as Forge's warm path, then an overall “faster than GitHub” comparison becomes worth repeating.

The complete sample boundaries, exclusions, phase timings, release provenance, and rollback points are in the large-Git benchmark report. Forge's public transport design is documented in Git Smart HTTP performance.