Python 3.15 hits rc1. Is free-threading ready for your app?

Python 3.15.0rc1 arrived on August 4, 2026, and the release announcement states there will be no ABI changes from this point forward in the 3.15 series. Wheels you build against rc1 keep working with the final release.

That matters more than it sounds. The headline change for 3.15 is a stable ABI for free-threaded builds, delivered by PEP 803. The practical answer for most teams is still: test it now, ship it later.

Key takeaways

• Python 3.15.0rc1 shipped on August 4, 2026, with rc2 scheduled for September 1 and the final release set for October 1, 2026 in PEP 790.
• Free-threaded CPython costs 1% to 8% in single-threaded performance depending on platform, per the official free-threading guide.
• The free-threaded build remains a separate, opt-in build. The default Python 3.15 install still runs with the GIL.

What PEP 803 actually fixes

The GIL is the global interpreter lock, the CPython mechanism that lets only one thread execute Python bytecode at a time. A free-threaded build is a separate CPython build with that lock removed, available since Python 3.13.

The blocker was never the interpreter. It was the packaging. Every C extension needed a separate binary wheel for free-threaded builds, and the ABI those wheels targeted was not stable. PEP 803 is the proposal that gives free-threaded builds a stable ABI, and it lands alongside PEPs 820 and 793 for the related C API, the rc1 announcement says.

For a C extension author, that turns an ongoing rebuild burden into a normal release. For you, it means the free-threaded wheel for a library is more likely to exist, and more likely to keep working across 3.15 point releases.

What free-threading costs you

Removing a lock is not free. The official guide puts the single-threaded overhead at roughly 1% on macOS aarch64 and roughly 8% on x86-64 Linux, varying by workload and hardware.

Memory is the less-discussed cost. The same guide attributes higher memory use to immortalized strings, larger object headers, deferred reclamation delays, mimalloc overhead, and the reference counting scheme.

Factor	Default build (GIL)	Free-threaded build
Single-thread speed	Baseline	1% to 8% slower
CPU-bound threads	One at a time	Truly parallel
Memory footprint	Baseline	Higher
C extension wheels	Universal	Separate build required
ABI stability in 3.15	Stable	Stable via PEP 803

Read that table as a trade, not an upgrade. You are paying single-thread speed and memory for parallelism you can only collect if your workload has parallelism in it.

Which workloads actually gain

Free-threading helps CPU-bound Python code running in threads, which is the case the free-threading guide describes as the target. It does very little for anything else.

1. CPU-bound work in threads. Image processing, numerical loops in pure Python, parsing, simulation. These scale with cores once the lock is gone.
2. Mixed workloads already using multiprocessing. Threads share memory, so dropping the process boundary can remove serialization overhead entirely.
3. Async I/O services. Little gain. An event loop was never blocked by the GIL in the first place.
4. NumPy-heavy pipelines. Little gain from the interpreter change, because the heavy loops already release the lock inside C code.

For example, a service that shells out to four worker processes to parse files in parallel is a strong candidate. A FastAPI application waiting on a database is not.

The thread-safety details that bite

Free-threading changes what "it worked before" means. Built-in types like dict, list and set use internal locks, but the free-threading guide is blunt that this describes the current implementation and is not a guarantee of current or future behavior.

Two specific hazards are documented in Python's C API free-threading notes. Accessing frame.f_locals from another thread is not safe and may crash the interpreter. Iterators are not safe for concurrent access, and concurrent iteration may produce duplicate or missing elements.

The practical rule is old and unchanged. Use threading.Lock around shared mutable state. Do not lean on the interpreter's internal locking as if it were an API.

How to test 3.15 free-threading without risking production

You can evaluate this in an afternoon, and the ABI freeze makes the results durable.

1. Install a free-threaded build. Official installers for macOS and Windows are on python.org downloads, and macOS binaries now install free-threading support by default, per the rc1 announcement.
2. Confirm which build is running with python -VV, or python -c "import sys; print(sys._is_gil_enabled())".
3. Run your existing test suite. Concurrency bugs that the GIL was hiding surface here, not in production.
4. Benchmark one representative CPU-bound path under both builds. Compare wall-clock time at your real thread count.
5. If you need a controlled comparison, re-enable the lock in the same binary with PYTHON_GIL=1 or python -X gil.

Rerun step 3 before the October 1, 2026 final release, since only clear bug fixes land between the release candidates and the final version.

Should you switch to free-threaded Python?

Not as a default. The default Python 3.15 build still ships with the GIL, and it remains the correct choice for most web services, scripts and data pipelines.

Switch when three things are true at once. Your profile shows CPU-bound Python, your parallelism is thread-shaped rather than process-shaped, and every C extension you depend on publishes a free-threaded wheel. Miss any one of those and you are paying 1% to 8% for nothing.

Test in October, plan for 2027. That is a defensible position for a US or European engineering team, and it is different from the "the GIL is gone" framing this release keeps attracting.

Frequently asked questions

When is Python 3.15 released?

Python 3.15.0 final is scheduled for October 1, 2026 in PEP 790. The first release candidate arrived on August 4, 2026, and a second was scheduled for September 1, 2026. Only clear bug fixes are accepted between the release candidates and the final release.

Is the GIL removed in Python 3.15?

No. The free-threaded build without the GIL is available as a separate, opt-in build, and the default Python 3.15 installation still uses the GIL. Python 3.15 adds a stable ABI for free-threaded builds through PEP 803, which makes C extension wheels for that build practical.

How much slower is free-threaded Python?

Between 1% and 8% on single-threaded code, according to Python's free-threading guide, with roughly 1% measured on macOS aarch64 and roughly 8% on x86-64 Linux. Memory use is also higher, because of immortalized strings, larger object headers and allocator overhead.

How do I check whether I am running free-threaded Python?

Run python -VV and look for the free-threading marker, or run python -c "import sys; print(sys._is_gil_enabled())". A configuration check also works: python -c "import sysconfig; print(sysconfig.get_config_var('Py_GIL_DISABLED'))".

Which Python code benefits from free-threading?

CPU-bound Python running in threads, such as parsing, simulation and numerical loops written in pure Python. Async I/O services gain little, because an event loop was never blocked by the GIL. NumPy-heavy pipelines also gain little, because those loops already release the lock inside C code.