Why GitHub Rewrote the Copilot Runtime in Rust

By Max Wells, updated September 28, 2026

TL;DR: GitHub says it rewrote the shared runtime behind Copilot CLI, Copilot App, and Copilot SDK from TypeScript and Node.js to more than 800,000 lines of production Rust. AI agents wrote most of the code across 128 pull requests. On GitHub's measured workload, an in-process client and session lifecycle fell from 5.25 seconds to 55.3 milliseconds, throughput rose from 7.55 to 120 lifecycles per second, and ten-client memory fell from 1,383 MB to 126 MB. These are GitHub benchmarks for one workload, not proof that every TypeScript application should be rewritten in Rust.

• What changed: Copilot's shared agent runtime moved from TypeScript and Node.js to Rust
• How: 128 incremental pull requests, tests, CI, staged releases, and AI-assisted implementation
• Measured result: lower startup, memory, and process overhead in GitHub's workload
• Rust implication: Rust becomes more attractive when one runtime must serve many embedded clients and sessions

What Did GitHub Announce About Copilot and Rust?

GitHub rewrote Copilot's shared runtime in Rust because the previous TypeScript and Node.js process model added startup, memory, and JSON-RPC overhead for embedded clients.

GitHub says it completed the migration of Copilot's shared agent runtime from TypeScript and Node.js to production Rust, using AI agents to write most of the code.

The announcement appeared on the GitHub Blog on September 16, 2026, and was updated September 23. It concerns the runtime behind the GitHub Copilot CLI, Copilot App, and Copilot SDK.

This is not a small command-line utility rewrite. GitHub describes the runtime as a shared agent harness used across Copilot products and integrations, including the cloud agent, VS Code, Visual Studio, Copilot Code Review, Copilot Studio, and Microsoft 365 products.

The basic shift looks like this:

Before:
Copilot SDK -> JSON-RPC -> Node.js CLI process -> TypeScript + V8
 
After:
Copilot SDK -> embedded Rust runtime -> shared agent sessions

GitHub's main argument is practical: the old architecture worked for a terminal application, but spawning Node.js and V8 for every embedded client added startup, memory, process, and communication costs. Rust allowed GitHub to embed the runtime more directly and control resource use more predictably.

What Is Confirmed and What Is Still a Claim?

The source confirms a large migration and reports strong measurements. It does not prove that changing programming language alone creates the result. The architecture changed too, especially the move from an out-of-process JSON-RPC path toward in-process embedding.

Why Did GitHub Move the Copilot Runtime from Node.js to Rust?

The original runtime was written in TypeScript and ran on Node.js and V8. That choice made sense when Copilot was mainly a console application. TypeScript enabled fast product development, and Node.js gave the team an accessible platform for building the first version.

The problem appeared when the same runtime became shared infrastructure.

For teams evaluating a similar move, the useful comparison is not simply Rust versus Node.js. It is whether an incremental Node.js to Rust migration can remove a measured bottleneck without forcing a risky rewrite of the whole product.

Before the migration, creating a client from the SDK meant starting another process:

Application
    |
    v
Copilot SDK
    |
    v
JSON-RPC messages
    |
    v
New Node.js + V8 process
    |
    v
TypeScript agent runtime

Every client paid for process startup, JavaScript parsing, V8 memory, and serialization across the JSON-RPC boundary. That overhead is tolerable for one interactive CLI. It becomes expensive when a server needs many independent agent sessions, or when several products embed the same runtime.

The Rust architecture aims to reduce those costs:

Host application
    |
    v
Copilot SDK
    |
    v
Rust runtime embedded through native interop
    |
    v
Many agent sessions in one host process

GitHub lists four requirements behind the decision: embedding through a C ABI, low startup overhead, low steady-state overhead, and predictable resource use. Rust helped meet those requirements, although GitHub also describes the migration as more complicated than the original TypeScript implementation.

How Did GitHub Rewrite 800,000 Lines Without a Big Bang Cutover?

GitHub migrated the runtime incrementally instead of keeping a long-lived rewrite branch and switching everything at once.

The port landed through 128 pull requests. Each pull request replaced one component or slice of TypeScript with a Rust implementation, kept a thin compatibility layer where needed, ran the existing end-to-end tests, and shipped through the normal release process.

The migration process looked like this:

Small Rust component
        |
        v
TypeScript shim or FFI boundary
        |
        v
Existing tests and CI
        |
        v
Prerelease rollout
        |
        v
Production release
        |
        v
Remove old implementation

GitHub reports roughly fourteen and a half weeks of porting. During that period, the main branch shipped 135 releases, including 100 prereleases and 35 stable releases. By August 21, the runtime was reported as 100 percent production Rust, with 832,378 lines of production Rust and 468,689 lines of Rust unit tests. The source's earlier "more than 800,000 lines" phrasing is a rounded version of this later precise count, not a separate codebase measurement.

This strategy matters more than the headline number. A huge rewrite is easier to validate when every change remains close to production, the test suite runs against the new code immediately, and failures can be connected to a small recent change.

It also limits migration drift. A separate rewrite branch would have moved while the active TypeScript codebase kept changing. By porting directly into main, GitHub paid integration cost continuously instead of saving all of it for the end.

Did Rust Make Copilot Faster?

GitHub reports major gains in one session-heavy workload, especially for in-process startup, throughput, and memory.

The most useful numbers from the announcement are:

GitHub deliberately measured the part affected by the runtime migration: client startup, process launch, session creation, event handling, persistence, and teardown. The test used a deterministic local chat completion server, so model inference and network latency did not dominate the result.

The benchmark still needs careful reading. It does not mean the Rust runtime is always 15.9 times faster. GitHub itself says the result is workload-specific. The improvement comes from several changes working together:

• Rust instead of TypeScript and Node.js for the runtime implementation
• in-process embedding instead of spawning a CLI process
• less JSON-RPC serialization between the SDK and runtime
• lower V8 and Node.js memory overhead
• a shared client serving many sessions

The fair conclusion is narrower:

For a high-concurrency agent runtime that repeatedly creates sessions, GitHub measured a large benefit from moving to Rust and removing the old process boundary.

That is useful evidence for architecture decisions. It is not a universal language benchmark.

What Does the Copilot Rewrite Mean for Teams Evaluating Rust?

GitHub's rewrite is a case for measuring and removing an expensive runtime boundary, not a reason to replace every TypeScript application with Rust.

The strongest lesson is the migration shape: keep the product shipping, replace small components, run the existing tests, and remove compatibility layers only after production evidence. Rust can improve resource use, but architecture, workload, and process boundaries determine where the benefit appears. Our guide on whether a system should be rewritten in Rust covers that decision more broadly.

How Much Did AI Agents Actually Do?

GitHub says AI agents wrote most of the Rust code. The port used the Copilot App and Copilot CLI themselves, with agent workflows handling implementation, compilation fixes, test execution, review feedback, rebases, and merge preparation.

This is also why the story matters for engineers learning Rust with AI tools. Agents can accelerate implementation, but someone still needs enough Rust knowledge to review ownership, async behavior, FFI, unsafe code, tests, and operational failure modes. See Learning Rust with AI Tools and Rust skills for AI infrastructure engineers for the practical skill implications.

The scale was large. GitHub reports more than 12.7 million events across the porting effort, including more than 23,000 compilation commands, 19,000 test commands, and 1.8 million tool starts.

But “AI rewrote Copilot” does not mean one prompt generated a finished runtime. The actual workflow had several control layers:

Human architecture decisions
        |
        v
Agent implementation
        |
        v
Compiler + tests + CI
        |
        v
Agent review and correction
        |
        v
Human spot checks and merge approval
        |
        v
Staged production rollout

GitHub also documents regressions caused by semantic differences between TypeScript and Rust libraries, missing SDK methods, branch drift, and incorrect automated fixes. Those failures are important. They show that the hard part is not generating Rust syntax. The hard part is preserving behavior while a large, active system keeps changing.

The agents acted as a very large implementation and operations layer. They did not replace architecture, test design, rollout decisions, or production ownership.

Does This Prove Every Node.js Application Should Be Rewritten in Rust?

No. GitHub's result applies to a shared, session-heavy runtime with strict startup and memory requirements.

A rewrite makes more sense when several conditions are true:

• the service starts frequently or serves many isolated sessions;
• memory and process count limit deployment density;
• the runtime must be embedded inside several products;
• latency and predictable resource use matter more than rapid feature iteration;
• the team can build strong compatibility tests and operate both stacks during migration;
• the current architecture creates measurable overhead, not only aesthetic discomfort.

A rewrite is harder to justify when the application is mostly ordinary CRUD, has low traffic, changes rapidly, or lacks a reliable behavioral test suite. In those cases, Rust may still be valuable for a focused hot path, parser, worker, or service boundary. A full rewrite can create more risk than performance benefit.

The decision tree is simple:

Measured bottleneck?
    no  -> improve current stack first
    yes
      |
      v
Can isolate hot path or boundary?
    yes -> migrate one component
    no
      |
      v
Strong compatibility tests and Rust ownership?
    no  -> build safety net first
    yes -> consider incremental rewrite

GitHub's migration is an argument for measurement and incremental delivery. It is not an argument for rewriting because Rust is fashionable.

What Should Rust Developers Learn from the Copilot Rewrite?

The biggest career lesson is not “AI writes Rust, so Rust knowledge matters less.” It is the opposite.

When agents generate implementation code quickly, the valuable skills move toward system judgment:

1. Runtime architecture: know when process boundaries, serialization, and language runtimes create real cost.
2. Rust fundamentals: read ownership, lifetimes, async behavior, traits, FFI, and unsafe code well enough to debug production failures.
3. Behavioral testing: preserve compatibility with fixtures, end-to-end tests, schema checks, and failure injection.
4. Performance analysis: distinguish CPU, memory, startup, throughput, tail latency, and network effects.
5. Migration design: split a rewrite into shippable slices instead of waiting for a perfect replacement.
6. Agent supervision: give agents constrained tasks, inspect diffs, reject plausible wrong code, and improve the workflow when failures repeat.
7. Operations: own observability, rollout, rollback, dependency updates, and incident response after generated code reaches production.

The useful profile now looks like this:

Rust fundamentals
    + runtime architecture
    + tests and benchmarks
    + FFI and deployment
    + AI agent supervision
    = engineer who can ship and verify large systems

This is why the announcement matters for Rust developers. GitHub is not only using Rust for a faster binary. It is using Rust as the embedded systems layer beneath an expanding family of AI products.

What Is the Main Limitation of GitHub's Announcement?

The measurements are credible evidence about GitHub's workload, but they remain company-reported benchmarks with several variables changing at once.

The comparison is not only TypeScript versus Rust. It also changes the process model, embedding model, SDK boundary, and memory layout. A different Node.js application with a different workload could see a smaller gain. A well-designed Rust service could also lose its advantage through inefficient architecture, blocking I/O, excessive allocation, or an unsuitable concurrency model.

The migration cost also matters. GitHub reports about 120,000 dollars in model token spend, plus engineering time and the cost of building the porting workflow. The source says the effort was completed primarily by one developer, but it also credits contributors who built interop, packaging, build, review, and SDK pieces.

The honest verdict is therefore:

Not:
Rust always beats TypeScript.
 
Yes:
Rust plus in-process embedding can remove major overhead
for a shared, high-concurrency runtime.
 
Also:
Agents can reduce rewrite cost when tests, CI, review, and rollout
make wrong behavior visible quickly.

Frequently Asked Questions

The Bottom Line

GitHub's Copilot rewrite is one of the clearest recent examples of Rust moving from a performance-focused component choice to the foundation of a large AI developer product.

The important lesson is not that Rust magically makes every program faster. GitHub changed both language and architecture: it removed a process boundary, reduced runtime overhead, embedded the shared agent loop more directly, and migrated in small production-tested steps.

AI agents made the rewrite cheaper to execute. Rust made the resulting runtime cheaper to operate for GitHub's measured workload. Neither removes the need for engineers who understand behavior, architecture, security, and failure modes.

For teams evaluating Rust, the practical takeaway is clear: measure a real bottleneck, isolate the expensive boundary, build compatibility tests, and migrate incrementally. For Rust developers, the opportunity is larger systems work at the intersection of runtime engineering, AI infrastructure, and agent supervision.

Related Rustify Articles

• Should You Rewrite It in Rust?
• Migrating a Node.js Service to Rust
• Rust for AI Infrastructure Engineers
• Learning Rust with AI Tools
• Building AI Agents from Scratch in Rust

Sources

• Migrating the GitHub Copilot runtime to Rust, using Copilot
• GitHub Copilot CLI
• GitHub Copilot SDK