For most of Python’s history, the answer to “can I use threads for CPU-bound work?” was a firm no. The Global Interpreter Lock (GIL) ensured that only one thread executed Python bytecode at a time, so the standard advice was to reach for multiprocessing and pay the cost of separate processes, pickled messages, and duplicated memory. Python 3.13 shipped an experimental free-threaded build without the GIL. Python 3.14 changed its status: per PEP 779, free-threaded Python is now officially supported — no longer an experiment, and promised not to be removed without a proper deprecation schedule.
This post walks through what the free-threaded build actually changes, what the single-threaded cost looks like now, when threads beat processes, and the practical decisions you face when adopting it — including the one about libraries, which turns out to be the hardest.
What the free-threaded build removes — and what it keeps
The GIL solved a real problem. It made the reference interpreter’s internal state (reference counts, object freelists, the memory allocator) safe to touch from any thread with a single lock. The price was that a multithreaded Python program could never use more than one core for Python code.
The free-threaded build, described in PEP 703, removes the GIL and replaces that one-big-lock design with fine-grained locking and lock-free primitives where possible. Reference counts become biased references — most increment and decrement operations on an object are performed by a designated “owning” thread without atomic instructions, while accesses from other threads use interlocked operations. Object headers are reorganized so the mutable bookkeeping lives on separate cache lines from the immutable parts — two threads reading an object no longer contend on the same cache line just because one of them is also writing to it.
Two clarifications matter, because the marketing around “no GIL” tends to blur them:
- Your Python objects are not suddenly thread-safe. A
list.appendis atomic-ish under the GIL by accident; without it, the usual data races on shared mutable state are back. You protect invariants with locks exactly like in any other language. - The GIL never made I/O-bound code faster — threads were already fine for I/O concurrency. What changes is CPU-bound parallelism: four threads can now genuinely run four cores of pure-Python work.
The single-threaded tax, measured
Removing a global lock means every reference-count update that used to be a plain integer increment can now need an atomic instruction, and object access patterns get less cache-friendly. That cost shows up on every workload, including code that never spawns a thread. In the 3.13 experimental build it was painful — commonly 30-40% slower on single-threaded benchmarks. In 3.14, the specializing adaptive interpreter (PEP 659) is enabled in free-threaded mode alongside many other optimizations, and the official documentation puts the penalty on single-threaded code at roughly 5-10%, depending on platform and compiler.
That is the number that changes the adoption calculus. A 40% tax meant “only for workloads desperate for parallelism.” A 5-10% tax means you can reasonably run the free-threaded build fleet-wide and stop thinking of it as a special configuration. Independent micro-benchmarks land in a similar range, though exact numbers vary by workload and CPU — benchmark your own code before committing.
One caveat: check your build flags. If you configure CPython with --disable-gil, you get the free-threaded runtime; the default build keeps the GIL. Official binary installers ship both variants — on Windows and macOS the free-threaded interpreter installs as python3.14t alongside the regular one, and on most Linux distributions you install a separate package such as python3.14-free-threaded.
Threads vs processes, concretely
To see where the crossover sits, here is a small CPU-bound benchmark you can run against both builds:
import sys
import threading
import time
def chunk(n: int) -> int:
total = 0
for i in range(n):
total += i * i
return total
def run_threads(workers: int, n: int) -> float:
threads = [
threading.Thread(target=chunk, args=(n,))
for _ in range(workers)
]
start = time.perf_counter()
for t in threads:
t.start()
for t in threads:
t.join()
return time.perf_counter() - start
if __name__ == "__main__":
print("GIL disabled:", sys._is_gil_enabled() is False)
n = 20_000_000
base = run_threads(1, n)
print(f"1 thread: {base:.2f}s")
for workers in (2, 4):
elapsed = run_threads(workers, n)
print(f"{workers} threads: {elapsed:.2f}s (speedup {base / elapsed:.2f}x)")On the default build, the speedup for 4 threads hovers around 1.0x — the GIL serializes everything, and the extra threads add contention. On the free-threaded build, the same code scales to roughly 3-4x on a quad-core machine, depending on how much of the workload stays inside pure-Python loops. Real code that spends significant time in C extensions (NumPy kernels, regex, JSON encoding) already released the GIL during those calls, so the visible gain depends on your Python-vs-C mix. The pure-Python fraction is what you win back.
This is also why multiprocessing is no longer automatically the right answer for CPU parallelism. Processes still win when you want hard isolation, when you are sandboxing untrusted code, or when a native dependency is not compatible with the free-threaded build. But threads avoid the process overhead entirely: no pickling of arguments and results, no duplicated interpreter state, no if __name__ == "__main__" guard requirements on Windows, and near-instant startup. For fan-out workloads — process 500 files, score 200 rows — a ThreadPoolExecutor on the free-threaded build is simply less machinery.
Subinterpreters: the middle option
Python 3.14 also standardized a third option with PEP 734: the concurrent.interpreters module exposes multiple interpreters — isolated Python runtimes inside one process — from the standard library. Each interpreter has its own module state and its own GIL-equivalent, so they run in parallel without sharing mutable objects by default. Communication is explicit, typically through queues or channels, which gets you an actor-style model: isolation close to processes, memory efficiency close to threads.
The trade-off is ecosystem maturity. Many C extensions are not yet multi-interpreter compatible, and inter-interpreter communication is deliberately low-level. Free-threading is the mainstream path; interpreters are the interesting one to watch.
Deciding: should you switch?
The decision reduces to two questions.
Do you have CPU-bound Python work? If your service is I/O-bound (most web backends are), free-threading buys you little — async and the usual thread pool for blocking calls already cover concurrency there. The compelling cases are data processing in pure Python, parallel fan-out in request handlers, template rendering, parsing, and anything where you previously forked processes purely to escape the GIL. Note that if your “Python CPU work” is actually NumPy, this changes little — NumPy already parallelizes internally and releases the GIL.
Are your dependencies compatible? This is the real gate. C extensions that poke at CPython internals need auditing for the free-threaded build; an extension compiled without Py_GIL_DISABLED support may crash or corrupt memory under concurrency rather than fail cleanly. The practical workflow: install the free-threaded interpreter, create a virtualenv, install your dependency set, run your full test suite under load, and watch for hangs or segfaults. Wheels built for the free-threaded ABI are marked cp314t; if a package only ships cp314 wheels, it is either pure Python or it will compile from source against the free-threaded headers — and compiling from source is not the same as being correct.
A pragmatic rollout that has worked for teams adopting it:
- Stage 1: keep the default build in production; run your CI test matrix additionally against the free-threaded interpreter. This surfaces incompatible dependencies early, with zero production risk.
- Stage 2: for services with measured CPU-bound bottlenecks, benchmark the free-threaded build against the default one on representative workloads. Compare both single-threaded latency (the 5-10% tax) and parallel throughput (the win).
- Stage 3: adopt where the win is real, and convert
multiprocessingpools to thread pools one service at a time. Keep process isolation for anything sandboxing untrusted input.
One more wrinkle: the GC that came and went
Worth knowing if you track interpreter internals: 3.14.0 shipped a new incremental cycle collector that cut GC pause times by an order of magnitude on large heaps. It was reverted in 3.14.5 back to the generational collector from 3.13 after reports of significant memory pressure in production. The episode is a useful reminder that the interpreter itself is under active, sometimes course-correcting, development — pin your patch versions and read the release notes even for minor updates.
Wrapping up
Free-threaded Python crossing into official support is the most significant concurrency change the language has ever shipped. The single-threaded tax is down to a level you can pay fleet-wide, threads are now a legitimate answer for CPU-bound work, and the multiprocessing-first reflex deserves re-examination. The practical blockers are C extension compatibility and the discipline to test under real concurrency. Start with CI: add the free-threaded interpreter to your test matrix this week, and you will know exactly where your stack stands before you need it.