[Ann] Pyrefly v1.0 (fast type checker & language server)
Posted by BeamMeUpBiscotti@reddit | Python | View on Reddit | 26 comments
Hi, Pyrefly maintainer here. Today we are pleased to share that Pyrefly, a fast type checker and language server for Python, has reached stable v1.0 status, meaning we are confident that Pyrefly is ready for production use.
Pyrefly was first released as an alpha in mid-2025 and followed up with a beta in November of that year. Since then, we have shipped over 60 minor releases: fixing hundreds of bugs, adding the features you’ve been asking for, and improving performance to be one of the fastest tools out there.
This would not have been possible without our amazing open-source community. To everyone who filed GitHub issues, submitted pull requests, gave us feedback at conferences, or joined us on Discord: thank you. Your contributions shaped this release, we’re grateful for every one of them, and we hope you continue being a part of the journey for future releases too.
We've published a blog post explaining what v1.0 means exactly, and what's next for Pyrefly.
Below is a summary of the changes to Pyrefly since the Beta release. The full release notes for v1.0 can be read on our Github.
Pyrefly v1.0 Release Notes
Performance Improvements
We've continued to push Pyrefly's performance since the speed improvements we shared in February. Since beta:
- 2–125x faster updated diagnostics after saving a file (no, that’s not a typo!). Thanks to fine-grained dependency tracking and streaming diagnostics, updates now consistently arrive in milliseconds
- 20–36% faster full type checking on large projects like PyTorch and Pandas
- 2–3x faster initial indexing when Pyrefly first scans your project
- 40–60% less memory usage during both indexing and incremental type checking
(Tested on an M4 Macbook Pro using open-source benchmarks from type_coverage_py and ty_benchmark.)
Compare the performance of Pyrefly and other Python type checkers on our regularly updated benchmarking suite, which runs against 53 popular Python packages.
Configuration Presets
A new preset configuration option provides named bundles of error severities and behavior settings.
| Preset | Description |
|---|---|
off |
Silences all diagnostics. Useful for IDE-only users or if you want total control of which errors are enabled. |
basic |
Low-noise, high-confidence diagnostics only (syntax errors, missing imports, unknown names, etc.). Ideal for unconfigured projects or IDE-first users. |
legacy |
For codebases migrating from mypy. Disables checks mypy doesn't have. pyrefly init now emits this preset automatically when migrating from a mypy config. |
default |
The standard Pyrefly experience. Equivalent to having no preset. |
strict |
Enables additional strict checks on top of the default preset. For users who want to avoid Any types in their codebase. |
See the configuration docs for details.
Onboarding Experience
We’ve made improvements to the out-of-the-box experience for projects without a pyrefly.toml.
- Automatic config synthesis — if you have a mypy or pyright config, Pyrefly automatically migrates your settings and synthesizes an appropriate in-memory Pyrefly config. (This is the same migration that
pyrefly initwould commit to disk.) - Basic preset for unconfigured projects — projects with no type checker config get the lightweight “basic” preset, which surfaces only high-confidence errors.
- VS Code status bar — the status bar shows the active preset — e.g. Pyrefly (Basic) or Pyrefly (Legacy) — so you always know which mode is active.
- Type error display settings — new VS Code settings let you control which preset applies to unconfigured files and suppress all diagnostics workspace-wide.
Type Checker Improvements
We've been hard at work making the type checker robust and feature-complete, with a focus on driving down false positives and improving type quality in real-world code bases. Here are some highlights:
- Across the board we've eliminated many sources of false positives in enums, dataclasses, ParamSpec, descriptors, and more.
- Support has been added for more type narrowing patterns, including preserving narrows in nested scopes and recognizing container membership checks.
- Overload resolution was substantially reworked to handle more real-world patterns.
- Pyrefly’s conformance to the Python typing specification has improved from 70% at beta to over 90% today.
- We've added experimental support for tracking tensor dimensions through PyTorch models — see "What's Next" below.
LSP & IDE Improvements
- We've added new refactoring capabilities like Safe Delete (with reference checking) and bulk
source.fixAll. - Navigation is more precise, and hover cards surface richer information for imports, tuples, and NamedTuples.
- Workspace mode is more stable, with multiple crash fixes and improved diagnostic publishing.
Framework & Notebook Support
- Django — Pyrefly has improved support for model relationships, fields, and views, and understands factory_boy factories.
- Pydantic — Pyrefly models Pydantic's runtime behavior more faithfully, with support for lax mode and range constraint validation, and handles more of the Pydantic ecosystem:
RootModel,pydantic-settings, andpydantic.dataclasses. - Pytest integration — We've added Code Lens run buttons for test functions, as well as code actions to annotate fixture return types and parameters.
- Jupyter notebooks —
.ipynbIDE support has reached full parity with.pyfiles, with rename, find references, code actions, and document symbols all supported.
Complementary Tooling
Pyrefly ships with tools to aid with adopting type checking in an existing codebase. Two new tools since beta:
pyrefly coverage reportoutputs a JSON report with annotation completeness and type completeness metrics per function, class, and module, so you can track coverage over time.- Baseline files let you snapshot current errors into a JSON file so only new errors are reported, as an alternative to inline suppression comments.
Updated Version Policy
Going forward, we’ll switch from a weekly to monthly cadence for minor (1.x.0) releases, with patch releases in between as-needed for critical fixes. We’ll continue providing release notes for minor versions, so you can see what’s new in each release.
What's Next
- Tensor shape checking — Experimental support for tracking tensor dimensions through PyTorch models and catching shape mismatches statically. Learn more.
- Pyrefly + AI agents — Pyrefly's speed makes it a natural verification step in agentic workflows. See our guide on adding Pyrefly to your agentic loop.
- Continued improvements — We'll keep expanding library support, reducing false positives, and iterating on your feedback. Let us know what you need on Github or Discord.
Oxenfree999@reddit
How does this compare to ty, the new type checker from Astral?
BeamMeUpBiscotti@reddit (OP)
Pyrefly has implemented more of the long-tail of typing spec requirements and IDE features (like refactorings and other nice things from Pylance/Pycharm). We've added support for libraries like Django and Pydantic, which ty hasn't done yet.
We both have different sets of experimental/non-standard features (ty has negation types, Pyrefly has tensor shape types).
In terms of perf, on average we're a bit slower than ty but use significantly less memory.
We've written a number of blogs that compare Pyrefly with existing type checkers in greater detail, which might be of interest to you. Note that benchmark numbers are likely outdated.
The developers of Positron, a data science IDE, also wrote a blog outlining how they picked a type checker to bundle: https://positron.posit.co/blog/posts/2026-03-31-python-type-checkers/
Brother0fSithis@reddit
We've been looking for a decent solution for encoding tensor shapes into the type system on my team, so that sounds interesting.
Can the tensor shape typing be used for normal numpy arrays?
brocketships@reddit
The developer experience Pyrefly offers over mypy is brilliant. However, for projects that use Python’s runtime dynamism, mypy plugins a critical to enable type checking. Packages like Pydantic and Django get special case treatment, but small projects are stuck. What’re your views on this and scope for better type checking support for more dynamic dataclasses-esque behaviour?
aloobhujiyaay@reddit
The biggest thing here honestly isn’t just raw speed, it’s the focus on lowering false positives and improving migration/onboarding. That’s what usually determines whether teams actually adopt a type checker long term
DanCardin@reddit
So running this on a codebase that passes mypy and/or pyright, does 1.0 imply i should expect no false positives?
That was my blocker during the alpha era. All of pyrefly, uv, and zuban had false positives exclusive to them. Particularly for sqlalchemy. I’ll give it another go and update
FarRub2855@reddit
False positives are always the biggest friction point when trying to get a team to actully adopt new tooling. Hopefully they smoothed out those SQLAlchemy edge cases for 1.0
nicholashairs@reddit
Yeah poor sqlalchemy support has been a real blocker for me adopting a lot of the new tools too 🙃
Asuka_Minato@reddit
I am working on some sqlalchemy support now. (since I need it in my work)
BeamMeUpBiscotti@reddit (OP)
We don't guarantee exact/perfect compatibility since the type system isn't fully specified/standardized, but we do provide utilities that automatically configure Pyrefly to be more similar your mypy/pyright config (
pyrefly init) and tools to automatically suppress any errors Pyrefly emits for your project (pyrefly suppress) so that the migration can be clean.Re: false positives, we run Pyrefly on a large corpus of open source projects to see how many errors are emitted as a rough proxy of that. Our total error counts across the whole corpus are roughly on par with Pyright, but if you have a particular project that we can't handle well & mypy/pyright can, please report it on our Github.
The blog post for the release talks a bit more about the meaning of v1.0:
DanCardin@reddit
I did immediately run into some (i think) self contained false positives, that I can report, but i dont see the multitude of sqlalchemy and other basic issues i used to, so i'm def open to trying to adopt it now
i wouldn't expect perfect agreement with mypy/pyright, but I think I would expect "type correct" code to never be falsely flagged (e.g. that regular python typing are all supported, where for example ty literally doesn't support basic typing constructs right now). There's obviously a long tail of either more ambiguous code or places where mypy or pyright are more or less strict, where i have much less expectation of perfect conformance. not to imply pyright doesn't but "being used in production" seems very meaningless.
ShidouMariya@reddit
Can pyrefly lsp replace pyright in the IDE?
BeamMeUpBiscotti@reddit (OP)
Pyrefly's supported IDE features should be approximately a superset of Pyright. It has some advanced stuff like refactorings that Pyright doesn't have.
rsheftel@reddit
First, excellent project. Question: you say that the IDE capabilities in VSCode are a superset of Pyright. I submitted two features in Pyright that are not supported in Pyrefly. I tried the new 1.0 version and they still do not look implemented, but perhaps I am looking wrong? Can you let use know if these are indeed implemented or still work in progress. Thanks again for a great project:
https://github.com/facebook/pyrefly/issues/2207#issuecomment-4276420503
https://github.com/facebook/pyrefly/issues/2207#issuecomment-4280008848
BeamMeUpBiscotti@reddit (OP)
The second one is a bug, and I think both of them have PRs open, but they weren't merged in time for this release
Chroiche@reddit
It seems to struggle a bit with some things resulting in it taking me to internals rather than the code I want to go to when hopping around.
BeamMeUpBiscotti@reddit (OP)
Pyrefly maintainer here: please feel free to file an issue on our Github
yonsy_s_p@reddit
https://pyrefly.org/en/docs/IDE/#other-editors
Try and check
me_myself_ai@reddit
WOW that is a version jump, congrats!! I had no idea this was even on the horizon. Seems like it took 3-4 years to get pyre (the original) to
v0.9.18, so ~11 months from alpha tov1.0.0seems like quite the acheivment.I’ve recently come around to Pyrefly after running into glaring gaps still left in
ty, and it’s been a stellar few months. I’ve now tried all four of the surviving typecheckers (mypy, ty, pyright, Pyrefly) within the past year or so, so I have some random compliments/endorsements:Your
textDocument/hoversnippets are the best out of the four I’ve tried! I especially love that they come with links, and you seem to do a noticeably better job at parsing the zoo of quasi-rst/md docstrs to be found in python libraries.Your project makes a ton of subtly-pythonic decisions, like trading Pyright’s huge list of CamelCase rules for a concise set of kebab-case ones. It's one of those projects where the docs, CLI, and other accoutrements all just feel... right? Intuitive? Consistent? Just 'written by python fans', I guess!
Pyrefly is so LSP-native (the incredible protocol that inspired MCP) that you can integrate it into Sublime without any code at all, just a short entry in a .json file. I'm releasing a Sublime plugin today that brings more to the table, but I consider it a huge accomplishment to be so spec-compliant and resilient.
Your process for finding the right venv (environment? interpreter?) for a given file is far and away the best out of the 4: it's the least opaque, the most configurable, and the most feature-rich/capable.
I have ~~some~~ 7 questions -- I'd love to hear from anyone on the team who finds the time and interest for any of them! Turns out I've been thinking about pyrefly a lot 😬
What word/abbrv should replace "typecheck"? It just looks weird next to its two devtool siblings, whose names are elegant, short, and commonplace:
lintandformat.typeobviously doesn't work, andcheckis used for linting. Maybe we could just claimanalyze? Fortune favors the bold, after all!Can we use
pyrein variable/file names, or is the four-letter version permanently taken up by the predecessor? I probably won't stop either way, but I'd be lying if I said this was the first time I've wondered what the internal policy is!Are "Code Lens" features important? The new spec is theoretically supported by Sublime, but it's been basically untouched AFAICT, even for clients of servers that have been already advertising support for a while. Do you see it as a fun addendum to the core job of an IDE language server, or a critical path forward? (In other words: should I bother to get it working?)
Does Pyrefly tend to have more
A != Afalse positives than most checkers? As in identical types failing comparison due to some internal module path inconsistency. It's a vague problem and my various setups are cursed enough to very likely be at fault, so not worthy of an issue yet. Still, it's definitely a pattern I've noticed only on Pyrefly, so I'm curious if anyone here has seen the same.Are you speaking/celebrating at PyCon? I just noticed that Meta doesn't have an employee on the PSF board (just JetBrains, Anaconda, and QT left standing it seems), but hopefully a company investing in its second OS typechecker will also shell out for some hotel rooms for y'all!**
Do you have any brazen AI dreams/plans? I loved your recent post on agents using pyrefly and see a few references in this one to using pyrefly to help people develop in pyTorch, but I wonder if anyone on the team shares my dreams of normalizing a much more closely-knit integration between LSPs and agents (for both of their sakes). Will there ever be a pyrefly (mini-)agent? Or perhaps a pyrefly harness for deterministically resolving tool call errors related to type mistakes?
Finally, is there a way to apply to work with just your team? I'd jump at the chance to work on the future of Python typing & AI IDEs now that I'm wrapping up a set of related freelance projects, but I definitely wouldn't want to go through the FAANG rigamarole again just to be placed on some team writing TPS report generators in Cobalt 😉.
Again: congrats. It's people like y'all that are making Python better than ever, year after year. Jokes aside, I hope the whole team finds some time to appreciate this accomplishment.
** If you do attend, please do stage some sort of dramatic clash with the
tyteam for the cameras. It would be worth it just to hear a local news anchor have to explain why a snake has types that must be checked!BeamMeUpBiscotti@reddit (OP)
Thanks for the kind words!
I think strictly speaking there's supposed to be a space between, like "type check" and "type checker" and "type checking", but I frequently write it as one word. I'm not sure it needs to be replaced as a term
Unfortunately, Pyre the name is already overloaded, which is why Pyre is
pyre-checkon Pypi and Github.I think using Pyrefly over Pyre is best to avoid confusion.
I think it's more of a nice-to-have. Historically it only existed on the heavier-weight IDEs, and many people were fine without it. Some IDE features definitely have become less important now that so many people use AI, for example code actions that produce boilerplate classes.
This certainly isn't expected, maybe there's an issue detecting the active Python environment. Feel free to file an issue on Github so we can help reproduce it.
We'll have more to say on this in the future, but we're thinking hard about this. Even measuring how much a type checker or language server affects agentic workflows is tricky, since it can be affected by benchmark selection, codebase, model selection, etc.
We don't have any openings right now, but I believe Meta has moved away from putting new hires into a general pool to per-team hiring.
BeamMeUpBiscotti@reddit (OP)
We are! The whole team will be there.
The typing summit on Thursday is jointly hosted/organized by a Pyrefly maintainer and a ty maintainer :-)
darkrevan13@reddit
Isn't self promotion forbidden on this subreddit?
BeamMeUpBiscotti@reddit (OP)
I got permission from the mods yesterday
drphillycheesesteak@reddit
Been using for months now. Congratulations on the v1 release! The pydantic support is best in class and the speed is sufficient for interactive feedback. I don’t get many false alarms at all. The main library I see issues with is astropy, but I don’t think this is pyrefly’s issue at all.
convex_dude@reddit
Super hyped about the Tensor shape checking. Thanks a million!
teerre@reddit
I've been using pyrefly for some time and it has been amazing. Blazingly fast and better much better at inference