ort: ONNX Runtime Bindings for Rust, Still at 2.0.0-rc
Fast ML inference & training for ONNX models in Rust
At a glance
- What is it?
- ort wraps Microsoft's ONNX Runtime for Rust inference and training, with pluggable backends and execution providers. The API is usable today, but the 2.0 line has not shipped a stable release, so version pinning is part of the integration work.
- Who is it for?
- Adopt ort if you already ship ONNX models and want to stay in Rust across desktop, server, or WASM targets, and you can pin to a specific 2.0.0-rc tag while the API settles. Do not adopt it if you need a stable semver API today, or if your model only exists as a PyTorch checkpoint you cannot export.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ort fills: ONNX models without a Python sidecar
Rust has ONNX parsing crates, but those give you a graph, not a scheduler. Running a model on a GPU or an NPU means handing the graph to something that knows about memory arenas, kernel selection, and device queues. Microsoft's ONNX Runtime is that something, and it is a C++ library. ort is the Rust interface to it. The README describes the crate as "a Rust interface for performing hardware-accelerated inference & training on machine learning models in the ONNX format," and notes it is based on the now-inactive onnxruntime-rs crate. That lineage matters: ort is not a from-scratch binding, it is the continuation of an abandoned one.
The audience is narrow and specific. You have a model that already exists in ONNX form, exported from PyTorch, TensorFlow, Keras, scikit-learn, or PaddlePaddle, and you want to call it from a Rust binary. That could be a desktop application shipping a detector, a server process embedding text, or a WASM module running OCR. The README's own list of downstream projects spans exactly that range, from Hugging Face's Text Embeddings Inference to Google's Magika to Ultralytics' YOLO inference library. If your model is still a .pt file and you have no export path, ort does not help you.
How ort sits between your Rust code and ONNX Runtime
The architecture is a wrapper with a backend seam. The default backend is ONNX Runtime itself, and the README states the crate tracks ONNX Runtime v1.28.0. On top of that, ort exposes a second layer: execution providers, which are the hardware-specific delegates inside ONNX Runtime. The project documentation has a dedicated page listing them, and the README claims support for "almost any hardware accelerator you can think of." That claim is doing work, so treat the provider list as the thing to check rather than the claim.
The more interesting design decision is the backend abstraction. The README links to a page on "other pure-Rust runtimes," which means ort's API is not permanently welded to Microsoft's C++ library. A backend swap is a real option in the design, though the README does not enumerate which pure-Rust runtimes are implemented or how complete each one is. That is a gap worth naming: the abstraction exists, the coverage behind it is not documented in the material available here.
Training is listed alongside inference in the project description and the README's opening line. ONNX Runtime does have training APIs, but the README gives no example of a training loop, no optimizer configuration, and no statement about which execution providers support training versus inference only. If training is your reason for looking at ort, the README does not give you enough to evaluate it.
Getting ort into a Cargo project
The README does not include a copy-paste install block, so the concrete setup lives in the guide and the examples directory. What the material does establish: the crate is published on crates.io under the name ort, the current version is 2.0.0-rc.13, and the API reference is hosted at docs.rs for that exact version. The badges at the top of the README track the minimum supported Rust version and the ONNX Runtime version, which tells you the project treats both as compatibility surfaces rather than incidental details.
The practical consequence is that a dependency line has to pin the release candidate explicitly, because Cargo will not select a pre-release version by default. You write the version string, not a caret range that could resolve to something else. The v2 API is also a break from v1: the README links a dedicated migration page at ort.pyke.io/migrating/v2, which exists precisely because code written against 1.x does not compile against 2.x. If you find a tutorial or a crate that depends on ort 1.x, the session construction and tensor types will not match what you see in the 2.0.0-rc.13 docs.
Build configuration is where the real work is. ort wraps a native library, so the build either links a prebuilt ONNX Runtime or compiles one. The README does not spell out the feature flags or environment variables that control this, but the MSRV and ONNX Runtime badges on the front page signal that both are tracked as first-class constraints. Read the guide's build section before your first cargo build, not after it fails.
The release candidate problem is the main adoption risk
The most recent releases are v2.0.0-rc.13, v2.0.0-rc.12, and v2.0.0-rc.11, dated July 2026, March 2026, and January 2026. Three release candidates across roughly seven months, with the API reference pinned to rc.13. That cadence tells you the 2.0 API is still being adjusted, and the migration guide from 1.x to 2.0 confirms the maintainers are willing to make breaking changes between major lines.
For a library that sits under a shipping product, this changes your upgrade math. A patch bump inside 2.0.0-rc is not guaranteed to be source-compatible in the way a stable semver release would be. You pin an exact rc tag, you read the release notes before moving, and you budget for the possibility that the next rc renames a type you use. That is a manageable cost for a project that is actively developed and has a documented migration path. It is a bad fit for a team that wants to set a version and forget it for a year.
The second failure mode is platform coverage. Execution provider support is not uniform across operating systems and architectures, and the README does not publish a matrix. A provider that works on Linux with CUDA may not exist for your target triple, and the pure-Rust backend path may not implement the operators your model uses. Verify against your actual target before designing around ort.
What you give up compared to tract or a Python service
The obvious alternative in the Rust ecosystem is tract, which is a pure-Rust inference engine with no C++ dependency. The difference in approach is fundamental. tract parses ONNX and executes it itself, so your build has no native library to link, no ONNX Runtime version to match, and no execution provider to configure. That makes cross-compilation and WASM targets simpler. The cost is that you are limited to the operators and optimizations tract implements, and you do not get the vendor-specific kernel libraries that ONNX Runtime's execution providers wrap.
ort takes the opposite bet: accept a native dependency and a version-tracking burden in exchange for the operator coverage and hardware acceleration that come from riding on ONNX Runtime. If your model runs fine on CPU and you value a self-contained build, tract is the simpler choice. If you need a GPU or an accelerator, ort is the path that gets you there without writing the kernel dispatch yourself.
The other alternative is not a library at all: run the model behind a Python service and call it over HTTP. That avoids the Rust binding entirely and gives you the full PyTorch or TensorFlow ecosystem. It also adds a process boundary, a serialization cost per request, and a Python runtime to deploy. For on-device inference, the README's framing of running "on your users' devices" rules this out. For a datacenter service with low request volume, the HTTP approach is often the pragmatic first version, and ort becomes worth the integration cost when latency or deployment footprint starts to matter.
Licence and the cost of tracking a native dependency
ort is Apache-2.0, which is permissive and compatible with commercial distribution. That covers the Rust crate. It does not automatically cover ONNX Runtime itself, which is a separate project with its own licence terms, and the README does not address that distinction. If you ship a binary that statically links ONNX Runtime, confirm the terms for the runtime independently. This is not legal advice, and the licence file in the repository is the authority for the crate.
Maintenance cost has two components. The first is the rc upgrade cycle described above: reading release notes, re-pinning, and fixing breakage. The second is the ONNX Runtime version the crate tracks. The README badge shows v1.28.0. When ONNX Runtime moves, ort moves, and your build configuration may need to follow. Projects that vendor a prebuilt runtime binary inherit that upgrade whenever they bump the crate.
The mitigation is to keep the ort dependency behind a thin internal trait in your own code, so the session setup and tensor conversion live in one module. That does not eliminate the upgrade work, but it confines it. The README's examples directory is the starting point for that module, and the v2 migration guide tells you what changed the last time the maintainers made a breaking cut.
Editorial conclusion
Adopt ort if you already ship ONNX models and want to stay in Rust across desktop, server, or WASM targets, and you can pin to a specific 2.0.0-rc tag while the API settles. Do not adopt it if you need a stable semver API today, or if your model only exists as a PyTorch checkpoint you cannot export. Before committing, run the example that matches your target, confirm the execution provider you need is listed for your platform, and check the v1 to v2 migration guide for the operators and session options you rely on.
Community notes