Python Type Checkers: mypy vs Pyright vs ty vs Pyrefly

mypy, Pyright, ty, and Pyrefly all check your type hints, but they differ in maturity, speed claims, and editor support — here’s how to choose

mypy and Pyright are the established, production-stable type checkers; ty and Pyrefly are fast, newer Rust-based challengers that double as language servers. All four read the type hints in your code and flag mismatches before it runs. They differ in maturity, who maintains them, and how much they lean on editor integration. If you’re still getting to grips with the annotations themselves, start with the type hints guide. This one is about the tool that reads them.

Versions as of 9 October 2026: mypy 2.4.0, Pyright 1.1.414, ty 0.0.85 (beta), Pyrefly 1.3.2. This area moves quickly, so check each project’s release notes before deciding.

mypy: the long-standing reference

mypy is the original Python type checker and describes itself simply as a static type checker that warns you when your code misuses the types you’ve declared. It’s classified production/stable on PyPI, ships a daemon mode for faster re-checks, and has a large body of documentation covering gradual adoption in an existing codebase, stub files, and configuration. Its main trade-off is speed on large codebases, which is exactly the gap the newer tools target.

Pyright: Microsoft’s checker and the engine behind Pylance

Pyright is described by Microsoft as a full-featured, standards-based static type checker designed for high performance on large codebases. It comes as a command-line tool and a VS Code extension, and its language-service features are delivered through Pylance, with the same contributors working on both. If you use VS Code for Python, you are probably already running Pyright-derived checking without having chosen it. It’s production-stable and has a weekly benchmark comparing it with other checkers.

ty: Astral’s checker, still in beta

ty comes from Astral, the team behind uv and Ruff. It’s written in Rust, includes a language server, and Astral’s own docs claim it is 10x-100x faster than mypy and Pyright, with fine-grained incremental analysis for quick updates while you edit. The caveat is maturity: it is still labelled beta, with a 0.0.x version number. You can try it without installing anything using uvx ty check.

Pyrefly: Meta’s checker, now stable

Pyrefly is developed at Meta and is a type checker plus language server in one. Its README says it reached a stable 1.0 release, is the default checker for Instagram’s roughly 20-million-line Python codebase, and has been adopted by projects including PyTorch and JAX. It also advertises built-in understanding of Pydantic, Django and pytest. As with ty, the speed figures (over 1.85 million lines per second, about 15x faster than mypy and Pyright on PyTorch) are the project’s own measurements.

A fifth to watch: Zuban

Zuban is a mypy-compatible type checker and language server written in Rust by the author of Jedi. Its site claims it’s 20-200x faster than mypy and describes the release as beta, and it’s AGPL-licensed, which matters if you embed it in anything. It’s worth knowing about because its mypy-config compatibility makes it easy to try next to an existing mypy setup.

How they compare

Which one should you use?

• Existing project already using one: keep it. Switching checkers means re-triaging every disagreement, which is rarely worth it unless check time is hurting you.
• New project, want the safe default: mypy or Pyright. Both are stable, widely documented, and supported by most CI setups and editors.
• VS Code user: you already have Pyright-based checking through Pylance, so the question is only what your CI runs.
• Large codebase where checks are slow: try Pyrefly first, since it’s marked stable, and evaluate ty as it matures. Time them on your own repo rather than trusting vendor benchmarks.
• Already on Ruff and uv: ty is the natural fit for the toolchain, but treat it as a second opinion until it leaves beta.

Whatever you pick, choose one checker as the source of truth in CI. The tools can disagree on the same code, and a pipeline that runs several will just argue with itself. For the editor side of the decision, see the best Python IDEs and editors.