6,900 stars · MIT, read from /blob/main/LICENSE, plain and unmodified, 'Copyright (c) Meta Platforms, Inc. and affiliates.' · 1.3.2 (2026-09-28), read from /releases/latest, whose body states the year, and confirmed on pypi.org/project/pyrefly/ · Track this in Scout
A fast type checker for Python that reads the settings your current checker already uses.
▶Repo detailsthe review · specs · pros & cons · install
What it does
It reads your Python source files. It prints a list of places where the types you declared do not agree with the code, with the file and line for each. It also runs as a language server, which is the background program your editor talks to for jump-to-definition, autocomplete, hover text and inline hints. It is a CLI, meaning you run it by typing a command rather than clicking, and pyrefly init reads an existing Mypy or Pyright settings file and converts it, so moving across is one command. The project publishes two figures: it checks "over 1.85 million lines of code per second", and in an editor a re-check after saving a file "typically complete in under 10 milliseconds". It is the default checker for a 20-million-line Python codebase at Instagram. What it does not do is check everything by default: with no settings file it runs a basic preset that shows only high-confidence problems such as syntax errors and missing imports, and hides the rest until you configure it.
Why it matters
Who it suits. Anyone with a Python codebase big enough that a checker takes a coffee break to finish, and anyone whose editor feels slow when the project grows. It also suits a team already using another checker, because the migration command means you do not start from a blank settings file. Skip it if your Python has no type annotations at all, because there is nothing for it to check yet, and skip it if you need a stable tool that never changes under you.
Verdict. Worth ten minutes today. pip install pyrefly and pyrefly init is the whole trial, and if you dislike it you uninstall it and your old settings file is untouched. Two honest warnings. The project says plainly that it does not follow the usual version rules, and that "any version may introduce new type errors and other breaking changes", so pinning a version in a shared project is sensible. And at 6,900 stars it is much smaller than astral-sh/ty, which Edition 44 covered and which is at 19,842 — two Rust type checkers for Python, from two different companies, both released this year. If you want the one with more users today, that is ty. If you want the one with a 20-million-line codebase behind it, this is it.
- The migration command reads your existing Mypy or Pyright settings, so there is no configuration to write on day one.
- It is both a command-line checker and a language server, so one install covers the terminal and the editor.
- MIT licence, read from the file, plain and with nothing added.
- It does not follow the usual version rules, and says so: any release may add new errors and break things.
- Without a settings file it deliberately hides most problems, so a first run can look misleadingly clean.
- Upgrading it, or any library you depend on, can reveal new errors in code you did not touch.
astral-sh/tyThe same job, also written in Rust, also released this year, and at 19,842 stars it has roughly three times the following; Edition 44 covered it.
Track this in Scout- microsoft/pyright
The checker behind the Python extension in VS Code, written in TypeScript, older and slower but the one most editors already use.
Track this in Scout - python/mypy
The original, written in Python, the reference for what the rules even are, and the slowest of the four.
Track this in Scout
python3 -m venv venv source venv/bin/activate pip install pyrefly pyrefly init pyrefly check --summarize-errors