On September 16, 2026, GitHub published a post on moving the Copilot runtime from TypeScript to Rust. That runtime sits under the Copilot CLI, the Copilot app, and the Copilot SDK. Coverage of the post appeared recently, but the post itself is dated September.

This article uses the post as its source. The post contains very few performance numbers, so this article covers only what it states.

The problem: the runtime was tied to the CLI's TUI

The post's account of the architecture goes roughly like this.

  • The CLI's terminal UI and the runtime were tightly intertwined.
  • The SDK therefore sat on top of the CLI and launched it as a subprocess. In the post's words, this "forced out-of-process communication just to make function calls."
  • Every SDK consumer had to ship or locate Node.js or a bundled V8. The post says the C#, Python, Go, Java, and Rust SDKs each paid for "a whole second language runtime per client, on the order of 100 MB of working set minimum." The 100 MB figure is an estimate, and the post gives no measurement conditions.
  • A crash in Node could take the session down, and deployments had two processes to supervise.

The goal was a runtime that is separate from the TUI, has low overhead, can be embedded in-process, and exposes a C ABI usable from all six SDK languages.

The method: replace modules, don't rewrite in parallel

According to the post, the timeline was:

  • An initial porting plan in early May 2026.
  • Port pull requests merged from May 12 through August 21, a window the post describes as about fourteen and a half weeks.
  • By August 21, the runtime was entirely Rust.
  • During that window, main shipped 135 releases (35 stable, 100 pre-release).

The product kept shipping while the runtime changed underneath it. That was only possible because TypeScript modules were replaced one at a time.

The scale, as stated in the post

Item Figure in the post
Final production Rust 832,378 lines
Rust unit tests 468,689 lines
TypeScript end-to-end tests 174,675 lines
Production TypeScript that passed through the port About 430,000 lines (initial estimate: about 130,000)
Pull requests merged to main 128

The test count is the part to notice. Claiming functional equivalence after a port of this size needs a test suite of comparable weight. The post also says AI assistance was used for the work. The table does not show how much effort went into verifying generated code.

What the performance claim does and does not support

The post's performance statement is one line: the runtime's performance "improved by orders of magnitude." It gives no baseline, workload, hardware, or measurement method.

Secondary coverage reports startup dropping from 5.25 seconds to 292 milliseconds, and memory for a 10-client batch dropping from 1,383 MB to 126 MB. We did not find those figures in the primary post, so this article does not present them as fact. Using them would require the original benchmark data.

What a team can take from this

The most direct lessons are for people building SDKs or CLI runtimes, not only for Copilot users.

  • Process boundaries shape features. When each function call crosses an IPC boundary, latency and failure points multiply. An embeddable runtime removes some of that cost.
  • A language runtime is a deployment cost. If every client of a multi-language SDK has to ship its own runtime, install size and security patching both grow.
  • Incremental replacement needs tests that can compare before and after. Swapping modules one at a time only works if the same tests can judge both implementations.

If you are considering a similar move, measure startup time, process count, resident memory, crash isolation, and binary size before and after, under the same conditions.

Limits

  • The main source is GitHub's own blog post. We did not find an independent benchmark.
  • The runtime is part of Copilot's internal structure. External developers cannot reproduce the conditions.
  • Line counts say nothing about quality. More lines does not mean a better implementation.
  • The post does not describe failed attempts or reverted changes in detail.

Conclusion

The most practical part of this case is not "Rust is faster." It is the order of the changes: first separate the runtime from the TUI, then replace modules one by one, and keep shipping releases throughout. The performance numbers are not in the primary source, so readers should check them directly. If you face the same problem, measure process boundaries and deployment units before deciding on a language change.

Reference