The Council argues that after two years of in-tree development, the copy-and-patch JIT delivers only single-digit percentage speedups while imposing significant complexity on the bytecode evaluator and cross-platform maintenance burden across x86-64, ARM64, Windows, Linux, and macOS. They want to pause new work to evaluate whether the JIT belongs in CPython at all, rather than continue investing in a project without a clear benchmark story.
The editorial frames the pause as closing a loop that started when Microsoft wound down the Mark Shannon-led Faster CPython team in April, which included Brandt Bucher and Ken Jin — the two engineers most associated with the JIT. With the corporate funding gone, the in-tree project that funding produced no longer has the engineering capacity to justify continued development.
The editorial highlights that PyPy has been delivering 4–7× speedups on the same workloads for a decade, while the CPython JIT team has been pushing only single-digit percentage gains. This comparison frames the in-tree JIT as a poor return on investment when a mature alternative already exists in the ecosystem.
The editorial acknowledges the copy-and-patch approach is genuinely clever — pre-compiling tiny templates per bytecode at build time and stitching them with pointer patches at runtime keeps runtime overhead minimal. But the implementation cost of keeping those templates synchronized with every bytecode change across five platforms turned out to be enormous, undermining the elegance in practice.
The Python Steering Council posted to discuss.python.org asking the maintainers of the experimental CPython JIT — the copy-and-patch compiler that shipped as an opt-in build flag in 3.13 — to pause active development. The post frames it as a request, not a kill: the council wants the team to stop landing new code while it figures out whether the JIT belongs in the main interpreter at all. The tier-2 optimizer and the JIT scaffolding stay in the tree. New work stops.
The stated reason is brutally simple: the JIT, after two years of in-tree development, still doesn't deliver consistent speedups large enough to justify the maintenance burden it imposes on the rest of the interpreter. The council points to the cost of keeping the JIT green across platforms, the complexity it adds to the bytecode evaluator, and the lack of a clear benchmark story. The team has been pushing single-digit percentage gains. PyPy has been delivering 4–7× on the same workloads for a decade.
Context makes this sting more. In April, Microsoft disbanded the Faster CPython team — the Mark Shannon-led group that delivered the specializing adaptive interpreter in 3.11 (the 25% speedup everyone celebrated) and seeded the JIT prototype. Brandt Bucher and Ken Jin, the two engineers most associated with the JIT, were among the names affected by that wind-down. The Steering Council pause now closes the loop: the funding left, and the in-tree project that funding produced is being told to stand down.
The copy-and-patch approach the CPython JIT uses is genuinely clever. Instead of building an LLVM-style compiler inside the interpreter, it pre-compiles tiny templates for each bytecode at build time, then stitches them together at runtime with a few pointer patches. The runtime cost is minimal. The implementation cost — keeping those templates synchronized with every change to the bytecode set, across x86-64, ARM64, Windows, Linux, and macOS — turned out to be enormous. Every time someone touched the eval loop, the JIT team had to re-validate templates on five platforms. The interpreter team is small. The JIT team was smaller. The math stopped working.
The deeper problem is structural. CPython's interpreter is reference-counted, has a GIL (until the free-threaded build matures), and treats every Python operation as a megamorphic dispatch over arbitrary user-defined `__add__` and `__getattr__` methods. A JIT can speculate past this — that's exactly what PyPy does — but only if it can also deoptimize cheaply when speculation fails. The CPython JIT inherited the interpreter's object model wholesale, which capped how much it could speculate. The specializing interpreter already grabbed most of the easy wins. What was left required structural changes the project wasn't authorized to make.
Community reaction on the thread is split into two camps and they're talking past each other. The pragmatists argue this is the right call: ship the free-threaded build, finish PEP 703, stop spending scarce maintainer time on a project that hasn't proven itself. The optimists argue the JIT was finally about to turn the corner — that the tier-2 optimizer work just landed, that the trace-based design hadn't been given a fair shot, and that pausing now means restarting from zero in two years when someone tries again. Both sides are partially right, which is what makes the decision genuinely hard rather than obvious.
There's also a quieter pattern worth naming. This is the second major performance bet CPython has walked away from in five years: Guido van Rossum's Shannon-Plan-era "5× faster Python" goal quietly slipped, the Faster CPython team got dismantled, and now the JIT is on ice. Meanwhile Mojo is shipping, PyPy keeps grinding, and the free-threaded build is consuming all the oxygen. CPython is making a real choice: parallelism over single-thread speed. That's defensible. It's also a concession.
If you have hot Python code paths and you were waiting for CPython to get fast, stop waiting. The honest options are unchanged from 2020: rewrite the hot path in Cython, Rust (via PyO3), or C; use PyPy where your dependency graph allows it; or move to a language built for the workload. Pure-CPython performance is going to keep improving incrementally via specialization and free-threading, but the kind of 3–5× step-change a working JIT would have delivered isn't on any roadmap right now.
For library authors, the implication is subtler. The free-threaded build (no-GIL) is the official long-term bet, and your C extensions need to be ready for it. If you've been deferring the work of marking your extension `Py_MOD_GIL_NOT_USED` and fixing the inevitable thread-safety bugs that surface, the calculation just changed: that's the path CPython is investing in, and it's the path through which your code will actually get faster on multi-core workloads. The free-threaded ecosystem is where the maintainer attention is going.
For anyone considering Python for a greenfield CPU-bound service, the calculus tightens. Go, Rust, and even modern JVM languages keep widening the gap on per-core throughput. Python's argument has always been ecosystem and developer velocity, not raw speed. That argument is intact. But "it'll get faster soon" can come off the pitch deck.
The JIT isn't being deleted — the council was explicit that the scaffolding stays and that someone could pick it back up. But "paused with no funded team" in open source usually means "shelved." The realistic forecast is that the next serious attempt at a CPython JIT will be a fresh design, probably tied to the free-threaded build, probably not before 3.16 or 3.17, and probably contingent on a corporate sponsor stepping in to replace what Microsoft pulled. Until then, CPython's performance story is: specializing interpreter, no-GIL, and the same advice we've given for fifteen years — push the hot loop into C.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.