mypy vs Pyright vs Pyrefly: Choosing a Python Type Checker in 2026

The Python type-checker market changed more in the last 18 months than in the previous decade. mypy and Pyright held a comfortable duopoly through 2024; in May 2026 Meta released Pyrefly 1.0 (written in Rust, 10-50x faster than the incumbents), and Astral's ty (also Rust) followed close behind in alpha. The choice is no longer "which one"; it's "which combination fits the project". This guide walks through the four contenders, the dimensions that actually matter (speed, memory, typing-spec conformance, IDE integration), and the decision rules that help you pick. The benchmarks below come from the official typing-spec conformance suite and from public reports by Meta, Pyrefly, and the pydevtools community. Part of our Modern Python 2026 guide.

The Four Contenders

mypy: the historical default

Started by Jukka Lehtosalo in 2012, maintained by the PSF, written in Python. The original type checker, the reference implementation against which PEP 484 was defined. Still common in CI for projects that started before Pyright became dominant.

pip install mypy
mypy src/

Strengths: long history, broad plugin ecosystem (django-stubs, sqlalchemy[mypy], pydantic plugins), well-understood error messages.

Weaknesses: slow on large codebases (Python implementation), permissive by default (you need --strict or per-rule configuration to catch what other checkers catch out of the box), occasional false negatives compared to Pyright on advanced typing features.

Pyright: Microsoft's fast TypeScript implementation

Started by Microsoft in 2019, written in TypeScript. The engine behind Pylance, the default Python language server in VS Code.

npm install -g pyright
pyright src/

Strengths: fast (much faster than mypy thanks to TypeScript's V8 engine), leads typing-spec conformance, strict by default, embedded everywhere Pylance is installed (which is a lot of editors).

Weaknesses: requires Node.js for command-line use, error messages occasionally cryptic, not Python-native (some Python developers prefer pure-Python tooling).

Pyrefly: Meta's Rust speedster

Released by Meta in May 2025 (initial), reached stable 1.0 in May 2026, written in Rust. Built to replace Pyre (Meta's older type checker) and to handle Instagram's 20-million-line codebase in seconds rather than minutes.

pip install pyrefly
pyrefly check src/

Strengths: dramatically faster than mypy and Pyright on real-world codebases (1.9s vs 144s on pandas), low memory footprint (~1GB on numpy vs Pyright's 3GB+), strict by default, monthly release cadence, deployed at Meta production scale.

Weaknesses: newer (less battle-tested than mypy or Pyright), smaller plugin ecosystem, occasional edge cases in inference still being refined.

ty: Astral's rising challenger

Released by Astral (makers of uv and ruff) as a public alpha in late 2025, written in Rust. Targets the same speed-and-conformance niche as Pyrefly, with Astral's signature install-and-go ergonomics.

pip install ty    # alpha
ty check src/

Strengths: blazingly fast (Rust), low memory, integrates with the uv ecosystem, backed by Astral's track record (ruff and uv both became industry standards within a year).

Weaknesses: alpha (breaking changes expected), spec conformance still catching up to Pyrefly and Pyright, ecosystem effectively zero compared to mypy.

Side-by-Side Configuration

All four checkers read configuration from pyproject.toml in modern projects. The exact section name differs.

mypy

# pyproject.toml
[tool.mypy]
python_version = "3.12"
strict = true
ignore_missing_imports = true

[[tool.mypy.overrides]]
module = "tests.*"
disallow_untyped_defs = false

Pyright

# pyproject.toml
[tool.pyright]
pythonVersion = "3.12"
typeCheckingMode = "strict"
reportMissingImports = "warning"
exclude = ["tests/fixtures"]

Pyrefly

# pyproject.toml
[tool.pyrefly]
python-version = "3.12"
strict = true

ty

# pyproject.toml
[tool.ty]
python-version = "3.12"

The configurations look superficially similar but have subtle differences in defaults and rule names. Migrating between checkers requires translating ignore patterns and per-rule overrides; the underlying type annotations themselves don't change.

The Real Differences in Practice

Speed

The Rust checkers (Pyrefly, ty) dominate. On the official Pyrefly benchmark, pandas takes 1.9 seconds with Pyrefly versus 144 seconds with Pyright. The gap on numpy is even larger when measured in real-world terms: 4.8 seconds vs 70 seconds for Pyright. mypy is slower than both. For small projects (under 10,000 lines) the difference doesn't matter; for medium projects (50k-500k lines) it shifts CI from "annoying" to "fast"; for enterprise-scale codebases (millions of lines) it can be the difference between fast feedback and giving up on type checking entirely.

Memory

The Rust checkers also use dramatically less memory. On numpy, Pyrefly uses about 1GB; Pyright uses over 3GB. For developers working on M-series MacBooks or other RAM-constrained machines, this is the difference between running the checker locally and offloading it to CI.

Spec conformance

The Python typing specification ships an official conformance test suite. Pyright currently leads at ~95% conformance, Pyrefly is close behind at ~90%, mypy at ~75%, ty at ~70%. For most application code, all four are good enough. For library authors writing public APIs that need to type-check correctly under whatever the user's checker happens to be, conformance matters more.

IDE integration

Pyright via Pylance is the de facto VS Code experience. mypy integrates via the official mypy daemon or third-party plugins for most editors. Pyrefly ships an LSP server and works with Neovim, Emacs, Sublime, and JetBrains via standard LSP clients. ty is LSP-capable but the experience is rougher.

Strictness defaults

mypy is permissive by default (you need strict = true to catch missing return types). Pyright, Pyrefly, and ty are strict by default, surfacing more issues out of the box. The right default depends on your team's appetite for type-related errors during the initial adoption phase.

Decision Matrix

Migration Considerations

Switching type checkers is usually low-friction because the annotations themselves stay the same. What changes:

• Ignore patterns: each checker uses its own comment syntax. mypy uses # type: ignore[code], Pyright uses # pyright: ignore[code], Pyrefly uses # pyrefly: ignore[code]. A migration script can usually find and translate these.
• Per-rule configuration: rule names differ (mypy's disallow_untyped_defs is Pyright's reportMissingReturnType). The mapping isn't always one-to-one.
• Strictness defaults: moving from mypy default (permissive) to Pyright or Pyrefly default (strict) typically surfaces dozens of previously-ignored issues. Plan for a fix-up sprint.
• Plugin ecosystem: mypy plugins for Django, SQLAlchemy, Pydantic don't have direct equivalents in Pyright or Pyrefly. Most libraries now publish typing-friendly APIs that don't need plugins, but legacy stacks may struggle.

Common Pitfalls

1. Treating different checkers' warnings as the same severity

What mypy considers an error, Pyright may consider a warning (or vice versa). Read each checker's severity classification carefully. Pyright distinguishes "error" / "warning" / "information"; mypy is binary (error or not).

2. Running too many checkers

Running mypy + Pyright + Pyrefly in CI seems thorough but produces noise from spec-interpretation disagreements. Pick two at most: usually Pyright (or Pylance) in the IDE and one of mypy/Pyrefly in CI.

3. Forgetting to gate CI on the checker

Type checking that doesn't fail CI is decorative. If the checker reports errors but the build still passes, developers stop fixing them. Make checker failures hard-fail in CI.

4. Adopting strict mode before fixing existing types

Switching mypy from permissive to strict on an old codebase produces hundreds of errors at once. Migrate incrementally: enable one strict rule per sprint until you reach full strict mode.

5. Ignoring typing_extensions

If you support older Python versions, the typing_extensions backport ports newer features. Without it, you have to choose between supporting older Python and using newer typing features. With it, you can have both. Covered in the type hints adoption guide.

Frequently Asked Questions

What is the fastest Python type checker in 2026?

Pyrefly (Meta, written in Rust) is the fastest currently stable type checker as of mid-2026. On the pandas codebase it runs in ~1.9 seconds; Pyright takes ~144 seconds for the same check. On numpy, Pyrefly completes in ~4.8 seconds using ~1GB of RAM, while Pyright takes ~70 seconds and uses over 3GB. At Meta, Pyrefly checks Instagram's 20-million-line codebase in roughly 30 seconds. The rising ty (Astral) is also Rust-based and posts comparable numbers. mypy, written in Python, is the slowest of the four on every benchmark.

Should I switch from mypy to Pyrefly or ty in 2026?

Switch if your mypy runs are slow enough to hurt CI or local edits (over 30 seconds for an incremental check is a common threshold). Pyrefly is stable as of 1.0 in May 2026 with a monthly release cadence and is deployed at Meta (Instagram, PyTorch, JAX), so it's production-ready. ty is still alpha (Astral, makers of uv and ruff) and worth tracking but not yet for production CI. Stay on mypy if it's fast enough, your tooling depends on its specific output format, or you need its strict typing conformance for spec-heavy libraries. The decision is local.

Does Pyright work outside VS Code?

Yes. Pyright is a Microsoft-maintained command-line tool first; Pylance is the VS Code extension that wraps it. You can use Pyright from the terminal, in CI, or integrate it with any LSP-aware editor (Neovim, Emacs, Sublime, JetBrains via plugins). On the command line, install it with npm: npm install -g pyright. In your CI config, run pyright src/ and it produces standard text or JSON output. Pylance adds VS Code-specific features like inline hints and refactoring; the underlying type checking is identical.

What is ty (Astral) and how does it compare to Pyrefly?

ty is Astral's new Python type checker, written in Rust, from the team behind uv and ruff. It targets the same goals as Pyrefly: native speed, low memory, and modern typing-spec conformance. As of mid-2026, ty is in alpha while Pyrefly hit stable 1.0 in May. Pyrefly currently leads on spec conformance and has more production deployments (Meta's Instagram, PyTorch, JAX). ty is closely watched because Astral's previous tools (ruff for linting, uv for environments) became industry standards within a year of release. The likely outcome is that one of them becomes the dominant fast checker and the other becomes a niche option, but neither is positioned to displace mypy and Pyright in 2026.

Can I run multiple type checkers on the same codebase?

Yes, and many production teams do. The common pattern: Pyright in the IDE (via Pylance) for instant feedback, mypy or Pyrefly in CI for the authoritative gate. The checkers disagree occasionally (different inference algorithms, different typing-spec interpretations), but most disagreements are subtle. When they conflict, the typing-spec conformance suite at typing.python.org is the tiebreaker. Running both adds CI time, but the cost is small if both are configured with reasonable strictness. Avoid running three; the diminishing returns aren't worth the noise.

The Bottom Line: Pick by Speed, Stack, and Editor

Four good options in 2026, all of them better than the same project a decade ago when no type checker existed. For most VS Code users, Pyright via Pylance is already running. For large codebases where speed matters, Pyrefly is the clear winner. For projects deeply tied to Django, SQLAlchemy, or other libraries with mature mypy plugins, mypy still earns its slot. ty is the most exciting alpha to track. The honest answer to "which one" is "probably two of them" — Pyright in the editor plus mypy or Pyrefly in CI. Up next: Pydantic vs dataclasses vs attrs vs TypedDict. Or browse the full Modern Python 2026 guide.