GitHub rewrites Copilot runtime in Rust and cuts startup time from 5.25s to 292ms

GitHub completed the migration of the runtime that powers the Copilot CLI, the Copilot app, and the Copilot SDK from TypeScript and Node.js to Rust, according to an InfoQ report published on October 9, 2026, based on a post from GitHub itself. The work replaced more than 800,000 lines of production code with an AI-assisted rewrite: in the end, the runtime totaled 832,378 lines of Rust in production plus another 468,689 lines of Rust unit tests.

The migration took about 14.5 weeks, delivered across 128 pull requests, while GitHub kept shipping releases as usual: there were 135 releases during the period, 35 stable and 100 pre-releases. There was no pause in development to make the engine swap.

The price of the inter-process boundary

The previous implementation relied on Node.js and V8, and communicated with host applications through an inter-process boundary. According to GitHub, this design added roughly 100 MB of working set per client just to keep the inter-process bridge running.

The new Rust implementation can be embedded directly into the host application through a C ABI, eliminating that boundary when the use case allows it. An out-of-process mode remains available for those who need it. In a measured scenario covering client startup, session creation, and a single-turn interaction, the time dropped from 5.25 seconds on the previous runtime to 292 milliseconds with the Rust runtime embedded in-process.

Swapping the engine in flight: an incremental strategy

Instead of rewriting everything in parallel and making a single cutover, GitHub replaced individual TypeScript components with Rust implementations one at a time. A temporary interoperability layer via N-API connected both ends during the transition.

This design allowed the existing end-to-end tests to keep validating the new code while other parts of the system still ran on TypeScript. The compatibility layer reached 2,019 internal N-API exports and 3,356 call sites in TypeScript before being fully removed, by which point the runtime was already mostly in Rust.

AI wrote the code, humans validated behavior

AI agents generated most of the Rust implementation. Human work focused on compiling, testing, and reviewing to catch regressions in behavior, state and lifetime handling, library semantics, and optimizations lost in the automated translation. GitHub recorded 4,478 direct runs of cargo check, of which 87.1% finished without errors.

The community reaction, cited by InfoQ, centered on the limits of automated verification in AI-assisted rewrites. A commenter identified as PLBjt summed up the core of the discussion:

The interesting part here is less that Copilot wrote Rust and more whether the migration kept the runtime's behavior stable at the boundaries.

PLBjt, comment in the InfoQ community

Francesco Pira, XR Tech Lead at Leonardo, highlighted small, reviewable changes, compatibility layers, and human engineering judgment as important elements of the approach. Côme Redon, Senior Solution Engineer at Microsoft, pointed to the challenge of identifying undocumented behavior contracts in legacy systems, ones that compilation alone does not reveal.

What changes for those building with the Copilot SDK

The Copilot SDK still offers language-specific interfaces, now available in TypeScript, Python, Go, .NET, Java, and Rust. For those integrating the SDK into their own tools, the relevant change isn't the runtime's language itself, but the two ways to consume it: embedded in-process in the host application via a C ABI, or in a separate out-of-process mode, as before.

In practical terms, teams building CLIs, editor extensions, or latency-sensitive integrations gain the option to embed the runtime and eliminate the ~100 MB of working set per client that the inter-process bridge required, on top of the startup gain measured by GitHub itself. Anyone already using the Copilot SDK through the high-level API in TypeScript, Python, Go, .NET, Java, or Rust shouldn't need to change application code: the rewrite was designed as an engine swap underneath the same integration surface.

The case also serves as a practical reference for teams evaluating large rewrites with the help of AI agents. The combination GitHub used, components replaced gradually, a temporary compatibility layer, end-to-end tests kept running throughout the transition, and human review focused on behavior (not just on compiling), is a concrete playbook for anyone considering applying the same strategy to their own legacy systems.

What remains open

The InfoQ report doesn't provide public data on full behavioral parity in scenarios such as cancellation, retries, and backpressure, precisely the points the community raised as hard to capture with compilation and automated tests alone. The source also doesn't include a migration guide aimed at external SDK consumers detailing any subtle behavioral differences between the old and new runtime.