Skip to main content

Rust Migration

LiteLLM is moving to Rust

See how much of the move to Rust is built and what is next.

Migration tracker

Where we are today

24% of built, shown as a .

24 percent of Major APIs is built in v1.107.0-rc.2. Redis + DB is planned to reach 29 percent. Router + deploy is planned to reach 40 percent. Config + cache is planned to reach 49 percent. Auth + spend is planned to reach 57 percent. /messages e2e, simple is planned to reach 57 percent. Planned percentages are rough estimates of the broader migration. Horizontal distance represents elapsed time.OctNov0%50%100%1.102 rc1Sep 131.103 rc1Sep 201.104 rc1Sep 281.106 rc1Oct 1124%1.107 rc2Oct 20 · latest29%Redis + DBNov 1 target40%Router + deployNov 8 target49%Config + cacheNov 14 target57%Auth + spendNov 21 target57%/messagese2e, simpleDec 1 target

The solid line shows released work. The dashed line shows estimated weekly goals toward the December 1 Messages milestone. How we measure progress

Earlier benchmark

Forwarding-only Rust beta results

The July 2026 AIGatewayBench report measured four gateways against the same mock server with no logging callbacks, spend tracking, or persistence enabled. These results isolate forwarding overhead; they do not measure the December 1 fast path with common proxy features.

Added latency at p99

  • 0.7 msLiteLLM Rust
  • 2.3 msPortkey
  • 4.5 msBifrost
  • 257.7 msLiteLLM Python v1

Logarithmic scale. A low value is better.

Maximum memory use

  • 21.8 MBLiteLLM Rust
  • 90.4 MBPortkey
  • 199.1 MBBifrost
  • 329.5 MBLiteLLM Python v1

A low value is better.

These numbers are the delay the gateway itself adds. Each gateway handled 5000 requests for each endpoint, and p99 is the slowest request in every 100. The AIGatewayBench report gives the full method, the raw data, and the limits of the test.

Engineering updates

How we are getting there

Watch the GitHub discussion for weekly updates directly from the developers, with much more detail than the blog posts.

  1. · Blog post

    Rust Migration: /v1/messages end-to-end in Rust by Dec 1
  2. · Blog post

    OCR uses Rust by default starting with v1.102.0-rc.1
  3. · Blog post

    Benchmarking the LiteLLM Rust AI Gateway: Overhead, Memory, and Cost
  4. · Blog post

    Migrating LiteLLM to Rust - Building the Fastest and Litest AI Gateway

FAQ

Frequently asked questions

  • What is planned for December 1?

    Nate's October 26 update shifts the migration from porting translation, then routing, then the web server to moving a common request path to Rust end to end. The target is about 20 times less proxy latency, around 1.5 milliseconds, for these requests. Updated benchmarks with common proxy features are still to come.

    The initial scope is /v1/messages with simple-shuffle routing, Anthropic models on Anthropic, Amazon Bedrock, or Vertex AI, and supported callbacks such as S3 logs and spend logging. Every enabled callback must be supported. Other endpoints, routing strategies, providers, and unsupported callbacks stay on Python until the fast path expands to cover them.

    This path needs Rust deployment, database-backed configuration, Redis access, routing, auth, response caching, and supported logging callbacks and spend tracking. We estimate that this work brings the broader migration to about 57% on the chart's existing scale.

    December 1 is the target for this common configuration. Coverage will expand to more configurations and request types after this path. The latency target is an expected result; updated benchmarks will confirm performance.

  • How will requests reach Rust or Python?

    An Axum server will sit in front of all requests and check early whether Rust can handle them. Supported requests will use the Rust fast path. Other requests will be forwarded to a Python worker on the same host. Rust implementations of the router and callbacks will be shared with Python through thin wrappers, and both servers will use the same Redis and Postgres protocols.

  • How is the percentage calculated?

    This tracks released components across the broader migration. It does not measure the share of traffic served by Rust. The December 1 projection is a rough estimate of the catalog work needed for the common Messages fast path, including its shared infrastructure. The October 26 update replaces the earlier roadmap dates.

    Every piece of work has a size in rough engineer-weeks, and a component's points are the sizes of its work. A piece earns 80% of its size once it is in a release but incomplete or not yet trusted, and all of it once it is done. Major APIs is 146 points in all.

    Major APIsPointsTodayBy Dec 1
    Deployment10010
    Rust core888
    Messages translation74.85.4
    Chat completions translation130.60.6
    Responses translation6.51.81.8
    Python-only request features38.50.80.8
    DB access808
    Auth and secrets138.610.6
    Budgets and rate limits505
    Spend tracking313
    Router808
    Logging and callbacks123.29.8
    Response cache126.610.2
    Config202
    Total14635.483.2
  • What do Partial and Done mean?

    A level says how confident we are in the work itself, not whether anything uses it yet. Groundwork that is finished and trusted but waits for the gateway to deploy is already done.

    • Partial

      In a release, but incomplete or not yet trusted, so it usually ships opt-in.

    • Done

      Complete and trusted, whether or not it runs by default or anything uses it yet.