Skip to content
Arol is a tech journalist who currently works as a contributor at How-To Geek since 2022. He first began writing online for the short-lived portal of Spanish-language gaming forum Emudesc in 2013. Years later, in 2017, he got his true start in tech journalism working for a small Google-focused site called Pixel Spot. He transitioned to a news and feature writer role at XDA Developers that same year, where he worked until 2021 before making the jump to other websites.
Arol brings nearly a decade of writing experience, and the occasional hot take, to his writings. While he’s a technology lover at heart, he holds computer hardware and smartphones particularly close to heart. You’ll normally find him covering news, although he has also written the occasional deal, buyer’s guide, how-to post, and round-up. He’s also written for Android Police and MakeUseOf. He’s also a Political Science student at the Central University of Venezuela, and a proud member of student movement Àgora UCV. When he’s not writing, you’ll probably find him hitting the gym, trying to ace a new hobby, reading his textbooks, or traveling. You can reach him at me@arolwright.com.
For years, Python threads could not use more than one CPU core at a time. That changed with the free-threaded build, which is now officially supported as of the time I’m writing this. Here’s a brief introduction to it, and why it could be a big deal.
What’s free-threaded Python, anyway?
The GIL is optional now, with trade-offs
Python has carried a global interpreter lock, known as the GIL, since its early days. The lock lets only one thread execute Python bytecode at a time within a process. That keeps CPython’s memory management simple and safe, but it also means threads cannot spread CPU-bound work across cores. Developers who wanted real parallelism usually reached for multiprocessing, which spawns separate processes with their own memory, or leaned on C extensions that release the lock. A free-threaded build removes the restriction entirely.
Proposed in PEP 703 and shipped as an experiment in Python 3.13 in October 2024, it lets several threads run Python code in parallel on different cores. That first release came with real costs. Single-threaded code ran noticeably slower, and some internal optimizations had to be switched off because they were not yet thread-safe. The turning point was PEP 779, which set the criteria for promoting the build and was accepted in June 2025. Python 3.14, released in October 2025, met them.
The documentation now calls the free-threaded build supported and no longer experimental, though it remains optional and separate from the default interpreter. The core team describes this as Phase II of a gradual plan. Whether a later phase makes free threading the only build is still an open question.
The specialized adaptive interpreter, which speeds up ordinary Python code, now runs in free-threaded mode, and the single-threaded penalty has shrunk to roughly 5 to 10 percent against the standard build. You also opt in by installing a distinct build, usually labeled 3.14t, rather than flipping a switch in an existing install. Tools like uv can keep both builds side by side, so you can compare them on your own code. It is the same language with a different runtime underneath.
How has it helped, actually?
Real parallelism, without the multiprocessing overhead
The benefit is clearest in CPU-bound code that you can split across threads. Think of parsing and transforming large batches of files, running scoring or feature calculations over many records, or processing independent chunks of data in a worker pool. On the standard build, a thread pool doing this work gains almost nothing, because the lock serializes the computation. Teams therefore moved to multiprocessing, and that brings its own tax. Every argument and result has to be pickled and sent between processes, memory use multiplies because each worker holds its own copy of shared data, and startup costs add up.
With the GIL gone, the same threaded code can scale across cores while every thread reads the same objects in memory. That removes the serialization step and keeps the program simpler, since you no longer need a separate process architecture just to use the hardware you paid for. The gain depends on how well the work divides. A job that spends most of its time waiting on network calls or disk was already fine with threads, because the lock is released during I/O, so it sees little change.
A job that mixes heavy computation with a lot of locking on shared state may scale poorly no matter which build runs it. The best results come from workloads that split into independent pieces and spend most of their time in Python code or in libraries that cooperate with free threading. The only honest way to know is to measure. Run the same threaded benchmark on both builds, at several thread counts, on the machine that will run it in production. Expect the single-thread comparison to favor the standard build slightly, and expect the multi-thread comparison to decide whether the switch is worth it.
Is it worth the hype?
Promising and usable, but not a default yet
As I always say when I’m about to close out an article, it depends. The build is supported, but it remains opt-in, and the cost is not zero. Single-threaded code still runs a few percent slower, so an application that never uses threads for computation gains nothing and loses a little. The experimental JIT compiler in 3.14 is also not yet available in the free-threaded build, which matters if you were counting on that boost.
The bigger obstacle here is the ecosystem. Packages with C extensions need wheels built for the free-threaded interpreter, and coverage is still uneven outside the core scientific-Python libraries, so one unsupported dependency can block adoption. Python 3.15, released in October 2026, addresses part of this with PEP 803, which adds a stable ABI for free-threaded builds, tagged abi3t. It lets extension authors publish one wheel that works across free-threaded releases, but build tools are still catching up with it.
There is also a quieter risk in your own code. The GIL hid many race conditions by accident, and removing it can expose bugs in code that was never truly thread-safe. Review shared state, add locks where needed, and test under load before trusting results. Still, the direction is clear. Major libraries are shipping free-threaded builds, and the core team treats the work as a long-term commitment rather than a side experiment. If your workload is CPU-bound, parallelizable, and built on compatible packages, try it now. Otherwise, keep an eye on it and retest with each release.
Worth testing, not yet a default
Free-threaded Python has moved from curiosity to a supported option. It rewards parallel, CPU-heavy work and costs a little elsewhere. Check your dependencies, benchmark your own code, and adopt it where the numbers justify it.
