It has been two years since the change, in Python's history. The threaded build is real and it works.. It is not being used much. Here is what people are not talking about.

For most of the two years I have seen the same news headline over and over. The Global Interpreter Lock is dead. Python is free. Everything is going to change. I even wrote about how excited I was when Python 3.13 came out. I really meant it. The Global Interpreter Lock had been the thing that people hated most about Python for thirty years the reason why a laptop with sixteen cores would run your code like it only had one core. Then in October 2024 the Global Interpreter Lock became optional. Everyone was celebrating.

The party is over now. Almost nobody is left. Python without the Global Interpreter Lock. It is officially supported.. If you go to a hundred places where people use Python for real work and ask how many have actually started using the new version you can count them on one hand. The difference between how big of a deal thiss how many people are actually using it is the real story of 2026. It is also the story that nobody wants to tell because it does not make anyone look good.

I want to explain why most people are not using the Python without the Global Interpreter Lock using real numbers instead of just talking about how it feels. Some of this might sound like I am criticising the people who worked on Python. I am not. Getting rid of the Global Interpreter Lock was one of the things the Python team has ever done. My point is simpler and more useful: the thing that was supposed to be all good has some downsides. The downsides affect the people who were supposed to benefit the most, from Python without the Global Interpreter Lock.

Removable is not the same as removed.

Let me clear up some confusion. The Global Interpreter Lock or GIL can be taken out.. It has not been taken out yet. These are two things but some headlines mixed them up.

What you actually get when you download Python is still the same. It still has the GIL. It still runs by default. This will not change for a time. There is another version called the threaded build that you have to install on purpose. You can tell it's different because it has a "t" suffix.

Python 3.13 was the test of this new build. Python 3.14 made it officially supported. Python 3.15 which comes out soon makes it even better.. At no point did the GIL get removed from the Python you already use.

The plan is to make free-threaded the default build one day.. This has not been scheduled yet. No one knows when it will happen. Maybe, around 2028 or 2029. This assumes that all the packages work together which they never have in the past.

The GIL is removable. The GIL is not removed. The headlines kept collapsing those into one sentence, and that one collapse is where most of the disappointment comes from.

You pay for the lock you are not using.

The thing that people forget to mention when they're happy about something is that turning off the GIL makes code that only uses one thread run slower. This is not a theory it happens every time you test it on every type of computer because of how the system is built.

The reason for this is simple. The GIL was doing some work for free. Now every Python object has its lock and way of counting references. If you look at Metas repository you can see how much this costs. The PyObject struct, which is the basis for every value in your program used to be sixteen bytes. Now it is roughly thirty two bytes. It has five fields for things like thread identity, a lock for each object and garbage collector information. Even the garbage collector was changed from a three generation design to a single generation design that stops everything. The way memory is allocated was also changed.

The Python object is like a box that holds everything. Now this box is bigger and heavier because it has to carry more things. This makes it slower when you are only using one thread. The GIL was, like a helper that did some work for you but now you have to pay for it in other ways.

In version 3.13 the tax was really bad. It was like a step backwards with things taking twenty to forty percent longer. This was because the special part that helps the system run faster was turned off to be safe.. Then version 3.14 came out and it made things a lot better by turning that special part back on. This made the problem much smaller. It was only a few percent. By the time version 3.15 came out things were pretty good. On Linux x86_64 it was nine percent slower and on Apple silicon it was about six percent slower. It also used a bit memory, about fifteen to twenty percent more. This is a lot better, than version 3.13. It is still something you have to pay for even if you do not use the features. The tax is always there whether you like it or not and you have to pay it even if you only use one thread.

The win is real. It is narrow.

The threaded build is not a letdown in the area it was made for. When you look at what it was designed to do the results are really what people said they would be. The Meta benchmarks show that tasks that use a lot of CPU power work well with many threads. A task like calculating the Mandelbrot set, which did not benefit from threads before now works much faster with more cores. Simulations like Monte Carlo show that the speed increases as much as the number of threads. PyTorch inference, which used to slow down with many threads now runs smoothly.

If you look at these examples you can see a pattern. All the tasks that work well are Python programs that use a lot of CPU power and were limited by the lock. If your work involves running Python code that does a lot of computations like a data pipeline or a model serving layer or a numerical job that you currently have to split across processes then the free-threaded build is not just hype for you. It is the improvement you were waiting for. You should try it out this week.

The problem is that this only applies to a part of the Python code that people use. Most Python programs are used for web backends and web backends spend most of their time waiting for things like databases, caches or other services to respond. The old lock was not a problem for these tasks because it was already letting other tasks run while it was waiting. So if you remove the lock you are not really gaining anything. You are still paying a small price for it. You get a penalty and almost no benefits, from the free-threaded build.

Every workload that wins is CPU bound code that used to need multiprocessing. The median Python service in production is a web backend, and the lock was never its bottleneck.

The ecosystem is in charge not the person using it.

Even if the work you have to do is a match you do not get to decide by yourself. The things your work relies on also have a say. Most of them get a vote that you cannot change.

The group of tools used for science has done the job and done it very well. NumPy, SciPy, pandas, PyTorch, scikit-learn, Cython, pydantic Pillow all come with wheels that can be used by people at the same time now. The teams at Quansight and Meta that work on making things run smoothly did an amount of work changing the way some parts of the code were packaged because these parts used to think they were protected by a lock. If you are using these tools then you are, on ground.

When you step one inch outside the core the floor gets really soft. The OpenCV library does not have a version that can be used by threads at the same time. The same thing is true for grpcio, which is used by an amount of service infrastructure but it does this very quietly.

The vLLM, which is the engine that runs the inference for half of the industry is still being worked on. JupyterLab only works if you have an end that is not free-threaded which means it has a GIL enabled, around the kernel that can be used by many threads.

If a project is using a Cython module or some custom C code then it is not ready to be used by everyone until it has been thoroughly tested. The vLLM and OpenCV and grpcio are all important so it is surprising that they are not more stable. Any project that relies on these things is, in a state where it needs to be tested before it can be used.

That is the end of it. The scientific core is one thing. When you step outside of it things get really tricky especially with OpenCV and grpcio and vLLM.

The switch can flip itself off.

This is something that should make people think twice before they get too excited. It is the thing that I do not see people talking about very much. The threaded build has a safety mechanism. When it uses a C extension that has not said it is safe by setting the Py_mod_gil marker in its module definition CPython thinks the worst. Turns the GIL back on for the whole process.

It does this without saying anything. There is no error message. There is no warning. There is not a log line. Your threaded interpreter becomes a regular GIL interpreter again the moment one unmarked package is imported anywhere, in your dependencies and you still have to pay the price for using only one thread even though you are not getting the benefits of parallelism anymore. You can run your program for weeks thinking that you are using threads freely while really one of your dependencies has turned the lock on without you knowing.

The only way to find out what is going on is to ask the interpreter after you have imported everything you need.

# the one check that tells you the truth
import sys
import numpy        # or anything with a C extension

if sys._is_gil_enabled():
    print("GIL is back on. An extension re-enabled it.")
else:
    print("Free-threading is actually active.")

That tiny function is the difference between a free-threaded deployment and a free-threaded deployment in name only. If you take one line of code away from this piece, take that one.

The honest truth for now

So the switch is turned off in most stores and now you can understand why. The tax affects threaded code, which is what most code is. The big benefit is for CPU bound multiprocessing workloads, which's not very common. The ecosystem is strong in the core and not so great everywhere else.. The safety mechanism can quietly change your decision without letting you know.

This does not mean we should ignore this. It means we should do something specific. If you use CPU bound Python that currently uses processes and your dependencies are good you should test the free-threaded build with your actual workload now because the benefit is exactly what was promised and it is easy to set up. If you run a web service that uses asyncio the free-threaded build does not have much to offer you this year and trying to use it would be a waste of time.

For everyone in between you should install python3.15t alongside your interpreter and run your test suite with it. Not to use it for work. To find out when you want to which of your dependencies will cause problems. When the default build is finally available at the end of the decade you will already know what will not work. That is more valuable than another news story about a change that for most of us has not really happened yet.

The story of the GIL was never going to end with one release. It was always going to be an difficult process where the interpreter would get there years before the ecosystem would. We are, in the middle of that process now. Saying it is a disappointment does not understand what is happening. It is the hard part of a difficult task being done properly and the hard part is where the real work is.