What Is ty? The Beginner's Guide to Astral's Python Type Checker

CodexFuse Team · 2026-11-04T17:16:51.251Z · 13 min read min read

What Is ty, Exactly?

ty is an extremely fast Python type checker and language server, written in Rust. It was built by Astral, the same team behind the Python tools uv and Ruff, and it is designed as a drop-in alternative to tools like mypy, Pyright, and Pylance. In plain terms: you point ty at your Python project and it finds type-related bugs — wrong argument types, values that could be None, dead code — before your code ever runs.

The name is pronounced "tee-why" (/tiː waɪ/) — just "ty", please, according to the project's own FAQ. Before its public release it was developed under the codename "Red-Knot", and ty was licensed under the MIT license. It runs everywhere Python developers work: as a command-line tool, as a watch-mode daemon, and as a language server inside your editor, where you get type feedback within a few milliseconds of typing.

Two things make this Python type checker genuinely different from a beginner's perspective. First, it was designed from the ground up around incrementality: the entire architecture exists so that editing one function re-runs only the computations that changed. Second, it catches real bugs in code that has no type annotations at all — no decorators, no hints required. We will show both ideas working below.

Who Made ty — and What Does the OpenAI Deal Mean?

Astral built ty, and Astral is the company behind uv (the Python package manager) and Ruff (the Python linter and formatter) — two tools that went from newcomer to industry standard within about a year each. That track record is why the Python world watches every Astral release so closely.

On March 19, 2026, OpenAI announced that it will acquire Astral, bringing its open-source developer tools — uv, Ruff, and ty — into OpenAI's Codex ecosystem. The announcement says the closing is subject to customary closing conditions, including receipt of regulatory approval, and that the Astral team will join the Codex team at OpenAI. In a Talk Python interview recorded June 2, 2026, Astral founder Charlie Marsh said, "We joined OpenAI about a month ago... I continue to lead the Astral team here at OpenAI."

What does that mean for you as a user? Nothing has been taken away: Astral has stated that OpenAI will continue supporting its open-source tools after the deal closes, and the astral ty project continues developing in the open on GitHub — at astral-sh/ty, astral.sh/blog/ty, and docs.astral.sh/ty — with new releases landing almost daily. No purchase price or formal closing date has been published by either company, so treat any figure you see elsewhere as a rumor.

How Do You Install ty? (A Five-Minute ty Tutorial)

Every ty Python installation starts the same way: uv makes it a one-liner. The fastest way to try ty is without installing anything at all, using uv. If uv is not on your machine yet, our guide to uv walks you through it — it is the same tool family, and the install routes are nearly identical.

1. Try it once, no install: run uvx ty check in any project. This downloads the latest ty and type-checks the current directory, then disappears.
2. Install it globally: run uv tool install ty@latest so ty is on your PATH. (Update later with uv tool upgrade ty.) Alternatives that also work: pipx install ty, pip install ty, mise install ty (our mise guide covers the tool manager), or the standalone installer curl -LsSf https://astral.sh/ty/install.sh | sh. Windows users get a PowerShell variant on the official install page.
3. Run it on your project: run ty check. ty checks every Python file in the working directory recursively, or everything in the project if it finds a pyproject.toml.
4. Check a single file: run ty check example.py. ty finds your packages from the active virtual environment (VIRTUAL_ENV), a .venv folder, or a python3 binary on your PATH — activate your environment first so dependencies resolve.
5. Turn on the editor integration: install the official astral-sh.ty extension from the VS Code Marketplace, and ty starts giving you feedback as you type. Then run ty check --watch in a terminal if you also want a live command-line view that re-checks incrementally on every save.

Two versions of one important command: uv add --dev ty installs ty as a development dependency of a single project (then run it with uv run ty), while uv tool install ty@latest installs it globally for use across all your projects.

What Does Running ty Actually Look Like?

A typical first run looks like this: you run ty check on an unannotated project and ty reports diagnostics with file names, line numbers, and suggested fixes, inspired by the Rust compiler's error messages. A single diagnostic can pull in context from multiple files to explain not just what is wrong, but why — and often how to fix it.

The speed is the part that changes habits. Astral reports that without caching, ty is consistently between 10x and 60x faster than mypy and Pyright. On the PyTorch repository, editing one load-bearing file caused ty to recompute diagnostics in 4.7 milliseconds — 80x faster than Pyright's 386 milliseconds. And Dagster's real-world migration story is even more relatable: their Pyright CI step took about 15 minutes on every pull request, and the equivalent ty step finishes in roughly 1–2 minutes.

Under the hood, ty checks the bodies of unannotated functions unconditionally — there is no equivalent of mypy's check_untyped_defs setting, because for ty it is simply the default. That is how it catches bugs in code you never annotated: Dagster found that ty flagged a real runtime path where pa_column.checks could be None and get iterated over, a bug Pyright had never reported. The bug could have raised a TypeError in production.

ty vs mypy vs pyright vs basedpyright vs pyrefly: Which One Should You Use?

The honest short answer: ty is the rising challenger, not the finished incumbent. If you have ever searched for "ty vs pyright" or "ty vs basedpyright", this is the section for you — the same core question covers mypy and pyrefly too. Here is the factual lay of the land, from official documentation and published case studies.

Three practical differences matter day to day. First, suppression comments: mypy uses # type: ignore[code], pyright uses # pyright: ignore[reportXyz], and ty uses # ty: ignore[rule]. Second, ty is reasonably strict by default and has no --strict flag at all. Third, ty has no plugin system — mypy-style plugins simply do not exist; instead, ty ships built-in support for popular libraries like Pydantic, Django, and pytest.

So when does it make sense to switch? The decision matrix from the community is blunt: if your stack is already uv plus Ruff, watch ty closely and start experimenting now — the ergonomics match. Dagster fully migrated its monorepo from Pyright to ty in about 100 agent-driven pull requests and stayed for the speed and the bugs it caught. If you need maximum spec conformance today, Pyright or the stable Pyrefly 1.0 remain the conservative picks. And keep the security note in mind: for editor integration or ty check --fix on untrusted projects, use ty 0.0.84 or newer, since earlier betas had a use-after-free vulnerability during incremental analysis.

Which Editors Work With ty?

ty ships an official language server, so any editor that speaks the Language Server Protocol can use it by running ty server. Out of the box, ty supports go-to-definition, find-all-references, completions with automatic imports, quick fixes, rename, hover, inlay hints, signature help, semantic highlighting, Jupyter notebooks, and call hierarchy.

• VS Code: install the official astral-sh.ty extension from the Marketplace. It automatically disables Pylance's own language server so you never run two Python servers at once.
• Neovim: configure it through nvim-lspconfig (Neovim 0.11 and newer have built-in LSP configuration).
• Zed: ty is included with Zed out of the box — no extension needed, though Zed's default primary Python LSP is basedpyright.
• PyCharm: ty has been supported natively since PyCharm 2025.3.
• Emacs: connect through the built-in Eglot client.

If you are new to language servers in general, the idea is simple: instead of a separate program you remember to run, the type checker lives inside your editor and underlines problems the moment you create them. On the kind of VPS many developers use as a remote dev box, the same server also powers fast remote editing over SSH.

What ty Won't Do (Yet)

ty is a type checker, not a linter — say that once and keep it straight, because this is the single most common beginner confusion. Ruff does the linting and formatting; in fact, ty's own language-server feature table marks formatting as "use Ruff for formatting". Ty does not report an error for missing annotations either: it infers types where it can and treats the rest as Unknown. If you want annotation-completeness enforced, Ruff's flake8-annotations rule group is where that lives.

It also has no plugin system, no --strict flag (strictness is the default), and no stable API — breaking changes, including changes to diagnostics, may occur between any two 0.0.x versions. The beta was announced in December 2025 and the latest release is 0.0.97 from today, November 4, 2026, with a stable release aimed for some point after the beta period. Several checks that exist in mypy and pyright are simply not implemented yet, and Astral's migration guide documents which ones.

Sources

Every factual claim above comes from a page fetched for this article on November 4, 2026:

• ty documentation (installation, type-checking, editors, language-server features, typing FAQ, coming-from-mypy-or-pyright guides) — docs.astral.sh/ty
• ty GitHub README and releases page (0.0.97 released 2026-11-04, version policy, MIT license, Python 3.10+ support) — github.com/astral-sh/ty
• "ty: An extremely fast Python type checker and language server" (beta announcement, performance figures, incrementality architecture) — astral.sh/blog/ty
• "OpenAI to acquire Astral" (March 19, 2026 announcement, regulatory-approval condition, Codex team) — openai.com/index/openai-to-acquire-astral; Astral's own post — astral.sh/blog/openai
• Talk Python To Me #552 (recorded June 2, 2026) — Charlie Marsh: "We joined OpenAI about a month ago... I continue to lead the Astral team here at OpenAI." — talkpython.fm
• "We Tried ty for Performance. It Found Real Bugs" (published 2026-05-21, Dagster migration: 15 min → 1–2 min CI, 4,500 diagnostics, the not-iterable bug Pyright missed) — dagster.io
• "mypy vs Pyright vs Pyrefly: Choosing a Python Type Checker in 2026" (conformance estimates, Pyrefly 1.0 May 2026) — codegym.cc
• pydevtools handbook — ty reference (pronunciation, "Red-Knot" codename, 0.0.84 security note, PEP 723 script isolation) and the mypy/pyright/ty comparison — pydevtools.com
• "What's up Python? Astral's new type checker" (December 2025, LSP "killer feature" framing) — bitecode.dev

Frequently Asked Questions

Is ty ready for production use?

It depends on your risk tolerance. Astral announced the beta in December 2025 saying it uses ty exclusively in its own projects and is ready to recommend it to motivated users for production use — and Dagster has fully migrated a large monorepo. But ty is still pre-1.0 with no stable API, breaking changes can land in any 0.0.x release, and several mypy/pyright checks are unimplemented. Try it on a side project first, then decide.

Does ty replace mypy or Pyright?

It can, and the official docs include a migration guide for exactly that move. Be aware of the differences: ty checks unannotated function bodies by default, is stricter out of the box, uses # ty: ignore[rule] suppressions, and has no plugin system — projects that depend on mypy plugins will need another plan.

What is the difference between ty and Ruff?

The ty type checker and Ruff are siblings, not competitors, and both come from Astral. Ruff is the linter and formatter: it enforces style rules, import order, and optional annotation completeness. ty is the type checker: it proves (or disproves) that the values in your program have the types you claim. Most Astral users run both, along with uv for packaging.

Which editors support ty?

VS Code via the official astral-sh.ty extension, Neovim via nvim-lspconfig, Zed out of the box, PyCharm natively since 2025.3, Emacs via Eglot, and anything else that speaks the Language Server Protocol through ty server. It auto-disables Pylance's server in VS Code to avoid conflicts.

Is ty still free and open source after the OpenAI deal?

Yes. ty is MIT-licensed, development continues publicly on GitHub, and Astral has stated that OpenAI will keep supporting its open-source tools after the deal closes. The release cadence — 0.0.95 on October 29, 0.0.96 on November 3, 0.0.97 on November 4, 2026 — shows active open development after the acquisition was announced.