uv 0.13.3 Fixes uv export Lag: Why 0.44s Became 60+ Seconds

uv 0.13.3, released on 20 October 2026, makes exactly one change. If you export lockfiles, it matters: uv export no longer takes a minute or more on projects whose dependency graphs use extras. The catch is that the fix is a revert, so an older and narrower export bug comes back with it.

Key takeaways

• uv 0.13.3 shipped on 20 October 2026 with one performance fix for uv export (PR #22750).
• The slowdown came from a correctness fix that was merged on 6 October 2026 and first shipped in uv 0.12.24 on 8 October 2026.
• In Astral’s own test, one export went from about 0.44 seconds to more than 60 seconds. After the revert it took about 0.25 seconds.
• The revert brings back a bug where exports could include optional dependencies through paths that don’t match the target environment.
• Draft pull request #22751 aims to keep both the speed and the correctness fix.

What changed in uv 0.13.3?

uv is Astral’s Python package and project manager. It is written in Rust and known for speed. The uv export command converts your uv.lock file into a format other tools can read: a pip-style requirements.txt, a PEP 751 pylock.toml, or a CycloneDX SBOM (software bill of materials), which is still in preview.

The 0.13.3 release notes have a single line: “Avoid severe uv export slowdowns in dependency graphs with extras.” Extras are optional feature sets that a package declares, like requests[socks]. They pull in extra dependencies only when you ask for them.

That line comes from PR #22750 by Astral founder Charlie Marsh, merged on 20 October 2026. The title says what it does: “Revert optional-extra activation tracking in exports.”

Why did uv export suddenly take 60 seconds?

Marsh bisected the problem. That means binary-searching the commit history until one change is left to blame. The search pointed to PR #22234.

That earlier pull request was written by contributor inanna-malick and merged on 6 October 2026, and it fixed a real bug. An export could pull in an optional dependency through a path whose environment markers didn’t match. Markers are conditions like sys_platform == 'win32'. The fix tracked whether an extra was “activated” separately from whether a package could be reached at all.

It also sent a package back for another pass whenever its activation state changed. According to the revert, that state was repeatedly propagated through the whole graph, and that is where the time went.

Picture a dispatcher who re-plans every delivery route in the city each time one customer edits an order. With ten customers, nobody notices. With thousands of linked orders, the dispatcher never leaves the office.

Marsh’s numbers, all on the same frozen lockfile:

• Before #22234: about 0.44 seconds.
• With #22234: more than 60 seconds.
• Current main with the revert: about 0.25 seconds.

Which uv versions are affected?

The change first shipped in uv 0.12.24 and was in every release until 0.13.3. Not every project hits the slow path. It only appears in graphs with extras, and how bad it gets depends on the shape of your graph.

If an export step in your CI pipeline got much slower after 8 October 2026, this change is the most likely cause.

What is the trade-off in the revert?

Marsh calls the revert a temporary mitigation. It brings exports back to normal speed. It also brings back the correctness bug that #22234 fixed and deletes the regression test written for it, requirements_txt_does_not_activate_extra_through_incompatible_path.

In practice, an extra can be activated along a path that doesn’t apply to your target environment. When that happens, its optional packages can end up in the export again. Your requirements.txt might list a package your server never needed.

My take: it was the right call. A correct export that never finishes in CI is no use to anyone. A fast export with a narrow, documented edge case is something you can check yourself.

That check matters most for SBOMs. If a security scanner reads your CycloneDX output, each extra package is one more line to review. Our report on the GhostAction attack on 94 GitHub repos shows why teams care what is in their dependency lists.

How do you upgrade to uv 0.13.3?

• Standalone installer: run uv self update.
• Pinned install: the release page gives a script for this exact version: curl --proto '=https' --tlsv1.2 -LsSf https://releases.astral.sh/github/uv/releases/download/0.13.3/uv-installer.sh | sh.
• Homebrew: the formula update has been merged, so brew upgrade uv works.
• pip or pipx: uv is on PyPI, so use pip install -U uv or pipx upgrade uv.
• CI: if you pin uv in GitHub Actions, change the version in your setup-uv step to 0.13.3.

Check the version with uv --version, then time your export step before and after. If you ship one lockfile to several platforms, compare the exported files as well, since the old edge case is back.

What happens next

The real fix is draft PR #22751, “Resolve export extra activation globally.” It stops re-propagating state one package at a time. It works out which packages can be reached before deciding which extras are active, gives each observable extra one global condition, and only repeats work inside the graph’s recursive loops.

The author’s early timings look promising. The original frozen workload of 19 exports took 0.454 seconds, against 0.516 seconds before #22234. A stress test with 1,000 dependent negative activations dropped from 82.18 ms to 17.38 ms. The author says the small differences shouldn’t be read as proven speedups, and reports that 198 export and conflict tests pass.

As of 20 October 2026 the PR is still a draft with no release date. Until it lands, uv 0.13.3 is fast but slightly less strict.

For more on Python tooling, read our explainer on Vlmhub’s one-call API for 9 vision model backends.

FAQ

Do I need uv 0.13.3 if I never run uv export?

Not urgently. The release only changes uv export, so nothing else works differently. Upgrading does no harm and keeps you current.

Is uv 0.13.3 less correct than uv 0.13.2?

In one narrow case, yes. It brings back the bug where exports could include optional dependencies through environment paths that don’t match your target. In return, exports with extras are fast again.

When will the proper fix ship?

There is no date yet. Draft PR #22751 aims to keep the correctness fix without the slowdown, but it had not been merged as of 20 October 2026.

Next step: run uv self update, time your next export, and follow PR #22751 if you ship requirements files to more than one platform.