What does the free-threaded build from PEP 703 change for the code you write?

The free-threaded build, shipped as an optional interpreter since CPython 3.13, removes the GIL so multiple threads can run Python bytecode in parallel. Your code becomes genuinely concurrent, which means races that the GIL used to hide are now real. You need explicit locks around shared mutable state, and you have to check that every C extension you depend on supports it.

Free threading landed as an experimental build in 3.13 and has been maturing since, and the key point is that it is a separate interpreter you opt into, not something that silently changed under everyone. With the lock gone, two threads can run bytecode on two cores at once, so a CPU bound worker pool finally scales without paying process startup and pickling costs. The trade is correctness. Under the old build a lot of sloppy code got away with unsynchronized dict updates because a bytecode boundary rarely landed in the wrong place. Now those are honest data races and you need a Lock or a queue. I tried it on a scoring job that was fanning work out to four processes, and threads gave similar throughput with a much smaller memory footprint since the model stayed loaded once instead of four times. The blocker for production was extensions. Anything with a C layer has to be rebuilt against the free threaded ABI, so before shipping it I would audit the dependency tree and check what the maintainers have published.