Free up disk space on a developer's Mac: the complete guide

To free up disk space on a developer's Mac, look at tools before documents. Most of the space goes to Xcode's build data and simulators, Docker's disk image and other virtual machines, package caches, dependency folders in old projects, toolchains you've moved on from, and local AI models.

Work through them in order of risk. First, what the tool rebuilds by itself, such as Xcode's DerivedData, package caches and the build folders of finished projects. Then what you can download again, such as node_modules, simulator runtimes and test browsers.

Last comes what may be the only copy: virtual machines, archives of builds you shipped, and models you made yourself.

Wherever a tool has its own way to clean up, use it. Xcode removes simulators and runtimes, Docker Desktop removes images and volumes, and package managers have cleanup commands that know which files are still in use. Finder is for the plain folders that tools rebuild.

Three things never to do: delete Docker.raw, move the whole ~/Library/Developer folder to the Trash, or remove a virtual machine without checking what's inside. The sections below cover each tool, where its files live, and the level the app's catalog gives each one.

Where the space goes on a developer's Mac

Developer tools are generous with disk space because it makes them fast. They cache every download, keep every build product, and keep every version you've installed, and very few of them clean up without being asked.

How do you see what your tools are using?

Start with System Settings › General › Storage. It can show a Developer category for some of Xcode's files, but most developer data lands in System Data, which Storage settings doesn't break down.

Finder gets you further. Open your home folder, choose View › as List, then View › Show View Options, and select Calculate all sizes. Sort by Size, then follow the largest folders down.

Many tools keep their data in folders whose names start with a dot, such as ~/.npm, ~/.cargo and ~/.gradle, which Finder hides. Choose Go › Go to Folder and type the path to open one directly.

• Xcode DerivedData5–100 GB · Safe
• Simulator runtimes20–200 GB · Managed by macOS
• Docker Desktop's disk, real size10–100 GB · Usually safe
• Other virtual machines and container tools10–150 GB · Review first
• JavaScript: node_modules and caches5–200 GB
• Rust: target folders, crates, toolchains5–100 GB
• Java and Android: Gradle, Maven, SDK10–100 GB
• Local AI models20–150 GB · Review first

Typical ranges on Macs that use these tools, from the research behind the app's catalog. Rows without a level mix items of different levels. Many Macs have far less.

What kind of data is it?

Everything below falls into one of four kinds, and the kind decides how carefully to treat it.

Kind	Examples	Level	What removing it costs
Rebuilds itself	DerivedData, package caches, build folders, logs	Safe	A slower next build or install
Downloads again, with your help	node_modules, .venv, test browsers, SDK images	Usually safe	A reinstall, and time
May be the only copy	Virtual machines, shipped archives, your own models	Review first	Possibly your work
Managed by a tool or macOS	Simulator runtimes, Homebrew's installed packages	Managed by macOS or Review first	Use the tool, not Finder

Why a cleanup comes back

Caches and build folders return as soon as you build again, so clearing them on a project you work on every day buys space for a day. The lasting gains come from projects you've finished, tools you no longer use, and versions you've moved past.

That's the thread through every section that follows: be generous with what belongs to the past, and leave the current project's caches alone unless you're short of space today.

Xcode and simulators

Xcode is often the largest single tool on an Apple developer's Mac. Nothing it keeps is removed when you update it, so years of builds, simulators and debug symbols add up.

What	Where it lives	Level
DerivedData	~/Library/Developer/Xcode/DerivedData	Safe
Device support files	~/Library/Developer/Xcode/iOS DeviceSupport and similar	Safe
Xcode's caches	~/Library/Caches/com.apple.dt.Xcode	Safe
Previews, test clones and playground simulators	~/Library/Developer/Xcode/UserData/Previews, XCTestDevices, XCPGDevices	Safe
Simulators	~/Library/Developer/CoreSimulator/Devices	Usually safe
Simulator runtimes	/Library/Developer/CoreSimulator/Images	Managed by macOS
Archives	~/Library/Developer/Xcode/Archives	Review first
Extra Swift toolchains	~/Library/Developer/Toolchains	Review first

Start with DerivedData

DerivedData holds intermediate build files, the code index and build logs, in a folder per project. Xcode rebuilds it the next time you build or open the project. Folders for projects you've stopped working on stay until they're removed.

To find it, choose Xcode › Settings, click Locations, and click the arrow next to the Derived Data path. Quit Xcode, then move the folders of old projects, or the whole DerivedData folder, to the Trash. The cost is a full, slower build and a fresh index.

Remove simulators and runtimes in Xcode, not Finder

Runtimes are often the largest part. Choose Xcode › Settings and click Components: Xcode lists what's installed and how much storage removing each one would recover. Click the information button next to a runtime you no longer need, then Delete.

Simulators are separate from runtimes and stay after their runtime is gone, listed as unavailable. In current Xcode, choose Xcode › Open Developer Tool › Device Hub, Control-click a simulator and choose Remove. In Xcode 26, it's Window › Devices and Simulators, then Simulators, then Control-click and Delete.

What to keep: archives and some device support files

Archives hold the exact app you built and its dSYM files, which turn crash reports into readable function names. Apple recommends keeping the archive of every build you distribute. Review them in Window › Organizer and remove only test builds that never shipped.

Device support files come back the next time you connect a device running that version. Sets for versions you no longer have a device for can't be copied again, so keep those if you still read crash reports from them.

Swift packages, CocoaPods and Carthage

Swift Package Manager keeps a shared copy of every package repository your projects use in ~/Library/Caches/org.swift.swiftpm, and packages built with the swift tool get a .build folder each. Both are Safe: the next resolve or build fetches and compiles again.

CocoaPods' download cache and its index of public pods are Safe too. Older setups cloned the whole index into a folder named master, which can take several gigabytes. A project's Pods folder and Carthage's Carthage/Build are Usually safe: the project won't build until they're installed again, and edits made inside Pods are lost.

Docker and other virtual machines

Containers on a Mac run inside a Linux virtual machine, and every tool keeps that machine's disk as one large file or folder. Full virtual machines from UTM, Parallels or VMware Fusion hold a whole computer each.

What	Where it lives	Level
Docker Desktop's disk	Docker.raw, inside ~/Library/Containers/com.docker.docker	Usually safe
OrbStack	data.img, in OrbStack's group container	Review first
Colima and Lima machines	~/.colima, ~/.lima	Review first
Podman machines	~/.local/share/containers/podman/machine	Review first
Apple's container tool	~/Library/Application Support/com.apple.container	Review first
UTM, Parallels, VMware Fusion, VirtualBox	Each app's virtual machine packages	Review first
Claude's Cowork VM	vm_bundles, in Claude's Application Support folder	Usually safe

Why Docker.raw looks bigger than it is

Docker.raw is a sparse file. Finder can show the largest size it's allowed to reach rather than the space it actually takes, so a file that seems to hold hundreds of gigabytes may use a fraction of that. OrbStack's data.img works the same way and can show several terabytes.

Never delete Docker.raw. It's the virtual machine's whole disk, and every image, container and volume goes with it, including databases you keep in volumes.

Free Docker space from Docker Desktop

Remove containers, images and volumes you no longer need in Docker Desktop's dashboard, and Docker gives the space back to your Mac by itself, sometimes after a few minutes. Export a volume's data first if it might matter.

To cap how large the disk can grow, change Disk usage limit in Settings › Resources › Advanced. The catalog's entry warns that lowering it deletes all containers and images.

Docker's build cache

Every image you build leaves layers in Docker's build cache, so the next build can reuse them. On a Mac that builds images often, it keeps growing inside Docker.raw, separate from the images you see in the list.

Clearing it keeps your images, containers and volumes; the next builds just take longer while the cache fills again. It's the Docker cleanup that leaves all of your data in place.

OrbStack, Colima, Podman and Apple's container tool

Each manages its own disk and gives space back its own way. OrbStack's image shrinks as you delete containers, images, volumes and machines in OrbStack. Colima returns unused space when it starts. Podman Desktop deletes a machine in Settings › Resources. Apple's container tool can report what's reclaimable and remove what nothing uses.

Their volumes and Linux machines can hold files you made. Look inside before deleting a whole machine.

Full virtual machines

A UTM, Parallels, VMware Fusion, VirtualBox or Tart machine is a complete computer, and everything you did inside it exists only in its package or folder. Delete one with the tool that made it, after copying out anything you need.

In Parallels Desktop, shut the machine down, open Control Center, Control-click it, choose Remove, then Move to Trash. Its snapshots live inside the machine's package, so deleting old ones in Parallels frees space too. In UTM, Control-click the machine in the list and remove it.

JavaScript and Node.js

JavaScript projects spread their space across many folders: one node_modules per project, a cache per package manager, and a build folder per framework. Old projects keep all three.

What	Where it lives	Level
node_modules in each project	Next to each package.json	Usually safe
npm cache	~/.npm/_cacache	Safe
pnpm store	~/Library/pnpm/store	Safe
Yarn Classic cache	~/Library/Caches/Yarn	Safe
Yarn 2 and later, global cache	~/.yarn/berry/cache	Usually safe
Bun cache	~/.bun/install/cache	Safe
.next, .nuxt, .svelte-kit, .turbo/cache	Inside each project	Safe
Node.js versions from nvm	~/.nvm/versions/node	Review first

node_modules in old projects

Every project's node_modules can take hundreds of megabytes, and finished projects keep theirs. Removing it loses nothing you wrote: it installs again from package.json and the lock file. The cost is a reinstall when you return. That's why it's Usually safe: safe, but not free.

Package manager caches

npm, Yarn Classic and Bun keep a copy of every package they download, and npm never trims its cache by itself. Clearing a cache costs downloads on the next install and doesn't affect projects already installed.

Yarn 2 and later is the exception: projects using Plug'n'Play load packages straight from its cache, so they stop running until you install again. JavaScript package manager caches compares each manager's cache and cleanup.

Why pnpm and Bun free less than they show

pnpm keeps each package once in its store and links it into every project that needs it. Much of the store's size is shared with your projects, so only packages no project references come back. pnpm's own prune removes exactly those.

Bun copies packages into projects as APFS clones, which share space with its cache until one changes. Removing the cache alone frees little while those projects keep their node_modules.

Framework build folders

Next.js, Nuxt and SvelteKit rebuild their .next, .nuxt and .svelte-kit folders whenever you start the development server or build. Turborepo's .turbo/cache keeps task results it can restore. All of them are Safe to clear in finished projects; the next run just does the full work.

Python

Python's space splits into caches, which are disposable, and environments, which are a choice. Old Python versions sit in between.

What	Where it lives	Level
pip cache	~/Library/Caches/pip	Safe
uv cache	~/.cache/uv	Safe
Poetry cache	~/Library/Caches/pypoetry/cache and artifacts	Safe
conda package cache	pkgs inside your Anaconda, Miniconda or Miniforge folder	Safe
Project environments	.venv or venv in each project	Usually safe
Poetry environments	~/Library/Caches/pypoetry/virtualenvs	Usually safe
Python versions from uv	~/.local/share/uv/python	Usually safe
Python versions from pyenv	~/.pyenv/versions	Review first

Caches go, environments are a choice

pip, uv and Poetry download or build anything they need again, so their caches only cost time. uv copies files into each environment by default, so environments don't depend on its cache. conda's own cleanup removes what no environment uses and leaves the rest.

A .venv is meant to be deleted and made again from the project's requirements or lock file. The catch is packages you installed by hand and never recorded; they need installing again one by one.

Small folders that add up

__pycache__, .mypy_cache, .pytest_cache, .ruff_cache and .tox are rebuilt on the next run, and all are Safe. Each is small, but a few hundred old projects' worth isn't.

Python versions you no longer use

pyenv builds each version from source, and packages and environments made with it live inside its folder. Removing one means rebuilding it if a project's .python-version asks for it. uv downloads versions on demand and gets them back by itself, but environments made with a removed version need making again.

Homebrew, Rust, Go and other languages

Homebrew, Rust and Go keep their caches in predictable places and each has its own cleanup, which makes them some of the easiest space to recover.

What	Where it lives	Level
Homebrew's downloads	~/Library/Caches/Homebrew	Safe
Homebrew's installed packages	/opt/homebrew/Cellar, or /usr/local/Cellar on Intel	Review first
Rust target folders	In each project	Safe
Cargo's registry and Git checkouts	~/.cargo/registry, ~/.cargo/git	Safe
Rust toolchains	~/.rustup/toolchains	Review first
Go module cache	~/go/pkg/mod	Safe
Go build cache	~/Library/Caches/go-build	Safe

Homebrew cleans up after itself, mostly

Homebrew removes old versions of a package when you upgrade it, and every 30 days an install or upgrade runs a wider cleanup, which also removes downloads older than 120 days. Its download folder in Caches can go to the Trash in Finder at any time; removing it doesn't uninstall anything.

Installed packages are different. Remove what you no longer use by uninstalling it with Homebrew, never by deleting folders in the Cellar: Homebrew keeps records of what it installed, and deleting behind its back leaves them wrong.

Rust's target folders

Cargo writes every build into a target folder at the root of the project, and large projects can reach many gigabytes as dependencies and build settings change. Removing it costs a full rebuild, nothing more.

Cargo's shared caches trim themselves now: since Rust 1.88, Cargo removes downloads it hasn't used in three months. Toolchains are managed by rustup, which reinstalls a project's toolchain when it's missing but not the targets and components you added.

Go's two caches

Go's build cache removes entries it hasn't used recently by itself. The module cache has no size limit and Go never trims it, and Go makes its files read-only, so it's cleared with Go's own clean command rather than in Finder.

Ruby, PHP, .NET, Dart and Flutter

The same pattern repeats in every language: a shared cache that comes back by itself, and a per-project folder that needs a reinstall.

• Ruby: Bundler's cache is Safe; a project's vendor/bundle is Usually safe; Ruby versions from rbenv are Review first, because each is built from source again.
• PHP: Composer's cache is Safe, and Composer already removes downloads unused for six months. A project's vendor folder is Usually safe.
• .NET: NuGet's global packages folder is Usually safe. NuGet never trims it, and packages from sources you can no longer reach can't be restored.
• Dart and Flutter: .dart_tool folders are Safe. The pub cache and Flutter's build folders are Usually safe: the pub cache also holds globally activated tools, and build can hold the Xcode archive of an iOS release.

Java, Kotlin and Android

JVM projects share large caches across every project, and Android adds an SDK, emulator images and virtual devices on top.

What	Where it lives	Level
Gradle caches	~/.gradle/caches	Safe
Gradle versions from the wrapper	~/.gradle/wrapper/dists	Safe
Gradle build folders	In each project and module	Safe
Maven local repository	~/.m2/repository	Usually safe
Android SDK	~/Library/Android/sdk	Usually safe
Emulator system images	~/Library/Android/sdk/system-images	Usually safe
NDK versions	~/Library/Android/sdk/ndk	Usually safe
Android Virtual Devices	~/.android/avd	Review first

Gradle trims itself, slowly

Gradle deletes cache entries it hasn't used for 7 to 30 days, and wrapper versions no project has used for 30 days. The folder can still reach many gigabytes, and clearing it costs every project a full download of its dependencies on the next build.

Android projects' build folders often reach several gigabytes. They're Safe to clear, with one thing to know: release builds and the mapping files you need to read crash reports from them go too, so keep a copy of anything you shipped.

Maven's local repository: one catch

Maven downloads anything missing on the next build, but it also keeps artifacts you built and installed from your own projects. Those come back only when you build and install those projects again, which is why the whole repository is Usually safe.

Android Studio's own tools

Remove SDK packages, system images and NDK versions in Android Studio: choose Tools › SDK Manager, select Show Package Details where you need to see versions, clear the ones you no longer need, and click Apply. Delete virtual devices in Device Manager, from the menu next to each device.

Android Studio also keeps a caches folder for every version you've run, and offers to delete old ones when you first run a new major version. SDKMAN, Coursier and other Java version managers keep every version you install until you remove it with the same tool.

Code editors and AI coding tools

Editors keep caches, logs and extensions; AI coding tools add conversation history and, sometimes, a virtual machine of their own.

What	Where it lives	Level
VS Code, Cursor and Windsurf caches and logs	Cache folders in each app's Application Support folder	Safe
VS Code and Cursor extensions	~/.vscode/extensions, ~/.cursor/extensions	Review first
JetBrains IDE caches	~/Library/Caches/JetBrains	Usually safe
Zed's language servers	~/Library/Application Support/Zed/languages	Safe
Claude Code conversation history	~/.claude/projects	Review first
Claude Code's MCP logs	~/Library/Caches/claude-cli-nodejs	Safe
Codex session history	~/.codex/sessions	Review first
Claude's Cowork VM	vm_bundles, in Claude's Application Support folder	Usually safe

Editors built on VS Code

VS Code, Cursor and Windsurf keep web, code and graphics caches, downloaded extension packages and session logs next to your settings. They rebuild them as they run, and your settings and extensions live elsewhere. Quit the app before clearing them.

Extensions are a different matter: uninstall the ones you don't use from the Extensions view, with the Manage button next to each. Removing the whole extensions folder uninstalls all of them.

JetBrains IDEs

Each JetBrains IDE keeps a caches folder per version, holding indexes and Local History, its record of your recent edits. A new major version deletes folders of versions not updated in 180 days, and Help › Delete Leftover IDE Directories does it sooner. Clearing the current version's folder costs a full re-index and its Local History.

Claude Code, Codex and Claude's Cowork VM

Claude Code keeps a full transcript of every session and deletes transcripts older than its cleanup period, 30 days by default, keeping its auto memory. Its logs of MCP server traffic are another matter: they include full tool results and can grow to many gigabytes. They're Safe to clear.

Codex keeps every thread so you can resume it, and the folder grows with regular use. Claude's Cowork VM bundle often reaches 10 GB or more; remove it with Help › Troubleshooting › Delete Cowork VM Bundle and Restart in Claude, and it downloads again when you next use Cowork.

Test browsers and local AI models

Two kinds of download stay on a developer's Mac long after the project that needed them: browsers your tests drove, and models you tried.

What	Where it lives	Level
Playwright's browsers	~/Library/Caches/ms-playwright	Usually safe
Playwright MCP browser profiles	mcp- folders in the same place	Usually safe
Puppeteer's browsers	~/.cache/puppeteer	Usually safe
Cypress's test app	~/Library/Caches/Cypress	Usually safe
Ollama models	~/.ollama/models	Review first
LM Studio models	~/.lmstudio/models	Review first
Hugging Face cache	~/.cache/huggingface/hub	Review first
Chrome's Gemini Nano	OptGuideOnDeviceModel, in Chrome's Application Support folder	Usually safe

Browsers your tests download

Playwright, Puppeteer and Cypress each download their own browsers or test app, and Playwright's take a few hundred megabytes per browser. Playwright tracks which projects use each version and removes versions nothing needs. Selenium Manager removes drivers and browsers unused for 30 days.

Removing Playwright's MCP profiles signs the browser your AI tools drive out of every website. Remove the browsers themselves only if you've finished with the projects that test with them.

Local models: the largest single files

A local language model is often several gigabytes, and every one you've tried stays until you remove it. Remove them in the tool that downloaded them: LM Studio deletes from My Models.

Ollama stores models as shared layers, so remove them with Ollama's own tool, never file by file in Finder. How to delete Ollama models explains the options.

The Hugging Face cache keeps every revision of every model a library downloaded, and removes nothing by itself. Models that need a sign-in or a license acceptance download again only after you do that. Chrome's Gemini Nano is removed by turning off On-device AI in Chrome's Settings › AI Innovations.

How to free up disk space on a developer's Mac, in order

With so many places, order matters more than thoroughness. This sequence gets most of the space back with the least risk, and stops as soon as you have enough.

Before you start, commit and push the work you care about, and note which projects you're actively working on. Everything below is easier to judge with that list in front of you, and nothing in it touches your source code.

1. Quit Xcode, Docker Desktop, your editors and anything that builds or runs code.
2. Clear DerivedData and the build folders of finished projects.
3. Clear package managers' caches with their own cleanup.
4. Remove simulator runtimes and unavailable simulators in Xcode.
5. Remove unused containers, images and volumes in Docker Desktop or your container tool.
6. Remove node_modules, .venv and similar folders from projects you've finished.
7. Remove models, test browsers and toolchain versions you no longer use, each in its own tool.
8. Review virtual machines and archives last, one by one.

A worked example

Say a 512 GB Mac has 30 GB free, and Finder shows these at the top: 60 GB of simulator runtimes, 35 GB of DerivedData, Docker's disk at 40 GB of real use, 25 GB of node_modules across old projects, and 45 GB of local models.

DerivedData goes first, all 35 GB if you're not mid-build: Xcode rebuilds what you open. Then the runtimes for OS versions you no longer support, in Xcode's Components settings, say 40 of the 60 GB. That's 75 GB back, at the cost of a few slow builds and downloads you control.

Docker comes next: remove stopped containers and unused images in Docker Desktop. The old projects' node_modules follow. The models go last, one by one, keeping the ones you still use and any you made yourself. Free space has gone from 30 GB to well over 100 GB without touching anything that can't come back.

Old toolchains and version managers

nvm, pyenv, rbenv, rustup, SDKMAN, mise and asdf all keep every version you install. Each version is a full install, sometimes with global packages inside it. Remove old ones with the same manager, and keep whatever your default or a project's version file points to.

Extra Swift toolchains from swift.org or swiftly sit in ~/Library/Developer/Toolchains. Xcode's own Swift isn't affected by removing them, but older snapshots may not be available to download again.

Game engines keep old versions too: the post on Unity's and Unreal's folders covers old editors along with the engines' own caches.

Empty the Trash, then check

Moving folders to the Trash frees nothing until you empty it. Build and run your current projects first, then empty it. If you use Time Machine, local snapshots can hold the deleted data for a while; macOS removes them as they age or when space is needed.

What never to delete

Some developer folders look like obvious targets and aren't. Removing them loses work or breaks tools in ways that are slow to repair.

Don't delete	Why	Instead
Docker.raw or OrbStack's data.img	Every image, container and volume is inside	Clean up in Docker Desktop or OrbStack
~/Library/Developer as a whole	Archives and device support files can't all be made again	Clear DerivedData and caches inside it
Archives of builds you shipped	Their dSYMs make crash reports readable	Delete test archives only, in Organizer
A virtual machine you haven't checked	Its contents exist nowhere else	Copy out what you need, then delete it in its app
Folders inside Homebrew's Cellar	Homebrew loses track of what's installed	Uninstall with Homebrew
Ollama's blob files one by one	Models share layers	Remove whole models with Ollama
~/.claude/projects	Holds Claude's auto memory for each project	Let Claude Code's own cleanup period handle it

Why not run a cleanup script from the web?

Scripts that promise to clear every developer cache at once skip the Trash, run with your tools still open, and often include folders from the table above. A cleanup that can't be undone is the wrong kind for a Mac you work on.

Fake cleanup guides are also a known way to get malware onto a Mac. The safer route is slower by minutes: each tool's own settings or cleanup, and Finder for the folders that rebuild themselves.

How the app does it

Wombit shows what's using your storage and explains every item in plain language, from a catalog written and checked by hand with sources. Developer files, from Xcode and simulators to Docker, package caches, build folders and AI models, are explained like everything else, and listed in Cleanup by level.

Select a folder on the map to see what it is, what removing it costs and its level, with a Move to Trash or Clean Up button. Only Safe items start checked and count in the headline number. Usually safe and Review first items, such as node_modules, virtual machines and models, wait for your choice.

• ~/Library/Developer/Xcode/DerivedData

  Xcode DerivedData

  Build products, indexes and logs Xcode keeps for every project you've built.

  Safe · Moves it to the Trash

• ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

  Docker Desktop disk image (Docker.raw)

  The virtual disk where Docker Desktop keeps all your images, containers, volumes and build cache.

  Usually safe · Runs docker --context desktop-linux builder prune --force

• ~/**/node_modules

  node_modules

  A JavaScript project's installed dependencies, which its package manager can install again.

  Usually safe · Moves it to the Trash

• ~/**/target

  Rust target folders

  Build output that Cargo creates in each Rust project, including compiled code, binaries and documentation.

  Safe · Moves it to the Trash

• ~/.gradle/caches

  Gradle caches

  Dependencies, build cache entries and other files that Gradle keeps for all the Java, Kotlin and Android projects you build.

  Safe · Moves it to the Trash

• ~/.ollama/models

  Ollama models

  Language models you've pulled or created with Ollama, stored as shared layers.

  Review first · Explained only: never removed

Tools with their own cleanup command run that command instead of having their files deleted, after the review sheet. What a command removes can't be put back, and the sheet says so. Hard links and APFS clones, such as pnpm's and Bun's, count once.

Simulator runtimes, Ollama's models and other items a tool manages are explained, with that tool's own steps, rather than moved. Everything else goes to the Trash, where you can put it back, and every cleanup is logged.

Seeing all of this explained is free. 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.