How do you check whether CPython is running the free-threaded build?

## Two facts, not one People say "am I on the no-GIL Python?" as if it were a single yes/no. On CPython 3.14 it is two separate facts, and confusing them is the most common beginner error on this topic. **Fact one: the build.** Free-threading is a compile-time configuration (`--disable-gil`), not a flag you can turn on for a normal interpreter. A free-threaded CPython is a *different binary* built from the same source, and it reports itself: - `sysconfig.get_config_var("Py_GIL_DISABLED")` is `1` on a free-threaded build. On a default build it is falsy — on some platforms `None`, on others `0` — so test it for truthiness, never with `is None`. - On POSIX, `sys.abiflags` is `"t"` on the free-threaded build and `""` on the default one. - The interpreter installs under a `t`-suffixed name — `python3.14t` next to `python3.14`, `python3.14t.exe` on Windows — precisely so both can coexist in one installation. - Compiled extension modules carry the tag too: `sysconfig.get_config_var("EXT_SUFFIX")` reads `.cpython-314-...` on the default build and `.cpython-314t-...` on the free-threaded one, which is why the two builds cannot share an extension binary. **Fact two: the runtime state.** `sys._is_gil_enabled()` returns whether the global lock is engaged *in this process, right now*. On a default build it always returns `True`. On a free-threaded build it normally returns `False` — but not always, and that is the interesting part. ## Why the two can disagree A free-threaded interpreter can end up running with the GIL on for two reasons: 1. **You asked for it.** `-X gil=1` on the command line, or `PYTHON_GIL=1` in the environment, forces the lock on at startup so you can compare behaviour or work around an unsafe dependency without switching binaries. 2. **An extension asked for it.** A C extension module must explicitly declare that it is safe without the lock. If one that has not declared it is imported, the interpreter turns the GIL back on for the whole process and emits a `RuntimeWarning` naming the module. Your process is then running the free-threaded *build* with the lock *enabled* — the worst of both worlds, since you are paying the build's single-threaded overhead and getting none of the parallelism. That is why a health check that only inspects the build configuration is not enough: it tells you what you installed, not what you got. ## What to actually write For a script or a notebook, one line is fine: ```python import sys print(sys._is_gil_enabled()) ``` For anything long-lived, log both values at startup, after all imports have run — the ordering matters, since the GIL can flip during import, not before it. A service that reports "free-threaded build: True, GIL enabled: True" has a dependency problem waiting for you, and you would much rather read that in a startup line than infer it three weeks later from a flat throughput graph. Note the leading underscore in `sys._is_gil_enabled`. It is deliberately private-looking: the CPython authors reserve the right to change it, and it exists mainly for diagnostics and test suites. Use it for exactly that — a startup log line, a test skip condition, a support script — and do not build behavioural branches all over an application on top of it. ## Version boundaries `sys._is_gil_enabled()` arrived with the first experimental free-threaded build in 3.13. The build was *officially supported* in 3.14 under PEP 779, which is when the wheel ecosystem and the packaging tooling started treating it as a first-class target rather than an experiment. On any interpreter older than 3.13 the function does not exist at all, so a compatibility check should reach for it with `getattr` if it has to run on those. On 3.14 itself, both the function and the `sysconfig` variable are always present, whichever build you are on — they simply report different values.