The authors of PEP 836 withdrew it on October 19, and that withdrawal means the experimental JIT compiler is coming out of CPython's main branch. Savannah Ostrowski posted the two paragraph notice on behalf of herself, Brandt Bucher and Ken Jin: "The Steering Council rightly sets a high bar for a proposal of this scope, and we don't feel we have the personal bandwidth to carry the current version forward." Brett Cannon confirmed the next day that JIT work in the CPython repo has stopped. Ten days earlier, Python 3.15 shipped with that same JIT upgraded and benchmarked at a 7 to 8 percent gain.

So the JIT project ended in the same month it posted its best numbers. That timing is the whole story.

How the clock started

The JIT landed in Python 3.13 in 2024 under PEP 744, which was an Informational PEP. It described the design (copy-and-patch, with LLVM needed only at build time) and left the hard questions open: who maintains it, how you measure it, what it does to debuggers and profilers. Nobody accepted anything. The code was on main because the 3.13 release manager, Thomas Wouters, encouraged its inclusion.

On June 5, 2026, the Steering Council froze it. Pablo Galindo Salgado posted the announcement: no new JIT features, optimizations or performance work on main until a Standards Track PEP was accepted. Bugfixes and security fixes could continue. The council gave the project six months. If no PEP was accepted in that window, "the JIT code must be removed from the main branch and development must be continued outside the main Python repository."

The council also admitted its own part. "Collectively we (the Steering Council) have not been as strict about following the process," Galindo wrote. Experiments were not supposed to run on main without a backing PEP. This one had for two years.

Mark Shannon, who drafted the original Faster CPython plan in 2020, asked for a grace period of a month or two to keep developing while the PEP was discussed. He warned about lost momentum and lost contributors. Wouters answered that the JIT shouldn't become "a moving target" while the PEP was debated.

What the PEP promised

PEP 836 arrived on July 3 with the title "JIT Go Brrr." It proposed a performance target of at least a 20 percent geometric mean improvement on pyperformance for the JIT plus free-threaded build, compared to the free-threaded interpreter without the JIT, by the first beta of Python 3.17. It also proposed replacing the tracing frontend with a method JIT, the approach Ruby took when it moved from YJIT to ZJIT.

That second part split the JIT's own developers. Shannon argued on August 19 that region selection had no business in a PEP and that Ruby's ZJIT was still slower than the stalled YJIT after a year of work. Bucher answered with a number from main's tracing JIT: a graphlib TopologicalSorter call needed over 40,000 nodes before the JIT reached a steady state, compiling more than 30 unique traces along the way. A method JIT with similar thresholds needed about 8,000 nodes and compiled four functions.

Bucher also wrote this, which I think explains the withdrawal better than anything in the official notice: "I spent four years working full time on this JIT and giving lots of talks on how it works, and explaining it only got harder with time, not easier. If the system no longer fits in my head, that should at least be minor cause for alarm regarding the implementation itself."

The Steering Council replied on September 21, with Thomas Wouters posting for the council minus Ostrowski, who recused as a PEP author. The PEP answered the council's questions, "although perhaps some less convincingly than others." Then came a list of things the council found too vague or too optimistic. Performance was a single range rather than a breakdown by platform, compiler and workload. Memory impact was hand waved. The compatibility review was scheduled for the last six months of a two and a half year timeline, which the council called "way, way too late." Security was "an underserved area." Design decisions were being made by a small group without review from the larger body of developers who'd end up supporting the result.

None of these were hard blockers, the council said. Four weeks later the authors withdrew.

The number

Python 3.15 came out on October 9. Its What's New page reports a 7 to 8 percent geometric mean improvement for the JIT over the standard interpreter on x86-64 Linux, and 11 to 12 percent over the tail-calling interpreter on AArch64 macOS. Individual benchmarks range from a 15 percent slowdown to more than double speed. You still have to opt in with PYTHON_JIT=1, and it's still labeled experimental.

Those are the best figures the JIT ever posted in a release. They are also well short of the 20 percent the PEP set as the floor for keeping the JIT in the tree, and the SC said out loud that it found the performance claims optimistic. PyPy gets an order of magnitude on the workloads it handles well. CPython's adaptive specializing interpreter, which shipped in 3.11 and needs no opt-in, already took the cheap wins. What was left for the JIT was the expensive part, and it paid out single digits.

I wouldn't have turned it on in production, and I doubt many people did. An 8 percent gain is smaller than the noise from a kernel upgrade. The downside was a code path that profilers, debuggers and C extensions had never been tested against. An optional feature that nobody opts in to has already received its verdict.

What changes for you

For anyone shipping Python today, nothing. The JIT is off by default in 3.13, 3.14 and 3.15. It stays in those branches, limited to bugfixes, for as long as those versions are maintained. The removal happens on main, which is Python 3.16, due in October 2027. The six-month window closes around December 5, and Cannon said the decision was made at the core developer sprints, where most of the current JIT contributors were in the room.

The reference implementation will be published and linked from the withdrawn PEP. Anyone who wants to carry it forward can, outside the repo, and would face the same bar to bring it back. CinderX, Meta's JIT, already lives outside the tree that way and has to chase every CPython release. Numba and PyTorch compile their own subsets. The Python core team's bet is now the interpreter, free-threading and lazy imports, and InfoWorld's read is that this is a pause rather than a burial. Maybe.

The part I keep coming back to is the funding. Microsoft laid off most of the Faster CPython team in May 2025. Bucher's "four years working full time" was Microsoft's money. The Faster CPython team Shannon led was Microsoft headcount. Seventeen months after that money stopped, the people still holding the project said they didn't have the bandwidth, and the council said the design was being decided by too few people. Both statements describe the same hole.

Open source projects that depend on one sponsor's headcount look healthy right up until the quarter the headcount goes away. The JIT was merged in 2024 on the assumption that the team maintaining it would exist in 2027. The Steering Council's job in June was to stop assuming that, and it did. A JIT that delivers 8 percent and needs a paid team to survive is a worse deal for CPython than no JIT at all. That's the call they made, and I think it's the right one.

My prediction: a method JIT comes back as a proposal within two years, backed by a company that needs it for its own workloads, and it starts from Bucher's reference implementation rather than from scratch. The 20 percent target will still be the number to beat.