Quick Answer: The Python experimental JIT, added to CPython for the 3.13 release, is being removed from the main branch. The steering council paused the work in June 2026 and demanded a standards-track PEP. The authors withdrew PEP 836 on October 19, 2026, so the code will likely be pulled early in the Python 3.16 development cycle.
The Python experimental JIT was supposed to be the big performance story of recent CPython releases. Instead, it's heading out the door, and the reasons say more about how Python governs major changes than about the compiler itself. As LWN.net reported, the project's own maintainers have now withdrawn the proposal that was meant to save it. Here's how that happened, and what it means if you build or ship Python.
How the JIT got into CPython without a PEP
Major CPython features normally land only after the steering council approves a standards-track PEP. That didn't happen here. Brandt Bucher gave a talk about the JIT at a core developer sprint and announced his plan to merge it. He had not written or submitted a PEP.
Council member Thomas Wouters, who was also the release manager for Python 3.13, pushed Bucher to write one. The result was PEP 744, "JIT Compilation," co-written with Savannah Ostrowski. It was an informational PEP, which means it documents a proposal without asking the community to formally approve it.
That distinction matters more than it looks. Work proceeded on the strength of an informational document for roughly two years. Nobody had to commit to a support plan, a maintenance model, or a set of success metrics. Most people skip this detail, but it explains why the council eventually stepped in.
The June ultimatum and the six-month clock
In June 2026, the council paused JIT work on the main branch until a standards-track PEP addressed maintenance, compatibility, success metrics, and a timeline. The council gave a six-month deadline. If the PEP wasn't submitted and accepted in that window, the council would require the JIT code to be removed from main.
Here's the sequence as it played out:
- 2024: The JIT lands in CPython for 3.13 under informational PEP 744.
- June 2026: The council pauses main-branch work and asks for a standards-track PEP.
- July 3, 2026: Bucher, Ostrowski, and Ken Jin publish PEP 836, "JIT Go Brrr: The Path to a Supported JIT Compiler for CPython," on the Python forum.
- September 21, 2026: The council posts a ten-point list of concerns.
- October 19, 2026: Ostrowski announces that PEP 836 is withdrawn.
Why did the council choose now? Wouters said there was no "single triggering event." The council had been discussing the JIT for a while, and it waited until after the Python 3.15 beta to make clear it was fine with the status quo for 3.15. The concern was interference: with instrumentation, debugging, and profiling, with external JITs such as CinderX, and with JIT-adjacent work like Numba and PyTorch's compile.
Why the council asked about experiments, not speed
Here's the counter-intuitive part. Most commentary frames this as a fight over whether the JIT is fast enough or ready for users. The council didn't argue that. Its September statement said PEP 836 answered every question it had asked, "although perhaps some less convincingly than others."
The real question was narrower. The council wanted to know whether the JIT should continue as an experiment inside CPython's main branch. Its reasoning was that experimentation in main creates a lack of unified design. Core developers, package maintainers, and users all face uncertainty when behavior and API surfaces keep changing under them.
The council's concerns were specific:
- Platform parity: The JIT should be easy to adopt on new platforms and should not require platform-specific knowledge to maintain.
- User-visible behavior: The PEP was "overly optimistic" about differences users would see with the JIT enabled. Users depend on interpreter idiosyncrasies, so the council wanted rules for whether those differences count as bugs.
- Memory impact: The council wanted these costs spelled out, not assumed away.
- Security: The council called this "an underserved area." It wanted a discussion with the Python security response team and a security review as part of any supported-status criteria.
- Design review: The council worried that design decisions were being made without critical review by the wider group of developers responsible for CPython.
A feature can work well and still fail this kind of review. The council's test was whether the community could absorb the change, not whether the code was good.
The compatibility review was the real sticking point
The most concrete disagreement was timing. PEP 836 proposed a compatibility review that would run the test suites of top PyPI packages against the JIT at the first Python 3.17 release candidate, expected in August 2028.
The council said that was "way, way too late." Its argument is worth understanding. If you test a compiler change only near release, you find breakages after the design has hardened and fixing them means reopening decisions. The council wanted the compatibility review to be "an ongoing and continuous process starting as soon as possible."
This is the trade-off in practice. Running the same package test suites early and often costs maintainer time now, but it surfaces behavior changes while they're cheap to fix. Waiting for a release candidate is cheaper in the short run and far more expensive when something breaks.
The PEP authors had a different view. Ostrowski argued that listing goals without sharing the plan behind them would be uncomfortable, because "goals without plans behind them aren't really goals at all." The council wanted more discussion before pronouncing on the PEP, and the authors decided they couldn't deliver that in time.
Comparing the options on the table
The JIT's path through CPython's governance involved several documents and states. This table shows where each one stands.
| Approach | Where it lives | Council position | Main trade-off |
|---|---|---|---|
| Experimental JIT in main (since 3.13) | CPython main branch | Council wants it removed unless a PEP is accepted | Fast iteration, but behavior and API keep shifting |
| PEP 744 "JIT Compilation" | PEP repository | Informational only; no consensus required | Easy to publish, but no maintenance commitment |
| PEP 836 "JIT Go Brrr" | Python forum draft, then withdrawn on October 19, 2026 | Answered the questions, though some less convincingly | Full plan, but the authors lacked bandwidth to finish |
| External JITs such as CinderX | Separate projects outside CPython | Council wants the in-tree JIT not to interfere with them | Isolation from main, but separate maintenance burden |
Note that the withdrawal doesn't mean the council rejected the technical ideas. The authors said they continue to believe in the direction, including free-threaded support and a method-based frontend.
What "withdrawn" actually means for you
Here's where most readers get it wrong. Many assume the JIT will hang around in 3.16 while a new proposal is drafted. That's unlikely. Brett Cannon said the work would stop in the main repository. Dunc Graham suggested an alternative PEP might still fit before the council's deadline, but Cannon said that was not likely because the people actively driving the JIT were either authors of PEP 836 or contributors to it.
The removal timing is also deliberate. The JIT will likely be removed fairly soon, so that any problems caused by removal can be fixed early in the Python 3.16 development cycle. Waiting until late in the cycle would give less time to find and fix them.
The authors plan to publish the reference implementation and link it from the withdrawn PEP, so others can build on it. Whether that happens is another matter. LWN noted that it is unclear whether the original drivers intend to keep working on the JIT, and that the project may simply be left for others to pick up if there's enough community interest.
What to do if you depend on the JIT
Even if you never enabled the JIT yourself, check whether your toolchain did. Here's a short audit you can run this week:
- Search your build scripts and CI configs for JIT-specific build options and runtime environment settings.
- Identify which Python versions you pin. Builds you already ship keep working. Future upgrades to 3.16 and later may not include the JIT.
- Run your test suite against 3.16 alpha builds as soon as they're available, which is the same kind of early compatibility check the council asked for.
- Decide whether you need the JIT's performance gains. If you do, evaluate external options, such as CinderX, before you need them. If you don't, remove the flags now so you don't get surprised later.
The main risk is discovering the dependency during an upgrade rather than before it. The council's concern about compatibility applies to users too.
Frequently Asked Questions
What is the Python experimental JIT?
The Python experimental JIT is a just-in-time compiler added to CPython, the reference Python interpreter, for the 3.13 release in 2024. Brandt Bucher led its development. It was labeled experimental, and its design was documented in informational PEP 744 rather than approved through a standards-track PEP.
Why is the Python JIT being removed?
The steering council paused work in June 2026 and required a standards-track PEP covering maintenance, compatibility, and success metrics. The authors withdrew PEP 836 on October 19, 2026. Without an accepted PEP, the council's deadline requires the code to be removed from CPython's main branch.
How do I keep using the JIT after it's removed from main?
The JIT is not guaranteed to be available in future CPython releases. Brett Cannon said work would stop in the main repository, but community work could continue elsewhere. If you need JIT performance, watch for the reference implementation the authors plan to publish, and evaluate external projects such as CinderX before you need them.
Will the Python JIT be removed in Python 3.16?
It is likely to be removed early in the Python 3.16 development cycle, according to the LWN report. The timing is intended to give maintainers time to fix any problems caused by removal before the release. Check the 3.16 release notes once they are published to confirm the final state.
Pass this to anyone whose CI pipeline still sets JIT flags, and ask them to check it before the 3.16 alpha lands. The Python experimental JIT may be leaving main, but the governance lesson applies to any feature that needs an approved plan before it ships.