GitHub rebuilt the runtime behind GitHub Copilot CLI, the Copilot app, and the Copilot SDK, after it had relied on TypeScript, Node.js, and the V8 engine. The result, according to the article published on the GitHub Blog, is more than 800,000 lines of production-focused Rust, most of which was completed with the help of AI agents through 128 pull requests gradually merged into the main branch.
The author says the work was completed over a few months, primarily with the participation of one developer, while the rest of the team continued developing runtime capabilities and expanding its use. GitHub says performance improved “by large amounts” after the migration, without providing detailed figures in the available section of the article to measure that improvement.
The Problem Was Not Limited to the Command-Line Interface
Copilot runtime is not limited to running the CLI. It is a shared layer used by multiple versions and products, including GitHub Copilot CLI, the Copilot app, and the Copilot SDK, as well as VS Code, Visual Studio, Cloud Agent, Copilot Code Review, Copilot Cowork, Copilot Studio, and the Excel, Outlook, PowerPoint, and Word apps.
In the previous design, the runtime and CLI were heavily intertwined. When products needed programmatic access, the SDK was effectively built on top of the CLI, by running a separate Node.js process and communicating with it through JSON-RPC. This approach was fast and flexible, but imposed an operational cost on every consuming application.
Creating a new CopilotClient meant starting an additional process hosting Node.js and V8, parsing JavaScript code generated from TypeScript, and absorbing the memory associated with the engine. Node.js crashes could also terminate the session, while applications had to monitor at least two processes. According to the article, SDK packages written in C#, TypeScript, Python, Rust, Go, and Java carried roughly 100 megabytes of working-set memory at minimum for the additional runtime, even when they did not need Node.js for anything else.
Why Was Rust Chosen?
GitHub defined clear goals for the new layer: separating the runtime from the TUI, reducing dependencies and operational costs, enabling in-process integration, and improving scalability and reliability. It also needed a C ABI that would allow the runtime to be used by the six SDK versions through different FFI mechanisms.
The article says Rust helped meet these requirements, while also providing a toolchain that supports a more modern security posture, reduces supply-chain risks, and offers greater support for correct-by-construction code. At the same time, it emphasizes that the experience is not a recommendation to convert every large TypeScript project to Rust; the choice resulted from specific requirements related to startup time, memory, embedding, and the predictability of resource consumption.
Gradual Replacement Instead of a Comprehensive Rewrite
GitHub did not execute the project through a long-lived branch or a single conversion at the end of the road. Instead, it chose an approach within the main branch, replacing each TypeScript component with a Rust component individually. Each pull request adds a thin binding layer that calls Rust and removes the old implementation in the same change, keeping the branch shippable and testing the new code directly inside the system.
- The normal work of the other developers continued without pausing the project.
- Each change became smaller and easier to review than a comprehensive rewrite.
- CLI and SDK end-to-end tests ran with every step.
- Regressions were discovered and fixed during the migration instead of being deferred until the final conversion.
GitHub also rejected keeping two parallel versions of every component for an extended period. The repository saw hundreds of pull requests each week, and maintaining two implementations in two languages with two dependency sets would have increased complexity. Comparing two versions becomes more difficult in components that manage mutable state, such as session formatting, because they handle callbacks and connect to broad parts of the system.
What Do the Numbers Reveal?
The initial estimate in May 2026 was about 130,000 lines of TypeScript, but it did not reflect the actual scope of the work. Components that had been counted as part of the TUI layer were later moved into the runtime, while new TypeScript code continued arriving in parallel with the migration. As a result, about 430,000 lines of TypeScript actually went through the migration process.
During the same period, about 300,000 production lines of TypeScript entered the project and about 430,000 were removed, while about 1,200,000 lines of Rust entered and about 365,000 were removed. These figures show that the apparent stability of the amount of TypeScript in the repository did not mean a lack of progress; rather, it concealed substantial movement involving additions, deletions, and the redistribution of responsibilities.
Why Does This News Matter?
The practical value of the experience lies not in using Rust alone, but in how the rewrite of a foundational layer shared by many products was managed. The atomic replacement of each component, while keeping the branch shippable and running tests continuously, reduces the risks of a “big-bang” conversion and makes rollback or fault localization clearer.
At the same time, the article does not prove that this approach suits every organization or that AI agents alone can guarantee the quality of a rewrite of this scale. The available section also does not provide published measurements of consumption before and after, nor does it explain the detailed human cost of review, testing, or handling regressions. Therefore, the clearest lesson remains related to incremental engineering and separation of layers, rather than treating Rust or agents as a universal solution for every migration.