If you have switched to uv for Python dependency management, you have probably noticed installs that used to take twenty seconds now take two. Most of that speed comes from a cache design that is more aggressive than pip's — which also means it grows differently, and clearing it has different consequences. Here is what is actually in ~/Library/Caches/uv and when you should touch it.

Where uv keeps its cache

By default, uv stores its cache at ~/Library/Caches/uv on macOS. You can confirm this, or override it, by checking the UV_CACHE_DIR environment variable — uv respects it the same way it respects most of its other configuration through environment variables rather than a config file buried in a dotfile.

Unlike pip, which mainly caches downloaded wheels and HTTP responses, uv caches at a finer grain. It stores:

  • Downloaded distributions — the wheel or sdist files themselves, same idea as pip.
  • Built wheels — when a package only ships source and needs compiling, uv caches the result of that build, not just the source.
  • Resolution metadata — package version and dependency metadata extracted during dependency resolution, so uv does not have to re-parse or re-query the same package information on every run.

That resolution metadata cache is the part pip does not really have an equivalent for, and it is a large part of why uv's dependency resolution feels near-instant on a second run of the same project.

uv cache clean

The command is straightforward:

uv cache clean

This removes the entire cache. There is also a scoped form:

uv cache clean <package-name>

which clears only entries related to one package, similar to pip's cache remove. And a read command:

uv cache dir
uv cache size

uv cache size is worth running before you decide anything — it gives you the actual number rather than making you du -sh a folder full of unfamiliar subdirectory names.

Why uv's cache can look bigger than pip's for the same work

Because uv caches built wheels in addition to downloaded ones, a project with several native-extension dependencies (common in data science and machine learning work) can end up with more cached artefacts than the equivalent pip workflow, which might have downloaded a prebuilt wheel directly and never needed to cache an intermediate build step. This is not waste — it is uv trading disk space for the ability to skip a compile step entirely on the next resolution, which is often the single slowest part of a Python dependency install.

If your machine builds packages from source often — either because prebuilt wheels aren't available for your platform, or because you are pinned to versions old enough that wheels were never published — expect uv's cache to grow faster than a comparable pip-only workflow would have.

uv versus pip's cache model, briefly

pip uv
Location on macOS ~/Library/Caches/pip ~/Library/Caches/uv
Caches downloaded wheels Yes Yes
Caches built wheels from source Not distinctly Yes
Caches resolution metadata No Yes
Content-addressed (dedupes across projects) Yes Yes

Both tools' caches are safe to delete entirely — nothing in either one is a source of truth, and both will happily rebuild it from scratch on the next install or resolution. The cost of clearing either is time, not correctness.

When clearing it actually fixes something

Two situations where uv cache clean (or the scoped uv cache clean <package> form) is the right call:

  • A build was interrupted or produced a corrupted wheel, and subsequent installs keep failing with a checksum or import error that a fresh download does not have. This is rare with uv's design, since it verifies hashes more strictly than older pip versions, but not impossible after a killed process or a full disk mid-write.
  • You changed the Python interpreter or platform (moved from Intel to Apple Silicon, or upgraded the Python minor version) and want to force a full rebuild rather than trust that uv's cache keys account for every variable correctly. In practice uv's cache keys do include the interpreter and platform, but a clean slate after a major environment change is a reasonable sanity check when something behaves unexpectedly.

For everyday disk pressure with no install problems, there is no correctness reason to clear the cache — only a space one.

uv also manages virtual environments, which are a separate concern

It's worth remembering that uv's cache and the virtual environments it creates (.venv folders, whether managed by uv venv or created implicitly by uv run) are entirely separate things on disk. Clearing the cache does not touch existing .venv directories, and deleting old .venv directories does not touch the cache. If a Mac is short on space from Python work generally, both need checking — the cache is one shared pool that benefits every project, while .venv folders are one full, uncompressed copy of every dependency per project.

A sensible routine

  1. uv cache size to see the real number.
  2. If it's large and you have no active install problems, leave it — it is doing its job.
  3. If you have disk pressure and are willing to trade it for slower rebuilds, uv cache clean reclaims it in one step.
  4. Separately, walk old projects for .venv folders you no longer need; those are typically the larger and more scattered cost.

Where VolumeLens fits in

Newer tools like uv are good about keeping their caches in one predictable, well-named location, but that only helps if you know to look there. VolumeLens scans your whole Mac and sizes every folder honestly, so ~/Library/Caches/uv shows up next to every other cache competing for the same disk — no need to remember which tool writes where. Insights recognises it by name, alongside the pip, Poetry, and Cargo caches that often sit on the same machine.