# LibTorch ABI Stable Plans 2026 **URL:** \ **Category:** Uncategorized\ **Created:** [May 7, 2026, 9:26pm UTC](https://dev-discuss.pytorch.org/t/libtorch-abi-stable-plans-2026/3380 "2026-05-07T21:26:29Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![janeyx99](https://yyz2.discourse-cdn.com/flex036/user_avatar/dev-discuss.pytorch.org/janeyx99/32/352_2.png) [@janeyx99](https://dev-discuss.pytorch.org/u/janeyx99)\ **Post date:** [May 7, 2026, 9:26pm UTC](https://dev-discuss.pytorch.org/t/libtorch-abi-stable-plans-2026/3380/1 "2026-05-07T21:26:29Z")
#### TL;DR - A limited subset of stable ABIs in libtorch exist, and we encourage you to use them! - We plan to land some more features and tools to improve user experience soon - We’re providing white glove services to help migrate libraries like torchvision and vLLM this year #### Context PyTorch’s C++ bits (`libtorch.so`) aren’t ABI stable. This means that when PyTorch releases a new version, a library that depends on libtorch.so (like torchvision) needs a separate build to work with the new version of PyTorch. We’ve worked in the past year to lift this restriction by introducing a new limited subset of stable ABIs in libtorch. If your library uses only APIs from this stable subset, you will be ABI stable with LibTorch, meaning you can build your binary on one torch version and run on another torch version! The following documents our goals and plans with “LibTorch ABI Stable”, or Project H-Beam as I like to refer to it. We will discuss the current status, the goals we aim to achieve in 2026, and some concrete milestones for how we plan to get there. We will not be going into the technical details in this post–for that, please take a look at our [docs](https://docs.pytorch.org/docs/stable/notes/libtorch_stable_abi.html)! #### Current Status - You Can Experience It Today! As of today (2026.05.07), LibTorch has a wide enough subset of stable APIs that a good number of modern C++ custom operator libraries can migrate to become ABI stable with LibTorch. Yes, you read that right, if you’re curious about getting onboarded, there’s nothing stopping you from looking into it today! (Check out our [docs](https://docs.pytorch.org/docs/2.11/notes/libtorch_stable_abi.html) and custom ops [tutorial](https://docs.pytorch.org/tutorials/advanced/cpp_custom_ops.html). There are also PyTorch [conference](https://pytorchconference.sched.com/event/27QEm/lightning-talk-a-stable-limited-libtorch-abi-how-and-why-jane-xu-meta) [talks](https://pytorchconferenceeu2026.sched.com/event/5b7d44b124d1e28f5e13693513b7f83b) that may be more visual, if I say so myself ;)) In fact, several ecosystem libraries have already migrated and are ABI stable: Flash-Attn-3, xformers, torchao, torchaudio. In other words, if you’re finding yourself recompiling FA3 from source, know that you may be being silly! If you build FA3 with torch 2.9+, you only need to build the wheel once (!); that same wheel will run fine with any later torch version. It may sound like the job is complete. We are not so confident, so we’d like to share our vision for “LibTorch ABI Stable”. #### Goals & Vision Ultimately, why we even embarked along this journey began with one motivation: we noticed a need for ABI stable libraries in the community, especially as the ecosystem spiderwebbed deeper. We wanted to help fill those gaps and create a nice experience for custom op library writers. We started by picking a library and brainstormed what it would require to make that library ABI stable with LibTorch. We realized we had to answer three questions. 1. Do we offer a sufficient set of ABI stable APIs that library writers need? =\> Feature Completion 2. How easy is it to write a library that would be ABI stable with LibTorch? =\> User Experience, "self-serve"ness 3. Which ecosystem libraries are important to make ABI stable? =\> Enablement These three prongs are how we will discuss our goals and milestones going forward, so let’s define them a bit more: **Feature Completion** - do we have a sufficient set of APIs supported through the C shim and torch/headeronly? - This includes all of what we consider “stable API” coverage: high-level C++ headers, C shims, torch/headeronly utils - `TORCH_TARGET_VERSION` - hardening of versioning logic - testing - e.g., sufficient testing to prevent regressions - build - e.g., Windows works, ROCm works **User Experience** - how easy is it to onboard to become stable? How “self-serve” is the process? - Docs/tutorials - Finetuning the Claude skill(s) and any thing that can be made deterministic should be. e.g., we should have a deterministic AST-based script that would convert a library’s unstable API usages to stable, and the skill can handle the trickier parts where you need to call a different API, adapt calling code, use `torch_call_dispatcher`, etc. **Enablement** - which libraries are we helping to onboard + will include in our roadmap? - Specific goals of enablement - Note we expect that points 3 and 4 above will be served by side effect from what we need to do for 1 and 2. - Which libraries? We will mark Project H-Beam as complete when we’ve accomplished our original motivation: we have filled the gaps where there is a need to make an ecosystem library ABI stable with LibTorch. We will do that by expanding the stable surface, doing a bit of enablement, and continuously improving the experience so that library writers can easily write LibTorch ABI stable libraries themselves. Note that the marked completion of this project is very dependent on the actual libraries we deem require involved migration, as the APIs they use will guide our stable surface expansion, and each enablement process will inform how to improve our user experience. Once all such libraries are migrated, parts of the feature completion and user experience prongs will naturally close out too. We do not see ourselves creating and maintaining a stable ABI surface covering all of LibTorch; that is NOT the goal. That said, the limited number of libraries mentioned here do not encompass all the libraries that we think would benefit from becoming ABI stable! By no means! There are several library migrations underway ([huggingface kernels](https://github.com/huggingface/kernels-community/issues/532), [torchcodec](https://github.com/meta-pytorch/torchcodec/pull/1260), [kvcached](https://github.com/ovg-project/kvcached/issues/306)) that simply don’t require direct involvement from us–and we love that. Ideally, all the library building blocks in the ecosystem can be nicely detangled from each other. The end of Project H-Beam should only mean the start of more ABI stable libraries in the ecosystem, where library authors can easily get there without our help. In the meantime, of course, please don’t be shy and [pester us](https://github.com/pytorch/pytorch/issues) with any concerns and feature requests you have! #### Concrete Milestones With the above in mind, here is how we’re breaking down what needs to be done: - Migrate vLLM (completely stable by Q3, targeting 2.13, 2.14) - Improve the Claude skills (drafts by end of May 2026, continuously iterate after) - Harden versioning (by end of H1) - Improve docs and tutorials (ongoing) - Explore migrating sglang (can be stable by 2.12/2.13 latest, but need to align) - Work with @NicolasHug to migrate torchvision (stable by 2.14)