Cloud Parts

Pyrefly

Meta’s Python type checker and language server, written in Rust, built to replace Pyre and fast enough to re-check code on every save.

What it is
Linters, formatters and type checkers (type checkers)
Type
Open source
Made by
Meta
License
MIT
Facts checked
9 October 2026
Website Source code

What it is

Pyrefly checks Python against the typing specification and infers types for unannotated locals and return values, which its editor extension can show and insert. It is written in Rust and designed to serve both batch runs in CI and latency-sensitive editor requests from one engine, so the command line and the IDE agree. Meta says it checks over 1.85 million lines of code per second, type-checks PyTorch 15 times faster than mypy and Pyright, and usually re-checks within 10 milliseconds of saving a file. It has built-in support for Pydantic, Django and pytest; for Pydantic it mirrors runtime validation, so Order(id="2") passes where Pyright reports a type error. Settings live in pyrefly.toml or [tool.pyrefly]; pyrefly init migrates a mypy or Pyright configuration, pyrefly suppress silences existing errors with comments, and pyrefly infer writes annotations.

Version 1.0 (May 2026) declared it stable and added presets (off, basic, legacy, default, strict, all). A project with no Pyrefly configuration to read or migrate gets basic, which reports only high-confidence errors such as syntax errors and missing imports. Pyrefly is the default type checker for Instagram’s 20-million-line codebase and has been adopted by PyTorch and JAX. New minor versions ship monthly, and any of them may add new errors, since it does not follow strict semantic versioning.

Why teams pick it

  • Speed on large codebases: Meta reports 1.85 million lines per second and sub-10 ms re-checks in the editor
  • One engine for CLI and language server, proven on Instagram’s 20-million-line codebase
  • Framework awareness for Pydantic, Django and pytest out of the box
  • Migration tools: pyrefly init reads mypy or Pyright settings, pyrefly suppress and pyrefly infer ease adoption

Watch out for

  • Young: alpha in 2025 and stable only since May 2026, and any monthly release may introduce new type errors
  • Unconfigured projects get the lenient basic preset, which can report nothing on real type errors until you add [tool.pyrefly] or pick a preset
  • Its speed figures come from Meta’s own benchmarks; Astral’s ty claims to be faster still in the editor
  • Where the typing spec is silent it makes different choices from Pyright and mypy (looser attribute narrowing, Pydantic coercion), so switching checkers changes results

Alternatives

What all type checkers have in common →
PyrightOpen sourceMicrosoft’s open-source static type checker for Python, written in TypeScript, which is also the engine inside the Pylance extension for VS Code.+1 basedpyright

How it fits with other technologies

Check a project, then baseline its errors (Pyrefly 1.3.2) · bash

# pyproject.toml has an empty [tool.pyrefly] table, so the default preset applies
uvx pyrefly check
#  INFO Checking project configured at `…/shop/pyproject.toml`
# ERROR `int` is not assignable to `str` [bad-assignment]
#   --> src/shop/orders.py:16:18
#    |
# 16 |     label: str = total(orders)
#    |            ---   ^^^^^^^^^^^^^
#  INFO 1 error
# (no error for Order(id="2", ...) on line 15: Pydantic would convert it at runtime)

uvx pyrefly suppress             # inserts  # pyrefly: ignore [bad-assignment]  above line 16
uvx pyrefly check
#  INFO 0 errors (1 suppressed)

See it in a real stack

No architecture uses Pyrefly yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2017–2026

In 2017 Meta began building Pyre to type-check Instagram’s huge Python codebase. It was written in OCaml, borrowed its multi-process architecture from Meta’s Hack and Flow checkers, and was designed as a CI and command-line tool that maximised throughput. That fitted the editor badly: computing more than the user needed could freeze the IDE, and Meta temporarily used Pyright as its language server, which brought mismatched errors between the editor and CI.

Meta’s Python language tooling team started over in Rust, developing in the open on GitHub, and announced Pyrefly as an alpha in spring 2025. It reached beta in November 2025 (0.42.0), by which point it was the default language server and type checker for everyone working on Instagram, and stable 1.0 in May 2026.

The rewrite deliberately reversed several Pyre decisions: one engine for both throughput and latency, a parser that recovers from errors, minimal rewriting of the syntax tree so editor features keep exact positions, and friendlier type narrowing on attributes even where that is less strictly sound.

Why it’s built this way

Rust instead of OCaml
Pyre’s OCaml multiprocessing forced shared data into string-to-string tables and struggled on Windows; Rust gave real threads, Windows, macOS and Linux as equals, and a larger contributor pool.
Design for the IDE from the start
Pyre was built for throughput in CI and couldn’t be retrofitted for editor latency; Pyrefly was designed to serve both, so the CLI and the editor share one view of the code.
Keep the syntax tree close to the source
Pyre lowered many constructs into others, which lost information that find-references and refactoring need; Pyrefly avoids that.
Usability over strict soundness
Pyre refused to trust isinstance checks on attributes once another function had been called, one of its most frequent complaints; Pyrefly allows that narrowing, trading some soundness for fewer false alarms.

Timeline

  1. 2017

    Meta starts Pyre, in OCaml, for Instagram

  2. 2025

    Pyrefly announced as an alpha, written in Rust

  3. 2025

    November: beta (0.42.0); default checker for Instagram developers

  4. 2026

    May: stable 1.0 with configuration presets

  5. 2026

    September: 1.3.2

Sources8 · facts checked 9 October 2026

Improve this page on GitHub