What survives

Read the pytorch/xla README from line one and the third line is a replacement notice. It is worth quoting rather than paraphrasing, because the wording is unambiguous about direction and vague about date, and both halves of that matter.

The tip of master at the time this lesson was written was a documentation commit from 23 April 2026, and a remote check on 14 August 2026 confirmed nothing had landed since. Four months without a commit is not by itself a verdict, but with the notice above it, the two readings agree.

The repository has been shedding pieces for a while, so the direction is not new. The XRT runtime is gone entirely, PJRT is the only one left. XLAThe compiler: brilliant at fusing along dataflow edges, structurally unable to change your algorithm. That gap is why kernels exist.taught in /l/xla →:CUDA is gone, and a CUDA device type now aborts with a message telling you to report a bug. xm.mark_step is a deprecation wrapper around torch_xla.sync. torchax, the other bridge chapter 10 names, moved out to its own repository in October 2025 and left only a README behind.

> [!NOTE]
> <b>4/22/2026</b>: To read more on our TorchTPU announcement see our latest
> blog post. Once TorchTPU is public it will replace PyTorch/XLA.
> <b>10/2025</b>: Based on community feedback, we have proposed a more native
> direction for PyTorch on TPU. Read the RFC and comment at #9684.

  blog post: https://developers.googleblog.com/torchtpu-running-pytorch-natively-on-tpus-at-google-scale/
  RFC:       https://github.com/pytorch/xla/issues/9684

The RFC behind that notice describes a native TPU backend rather than a lazy one. Ops dispatch eagerly through PyTorch's PrivateUse1 dispatch key, compilation happens asynchronously in the background rather than at a barrier you place by hand, and torch.compile and DTensor are the first-class paths instead of torch_xla.compile and a torch_xla-specific sharding API.

The blog post fills in the shape: three eager modes, called Debug Eager, Strict Eager and Fused Eager, built on that dispatch key. Notice what that does to the mode landscape from lesson three. Eager stops being a boolean that reroutes a lazy engine and becomes the actual dispatch path, with compilation as the exception rather than the rule.

One thing survives explicitly, and it is the one that matters most for anyone who has read the xla path. XLAThe compiler: brilliant at fusing along dataflow edges, structurally unable to change your algorithm. That gap is why kernels exist.taught in /l/xla → is retained, as the torch.compile backend, reached through StableHLO. The compiler does not go away. The tracing frontend in front of it does.

Lessons one and two are mechanism. Interior nodes excluding shapes from their hashes, force_ltc_data merging first, the step barrier syncing every live tensor, views excluded on purpose: all of that is how one specific design solved the problem of turning eager PyTorch into whole compiled graphs. A design that dispatches eagerly and compiles in the background does not need most of it.

Lesson four is boundary. A compile-and-execute interface over an accelerator runtime, with transfers in both directions and asynchronous handles, is not a torch_xla idea. It is what every framework on every accelerator ends up with, which is why the same shape appears at /xla/pjrt/pjrt-boundary from the plugin side and at /xla/ifrt/above-the-compiler one layer up. Donation living inside the compiled module rather than in an execute call is a property of how XLAThe compiler: brilliant at fusing along dataflow edges, structurally unable to change your algorithm. That gap is why kernels exist.taught in /l/xla → expresses aliasing, not of how torch_xla drives it.

Lesson three sits across both. torch_xla.compile is mechanism and will go. The cache-key discipline underneath it will not, because a compiled program is only reusable if something can decide two invocations are the same, and something has to pay when that decision says no. The eviction cliff is a design bug in one implementation; the fact that a compilation cache has a policy is permanent.

The lazy engine is one implementation. The seam is the design, and it is what will still be there afterwards.

Once TorchTPU is public, this arc becomes a checklist rather than a manual, and these are the entries worth checking first. Does the compilation cache key still carry the framework's git revisions, or has background compilation changed what invalidation means? Is there still a hard failure on cache eviction, or did the fallback in that TODO finally get written?

Where does buffer donation live now, given that eager dispatch has no barrier at which aliasing is provably safe? What replaces the step barrier as the place a program's shape is decided, and what is the diagnostic that tells you which line forced a compile, now that the eight-way classifier no longer has a step marker to classify?

Every one of those questions is answerable in an afternoon by someone who has read this arc, and not answerable at all by someone who has only read the migration guide. That is the case for learning a system on its way out: not the API, which expires, but the set of problems the API was solving, which does not.