Python caches on Mac: pip, uv and Poetry, and how to clear them

The pip cache on a Mac lives in ~/Library/Caches/pip. It holds the packages pip has downloaded and the wheels it built from source, for every Python on your Mac, and pip's documentation describes no size limit or automatic cleanup for it.

It's safe to delete: move the folder to the Trash in Finder, and pip downloads what it needs again.

uv and Poetry keep caches of their own. Poetry's is in ~/Library/Caches/pypoetry, and its cache and artifacts folders can go to the Trash the same way. uv's is in a hidden ~/.cache/uv folder, and uv's documentation says it's never safe to change that cache by hand, so it's cleared with uv's own command, which has no app or button.

Clearing any of these costs only time. The next installs download packages again, and packages with no ready-made build for your Mac compile again. Your installed packages and virtual environments keep working.

The one folder to leave alone is Poetry's virtualenvs folder, which sits next to its cache and holds your projects' environments. This post goes through each cache, what its own cleanup removes, and the small caches Python tools leave inside every project.

Where Python's caches live on a Mac

Python tools don't agree on where caches go. Some use the Mac's own Caches folder in your Library, and some use a hidden .cache folder in your home folder, a convention from Linux.

Tool	Folder	What it holds	Move it to the Trash?
pip	~/Library/Caches/pip	Downloads and wheels it built	Yes
uv	~/.cache/uv	Packages, unzipped wheels, tool environments	No; use uv's own cleanup
Poetry	~/Library/Caches/pypoetry/cache	Package information from indexes	Yes
Poetry	~/Library/Caches/pypoetry/artifacts	Downloaded package files	Yes
Poetry	~/Library/Caches/pypoetry/virtualenvs	Your projects' environments	Not as a cache
conda	pkgs, inside its install folder	Packages it downloaded and unpacked	No; use conda's cleanup
Projects	__pycache__, .mypy_cache, .ruff_cache, .pytest_cache	Results tools save between runs	Yes

A wheel is Python's ready-built package format. When a package has no wheel for your Mac, pip and uv build one from the source code, which can take a while, and they cache the result so they don't build it twice.

Why is uv's cache in a hidden folder?

uv follows a Unix convention on the Mac. Its documentation says it uses the folder set by the XDG cache variable if there is one, and otherwise ~/.cache/uv. Folders whose names start with a dot are hidden in Finder, so uv's cache doesn't show up when you browse your home folder.

pip uses the Mac's own location, ~/Library/Caches/pip. Its documentation notes that from pip 26.2 it also respects the XDG cache variable on the Mac. If you have that variable set, a newer pip can start a fresh cache in another folder and leave the old one behind.

How do you open these folders in Finder?

1. In Finder, choose Go › Go to Folder.
2. Type the path, such as ~/Library/Caches/pip or ~/.cache/uv. The tilde stands for your home folder.
3. Press Return.
4. Select a folder and choose File › Get Info, or press Command-I, to see its size.

The steps are the same in macOS 27 Golden Gate and macOS 26 Tahoe. Go to Folder opens hidden folders too.

Where does Storage settings count them?

The caches in your Library and in ~/.cache count as System Data in System Settings › General › Storage. Apple describes System Data as files that don't fall into the other categories, and says you can't manage its contents there. The System Data guide explains the rest of it.

Caches inside your projects count wherever the projects are. If they're in your Documents folder, they're part of Documents.

How much space do Python caches take?

The research behind the app's catalog puts Python's caches and environments together at 2 to 50 GB on Macs that use Python. What decides it is the packages you install. Most are small, but scientific and machine learning packages are large, and every version you install adds another copy to the cache.

• TensorFlow 2.21.0223.8 MB
• PyTorch 2.14.1127.3 MB
• jaxlib 0.11.264.9 MB
• pyarrow 26.0.036.3 MB
• SciPy 1.18.128.7 MB
• NumPy 2.5.412 MB
• pandas 3.0.610.1 MB

Sizes of each package's newest release on PyPI, the Python Package Index, for Python 3.13 on a Mac with Apple silicon, checked on 13 October 2026. pip's cache keeps each download; uv keeps packages unzipped as well.

Install two versions of PyTorch across a couple of Python versions, and the cache holds several of those downloads. Nothing removes them until you do.

The pip cache on a Mac

pip is Python's standard package installer. Every copy of it on your Mac, whether its Python came from python.org, Homebrew or another installer, uses the same cache folder unless you've told it otherwise.

What does pip keep in its cache?

Two things, according to pip's documentation. An HTTP cache, which works like a web browser's: the responses pip downloaded, including package files, reused while they're still valid. And a cache of wheels pip built locally, reused instead of building the same package version again.

pip's documentation calls the folder's layout an implementation detail that may change. The HTTP cache is in a folder named http-v2, and built wheels are kept separately.

Which builds doesn't pip cache?

Wheels built from a folder on your Mac, such as a project you install from its own source code, aren't kept between runs, according to pip's documentation. pip caches what it builds from downloaded source, so a package you install from your own working copy never adds to the cache.

When should you remove just one package?

When a cached build is the problem. pip's documentation gives an example: a package built without its optional fast extensions, because they failed to compile, keeps being reused from the cache. Removing that one package's wheels makes pip build it again.

That's done with pip's cache command, which can remove a single package. In Finder there's no reliable way to pick out one package, since pip doesn't promise a folder layout.

Why does the pip cache keep growing?

Because nothing trims it. pip's documentation describes no size limit and no automatic cleanup for cached wheels. Every package version you install in any environment stays, so a few years of projects, upgrades and Python versions build up.

Large packages make it obvious. One machine learning project can add hundreds of megabytes, and trying a few versions of the same library multiplies that.

Is it safe to delete the pip cache?

Yes. The pip cache entry describes it as packages pip downloaded or built, kept so later installs don't repeat the work. Installed packages and environments aren't affected; the next installs download again, and packages built from source are built again.

1. Make sure nothing is installing Python packages at that moment.
2. In Finder, choose Go › Go to Folder, type ~/Library/Caches and press Return.
3. Move the pip folder to the Trash.
4. Empty the Trash when you're sure you don't need it back.

Move only the pip folder, never the Caches folder itself, which every app on your Mac uses.

What do pip's own cache commands do?

pip has a cache command in Terminal, with no app or button. Its documentation lists what each part does:

pip's cache command	What it does
Dir	Shows which folder pip uses as its cache
Info	Shows the cache's size and locations
List	Lists cached wheels, optionally for one package
Remove	Removes one package's wheels; HTTP cache files stay
Purge	Removes everything from the wheel and HTTP caches

Purging does much the same as moving the folder to the Trash, except that what it removes is gone at once. The Trash gives you a chance to change your mind.

What is the old http folder?

pip 23.3 changed the format of its HTTP cache and moved it to the http-v2 folder. pip's documentation says that if you've switched completely to newer versions of pip, you may delete the old http folder. On the Mac measured later in this post, it was still there, at 1.7 MB.

If an old Python on your Mac still uses a pip from before 23.3, it reads the old folder. Otherwise nothing does.

Can you stop pip from caching?

pip has an option to turn its cache off, but its documentation advises against it unless something else already caches packages for you, such as layered container builds. Without the cache, pip is slower and downloads more.

For a Mac, clearing the cache now and then is the better trade. You keep fast reinstalls in between.

The uv cache

uv is a fast Python package and project manager, written to replace pip, virtualenv, pipx and several other tools with one. It caches more than pip, and it treats its cache differently.

What's in uv's cache?

According to uv's documentation and its source code, the cache holds the packages uv downloads, the wheels it builds, package lists from indexes, Git checkouts, and a ready-unzipped copy of each package. It also holds the environments uv creates for scripts, and for tools run once without installing them.

uv's storage reference describes the cache as data that's disposable but useful to keep for a long time. uv recreates anything it needs.

Why is uv's cache often bigger than pip's?

Because uv keeps packages unzipped, ready to place into environments. Installing a package into a new environment is then a matter of cloning files, which is quicker than unpacking them again.

On the Mac measured later in this post, uv's cache was 3.7 GB, and 3.5 GB of it was those unzipped packages. pip's cache on the same Mac was 91 MB.

Why shouldn't you delete uv's cache in Finder?

uv's documentation is explicit: it's never safe to modify the cache directly, for example by removing a file or folder. uv's cache is built for several uv commands to read and write it at once, and it expects to manage its own entries.

So for uv there's no Finder route. Clearing it is done with uv's own command, in Terminal; uv has no app or button for it.

What do uv's cache commands remove?

uv's cache command	What it removes	Notes
Clean	Everything in the cache	Environments for tools run with uvx go too
Clean, with package names	Only those packages' entries	The rest stays
Prune	Unused entries and the environments kept in the cache	The documentation says it's safe to run regularly
Prune, for CI	Pre-built wheels and unzipped source code	Keeps wheels built from source
Size	Nothing	Shows the cache's size
Dir	Nothing	Shows the cache's folder

Prune is the gentler choice for routine use, because it keeps what's still in use. Clean empties everything, which is what you want when space is short.

Does clearing uv's cache break your environments?

Not with uv's default settings. uv's settings reference says it clones packages from the cache into environments on the Mac, so each environment has its own copy and doesn't depend on the cache.

The exception is an optional mode where environments link to the cache instead. uv's documentation discourages it, and warns that clearing the cache then breaks every installed package. If you or your team turned that on, recreate environments after clearing.

Tools you installed with uv aren't in the cache. They live in their own folder and stay until you uninstall them; only the environments for tools run once without installing go with the cache.

Why can clearing uv's cache free less than its size?

Because of how those clones work. Apple's documentation for APFS, the Mac's file system, says a clone takes no additional space on disk, and that the original and the copy share every block that hasn't changed.

So a package uv cloned into three environments is stored once. Clearing the cache removes one of four files that share the same blocks, and the space stays in use until the environments are gone too. A folder's size counts each file in full, so the cache can look bigger than what clearing it frees.

Poetry's caches

Poetry manages a project's dependencies and its virtual environment together. On a Mac it keeps its caches and, by default, those environments in one folder, ~/Library/Caches/pypoetry.

What's in Poetry's cache folder?

Three folders, according to Poetry's source code and documentation:

• cache: package information from indexes such as PyPI, kept by repository.
• artifacts: the package files Poetry downloaded.
• virtualenvs: the environments Poetry created for your projects, unless a project keeps its environment inside its own folder.

The first two are what the Poetry cache entry describes. The third is not a cache at all.

Is it safe to delete Poetry's cache?

The cache and artifacts folders, yes. Poetry downloads package information and files again as it needs them, so the next installs take longer and need an internet connection.

1. Make sure Poetry isn't installing anything.
2. In Finder, choose Go › Go to Folder, type ~/Library/Caches/pypoetry and press Return.
3. Move the cache and artifacts folders to the Trash.
4. Leave virtualenvs where it is.

What does Poetry's cache clear command remove?

Less than its name suggests. Poetry's documentation says it removes packages from cached repositories, and Poetry's source code shows it works only in the repository folder, inside cache. It doesn't touch artifacts, the downloaded files.

So on a Mac where Poetry has downloaded many large packages, its own command can leave most of the space behind. Moving artifacts to the Trash in Finder is the way to clear that part.

Why not delete the whole pypoetry folder?

Because of virtualenvs. The Poetry virtual environments entry explains that each project's environment, with all its installed packages, lives there by default. Delete them, and those projects can't run until Poetry installs their dependencies again.

That's often fine for projects you've finished. The post on old Python environments covers how to tell which environments are still in use.

What is Poetry's folder in Application Support?

Poetry itself, if you installed it with its official installer. Poetry's documentation says the installer puts it in ~/Library/Application Support/pypoetry on a Mac, with a link to the poetry command in a hidden folder in your home folder.

It isn't a cache. Removing it removes Poetry, and Poetry's documentation describes running its installer again with an uninstall option to remove it completely.

Caches inside your projects

Some Python tools save results inside each project folder, so the next run has less to do. Most of these folders are small, but they appear in every project, including ones you stopped working on years ago.

What are pycache folders?

When Python imports a module, it saves a compiled version in a __pycache__ folder next to the source file. Python's documentation says it checks the source file's date and recompiles automatically when the source changes, and that the file names include the Python version, so several versions can share a project.

Removing them changes nothing about how your code runs. The __pycache__ folders entry notes the only cost: the first run afterwards is slightly slower while Python compiles again.

Does deleting pycache make Python slower?

Only for that first import. Python's documentation is clear that a program doesn't run faster from a compiled file; the only thing that's faster is loading it. Once Python has recompiled a module, it's back to normal.

uv's documentation adds that uv doesn't compile packages when it installs them, by default. Python does it lazily, the first time each module is imported, so __pycache__ folders inside environments appear as you use them.

Can you stop Python from making them?

Yes, with Python settings in your shell, which have no app or button. One stops Python writing compiled files at all. Another, from Python 3.8, writes them all into a single separate folder instead of next to your code, which keeps project folders tidy.

Most people don't need either: the folders are small, and they come back as soon as you run the code.

What are .mypy_cache, .ruff_cache and .pytest_cache?

Results from three common tools, each kept in the project where it ran:

Folder	Tool	What it holds	If you delete it
.mypy_cache	mypy, a type checker	What it learned about your code and its dependencies	The next check takes longer
.ruff_cache	Ruff, a linter and formatter	Which files it already checked	The next run checks every file
.pytest_cache	pytest, a test runner	Which tests failed last time	It can't rerun only the failed tests
.tox	tox, a test automation tool	Whole test environments	The next run rebuilds them

The first three hold results; the last holds whole environments, so it's usually the largest. The environments post covers it with the others.

How do you find them across all your projects?

__pycache__ folders show in Finder, but the folders whose names start with a dot are hidden, so browsing won't reveal them. In a single project, choose Go › Go to Folder and type the project's path followed by the folder's name to open it directly.

Across dozens of projects, a disk map that shows hidden folders is the practical way to see them all, which is what the last section of this post covers.

Other Python downloads that look like caches

A few more folders fill up as you use Python. Some are caches in the same sense; others only look like them.

conda's package cache

If you use Anaconda, Miniconda or Miniforge, conda keeps every package it downloaded in a pkgs folder inside its install folder. The conda package cache entry explains it: conda's own cleanup removes downloaded archives and packages no environment uses, and keeps the rest.

The environments post goes through what each conda cleanup option removes, and why emptying pkgs in Finder is a mistake.

pipx and its temporary environments

pipx installs Python command-line apps, each in its own environment, and those installed apps aren't a cache. pipx also runs apps once without installing them, and keeps the environments it makes for that in its cache folder for a while, so the next run starts quickly. Its documentation describes them as cached for a limited time.

Models and datasets

Python libraries for machine learning download models, often far larger than any package. PyTorch keeps models it loaded through its hub in ~/.cache/torch/hub, the PyTorch Hub cache entry. Libraries from Hugging Face keep theirs in their own cache, covered in the post on the Hugging Face cache.

Those are worth a separate decision, because downloading a model again can take a long time.

Environments and Python versions

Virtual environments, Python versions installed by pyenv or uv, and apps installed with pipx or uv's tool feature hold installed software, not downloads. They're not caches, and clearing these caches doesn't remove them.

Which cache to clear first: a worked example

The size of each cache depends on how you work. Here's one developer's Mac, measured in October 2026, as an illustration of where the space tends to be.

Folder	Size	What it is
~/.cache/uv	3.7 GB	uv's cache, 3.5 GB of it unzipped packages
~/Library/Caches/pip	91 MB	pip's cache, 1.7 MB of it the old http folder
~/.local/share/uv/tools	126 MB	Tools installed with uv; not a cache
~/.local/share/uv/python	119 MB	Python versions installed by uv; not a cache

Poetry wasn't installed on that Mac. On a Mac that uses it, check its artifacts folder the same way.

How do you measure your own Mac?

1. In Finder, choose Go › Go to Folder, type ~/Library/Caches/pip and press Return.
2. Choose File › Get Info and note the size.
3. Do the same for ~/.cache/uv and ~/Library/Caches/pypoetry, if they exist.
4. Open the pypoetry folder and check its artifacts and virtualenvs folders separately, since only one of them is a cache.

A folder that doesn't exist means that tool has never run on your Mac, or keeps its cache somewhere else. Each tool's documentation lists the setting that moves it.

What each step frees and costs

Step	What it frees	What it costs
Move pip's cache to the Trash	All of it, once you empty the Trash	Downloads and builds again
Move Poetry's cache and artifacts to the Trash	All of it, once you empty the Trash	Downloads again
Clear uv's cache with uv	Up to its size, less what environments share	Downloads again; tools run once are recreated
Remove project caches	All of them	Slower first runs
Run conda's cleanup	What no environment uses	Downloads again for new environments

Where to start

If uv's cache is large, it's the biggest single win, and it's uv's command that clears it. If you use pip and Poetry more, their folders go to the Trash in Finder, and you can put them back if anything surprises you.

Project caches come last. Each is usually small, and they come back the next time you work on each project.

Mistakes to avoid

Python's caches are among the safest things to clear on a Mac. The mistakes come from the folders next to them.

Don't move the Caches folder itself

~/Library/Caches holds caches for every app on your Mac, not just Python's. Move only the pip or pypoetry folder inside it. The post on whether Library's Caches folder is safe to delete explains what else lives there.

Don't treat environments as caches

Poetry's virtualenvs folder, a project's .venv folder and conda's envs folder all hold installed packages, and they sit near caches. Deleting them doesn't lose your code, but the projects stop running until you install their dependencies again.

Don't clear a cache during an install

An install in progress reads and writes the cache. Clearing it at the same moment can make that install fail. Finish or cancel it first.

Don't paste cleanup commands from a web page

Each package manager here has a cleanup command, and a command copied from a web page can do more than it says. pip's and Poetry's caches need no Terminal at all: Finder does the same job, with the Trash as a safety net.

Don't expect Python to get faster

Clearing caches frees disk space, and that's all. It doesn't make Python, your tests or your Mac run faster; if anything, the next installs and the first runs are slower while the caches fill again.

Keeping Python caches in check

Caches are meant to grow; that's their job. The aim isn't an empty cache, but one that doesn't hold years of versions you'll never install again.

How often should you clear them?

When you need the space, or every few months if you install a lot. Clearing every week only means downloading the same packages again.

A good moment is after finishing a project that used large packages, or after upgrading to a new Python version, when packages built for the old one won't be needed again.

A routine that works

1. Every few months, check the size of each cache folder with Get Info.
2. Move pip's cache, and Poetry's cache and artifacts, to the Trash when they're large.
3. Prune or clear uv's cache with uv.
4. Delete environments for finished projects, then clear the caches, so shared space comes back too.
5. Remove project caches from projects you no longer open.

The order in the fourth step matters for uv: environments cloned from its cache share space with it, so removing both is what frees the space they share.

Should Time Machine back up Python caches?

There's little reason to. Everything in them can be downloaded again. To exclude them from Time Machine, in macOS 27 or macOS 26:

1. Choose Apple menu › System Settings, click General in the sidebar, then click Time Machine.
2. Click Options.
3. In Finder, choose Go › Go to Folder, type ~/Library/Caches and press Return, then drag the pip folder onto the list of excluded items.
4. Do the same with ~/.cache, and drag the uv folder onto the list.
5. Click Done.

Apple's steps allow dragging items onto that list as well as adding them. Apple notes that excluded items still appear in Time Machine's local snapshots.

Do you need the caches when you work offline?

They help. uv has an offline setting that relies only on cached data and local files, its settings reference says, and an empty cache leaves it nothing to install from. Clear caches before a trip only if you're sure you won't need them.

Other languages' package managers keep similar caches; the post on npm, Yarn, pnpm and Bun caches covers the JavaScript ones.

How the app does it

Wombit finds each Python cache, including the ones in hidden folders and inside every project, and explains what it is and what clearing it costs. Hard links and APFS clones count once, so a cache that shares space with environments isn't counted twice.

pip's cache, Poetry's cache and artifacts, and the caches inside your projects are Safe: they start checked in Cleanup and go to the Trash, where Put Back returns them. uv's cache is Safe too, and after the review sheet the app runs uv's own command instead of moving it, as uv's documentation asks.

conda's cleanup keeps what environments still use, so the review sheet shows its size as "up to", and says that what a command removes can't be put back. Poetry's virtualenvs folder is Usually safe: it's listed separately and never starts checked.

• ~/Library/Caches/pip

  pip cache

  Python packages pip has downloaded or built, kept so later installs don't repeat the work.

  Safe · Moves it to the Trash

• ~/.cache/uv

  uv cache

  Python packages, wheels and temporary tool environments that uv downloaded or built.

  Safe · Runs uv cache clean

• ~/Library/Caches/pypoetry/{cache,artifacts}

  Poetry cache

  Package information and downloaded files that Poetry keeps to make installs faster.

  Safe · Moves it to the Trash

• ~/**/__pycache__

  __pycache__ folders

  Compiled Python files that Python saves next to your code so modules load faster.

  Safe · Moves it to the Trash

• ~/**/.mypy_cache

  .mypy_cache folder

  Type-checking results mypy saves so later checks only redo the work for code that changed.

  Safe · Moves it to the Trash

• ~/**/.ruff_cache

  .ruff_cache folder

  Results Ruff saves so it only checks and formats files that changed.

  Safe · Moves it to the Trash

• ~/**/.pytest_cache

  .pytest_cache folder

  Information pytest keeps between test runs, such as which tests failed last time.

  Safe · Moves it to the Trash

• ~/{miniconda3,miniforge3,anaconda3}/pkgs

  conda package cache

  Packages conda downloaded and unpacked, kept to create and update your environments.

  Safe · Runs conda clean --all --yes

Seeing every cache and what it holds is free. Clearing them in Cleanup is PRO: one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.