Meta's New Tool Kills Python Lag

Why Your Python Editor Feels Slow (And How Meta Fixed It)

Python developers know the feeling: you pause mid-thought because your editor is still catching up. Autocomplete stutters, type errors appear several seconds late, and “go to definition” spins on large projects. At Meta scale—Instagram alone spans millions of lines of Python—existing tools like Pyre simply stopped keeping pace.

Meta’s answer is Pyrefly, a new type checker and language server built to crush that lag. Instead of treating feedback as a background batch job, Pyrefly treats every keystroke as an event that deserves an immediate response. The promise: analysis fast enough that your editor feels local, even when your codebase looks like a small operating system.

Meta set an aggressive target for Pyrefly: type checking on every single keystroke across multi-million-line repositories. Internal benchmarks show Pyrefly analyzing about 1.8 million lines of Python per second on Meta’s hardware, enough to re-check Instagram’s entire codebase in roughly 13.4 seconds. Against open-source projects, it processes PyTorch in 2.4 seconds, versus 35.2 seconds for Pyright and 48.1 seconds for MyPy.

That speed changes what developers expect from their tools. Instead of saving a file, running a separate checker, and waiting for a wall of diagnostics, Pyrefly streams results directly into the editor as you type. Hover tooltips, inlay hints, and navigation all come from the same high-speed engine, so there is no mismatch between what your IDE shows and what your CI pipeline enforces.

Laggy feedback forces a reactive workflow: write a bunch of code, run checks, then backtrack through a pile of errors. Pyrefly flips that into a proactive loop where problems surface in the same moment they’re introduced. Type hints, import issues, and even complex inference failures appear early enough that they feel like part of editing, not a separate QA phase.

By designing Pyrefly as a unified language server and CLI, Meta makes this instant feedback model consistent everywhere. The same engine powers VS Code, PyCharm, Neovim, Jupyter, and headless checks in CI. For Python teams drowning in slow tools, the pitch is blunt: your editor no longer has to be the bottleneck.

Pyrefly: More Than a Type Checker, It's Your IDE's New Brain

Pyrefly arrives as a hybrid: a lightning-fast static type checker fused with a full language server in one Rust-powered package. Instead of bolting a type checker onto an editor plugin, Meta built a single engine that handles real-time type analysis, autocomplete, navigation, and refactors across millions of lines of code. That same engine is capable of scanning 1.8 million lines of Python per second on Meta’s internal benchmarks.

Unified design means your CLI and your editor speak with one voice. Run `pyrefly check` in CI, then open the same project in VS Code, PyCharm, Neovim, or Cursor, and you get identical diagnostics, identical type inference, identical import resolution. No more “CI says it’s broken, my editor says it’s fine” or vice versa.

That shared brain powers everything from instant “go to definition” to automatic import updates when you rename a file. Rename a core module in a massive monorepo and Pyrefly updates imports consistently, whether the change comes from a quick-fix in your IDE or a scripted refactor via the CLI. The tool treats your codebase as a single, coherent graph, not two separate worlds of “editor features” and “batch checks.”

Most Python setups today look nothing like that. A typical stack might combine: - MyPy or Pyright for type checking - A separate LSP like pyright-langserver or pylsp - Editor-specific plugins with their own indexing logic

Each layer maintains its own cache, its own understanding of imports, and its own idea of what counts as an error. That fragmentation explains why autocomplete can lag, navigation can misfire, and CI can catch issues your editor quietly ignores.

Pyrefly’s unified engine eliminates those contradictions. Smart import root detection, automatic site-packages discovery, and prioritized stub packages run through one deterministic pipeline. Developers get a single source of truth for types and symbols, whether they are typing in a Jupyter notebook, committing from the terminal, or chasing a bug deep in Instagram-scale code.

The 1.8 Million Lines Per Second Benchmark, Explained

1.8 million lines per second sounds like marketing spin until you translate it into real workloads. At that speed, a checker can reanalyze a 100,000-line service in about 0.06 seconds, effectively instant from a human perspective. Scale that to Meta’s internal benchmarks and Pyrefly chews through Instagram’s codebase in 13.4 seconds where the old Pyre needed more than 100 seconds.

Benchmarks against public projects make the gap harder to ignore. On PyTorch, Pyrefly finishes a full type check in 2.4 seconds, while Pyright takes 35.2 seconds and MyPy stretches to 48.1 seconds. That’s not a marginal win; it is more than an order-of-magnitude speedup over tools many teams already consider “fast enough.”

Raw throughput matters because Pyrefly’s engine runs on every keystroke, not just on manual invocations. When a type checker can process millions of lines per second, your editor can afford to rerun analysis continuously without stuttering. The usual “save and wait for the linter” rhythm collapses into a tight feedback loop where errors, warnings, and inlay hints update as quickly as syntax highlighting.

Real-time feedback changes how you write code. Rename a model, and imports update without a pause; jump to a definition buried deep in a multi-folder tree, and navigation feels like jumping within a single file. That responsiveness keeps your mental model loaded, instead of forcing you to context switch every time tooling locks up.

Developers with smaller projects often assume these gains only matter at Meta scale. But Pyrefly’s speed benefits a 5,000-line hobby app as much as a million-line monolith by shifting checks from “batch job” to “background reflex.” Even on modest hardware, the same architecture that obliterates PyTorch’s timings turns routine refactors and exploratory edits into low-friction operations.

Fast type checking also catches bugs earlier in the lifecycle. Mis-typed Pydantic models, broken Django ORM relations, or incorrect NumPy shapes surface while you are still in the file that introduced them, not minutes later in a CI log. For a deeper dive into the design and benchmarks, Meta’s team documents the system at **Pyrefly: A Fast Python Type Checker and Language Server**, including the hardware setup behind those 1.8 million lines-per-second numbers.

Instant Gratification: Autocomplete and Navigation That Works

Speed changes how Python feels under your fingers. With Pyrefly wired into your editor, autocomplete stops behaving like a network request and starts acting like a local keystroke. Meta’s goal of “type checking on every single keystroke” translates directly into suggestions that appear as fast as you can type, even in codebases that run into the millions of lines.

Traditional VS Code extensions often stall for 200–500 ms when a project grows, enough to make completion feel sticky and unreliable. Pyrefly leans on its 1.8 million lines-per-second engine to recompute context almost instantly, so completions stay accurate while you rapidly jump between files, branches, or virtual environments. No warm-up delay, no “indexing…” banner, just live results.

Navigation gets the same treatment. Click “go to definition” on a symbol buried behind three layers of re-exports and conditional imports, and Pyrefly resolves it immediately using its smart import resolution pipeline. It tracks import roots, site-packages, stub priorities, and a deterministic search order so your cursor lands on the right file, not a random `__init__.py` guess.

Large, messy repos usually break navigation first: multiple folders, vendored libraries, mixed tools, half-typed legacy modules. Pyrefly’s unified engine keeps a single, coherent view of the project graph, so jumping from a Django view into a Pydantic model or a NumPy-heavy utility function feels instant. Developers get IDE-grade navigation whether they sit in VS Code, PyCharm, NeoVim, or Cursor.

The surprise productivity win hides in rename operations. Move or rename a Python file and Pyrefly’s automatic import updates sweep your project and rewrite every affected import statement. That includes deep package paths, relative imports, and cross-package references that usually require a brittle search-and-replace.

On a mid-sized service with 200–300 Python files, a single rename can scatter broken imports across dozens of modules. Pyrefly turns that into a one-step refactor: rename, watch imports update, keep coding. Fewer `ImportError` surprises, fewer half-broken branches, and far less time sunk into manual cleanup after “just organizing some files.”

Combined, zero-lag autocomplete, instant navigation, and safe renames make Pyrefly feel less like a background linter and more like an always-on co-pilot. The performance headline—1.8 million lines per second—matters here not as a benchmark flex, but as the reason these features stay fast under real, ugly, production code.

How Pyrefly Understands Your Code Better Than You Do

Pyrefly does not just scream through 1.8 million lines per second; it also quietly reverse‑engineers your codebase. Strong type inference means it can make sense of decade-old, unannotated Python and still give you precise types for variables, attributes, and return values. Legacy modules that never heard of `typing` suddenly light up with inlay hints and accurate autocomplete.

That inference runs deep enough to power refactors. Rename a function in an untyped file and Pyrefly can still track where it’s used, because its internal model treats “missing annotations” as a puzzle, not a failure state. You get most of the benefits of strict typing without a multi‑month annotation slog.

Flow-aware narrowing is where Pyrefly starts feeling like a human reviewer who never forgets context. Write an `isinstance(user, Admin)` check and everything in that branch narrows `user` to Admin automatically, with no extra `cast()` calls or comments. Once the control flow proves a type, Pyrefly carries that fact through loops, early returns, and nested conditionals.

That narrowing also prevents type pollution as code branches reconverge. If one path guarantees a non‑`None` value, Pyrefly stops nagging you about `Optional` access in that region, while still warning you in less safe branches. The result: fewer spurious errors, more attention on actual bugs.

Error messages get the same treatment: less compiler‑ese, more editor coach. Instead of “incompatible types in assignment,” Pyrefly spells out “expected list[str], got list[int] from `parse_ids()`,” often with the exact expression highlighted. For chained calls, it points at the failing hop and suggests the missing annotation or cast that would fix it.

Context-rich diagnostics matter at Meta scale. When you are jumping between services, Pyrefly can tell you that a mismatch comes from a stale Pydantic model or a Django ORM field that changed type three commits ago. That kind of breadcrumb trail turns what used to be a 30‑minute blame hunt into a 30‑second fix.

Library awareness is where Pyrefly stops feeling like a generic checker and starts feeling ecosystem‑native. Built‑in stubs for Django ORM, Pydantic v2, and NumPy ship with nearly 90% type completeness, so your autocomplete and hover docs understand querysets, validators, and ndarray shapes. Instead of drowning you in “missing type information,” Pyrefly behaves like it has read the same framework docs you have—only more carefully.

Built in Rust: The Secret to Pyrefly's Insane Speed

Rust sits at the center of Pyrefly’s speed story. Meta rebuilt its Python type checker from the ground up in Rust, abandoning the old OCaml-based Pyre to squeeze out every microsecond of latency. That language switch unlocks the kind of raw performance needed to blast through 1.8 million lines of code per second without melting laptops.

Rust’s low-level control and zero-cost abstractions help Pyrefly run close to the metal while keeping memory safety guarantees. No garbage collector means no surprise pauses right when your IDE asks for autocomplete or “go to definition.” Cross-platform support and a modern toolchain let Meta ship the same high-performance engine to Linux dev servers, macOS laptops, Windows desktops, and even WebAssembly for browser demos.

Under the hood, Pyrefly doesn’t just re-check your entire project on each edit. A custom incremental computation engine tracks fine-grained dependencies between files, symbols, and types, then recomputes only what a single keystroke invalidates. That design turns “type checking on every keystroke” from marketing copy into something that actually holds up on Instagram-scale monorepos.

This incremental core powers everything the IDE layer does. Autocomplete, hover tooltips, inlay hints, and semantic highlighting all tap the same cached analysis, so responses come back in milliseconds instead of seconds. The CLI uses the identical engine, which means `pyrefly check` and your editor share one coherent, aggressively optimized view of your code.

Rust is quietly becoming the default for high-performance Python tooling. Ruff uses Rust to deliver blazing-fast linting, and Ty (the experimental Rust-based type checker from the Python typing community) pushes on type system expressiveness. Pyrefly positions itself above both as a full-stack solution: a unified IDE + CLI brain rather than a single-purpose linter or checker.

Meta’s engineering blog post, Introducing Pyrefly: A new type checker and IDE experience for Python, makes the strategy explicit: Rust for performance, incremental algorithms for responsiveness, and one engine to rule editor integrations and batch checks alike.

Switching is Painless: Migrating from MyPy in Minutes

Python teams already invested in MyPy or Pyright usually hit the same wall: migration dread. Pyrefly’s answer is a single command. Run `pyrefly init` in your repo and it immediately starts excavating your existing setup instead of forcing a greenfield configuration.

Under the hood, `pyrefly init` scans for `mypy.ini`, `pyproject.toml`, `mypy.cfg`, `pyrightconfig.json`, and other familiar files. It reads your current diagnostic settings, including strictness levels, enabled/disabled checks, and custom plugins, then maps them onto Pyrefly’s own configuration model.

Crucially, Pyrefly doesn’t toss out all your hard-won noise suppression. It imports suppressed error codes, per-file ignore patterns, and directory-level overrides so you keep the same “signal vs. noise” profile you tuned over months of CI failures. Existing `# type: ignore` and `# pyright: ignore` style comments still make sense in a Pyrefly world.

File selection rules migrate too. Pyrefly mirrors your include/exclude patterns for `tests/`, `build/`, `venv/`, generated code, and third-party vendored libraries, so it doesn’t suddenly start type checking half your `node_modules` equivalent. If your monorepo uses multiple roots or nested configs, Pyrefly records those boundaries instead of flattening everything.

Gradual adoption sits at the center of the design. Teams can start by pointing Pyrefly only at a few high-value packages and expand coverage as they fix issues, rather than flipping the entire repo on day one.

To make that safe, Pyrefly leans on baselines. You can snapshot all current errors into a baseline file, treat it as “known debt,” and fail CI only on new regressions. Over time, deleting chunks of that baseline becomes a measurable refactor milestone.

Inline ignores and partial project includes finish the story. You can silence genuinely unfixable edges in legacy code, keep experimental directories opt-out, and still get blazing-fast, IDE-grade feedback everywhere else.

Beyond Your Code: Pyrefly's Deep Dive into Django & Pydantic

Python frameworks usually turn type checkers into mush; Pyrefly treats them like first‑class citizens. Meta wired its new engine directly into Django’s ORM and Pydantic v2, so it does not just see your app as a pile of `.py` files, but as a graph of models, fields, validators, and querysets it can reason about in real time.

Django users feel this first. When you write `MyModel.objects.filter(user__email__icontains="meta.com")`, Pyrefly tracks the queryset’s element type all the way through `.filter()`, `.select_related()`, and `.values_list()`, so autocomplete on chained calls stays precise instead of collapsing to `Any`. Go‑to‑definition jumps into the actual model field or manager method, even in sprawling multi‑app projects, because its import resolver understands Django’s app layout and dynamic model loading.

Pydantic v2 support goes beyond “knows the class name.” Pyrefly understands `BaseModel` configs, `field_validator` and `model_validator` decorators, generics like `BaseModel[T]`, and complex nested schemas. That translates into accurate types for `model.model_dump()`, `parse_obj_as()`, or response models in FastAPI-style stacks, with hover tooltips that show the final concrete type instead of a generic placeholder.

Scientific Python stacks usually sit in the type system’s blind spot, but Pyrefly ships NumPy stubs with nearly 90% type completeness. When you slice a `ndarray`, call `np.stack`, or broadcast shapes in linear algebra code, the engine keeps track of dtypes and dimensions closely enough to power meaningful autocomplete and catch obvious misuse. Data scientists get real static checking on analysis notebooks instead of a wall of `Any`.

Support for Jupyter Notebooks turns all of this into something notebook‑native, not an afterthought. Pyrefly keeps a live model of the notebook across cells, so renaming a Pydantic model or Django helper updates references everywhere, and navigation works even when definitions live in earlier cells. Combined with its 1.8‑million‑lines‑per‑second core, that means notebook users finally get IDE‑grade feedback without abandoning their Jupyter workflow.

Is Pyrefly Ready For You? A Beta-to-Production Breakdown

Beta label or not, Pyrefly already looks like a serious contender for day-to-day work. Meta ships it internally at Instagram-scale, and the IDE side of the stack is explicitly production-ready, even while the core type checker still lives in beta territory.

Ideal early adopters fall into a few clear buckets. If you work in a medium or large Python codebase, live in VS Code or PyCharm, and feel every millisecond of autocomplete lag, Pyrefly targets you directly.

Teams that lean hard on type hints also land squarely in the “install now” camp. So do Django and Pydantic-heavy shops, where Pyrefly’s deep Django ORM and Pydantic v2 understanding, plus ~90% NumPy stub coverage, translate into more accurate errors and richer navigation than generic type checkers.

Good candidates include developers who: - Maintain multi-module monoliths or sprawling microservice repos - Already run MyPy or Pyright in CI but hate slow feedback in the editor - Use Django, Pydantic v2, or data-heavy libraries on a daily basis

Caution makes sense if you live on the bleeding edge of typing. Heavy users of niche or experimental features—exotic `typing_extensions` constructs, protocol trickery, or custom plugin hooks—may hit rough edges while Meta finishes full typing spec implementation.

You might also wait if your current MyPy or Pyright setup feels flawless and fully covers specialized libraries. Pyrefly’s library surface grows weekly, but if you depend on obscure internal tools or untyped vendor SDKs, you may prefer to watch one or two releases before switching your entire org.

Rapid iteration backs up Meta’s claims. Since the early alpha, Pyrefly has seen over 350 bugs fixed, spec conformance jump from 39% to 70%, and continuous tuning of incremental performance and memory use.

For editor integration, the story is much simpler: treat Pyrefly’s extension as ready today. The VS Code plugin on Pyrefly - Python Language Tooling - Visual Studio Marketplace ships the same ultra-fast engine that powers Meta’s own workflows.

If curiosity beats caution, start small. Drop Pyrefly into a side project, let it auto-migrate your MyPy config, and see if the 1.8-million-lines-per-second brain earns a permanent slot in your toolchain.

The Future is Typed: What Pyrefly Signals for Python's Evolution

Python’s future looks a lot more opinionated than its “do whatever” past, and Pyrefly is a big reason why. Meta is not shipping a toy; it is shipping the engine that already keeps Instagram’s sprawling Python stack in check, then open-sourcing it. A tool that can blast through 1.8 million lines per second on 166 cores while still driving real-time editor feedback sends a clear signal about where serious Python development is heading.

Meta’s roadmap doubles down on that signal. The team is actively chasing full typing spec implementation, pushing conformance from the current ~70% toward 100%, so edge-case generics and exotic protocols behave exactly as PEPs describe. They are also tuning incremental checks to be even faster, which matters more than the headline benchmark once you live in a constantly-changing monorepo.

Framework support is set to get more aggressive, not less. Today Pyrefly ships deep integrations for Django ORM, Pydantic v2, and NumPy with roughly 90% type completeness; Meta’s plan adds: - Even richer Django and Pydantic understanding - More first-class stubs for popular libraries - Smarter analysis of framework-specific patterns and metaprogramming

Performance work is not just about speed, either. Meta explicitly calls out lower memory usage as a near-term goal, crucial when you run dozens of parallel checks in CI or on resource-constrained laptops. A stable v1 release sits on the horizon as they burn down edge cases and harden the engine beyond the current beta, which has already seen 350+ bugs fixed.

Philosophically, Pyrefly flips Python tooling from “tax” to “turbocharger.” Traditional type checkers often feel like compliance: slow CI jobs, noisy error dumps, and configs you touch only when they break. Pyrefly instead behaves like a co-pilot—instant navigation, automatic import updates on rename, and in-editor type inference that makes untyped legacy code feel modern.

As Python powers ever-larger systems—ad platforms, recommender engines, financial pipelines—tools like Pyrefly stop being optional niceties. High-speed, spec-accurate, framework-aware type checking running on every keystroke becomes basic infrastructure, the same way unit tests and CI once graduated from “nice to have” to non-negotiable.

Frequently Asked Questions

What is Pyrefly?

Pyrefly is a high-performance static type checker and language server for Python, built by Meta in Rust. It's designed to provide instant feedback, code navigation, and type checking, even in massive codebases.

How is Pyrefly different from MyPy or Pyright?

Pyrefly's main differentiators are its incredible speed (analyzing millions of lines per second), a unified engine for both the CLI and IDE, and deep, built-in support for popular libraries like Pydantic v2 and Django.

Is Pyrefly ready for production use?

The Pyrefly IDE extension is considered production-ready. The core type checker is still in beta, meaning it's robust but may have some edge cases that are actively being resolved before the stable v1 release.

Do I need to annotate all my code to use Pyrefly?

No. One of Pyrefly's key features is its powerful type inference, which can understand and analyze unannotated legacy code, providing many benefits without requiring a full migration to type hints.