Python Free-Threaded Mode (No-GIL) Explained

What free-threaded Python actually is, why it’s opt-in rather than the default, and when disabling the GIL is worth trying

Free-threaded Python removes the Global Interpreter Lock (GIL), letting threads run Python code truly in parallel — but it’s an opt-in build, not the default, and it doesn’t speed up the code you’re running today. Here’s what actually changed, and who it’s for right now.

The problem it solves: the GIL

CPython’s Global Interpreter Lock has always meant that only one thread can execute Python bytecode at a time, even on a multi-core machine — threads take turns rather than running simultaneously. This is why threading in Python has traditionally helped with I/O-bound waiting (a thread can release the GIL while waiting on a network call) but never with CPU-bound parallelism the way it does in languages without a GIL. For genuine CPU parallelism, Python developers have reached for multiprocessing (separate processes, no shared memory) or offloaded the work to a C extension like NumPy instead.

Free-threaded builds remove that lock, so multiple threads can genuinely execute Python bytecode on separate cores at the same time.

Officially supported, still opt-in

PEP 779, accepted June 2025, moved the free-threaded build from experimental (introduced in Python 3.13) to officially supported starting in Python 3.14 — a real commitment from the core team, not a permanent side experiment. But “supported” doesn’t mean “default”: you install it as a separate build, distinguished by a t suffix (python3.15t alongside the regular python3.15), and the standard python.org installer still installs the GIL-enabled interpreter unless you explicitly choose the free-threaded option.

The real trade-off: overhead, not a free lunch

Removing the GIL requires making the interpreter thread-safe in other ways, which adds overhead — reference counting in particular gets more expensive without a single global lock protecting it. PEP 779 sets a ceiling on this cost (roughly a 5-10% single-threaded slowdown versus the standard build by Python 3.14, down from a larger gap in early experimental versions) and a memory-overhead limit, but it’s still a cost. Running free-threaded Python on single-threaded code doesn’t make it faster — it can make it marginally slower, for no benefit.

Where it actually helps

Free-threaded mode is for genuinely CPU-bound, multi-threaded Python — numerical code, data processing, or custom algorithms spread across threading.Thread workers where you’d previously have needed multiprocessing (with its separate-memory-space overhead) to get real parallelism. If your bottleneck is I/O (waiting on a database, an API, a file), you already get concurrency benefits from threading or asyncio under the standard GIL build — free-threading doesn’t add anything there.

What 3.15 adds: a stable ABI for free-threaded builds

Python 3.15 adds PEP 803, a Stable ABI for free-threaded builds (nicknamed abi3t). It matters to the people who build C extensions rather than the people who use them: an extension targeting the Stable ABI can now be compiled once for free-threaded CPython, rather than needing a separate version-specific build for every Python release. The official notes are candid that moving over usually takes non-trivial source changes, such as switching to newer APIs and a new module export hook. Extensions that can’t switch continue to ship separate abi3 and cp315t builds. Build tools with abi3t support include meson-python, scikit-build-core and Maturin.

The practical effect for you is indirect: it lowers the cost for library authors to publish free-threaded wheels, which is the thing the ecosystem section below says is holding adoption back.

The ecosystem isn’t fully there yet

A large share of Python’s performance-critical libraries are C extensions, and not all of them are thread-safe under a free-threaded build yet — some still rely on the GIL implicitly for correctness, not just performance. The Python Free-Threading Guide tracks ecosystem compatibility if you’re considering testing it against real dependencies rather than a toy benchmark.

Should you try it

Not by default. For nearly everyone, the standard GIL-enabled build remains the right choice — it’s what your dependencies are tested against, what tutorials assume, and what has zero single-threaded overhead cost. Test the free-threaded build specifically if you have CPU-bound multi-threaded code today and want to measure a real before/after on your own workload — treat the PEP’s numbers as a ceiling on overhead, not a promise of speedup, since that depends entirely on how much of your workload can actually run in parallel.