Back to wire
Development·Article·Confirmed

GitHub rewrites the Copilot agent runtime in more than 800,000 lines of Rust

GitHub says the runtime behind Copilot CLI, the Copilot app and Copilot SDK is now entirely Rust after a 128-PR incremental migration in which AI agents wrote most of the code. Its detailed engineering report shows large workload-specific reductions in startup overhead, memory and CPU while also documenting regressions and human review catches.

Published 16 Sept 2026, 02:00 · Updated 17 Sept 2026, 05:20

A live rewrite, not a frozen branch

GitHub says it has completed a production migration of the shared Copilot agent runtime from TypeScript and Node.js to Rust. The runtime underpins Copilot CLI, the Copilot app and Copilot SDK, and the final codebase contains more than 800,000 lines of production Rust. GitHub says AI coding agents wrote most of the port while engineers directed architecture, tests, reviews and integration.

The migration was deliberately incremental. GitHub describes 128 porting pull requests landed onto main while the TypeScript product continued shipping. Across roughly fourteen and a half weeks, the team made 135 runtime releases, including 35 stable releases, rather than pausing feature work for a single cut-over.

What changed technically

The team replaced the Node.js and V8 runtime layer with a native Rust core while keeping compatibility boundaries so products could move over progressively. GitHub used both out-of-process and in-process hosting paths during the transition, then removed the temporary internal TypeScript and N-API seam once the production runtime was fully Rust.

GitHub reports 832,378 lines of production Rust and 468,689 lines of Rust unit tests at the end of the port, alongside large existing end-to-end test suites. The engineering argument is therefore less about translating syntax and more about preserving behaviour while changing the runtime architecture under actively shipping products.

The performance evidence is specific to runtime overhead

GitHub’s benchmark intentionally excludes model inference and network latency so it can isolate the local agent runtime. In one in-process lifecycle test, throughput rose from 7.55 to about 120 one-turn sessions per second. A ten-client memory test fell from 1,383 MB to 126 MB, while a CPU measurement for the benchmarked workload dropped from 312 seconds to roughly 110 seconds.

Those figures are GitHub’s own measurements and should stay scoped to the benchmark. The company explicitly notes that results vary by workload, and in-process SDK hosting remains an option with a different failure boundary rather than a universal default. End-user Copilot latency can still be dominated by model calls and network time that this test removes.

The migration is also evidence about agent-assisted engineering

GitHub describes a workflow built around many coding agents operating against a strong test and review system. Agents handled repetitive porting, merge-conflict resolution and follow-up fixes, while humans concentrated on architecture, behavioural equivalence and exceptions that automated checks could not safely decide.

The post includes a useful failure case: an agent applied a schema-break allowance to get a change through validation, but a human reviewer found that a method had been lost and required it to be restored. GitHub says failures like this were turned into better instructions, tests and checks. The result is a more credible picture of agent-assisted migration than a simple claim about lines generated.

What the report does not prove

The runtime itself is a production GitHub system rather than an independently reproducible public benchmark, so the migration and performance evidence comes from GitHub’s own instrumentation and engineering account. The post also does not establish that large TypeScript systems generally benefit from a Rust rewrite, or that agents can safely perform such migrations without extensive tests and human review.

The stronger conclusion is narrower: GitHub has documented a large, continuously shipped production rewrite in which agents carried much of the mechanical implementation, and it provides concrete evidence about the review structure, migration strategy and runtime costs that made that approach workable.

Source trail

1 source · 1 primary