When would you deploy the free-threaded CPython build instead of a process pool?

## What the build changes The free-threaded build is a compile-time variant of CPython in which the global interpreter lock is removed and object reference counting is made thread-safe by other means. Python threads in that build execute bytecode concurrently on multiple cores. It first shipped as an experimental option in 3.13 and, under PEP 779, became an officially supported build in 3.14 — supported, but still separate: the default download and the default `python3.14` binary on virtually every platform is the ordinary build with the lock. ## The case for it The process model has one structural weakness: nothing is shared. If eight workers each need a five-gigabyte in-memory structure, you either build it eight times or engineer around it with shared memory and a serialized layout. Threads have no such problem — they see the same objects at the same addresses — and the free-threaded build lets those threads actually run in parallel. So the strongest case is *large shared read-mostly state plus CPU-bound work over it*: an in-memory index being queried or rebuilt, a big graph being traversed, a model of any kind held once and used by many workers. The second strongest case is fine-grained work where the per-task pickling cost of a process pool dominates, since threads pass references rather than copies. ## The case against it First, single-threaded speed. PEP 779 documents roughly a 5–10% penalty against the ordinary build. A service that is not actually parallel pays that for nothing. Second, the ecosystem. Extension modules must be compiled for the free-threaded ABI and must declare that they support running without the lock; an extension that does not causes the interpreter to enable the lock at import, silently undoing the reason you deployed the build. Qualifying a dependency tree is real work, and it is the usual practical blocker. Third, correctness. The lock never made Python code thread-safe, but it did make many individual operations effectively atomic and hid a great deal of sloppiness. Without it, shared mutable state needs actual synchronization — `threading.Lock`, immutability, or per-thread ownership — and long-standing code that got away with a read-modify-write on a shared dictionary can start losing updates under real parallelism. Fourth, operations. You are running a different binary, so container images, wheels, build pipelines and support expectations all fork. That is an organizational cost, not a technical one, and it is often the deciding cost. ## How to decide Treat it as a qualification exercise, not a flag flip: 1. Confirm the workload is CPU-bound in pure Python and that the shared state is the reason processes are painful. If processes are fine, stop here. 2. Check every extension on the hot path for free-threaded support and verify at runtime that the lock actually stayed disabled — `sysconfig.get_config_var` reports whether the interpreter was built free-threaded, and the build reports itself in `sys.version`. 3. Benchmark three ways: default build serial, default build with processes, free-threaded build with threads. Include the single-threaded penalty in the comparison. 4. Audit shared mutable state and add explicit locking before, not after, you scale threads. ## Adjacent option worth naming Python 3.14 also brought multiple interpreters into the standard library through `concurrent.interpreters` and `concurrent.futures.InterpreterPoolExecutor` (PEP 734). Each interpreter has its own lock since 3.12, so this gives parallel bytecode inside one process with much stronger isolation than free-threading, at the price of not sharing arbitrary objects. Between processes, subinterpreters and the free-threaded build, the question is always the same: how much do the workers need to share, and how much are you willing to pay to give it to them?