Python 3.13 offers an experimental free-threaded CPython build that can run Python threads without the global interpreter lock enabled. It is not the default installation, and it does not mean that Python has universally removed the GIL. Treat it as a separate runtime variant that needs an isolated environment, dependency review, race analysis, and measurement—not as a switch that grants linear speedup to an existing service.

Verify the runtime you are measuring

Installation and executable naming vary by platform. Record the Python version, implementation, build configuration, and GIL status at the beginning of every benchmark instead of trusting a filename. Keep conventional and free-threaded virtual environments separate, and verify lock files and binary wheels in each environment.

import sys
import sysconfig

def runtime_report() -> dict[str, object]:
    enabled = getattr(sys, "_is_gil_enabled", lambda: True)()
    return {
        "version": sys.version,
        "implementation": sys.implementation.name,
        "gil_enabled": enabled,
        "py_gil_disabled": sysconfig.get_config_var("Py_GIL_DISABLED"),
    }

print(runtime_report())

This report belongs beside benchmark results. Check the exact probing interfaces against the Python 3.13 documentation. Some extension modules may enable the GIL when imported or may have no compatible wheel. An interpreter capable of free threading does not prove that the running dependency graph is operating that way.

Pick a workload with a plausible benefit

The strongest candidate is divisible, CPU-bound Python work with little shared state, such as parsing independent documents in pure Python. A network, storage, or database-heavy service can already overlap waiting with asynchronous I/O or conventional threads, so removing the GIL may not move its bottleneck. Work dominated by native libraries that already release the GIL may show little additional benefit.

A process pool remains an important baseline. Processes incur serialization and memory overhead, but offer mature isolation and fault boundaries. Compare at least conventional CPython with one thread, conventional CPython with threads, a process pool, and free-threaded threads. Comparing only an intentionally weak old configuration to an optimized new one is not useful evidence.

Also consider deployment shape. A container with one CPU quota cannot exploit eight Python threads merely because the host has eight cores. Memory bandwidth, allocator contention, and synchronization can flatten or reverse scaling before the logical core count.

Interpreter safety is not application atomicity

Built-in types use internal synchronization to protect interpreter invariants, but an application must not assume compound operations are business-level atomic. “Insert if absent,” read-modify-write, and iteration concurrent with mutation contain several semantic steps. They need a lock, queue, immutable snapshot, or single owner. Races previously obscured by the GIL can become easier to reproduce in a free-threaded build.

Reducing shared mutable state is usually more dependable than adding many fine-grained locks. Give workers immutable inputs and independent results, then merge through one owner. Use explicit primitives such as queue.Queue for communication. A third-party object is thread-safe only if its contract says so; its Python surface does not establish safety.

Make extension compatibility a gate

C extensions may contain global caches, reference-count assumptions, or mutable state that was implicitly protected by the GIL. Produce a complete dependency inventory, install and import it in an isolated free-threaded environment, run upstream tests where available, and then run the application’s concurrent scenarios. If a compatible wheel is missing, do not improvise a production build. Pin the compiler, ABI, sources, flags, and build log.

Record when importing a module re-enables the GIL. A program that starts successfully may no longer be exercising the intended mode. Replacing a dependency also carries feature, correctness, security, and maintenance costs that belong in the decision.

Build a reproducible benchmark

Fix the data set, warm-up, thread counts, CPU conditions, Python patch release, and dependencies. Measure throughput, tail latency, CPU utilization, memory, and correctness. Begin at one thread and increase gradually; degradation beyond the useful core count is part of the result. Run several trials and report a distribution rather than selecting the fastest pass.

Every performance run needs output validation and a separate stress suite. A faster wrong answer is not a speedup. Native ThreadSanitizer builds can help expose defects, but their instrumentation changes performance, so use them for diagnosis rather than published timings.

Define an adoption gate

A safe experiment starts in development, moves to a deterministic load test, and then reaches a small reversible workload. Require a stable improvement on representative hardware, compatible extensions, race-focused tests, observability that reports runtime mode, and an immediate conventional-build fallback. Track Python maintenance releases because experimental behavior and ecosystem support evolve.

Python 3.13 free-threaded CPython is a valuable experimental path, not a general acceleration promise. Confirm the environment and dependency mode, choose CPU-parallel work, keep process pools as a baseline, revisit every shared-state assumption, and measure correctness together with speed. Expand usage only when the benefit survives those constraints and operations can roll back safely.