Python Type Checking Just Got a Rust Overhaul: ty, Pyrefly, and the End of Slow mypy

For most of Python’s history, adding type hints to your code came with a trade-off: you got better editor support and fewer runtime bugs, but you paid for it with a type checker that crawled through your codebase at a pace that made you reconsider whether the whole thing was worth it. mypy, the community standard since 2012, is written in Python and checks types at Python speed — which is to say, not fast. On a medium-sized project, a full mypy run can take longer than your test suite.

That trade-off is dissolving. In the past two years, three new type checkers written in Rust have entered the field: ty from OpenAI, Pyrefly from Meta, and Zuban from independent developer David Halter. All three are dramatically faster than mypy — not by percentage points, but by multiples. And one of them, Pyrefly, already hit 1.0 in May 2026.

If you have been putting off adding type hints because mypy was too slow, or if you are running mypy and wondering whether there is a faster option, the landscape just changed. Here is what the new tools do, how they compare, and which one fits your project.

The Players

Six type checkers matter in 2026. Four of them have been around for years. Two are new enough that you might not have heard of them yet.

mypy is the original. Launched in 2012 and maintained by the Python community, it is written in Python, MIT-licensed, and still the most widely used type checker by a wide margin. It is also the slowest by a wide margin. mypy is permissive by default — it will not complain about untyped code unless you configure it to — which makes it easy to adopt incrementally but also easy to under-use.

pyright is Microsoft’s entry, written in TypeScript and first released in 2019. It is faster than mypy and stricter by default, which is why it powers the type checking in VS Code’s Pylance extension. If you have ever seen red squiggly lines under a type mismatch in VS Code, that was pyright.

Basedpyright is a community fork of pyright that adds features and fixes the original maintainer considers out of scope. It is mostly a drop-in replacement for pyright with a more opinionated defaults.

Now the Rust newcomers.

Pyrefly is Meta’s type checker, written in Rust and released as 1.0 in May 2026. Meta built it to check Instagram’s Python codebase — roughly 20 million lines — and claims it can do a full check in about 30 seconds. That works out to roughly 1.85 million lines per second. Even if you halve that number for real-world conditions, it is still fast enough to run on every save in your editor without you noticing.

ty is OpenAI’s entry, also written in Rust, MIT-licensed, and currently in beta. OpenAI claims ty runs 10 to 100 times faster than mypy and pyright. The project is less mature than Pyrefly — it does not yet have full editor integration or a 1.0 release — but it inherits from the same tooling philosophy that produced uv and Ruff at Astral, OpenAI’s partner on Rust-based Python tooling. If you follow Python tooling at all, you know that track record: uv replaced pip, Ruff replaced Flake8 and is working on replacing Black. ty is angling to do the same thing to mypy that Ruff did to Flake8.

Zuban is a one-person project by David Halter, the creator of the Jedi autocompletion library. It is AGPL-licensed with a commercial option, which limits its adoption in corporate environments but does not diminish the technical achievement.

The Speed Difference

The Rust-based checkers are faster than mypy and pyright. The question is how much faster, and the answer depends on who you ask and what code you test.

OpenAI claims ty is 10 to 100 times faster than mypy and pyright. Meta claims Pyrefly processes 20 million lines in 30 seconds. Zuban claims 20 to 200 times faster than mypy. These are vendor numbers, measured in controlled environments with codebases the vendors chose, running on hardware they optimized for. Treat them as plausible upper bounds, not guarantees.

Independent benchmarks tell a more grounded story. Tim Hopper at pydevtools ran all six checkers on a single Apple Silicon laptop in June 2026 using each tool’s then-current release. On a medium-sized open-source codebase, ty checked roughly 17 times faster than mypy on a single core. Pyrefly was about 14 times faster. Zuban was 10 to 12 times faster. pyright and Basedpyright sat between the Rust checkers and mypy — faster than mypy but not by an order of magnitude.

Those numbers are still transformative. A mypy run that takes 60 seconds becomes a ty run that takes 3.5 seconds. A CI pipeline that spends five minutes on type checking drops to under 20 seconds. The difference between “I will run type checking before I push” and “I will run type checking on every save” is not 10x or 17x. It is whether the feedback loop is short enough that you actually use it.

Beyond Speed: Strictness, Editor Support, and Licensing

Speed is the headline, but it is not the only thing that matters when you pick a type checker.

Strictness by default. pyright and Basedpyright are the strictest out of the box. They will flag untyped function parameters, missing return type annotations, and implicit Optional types — the kinds of things that mypy ignores unless you explicitly enable strict mode. ty and Pyrefly fall somewhere in the middle: stricter than vanilla mypy, more permissive than pyright. Zuban is closer to pyright on strictness.

Editor integration. pyright has the deepest editor support because it powers Pylance in VS Code. mypy has plugins for most editors but no first-party LSP server. Pyrefly ships with an LSP server and works in VS Code and Neovim. ty does not yet have editor integration — it is a CLI tool at this stage — which limits it to CI and pre-commit hooks for now. If you need in-editor type errors today, Pyrefly or pyright is the realistic choice.

Licensing. All of the major options except Zuban are MIT-licensed, which means no legal friction for commercial use. Zuban uses AGPL with a commercial license option, which some organizations will find disqualifying regardless of the tool’s technical merits.

Which One Should You Use?

The answer depends on where you are starting from and what you need most.

If you are not using type checking at all, start with Pyrefly. It is fast enough to run on every save, strict enough to catch real bugs without being oppressive, and has editor integration that works today in VS Code and Neovim. The barrier to entry for type checking has never been lower, and Pyrefly is the tool that lowers it the furthest. Install it, add a minimal config file, and run it on save — you will catch type errors you did not know you had within the first hour.

If you are currently using mypy and frustrated with the speed, switch to ty or Pyrefly. Both support most of the mypy configuration options and type-checking features you are already using. ty is faster on benchmarks but lacks editor integration. Pyrefly is slightly slower but works in your editor. The pydevtools migration guide estimates that most mypy projects can switch to either tool in under an hour, including configuration changes and fixing any new errors the stricter defaults surface. Start by running the new checker alongside mypy in CI with a loose configuration, tighten the rules incrementally, and remove mypy once you have had a clean run for a few weeks.

If you are using pyright in VS Code and happy with it, stay on pyright for now. The speed difference is noticeable but not transformational enough to justify a migration if your current setup is working. Revisit when ty ships editor integration — that is the moment the calculus changes and the combination of speed plus in-editor feedback becomes compelling enough to switch.

If you work at a company with a large Python codebase, evaluate Pyrefly first. It is the only Rust-based checker that has been battle-tested at Meta-scale and has a stable 1.0 release. The Instagram numbers are not marketing — they represent real production workloads at a scale few organizations approach. If Pyrefly can handle 20 million lines of Python without breaking a sweat, it can handle whatever your company throws at it.

What This Means for Python Type Hinting

The Rust rewrite of Python tooling has already transformed package management (uv) and linting (Ruff). Type checking is the next frontier, and the timing matters because it removes the last serious objection to adopting type hints at scale.

When mypy was the only option, type checking was something you did in CI, not in your editor. The feedback loop was too slow. That meant type errors surfaced minutes or hours after you wrote the code, which meant they felt like an interruption rather than a safety net. The Rust-based checkers change that loop from minutes to milliseconds. A type error that appears as you type is a helpful assistant. A type error that appears in a CI log 10 minutes after you push is an annoyance.

There is a secondary effect worth paying attention to: the Rust tooling ecosystem is raising expectations across the board. uv made it unacceptable for package installation to take 30 seconds. Ruff made it unacceptable for linting to take longer than saving a file. ty and Pyrefly are doing the same thing for type checking, and once you have experienced near-instant feedback, going back to a slow checker feels broken, even if the old tool was doing exactly the same job.

The practical consequence is that Python projects of all sizes now have access to type checking that is fast enough to run continuously — on every save, in every editor, as part of every commit. That is not just a performance improvement. It is a change in how type hints fit into a development workflow, and it is the difference between a tool you use when you have to and a tool you rely on because it makes you faster.