Would you use ty for type checking in CI yet?

For a work project, I’d pick the checker that already covers the features your code relies on. ty is still in an early 0.0.x stage, and its diagnostics or behavior may change between releases. That can mean extra churn when upgrading, even if the tool is improving quickly.

If you want to try it, pin the version and run it separately before making it a required CI check. That gives you a clearer picture of compatibility without making every change depend on an evolving tool.

If basedpyright is already working for you, there’s not much reason to switch just because a newer checker looks fast or interesting. I’d keep the established setup for the main CI gate and test ty on a branch or as a non-blocking check. Revisit once its feature coverage and release stability fit your project.

The right choice depends a lot on the framework and codebase. Some developers report using mypy for Django because its ecosystem support suits their needs, while others prefer alternatives like Zuban or pyrefly for different projects. I’d test candidates against your actual dependencies and existing annotations rather than rely on a general ranking.

For a library that other people depend on, running more than one checker can be useful. Pin each tool to a specific version, and run the full CI suite whenever you change those pins. Just be ready for overlapping or conflicting diagnostics, and don’t treat every checker as a required gate unless you’ve decided how to handle that noise.

For a small project where you can absorb occasional changes, trying ty now seems reasonable. For a company pipeline with strict stability requirements, I’d wait or keep it advisory for now. Those are different risk tolerances, not a single answer for every team.