Python's Experimental JIT Is Being Removed: What It Means for You

CPython's experimental just-in-time (JIT) compiler is expected to be removed from the main development branch early in the Python 3.16 cycle. The authors withdrew PEP 836, the proposal that would have made it a supported feature, on October 19, 2026. For almost everyone this changes nothing in production. The JIT was off by default in every official build, Python 3.13–3.15 keep the code they shipped with, and the faster-CPython work most people actually benefit from (the specializing interpreter and its follow-ups) is not affected. If you turned the JIT on yourself, you have a few things to check, covered below.

What happened, in order

The JIT has an unusual history for a core CPython feature. According to LWN's report from October 26, 2026, Brandt Bucher merged it into CPython in early 2024 without a standards-track PEP. Python 3.13 shipped it as an opt-in experiment. Here is how it went from there to removal:

Ostrowski's withdrawal post says the 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." The authors say they still believe in the technical direction, "including free-threaded support and a method-based frontend". They will publish the reference implementation and link it from the withdrawn PEP so others can build on it.

Why the council said no to the status quo

The council's objection was less about whether a JIT is a good idea and more about how this one would be supported. LWN lists the concerns as maintenance burden, platform support, memory impact, user-visible behaviour differences, security and compatibility testing, plus a sense that core design decisions needed review from more core developers. InfoWorld's summary adds that the council found PEP 836 short on detail about long-term support, how performance would be measured, and integration with debugging and profiling tools. It also judged the performance expectations overly optimistic: gains were measurable but small and concentrated in programs such as long-running tight loops.

LWN reports that the council's position was that work stops in the main repository, but the community is free to continue it elsewhere.

How fast was the JIT, really?

The numbers explain why an experimental feature struggled to justify its maintenance cost.

• Python 3.14: The official release notes said enabling the JIT could range "from 10% slower to 20% faster, depending on workload". They did not recommend it for production.
• Python 3.15: The 3.15 release notes report a 7–8% geometric-mean improvement on pyperformance over a fully optimised interpreter on x86-64 Linux, and 11–12% over the tail-calling interpreter on AArch64 macOS. Individual benchmarks ranged from about 15% slower to more than 100% faster.
• PEP 836's own measurements (June 2026) put the JIT at roughly 4–12% faster on Tier 1 platforms: 1.126x on an Apple M3 Pro, 1.073x on AmpereOne Linux aarch64, 1.069x on an Intel i5-8400, and 1.047x on a Ryzen 5 3600X under Windows.
• The goal the PEP set: at least a 20% geometric-mean gain for JIT plus free-threading over the free-threaded interpreter, by Python 3.17 beta 1.

For comparison, the 3.14 tail-calling interpreter, an internal change that alters no visible behaviour, was benchmarked at 3–5% faster on pyperformance with Clang 19+. A JIT that adds LLVM as a build dependency, complicates native debugging and initially didn't support free-threading has a hard time competing with single-digit wins like that. Its real promise was the future headroom, and that is what the council wanted spelled out.

Does this affect you?

Most likely not. Use this checklist to be sure.

Scenario 1: You never touched the JIT

If you install Python from python.org, a distro package, a Docker image or a version manager and never set PYTHON_JIT=1 or built CPython with --enable-experimental-jit, you never ran the JIT. In 3.14 the official macOS and Windows binaries shipped with it built in but off. PEP 836 notes that Fedora and Gentoo also ship it built but disabled. Nothing changes for you.

Scenario 2: You enabled it on 3.13, 3.14 or 3.15

Your current interpreter keeps working. Removing code from CPython's main branch doesn't change already-released versions. Python 3.15 came out on October 9, 2026 with the JIT included, and it stays an experimental, opt-in feature on those branches. What you lose is a future: it won't be in 3.16, and per the council's pause, nothing new lands in main beyond bug and security fixes before the removal.

Scenario 3: You build CPython from main or test 3.16 alphas

Expect --enable-experimental-jit and related build machinery to disappear during the 3.16 cycle. Neither LWN nor the PEP gives an exact removal date, so watch the alphas. PEP 826 has alpha 2 on November 10, 2026 and beta 1 (feature freeze) on May 4, 2027. Python 3.16.0 final is scheduled for October 5, 2027.

How to check what you're running

These steps take about five minutes across a codebase:

1. Check the interpreter. On Python 3.14 or later, the sys._jit namespace tells you directly:

   python -c "import sys; print(sys._jit.is_available(), sys._jit.is_enabled())"
   

   is_available() reports whether the binary was built with JIT support. is_enabled() reports whether it's active in this process. False False or True False means you aren't using it.
2. Search your config. Grep Dockerfiles, CI workflows, systemd units, .env files and Kubernetes manifests for PYTHON_JIT.
3. Search your build scripts. If you compile CPython yourself, look for --enable-experimental-jit in configure invocations. On a built interpreter, python -c "import sysconfig; print(sysconfig.get_config_var('CONFIG_ARGS'))" shows the configure flags it was built with.
4. If you find it, measure it. Run your own benchmark or a representative workload with PYTHON_JIT=0 and PYTHON_JIT=1. If the gap is within noise, remove the flag now so a future upgrade to 3.16 doesn't surprise anyone.
5. If the gap is real, document it. Record the workload, the speedup and the Python version. That's the evidence you need to choose an alternative, and the kind of data any future effort to revive the JIT will need.

Leaving PYTHON_JIT=1 set on an interpreter without JIT support is harmless. The flag simply won't do anything. The risk is losing a speedup you were quietly relying on.

If you need Python to be faster, what now?

The JIT was never the main source of recent CPython speedups. Here are your realistic options, from least to most effort:

PEP 836's authors made the key point against "just use PyPy": many users can't switch runtimes because of supported-version requirements, extension compatibility or tooling. That gap is real. A JIT inside CPython would have reached people stuck on the reference interpreter, and for now nothing replaces it.

For teams running Python-heavy AI backends, a practical note: if your service is mostly waiting on model APIs, the interpreter is rarely the bottleneck. Measure token spend and latency before you spend engineering time on interpreter speed. The LLM API Cost Calculator is a quick way to see where the money goes.

What to watch next

• The reference implementation. The authors have committed to publishing it and linking it from the withdrawn PEP 836. Whether anyone keeps developing it in a fork is the main open question. InfoWorld notes that any revival would face the same high bar to get back into CPython.
• The removal commit in 3.16 alphas. Alpha 2 lands November 10, 2026. Check the changelogs if you build from source.
• Where performance work goes next. Free-threading and the interpreter improvements in 3.14 and 3.15 are still on track. If you care about Python speed, that's where gains are most likely to show up in 3.16.

What to do now: run the sys._jit check, grep for PYTHON_JIT, and if you find it, benchmark with it on and off. For nearly every team, the answer will be "we never used it", and you can close the ticket.