Is Rust Silently Becoming the Language of AI

Spend enough time following Python tooling and AI infrastructure, and you start noticing the same implementation detail - "written in Rust".

The validator is Rust. The tokenizer is Rust. The DataFrame engine is Rust. Even the tools installing and checking the Python code are Rust. Developers still open Python files, but more of the machinery supporting those files is being built in another language. That shift now extends beyond individual libraries. OpenAI has documented a major Python to Rust service migration. Anthropic has shipped a Rust rewrite of the runtime powering Claude Code. Both companies are also using their own coding agents to carry out migrations that would previously have required substantial engineering time. Its tempting to connect those developments and conclude that Rust is going to overtake Python as the language of AI. I think Rust has a credible path to becoming much more important across AI infrastructure. Whether it also becomes the language most AI developers write depends on how far that transition reaches through the stack.

The rewrite trend is real, but it takes several forms

Pydantic provides a clear example of an existing Python library moving core functionality into Rust. With version 2, validation and serialisation moved into a separate package, pydantic-core. Developers continue defining models in Python, while Rust performs much of the work beneath the API. Thats relevant to AI applications because structured model responses and tool arguments need validation before they become application inputs. Hugging Face Tokenizers exposes a Rust implementation through interfaces including Python. Polars provides a Rust query engine for DataFrame processing, again with a Python API. Safetensors uses Rust with Python bindings for storing and loading model weights through a format designed to avoid executable pickle payloads.

These projects have different histories. Polars is an alternative to pandas, rather than pandas translated into Rust. Pydantic rewrote an existing core. Other libraries were designed around Rust from the beginning. The broader pattern is that maintainers can put substantial processing behind a Python interface and choose Rust for its implementation. A simplified application could combine those components like this......

The diagram shows possible responsibilities, rather than prescribing a dependency chain for every AI application.

The application can remain recognisably Python throughout. Its author may never write a line of Rust, even though several dependencies execute Rust code. The same transition appears in the surrounding tools. Ruff checks and formats Python using Rust. uv manages Python packages and projects using Rust. Neither runs the neural network, but both demonstrate that participating in the Python ecosystem no longer implies implementing its infrastructure in Python.

Why Rust is attractive for these components

Rust gives maintainers control over memory layout, allocations and ownership, with compiler checks around how values are borrowed and shared. It manages memory without requiring a tracing garbage collector. For code processing large buffers or serving many concurrent requests, those properties create opportunities to reduce overhead and make resource ownership explicit. The comparison depends on the starting point. Python already offers memory management that protects application developers from many manual memory errors. A Python to Rust migration often seeks execution efficiency and more explicit resource control. Moving native code from a language with manual memory management can additionally bring stronger compiler enforcement around lifetimes and cleanup.

Interoperability makes that choice easier to adopt. PyO3 supports writing native Python modules in Rust, and maturin helps build and publish them. The boundary works especially well when Python can hand over a meaningful batch of work. Repeated crossings, conversions and copies can erode the benefit when the interface is too fine grained. Using Rust also does not automatically move Python objects outside the interpreter's threading rules. The implementation has to manage its interaction with Python correctly. Native parallelism is useful when work can operate independently of those objects and when the workload benefits from it. These are engineering tools rather than automatic performance results. Algorithms, data structures and the shape of the interface still determine how much the application gains.

OpenAI: tokenisation behind a Python API

OpenAI’s tiktoken is a useful place to start because it makes the boundary concrete. Its public interface lets Python applications select an encoding, turn text into token IDs, and decode those IDs back into text. Underneath, the package builds a Rust extension using PyO3. The Rust source implements the core byte pair encoding machinery, including the merge operations and lookups needed to map text into tokens. Thats a bounded computational job. The application supplies text and receives tokens. Rust can perform the processing internally without making every individual operation a Python level call.

For an application preparing documents for an embedding pipeline, tokenisation can happen repeatedly while calculating chunk sizes, enforcing input limits or processing batches. Improvements there can reduce the CPU work surrounding model execution. The gain depends on how much tokenisation the application actually performs. This is also an example of why a Rust implementation does not require users to abandon Python. Someone importing tiktoken is adopting Rust as a dependency while continuing to work through a Python API. It would be a mistake to infer the language of OpenAI's entire internal model pipeline from that package. What the public project establishes is specific, OpenAI publishes a tokenizer whose performance sensitive core is implemented in Rust and made available to Python users.

OpenAI: Rust in the coding agent itself

Codex CLI shows Rust taking a larger role in the application. OpenAI's repository contains the Rust implementation under codex-rs. Its build instructions use Cargo, and codex core implements the agent's business logic for use by its Rust interfaces. The CLI runs locally, interacts with a developer's repository and connects the model to tools that can inspect files, apply changes and execute commands. That puts Rust in the software coordinating the agents work. The local agent needs to manage interactions with the model, tool execution, session state and the user. The model providing the intelligence remains a separate part of the system.

For this kind of program, responsiveness and reliable process management are useful engineering properties. A command line agent may spend much of its time waiting for a model, but it still needs to handle cancellation, subprocess output and errors correctly while that work is happening. My interpretation is that this is a broader signal than adopting a faster library. OpenAI is using Rust for an AI product's execution machinery, with the language visible in the application architecture itself. It also shows how distribution and implementation can differ. An installation route through npm does not mean the underlying application must be implemented in JavaScript. The package manager can distribute a native executable.

OpenAI: replacing a production Python service

The strongest Python to Rust example is Habitat, OpenAI's online storage platform. Their September 2026 engineering account describes Habitat evolving from a Python client library into a standalone service. It centralises storage concerns including routing, authorisation and connection handling. The team deliberately retained Python during that transition so it could establish the platform before undertaking another major change. OpenAI reports rewriting the service in Rust during Q2 2026 with two engineers assisted by Codex and GPT-5.5. At publication, the Rust implementation handled 95 per cent of its production requests. OpenAI reported six times greater CPU efficiency, fifteen times greater memory efficiency and lower average and tail latencies than the Python implementation. These are results for that service migration, rather than general Rust vs Python performance guarantees.

The simplified diagram below places the rewritten service between product clients and storage. It omits proxies, regional routing and other deployment details.

This example changes the discussion because it concerns ordinary distributed systems work supporting an AI product. Storage access can become expensive enough that reducing per request overhead is commercially useful, even though the service never performs a neural network calculation. At sufficient traffic, a small allocation repeated on every request becomes a capacity concern. A little CPU overhead becomes a fleet of machines. Latency variability becomes visible across many user journeys. Theres also a useful sequencing lesson here. You can first stabilise a service boundary and later replace its implementation. That boundary limits how much of the surrounding product has to change at the same time.

Anthropic: Rust beneath Claude Code

Anthropic's clearest publicly documented production example is Bun. Bun combines a JavaScript and TypeScript runtime with development tools such as a bundler, package manager and test runner. Anthropic acquired Bun in December 2025. The acquisition announcement explicitly linked it to the infrastructure powering Claude Code, the Claude Agent SDK and future coding products. It also explained that Claude Code ships as a Bun executable. Bun 1.4, released in August 2026, brought its move from Zig to Rust into a public versioned release. The release announcement says Claude Code had already been using the Rust port for months. Anthropic's migration account dates its shipment inside Claude Code to June. That creates a direct connection between the Rust implementation and an AI product people use. Claude Code can run application logic through Bun while Bun handles the underlying runtime responsibilities.

There are several language boundaries in that arrangement. JavaScript or TypeScript application code can depend on a runtime implemented in Rust. That runtime can still embed components written in C or C++. Rust adoption at one layer does not require every neighbouring layer to change language. For the user, much of that work is invisible. They start a coding agent and expect it to launch, access the project and operate reliably. The implementation language becomes visible mainly through its effects on the product and the engineering work needed to maintain it.

Why the Bun team chose Rust

Jarred Sumner's account places stability at the centre of the rewrite. He describes bugs involving memory lifetimes and cleanup, including use after free errors and missed releases on error paths. Rust offered compiler enforcement and automatic cleanup for patterns the team had previously managed through conventions and custom machinery. The account reports reaching a fully passing existing test suite across platforms in eleven days, with one engineer supervising Claude Code workflows. The port still introduced nineteen known regressions. Bun also retains unsafe Rust and C/C++ dependencies, including JavaScriptCore. Those details show both the attraction of stronger language checks and the continuing work needed around a large native runtime.

Anthropic's separate migration guide explains the process more broadly, engineers establish translation rules and verification, then agents translate, compile and test against the intended behaviour. Its published migration kit includes dependency mapping, adversarial review and a final behaviour matching stage. My reading is that two developments reinforced each other. Rust supplied properties the runtime team wanted, while coding agents reduced the effort needed to attempt the migration. An implementation choice that had been attractive but expensive became practical enough to pursue. Thats a more substantial change than another language winning a synthetic benchmark. It changes the calculation around replacing an established codebase.

Anthropic: exploring Rust for verified execution

Anthropic has also described a different use of Rust in research. In an October 2026 formal verification report, it says Claude developed an interpreter for a large subset of Python in Rust. The experiment used Verus to prove adherence to specified CPython semantics, then compared behaviour across more than 1.7 million randomly generated Python programs. Anthropic reports agreement in 99.95 per cent of those tests, with remaining differences associated with known corner cases. This was an experiment with a defined subset and specification. It does not establish that Claude's training platform runs on a replacement Python interpreter, or that arbitrary Python packages can move to it unchanged. It demonstrates another possible direction f, preserve a familiar language at the interface while changing the implementation and strengthening what can be checked about its behaviour.

The verification aspect is relevant to AI generated software. A language compiler can check certain properties of code, while tests compare observed behaviour and a formal proof checks a stated property under its assumptions. Each offers a different kind of evidence. None removes the need to decide whether the specification captures the behaviour the application requires.

AI is also making rewrites easier to attempt

There is a feedback effect running through these examples. AI applications create demand for efficient, reliable infrastructure. Coding agents then help produce that infrastructure. As migrations become cheaper to execute, teams can reconsider language choices that had previously been too expensive to revisit. The difficult part remains defining what the replacement has to preserve. A compiler accepting a Rust port does not prove that it handles timeouts, malformed inputs, ordering and cancellation in the same way as the original. Compatibility depends on observable behaviour across those cases. A useful general migration process needs an independent comparison with the original implementation. The diagram below is a general approach, rather than a claim that either company used this exact workflow.

For a real service, that comparison extends beyond response bodies. It can include status codes, side effects, error handling and resource behaviour. Production rollout then provides evidence about workloads that tests may not have captured. The work shifts towards designing the process that makes a large volume of generated changes reviewable. Producing more code is useful only when the team has a credible way to decide whether that code is ready.

Why this still leaves plenty of room for Python

Python has always drawn strength from combining accessible application code with efficient implementations underneath it. PyTorch's documentation describes its Python frontend invoking C++ for expensive operations. Rust is entering an ecosystem that already uses that separation extensively. That means Rust's success can strengthen Python. A faster validator, tokenizer or data processing engine gives a Python developer more capability without requiring a language migration. Training and experimentation also place different demands on an ecosystem from operating an established service. Someone testing a new model architecture needs the required operations, examples, debugging tools and integrations to be available. A team deploying a fixed workload can make different trade offs around resource usage, packaging and operational control.

Rust frameworks such as Hugging Faces Candle demonstrate a path towards writing model running applications directly in Rust, including GPU support. Teams still need to verify that the framework supports their particular models, operations and hardware. There is also a practical limit to language level acceleration. Consider an illustrative pipeline spending ninety per cent of its runtime executing a model and ten per cent preprocessing inputs. Halving the preprocessing time reduces total runtime by five per cent. That saving may be worthwhile, but its size follows from the workload. A service waiting for a remote model response presents another calculation. Rewriting its orchestration may improve memory consumption or deployment characteristics while barely changing response time. Measurement determines whether those improvements justify the migration.

What overtaking Python would actually mean

Rust can gain ground in several ways at once. More libraries can adopt it internally. More production services can use it directly. More developers can choose Rust APIs for their application code. Those transitions do not necessarily happen at the same speed. OpenAI's tiktoken illustrates Rust behind a Python interface. Codex CLI puts Rust in an agent application. Habitat demonstrates a production service moving away from Python. Anthropic’s Bun work places Rust underneath a widely used coding product, while its interpreter experiment explores stronger verification around execution.

My expectation is that Rust will take a larger share of AI infrastructure, especially where teams can identify expensive repeated work or difficult native code maintenance. The evidence supports that direction much more strongly than a prediction that researchers will collectively abandon Python. The point at which developers routinely choose Rust for new model development workflows would be a further shift. It would require making that choice productive, beyond the performance of individual components. For now, the change can happen one dependency and one service at a time. A developer keeps writing Python. Their tokenizer runs Rust. Their data processing engine runs Rust. A backend service moves to Rust behind the same network API. Their coding agent helps implement the next migration.

Rust doesnt need every AI developer to change editors, notebooks or habits to become central to the systems they rely on. More of that transition is already happening underneath without them noticing!

• Pydantic — architecture and Rust core
• Hugging Face — Tokenizers
• Polars — user guide
• PyTorch — Safetensors
• Astral — Ruff
• Astral — uv
• OpenAI — tiktoken repository
• OpenAI — tiktoken’s Rust extension configuration
• OpenAI — tiktoken’s Rust implementation
• OpenAI — Codex repository
• OpenAI — Codex build instructions
• OpenAI — codex-core
• OpenAI — scaling Habitat and migrating from Python to Rust
• Bun — joining Anthropic
• Bun — version 1.4 release
• Anthropic — large-scale code migrations with Claude Code
• Bun — rewriting Bun in Rust
• Anthropic — Claude Code migration kit
• Anthropic — formal software verification, including a Python interpreter in Rust
• PyTorch — C++ frontend and its relationship to Python
• Hugging Face — Candle Rust machine-learning framework
• The Rust Book — ownership and memory management
• PyO3 — Rust and Python interoperability