Below is each of those places: where it lives, how to measure it, what’s safe to delete and the tool’s own cleanup command. First, though, a short read-only script that measures all of them at once, so you clean what’s big on your Mac rather than what a generic guide lists.

The checklist

“Comes back” means the tool recreates it when it next needs it, at the cost of time and bandwidth. “No” means deleting it loses something for good.

Measure first with one read-only script

Save this as dev-disk-audit.sh:

#!/bin/bash
# dev-disk-audit.sh: size the usual developer storage on a Mac, largest first.
# Read-only: it sizes things with du, find and test, and changes nothing.
#
#   bash dev-disk-audit.sh [projects folder]     (zsh dev-disk-audit.sh works too)
#
# The projects folder (default: your home folder) is searched for node_modules
# and Cargo target folders. Hidden folders, ~/Library and ~/go/pkg are skipped
# there. Sizes are space allocated on disk, in decimal GB and MB like Finder.

root=${1:-$HOME}
L=$HOME/Library

# Print "KB<tab>label<tab>path" if the path exists; stay silent if it doesn't.
measure() {
  if [ -e "$2" ]; then
    printf '%s\t%s\t%s\n' "$(du -sk "$2" 2>/dev/null | cut -f1)" "$1" "$2"
  fi
}

# One "KB<tab>path" line per node_modules folder, and per target folder that
# Cargo has tagged with CACHEDIR.TAG (other tools' target folders are left out).
projects=$(find "$root" -mindepth 1 \
  \( -name '.*' -o -path "$L" -o -path "$HOME/go/pkg" \) -prune -o \
  -type d -name node_modules -prune -exec du -sk {} + -o \
  -type d -name target -prune -exec test -f {}/CACHEDIR.TAG \; -exec du -sk {} + \
  2>/dev/null)

# Print size lines as a table: "KB<tab>label<tab>path" or "KB<tab>path".
table='function size(k) { b = k * 1024
    return b >= 1e9 ? sprintf("%7.1f GB", b / 1e9) : sprintf("%7.1f MB", b / 1e6) }
  function short(p) { return index(p, home) == 1 ? "~" substr(p, length(home) + 1) : p }
  NF < 2 { next }
  { sum += $1
    if (NF == 2) printf "%s  %s\n", size($1), short($2)
    else printf "%s  %-28s %s\n", size($1), $2, short($3) }
  END { if (total) printf "%s  Total measured\n", size(sum) }'

printf 'Developer storage, largest first\n\n'
{
  measure "Xcode DerivedData"          "$L/Developer/Xcode/DerivedData"
  measure "Xcode Archives"             "$L/Developer/Xcode/Archives"
  measure "iOS device support"         "$L/Developer/Xcode/iOS DeviceSupport"
  measure "watchOS device support"     "$L/Developer/Xcode/watchOS DeviceSupport"
  measure "Simulator devices"          "$L/Developer/CoreSimulator/Devices"
  measure "Simulator caches"           "$L/Developer/CoreSimulator/Caches"
  measure "Docker Desktop disk image"  "$L/Containers/com.docker.docker/Data/vms/0/data/Docker.raw"
  measure "OrbStack disk image"        "$L/Group Containers/HUAQ24HBR6.dev.orbstack/data/data.img"
  measure "OrbStack disk image"        "$L/Group Containers/HUAQ24HBR6.dev.orbstack/data/data.img.raw"
  measure "npm cache"                  "$HOME/.npm"
  measure "Yarn 1 cache"               "$L/Caches/Yarn"
  measure "Yarn 2+ global cache"       "$HOME/.yarn/berry/cache"
  measure "pnpm store"                 "$L/pnpm/store"
  measure "Cargo registry"             "$HOME/.cargo/registry"
  measure "Cargo git dependencies"     "$HOME/.cargo/git"
  measure "Rust toolchains"            "$HOME/.rustup/toolchains"
  measure "Gradle caches"              "$HOME/.gradle/caches"
  measure "Gradle wrapper downloads"   "$HOME/.gradle/wrapper/dists"
  measure "Android system images"      "$L/Android/sdk/system-images"
  measure "Android emulators (AVDs)"   "$HOME/.android/avd"
  measure "Homebrew downloads"         "$L/Caches/Homebrew"
  measure "Homebrew packages"          "/opt/homebrew/Cellar"
  measure "Homebrew packages"          "/usr/local/Cellar"
  measure "CocoaPods cache"            "$L/Caches/CocoaPods"
  measure "pip cache"                  "$L/Caches/pip"
  measure "uv cache"                   "$HOME/.cache/uv"
  measure "Go module cache"            "$HOME/go/pkg/mod"
  measure "Go build cache"             "$L/Caches/go-build"
  printf '%s\n' "$projects" | awk -F'\t' -v r="$root" '
    $2 ~ /\/node_modules$/ { n += $1; nc++ }
    $2 ~ /\/target$/       { t += $1; tc++ }
    END { if (nc) printf "%.0f\tnode_modules folders (%d)\t%s\n", n, nc, r
          if (tc) printf "%.0f\tRust target folders (%d)\t%s\n", t, tc, r }'
} | sort -rn | awk -F'\t' -v home="$HOME" -v total=1 "$table"

if [ -n "$projects" ]; then
  printf '\nLargest project folders\n\n'
  printf '%s\n' "$projects" | sort -rn | head -n 10 |
    awk -F'\t' -v home="$HOME" -v total=0 "$table"
fi

Then run it with the folder that holds your projects:

bash dev-disk-audit.sh ~/code

It runs under the zsh and bash 3.2 that come with macOS, installs nothing and only reads: du, find and test look at your files, and sort and awk print the table. Paths that don’t exist are skipped. Without a folder argument it searches your whole home folder, which is slower, and macOS may ask before Terminal reads Desktop, Documents or Downloads.

Some choices in it are deliberate:

• Allocated space, not apparent size. Docker’s and OrbStack’s disk images are sparse files: ls -l shows what they could grow to, du shows what they occupy.
• A target folder counts only if Cargo tagged it with CACHEDIR.TAG, a cross-tool convention meaning “everything in here can be regenerated”. Maven builds into target folders too, and those stay out of the Rust total.
• OrbStack’s disk image is sized as a file, not by listing its folder. On macOS 15 and later, reading inside another app’s group container can trigger a permission prompt.

Two caveats. du counts a hard-linked file once per run but counts every APFS clone in full, and on macOS pnpm clones files from its store into node_modules by default, so read the total as an upper bound. And simulator runtimes live outside your home folder; the next section shows how to size them.

Xcode

DerivedData

~/Library/Developer/Xcode/DerivedData holds build products, intermediate files and logs, mostly one folder per project. Deleting a project’s folder costs a full rebuild and nothing else. Quit Xcode first. If you’ve moved it, Xcode > Settings > Locations shows where.

Archives

Product > Archive saves to ~/Library/Developer/Xcode/Archives, and nothing recreates an archive once it’s gone. Each one holds your app’s binaries and their dSYM files, and Apple’s documentation says to keep the archive for every build you distribute, or you may not be able to diagnose its crash reports. Review them in Window > Organizer, delete archives for builds that never shipped, and move the rest to another disk if you need the space.

Device support

When you connect an iPhone, iPad or Apple Watch, Xcode copies its system symbols into ~/Library/Developer/Xcode/iOS DeviceSupport (or watchOS DeviceSupport, and so on) so it can symbolicate system frameworks in crash reports. Each OS release and device model gets its own set.

Sets for versions you no longer test against are reasonable to delete. Xcode copies them again when a device on that version connects, and xcodebuild -prepareDeviceSupport can fetch them on request. Keep any you need for symbolicating your users’ crash reports.

Simulators and runtimes

Each simulator keeps its installed apps and data in ~/Library/Developer/CoreSimulator/Devices, and deleting a simulator deletes everything in it. List first:

xcrun simctl list devices
xcrun simctl delete unavailable

The second command removes only the simulators your current Xcode SDK doesn’t support.

Runtimes, the system images that simulators boot, are stored outside your home folder, so ask simctl about them:

xcrun simctl runtime list
xcrun simctl runtime delete <identifier>

list ends with their total size. Xcode > Settings > Components does the same job (click the info button next to a runtime, then Delete) and can download older runtimes again. Run xcrun simctl runtime on its own to see what your Xcode version supports; current versions can preview a cleanup with delete --notUsedSinceDays <days> --dry-run.

Docker Desktop and OrbStack

Start with Docker’s own accounting:

docker system df
docker system df -v

It splits usage into images, containers, local volumes and build cache, with a RECLAIMABLE column for space nothing is using; -v lists every item. Then prune, narrowest first: docker builder prune removes only the build cache, docker image prune -a removes every image no container uses, and docker system prune removes stopped containers, unused networks, dangling images and the build cache. Each asks for confirmation unless you add -f:

docker builder prune
docker image prune -a
docker system prune

Images and build cache come back when you pull or build again. Stopped containers don’t, and neither does anything you changed inside them. Volumes are the real risk: they hold databases and other container state, and removing them is permanent. The commands above leave volumes alone, but docker system prune --volumes adds anonymous volumes, and docker volume prune -a also removes named volumes that no container is using. Check docker volume ls first.

Docker Desktop’s disk image

Docker Desktop keeps all of this in one sparse file, Docker.raw, in ~/Library/Containers/com.docker.docker/Data/vms/0/data. Settings > Resources > Advanced shows its location, its maximum size and what it actually uses, while some tools report only the maximum. In Terminal:

ls -klsh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

The first column is the space it occupies; the size column further along is the maximum.

Does it shrink? Docker’s current documentation says deleting images frees space on your Mac, though it can take a few minutes to show, while deleting files inside a running container doesn’t free it automatically. To reclaim space on demand, Docker documents this command:

docker run --privileged --pid=host docker/desktop-reclaim-space

Don’t move or delete Docker.raw in Finder, because Docker Desktop can lose track of it; change its location in Settings instead. And lowering the Disk image size slider deletes the current image, with every container and image inside.

OrbStack

OrbStack keeps images, containers and Linux machines in a sparse disk image (data.img or data.img.raw) in ~/Library/Group Containers/HUAQ24HBR6.dev.orbstack/data. Its documentation explains that the file can show an apparent size of 8 TB while using only what you store, and that it shrinks automatically when you delete data. du -h on the file, or “size on disk” in Finder’s Get Info window, gives the real figure.

OrbStack creates a Docker context called orbstack, so the commands above work against it. If you run more than one engine, docker context ls shows which one your commands reach, and docker --context orbstack system df asks OrbStack directly.

node_modules and package caches

Every JavaScript project carries its own node_modules. To list them by size:

find ~/code -type d -name node_modules -prune -exec du -sh {} + | sort -h

-prune stops find from descending into each one, so nested node_modules aren’t counted twice. Deleting a project’s node_modules is safe while its package.json and lockfile are intact: npm ci reinstalls exactly what package-lock.json specifies, and pnpm install or yarn install rebuild it for those tools.

The shared caches:

• npm keeps its cache in ~/.npm (npm config get cache confirms it). npm’s documentation calls the cache self-healing and says clearing it should only be needed to reclaim disk space. npm cache verify garbage-collects data that isn’t needed; npm cache clean --force empties it.
• Yarn 1: yarn cache dir prints the location, under ~/Library/Caches/Yarn on a Mac, and yarn cache clean empties it. Yarn 2 and later keep a global cache in ~/.yarn/berry/cache by default, and yarn cache clean --mirror clears it.
• pnpm keeps one content-addressable store, ~/Library/pnpm/store on macOS (pnpm store path prints it). pnpm store prune removes packages no project references. pnpm’s documentation calls that harmless but suggests not running it too often, since switching to an older branch may need those packages again.

Rust

Every Cargo workspace builds into a target folder at its root. cargo clean deletes it, and the next build compiles everything again; in current Cargo, cargo clean --dry-run shows what would go. To find every Rust build folder without catching other tools’ target folders, look for Cargo’s tag:

find ~/code -type d -name target -prune -exec test -f {}/CACHEDIR.TAG \; -exec du -sh {} + | sort -h

Cargo’s shared downloads live in ~/.cargo/registry (the index, downloaded .crate archives in cache and unpacked sources in src) and ~/.cargo/git. The Cargo Book says you can remove any part of this cache and Cargo will restore what a build needs. Since Rust 1.88, Cargo also cleans it on its own, removing files downloaded from the network after three months without use and files from your own system after one month. Leave ~/.cargo/bin alone: it holds the tools you installed with cargo install.

Installed toolchains live in ~/.rustup/toolchains. rustup toolchain list shows them, and rustup toolchain uninstall <name> removes old nightlies or pinned versions you no longer build with.

Gradle and Android

Gradle’s user home, ~/.gradle, keeps downloaded dependencies and build caches in caches and wrapper distributions in wrapper/dists. Gradle prunes these itself: by default it checks every 24 hours and removes entries unused for 30 days (downloaded resources, released wrapper distributions) or 7 days (created resources, the build cache).

In a project, ./gradlew clean deletes the build directory. To clear the shared cache entirely, run ./gradlew --stop to stop that Gradle version’s daemons, then delete ~/.gradle/caches. The next build downloads its dependencies again, and offline builds fail until it has.

Android emulators use two kinds of storage:

• System images live in the SDK, by default ~/Library/Android/sdk/system-images. In Android Studio’s SDK Manager (Tools > SDK Manager), which also shows the SDK’s real location, clear the checkbox next to an image you no longer use and click Apply. You can download it again later.
• Each emulator’s own data, its installed apps and settings, lives in ~/.android/avd. In Device Manager, an emulator’s ⋮ menu has Wipe Data, which resets it to new, and Delete, which removes it. Both are permanent.

Homebrew

brew --cache prints the download cache, ~/Library/Caches/Homebrew by default. brew cleanup removes old versions of installed formulae, stale lock files and downloads older than 120 days (HOMEBREW_CLEANUP_MAX_AGE_DAYS changes that). Preview it first with -n, which only shows what would be removed. --prune=all removes all cached files, whatever their age, and brew autoremove -n lists dependencies nothing needs any more:

brew cleanup -n
brew cleanup
brew cleanup --prune=all
brew autoremove -n

Unless HOMEBREW_NO_INSTALL_CLEANUP is set, Homebrew already cleans up the packages involved after brew install, upgrade and reinstall, and everything every 30 days. brew autoremove without -n uninstalls formulae that were only installed as dependencies and are no longer needed. Installed packages live in $(brew --prefix)/Cellar; remove them with brew uninstall, not by deleting folders.

Other caches worth checking

• CocoaPods: ~/Library/Caches/CocoaPods. pod cache list shows what’s there, pod cache clean --all empties it, and the next pod install downloads what it needs.
• pip: pip cache dir (~/Library/Caches/pip on macOS), pip cache info for its size and pip cache purge to empty it. pip’s documentation says the cache layout can change between versions, so use these commands rather than deleting files by hand.
• uv: uv cache dir (~/.cache/uv), uv cache prune for unused entries and uv cache clean for everything.
• Go: the module cache is go env GOMODCACHE (~/go/pkg/mod by default) and the build cache is go env GOCACHE (~/Library/Caches/go-build on a Mac). Go creates module cache folders read-only, so rm -r fails part-way; use go clean -modcache. Go trims the build cache itself, and go clean -cache empties it.

Before you delete anything

Moving something to the Trash in Finder frees its space only when you empty the Trash, while rm -rf and each tool’s own prune and clean commands are permanent. Archives, Docker volumes and stopped containers, simulator and emulator data, and ~/.cargo/bin don’t come back. Everything else here rebuilds or downloads again, at the cost of time and bandwidth, so the caches for this week’s projects are usually worth keeping.

Disk Whisk, the Mac app behind this blog, shows the same kind of breakdown without a terminal, including what OrbStack, Docker Desktop, Colima and Lima hold, and clears containers through each engine’s own tools rather than by deleting its disk image.

This guide shows where each app keeps its big generated files and how to remove them with the app’s own commands. Menu names match Final Cut Pro 12.4, Logic Pro 12.3, GarageBand 10.4.14, Adobe’s current help pages for Premiere, After Effects and Lightroom Classic, and Photos on macOS Tahoe 26.

Three kinds of space

Before you delete anything, ask what it will cost to get it back. Everything here falls into one of three groups.

• Rebuilds itself. Safe to remove. The app recreates it from your originals, so the cost is time: rendering, re-caching and slower playback for a while.
• Re-downloadable. Safe to remove. It comes back from Apple or iCloud, so the cost is bandwidth and waiting.
• Losing this loses work. Your footage, recordings, photos, projects, catalogs and libraries. Never delete these to make room. If you need the space, move or archive them with the app’s own tools.

Use the app, not the Finder

Several of these files sit inside something that looks like a single file in the Finder: a Final Cut Pro library, your Photos library, Logic’s Logic Pro Library.bundle. These are packages, folders that the Finder shows as one item. You can open one with Show Package Contents and delete things inside it. Don’t.

Each app keeps its own record of what’s inside. A Final Cut Pro library tracks your media files, your edits and their metadata, and Adobe’s media cache has a database that links to every cached file. Delete files behind the app’s back and that record no longer matches what’s on disk. Apple’s Photos guide is direct about it: to avoid deleting or corrupting a photo library, don’t access or change its contents in the Finder.

An app’s own command knows which files are safe to remove and updates its records as it goes. Every step below uses one.

Final Cut Pro

The first time you open Final Cut Pro, it creates a library in your Movies folder. Media you import into a library is stored inside it (Apple calls this managed media), and by default so are the files Final Cut Pro generates: render files, optimized media and proxy media.

Delete render, optimized and proxy files

1. Select the library in the Libraries sidebar. To see how much space generated files use, choose File ▸ Library Properties (Control-Command-J) and scroll to Cache.
2. Choose File ▸ Delete Generated Library Files.
3. Select Delete Render Files, then choose unused or all render files. Select Delete Optimized Media and Delete Proxy Media too if you want those gone.
4. Click OK.

There are matching commands for events, projects and clips (Delete Generated Event Files and so on) if you only want to clear part of a library. Your original media isn’t touched. Final Cut Pro regenerates render files the next time you work on the project, but you have to recreate optimized and proxy media yourself. The library and clip versions of the command also delete generated files stored outside the library.

Unused render files build up as you change timelines and when you update Final Cut Pro, macOS or plug-ins, so clearing them now and then is a cheap habit.

Keep the cache on another drive

In Library Properties, click Modify Settings. The Cache menu sets where render files, analysis files, thumbnails and audio waveforms go. Choose a folder on another drive, and Final Cut Pro asks whether to move your existing render files there.

What not to delete

The library itself holds your edits and any managed media. If you imported media as external files, the library links to them where they are, and those folders are your originals. Both are in the third group.

Logic Pro and GarageBand

Logic’s sound packs

In Logic Pro 12, all the sound content lives in one file, Logic Pro Library.bundle, in your Music folder. Apple lists plug-in settings, channel strip settings, patches, Apple Loops and samples among its contents. The sound packs in it are re-downloadable.

1. Choose Logic Pro ▸ Sound Library.
2. Click Manage Packs in the upper-left corner. The total space used by installed packs is shown at the top, and each pack’s size is in the list.
3. Click Delete next to any pack you don’t use.

If a task needs a pack you’ve removed, Logic asks whether to download it. Don’t trash the whole bundle to save space: it holds more than the packs you downloaded.

Move the Sound Library instead

To keep every sound, move the library to another drive. In the Finder, drag Logic Pro Library.bundle (the whole file, never its contents) to the other drive. This is the one Finder step in this guide, and it’s Apple’s own method. Then choose Logic Pro ▸ Settings ▸ General, and under Sound Library click Locate and choose the bundle in its new place. Once the copy is on the other drive, you can delete the original from your Music folder.

If you upgraded to Logic Pro 12, Apple says the upgrade cloned your old library into the new bundle without using extra space on your Mac, and that you don’t have to delete the old sound library files to save space. Keep them if you still use an older version of Logic, which can’t read the new bundle.

GarageBand

GarageBand can fetch its sounds with GarageBand ▸ Sound Library ▸ Download All Available Sounds and repair them with Reinstall Sound Library, but Apple’s guide doesn’t describe a way to delete sounds from inside the app. For that, choose System Settings ▸ General ▸ Storage, open Music Creation, select an item and click Delete. That category lists GarageBand, Logic and MainStage content together, so check what each item is first.

Your Logic projects, GarageBand songs and anything you recorded are in the third group.

Premiere and After Effects

Adobe dropped “Pro” from Premiere’s name with version 26 in January 2026, and its menus now say Premiere.

Premiere’s media cache

When you import footage, Premiere writes cache files, such as conformed audio (.cfa) and peak (.pek) files, to speed up playback. By default they’re in ~/Library/Application Support/Adobe/Common, and the cache database is shared with After Effects and Media Encoder.

1. Choose Premiere ▸ Settings ▸ Media Cache.
2. Click Delete next to Remove Media Cache Files.
3. Choose Delete unused media cache files (files for source media Premiere can no longer find) or Delete all media cache files from the system. For the second, Adobe suggests restarting Premiere and doing it before you open a project.

Deleted cache files are recreated when the media needs them, so expect a slower first open on a big project. Under Media Cache Management in the same settings, you can have Premiere delete cache files older than a set number of days (90 by default) or once the cache passes a share of the drive (10% by default). Automatic deletion is off until you choose one.

Premiere’s preview files and proxies

Rendering a timeline creates preview files. With the Timeline panel active, choose Sequence ▸ Delete Render Files, or Sequence ▸ Delete Work Area Render Files for part of it. File ▸ Project Settings ▸ Scratch Disks shows where they’re stored. To get smooth playback back, re-render with Sequence ▸ Render In to Out.

Premiere doesn’t delete proxies for you. Right-click the clips in the Project panel and choose Proxy ▸ Detach Proxy. Adobe notes this leaves the files on disk, because another project might use them. Unless you chose a location, they’re in a folder named Proxies next to your original clips. Delete only that folder: your camera originals sit right beside it.

After Effects’ disk cache

After Effects saves rendered frames to a disk cache that it keeps between sessions. By default the cache can grow to 10% of the drive, up to 100 GB.

• Choose After Effects ▸ Settings ▸ Disk and click Empty Disk Cache, or choose Edit ▸ Purge ▸ All Memory & Disk Cache.
• In the same panel, Clean Database & Cache removes media cache files for footage whose source files are no longer available. Connect the drives with your current footage first, or After Effects treats that footage as missing and clears its cache too.
• Empty All Caches, under After Effects ▸ Settings ▸ Startup & Repair, clears the disk cache, media cache and database cache together.

Lightroom Classic

By default, Lightroom Classic keeps your catalog, Lightroom Catalog.lrcat, in ~/Pictures/Lightroom, with two large files beside it: Lightroom Catalog Previews.lrdata and Lightroom Catalog Smart Previews.lrdata. The catalog links to your original photos, which stay wherever you imported them. The catalog and the originals are in the third group. The previews are not.

Standard and 1:1 previews

Choose Library ▸ Previews ▸ Discard Standard and 1:1 Previews. Lightroom Classic recreates them when it needs them, so browsing is slower at first. The 1:1 previews are the big ones: in Lightroom Classic ▸ Catalog Settings, set Automatically Discard 1:1 Previews so they don’t pile up. Recent versions also let you cap the preview cache size there.

One catch: Adobe warns that previews of photos you’ve archived are lost too. Previews are drawn from the originals, so do this while your photo drives are connected.

Smart Previews

Smart Previews are smaller, lossy DNG stand-ins that let you edit while your originals are offline. Remove them with Library ▸ Previews ▸ Discard Smart Previews, and make them again with Library ▸ Previews ▸ Build Smart Previews.

Only discard them while your originals are connected. If the status under the Histogram says Smart Preview rather than Original + Smart Preview, Lightroom Classic can’t find the original, and the Smart Preview may be the only version you can work with.

Camera Raw cache

Choose Lightroom Classic ▸ Preferences, find Camera Raw Cache Settings and click Purge Cache. Adobe sets this cache to 5 GB by default. Only the Develop module uses it, and it fills again as you edit.

Apple Photos

Your Photos library is a package in your Pictures folder. If you use iCloud Photos, Photos can make room for you: choose Photos ▸ Settings, click iCloud and select Optimize Mac Storage. Photos then keeps smaller versions on your Mac when storage space is limited, with the full-size originals in iCloud, ready to download again. To bring them all back, select Download Originals to this Mac. iCloud Photos stores your whole library in iCloud, so you need iCloud storage for all of it.

If you don’t use iCloud Photos, the library on your Mac may be your only copy. Back it up, and leave it in the third group.

The short version

Clear what rebuilds itself with each app’s own command. Delete what’s re-downloadable when you can afford to fetch it again. Move or archive your libraries, catalogs, projects and originals, and never delete them to make room.

If you want to see where the space is going first, Disk Whisk shows what’s filling your Mac and explains each item, and anything you approve goes to the Trash.

How we put this together. We haven’t run these apps side by side on one Mac. This comparison is based on each tool’s own documentation, store listings and published prices as of October 2026, linked so you can check them. Prices are US list prices, and some vary by region. We make Disk Whisk, one of the apps below, so weigh that section accordingly.

Start with Apple’s Storage settings

Every Mac already has a free storage tool. Choose Apple menu → System Settings → General → Storage. Apple’s guide describes a chart of what each category uses, followed by three recommendations:

• Store in iCloud keeps Desktop and Documents files, photos and messages in iCloud, and leaves only recently opened files on the Mac when space is needed.
• Optimize Storage removes Apple TV movies and shows you’ve watched, and keeps only recent email attachments.
• Empty Trash automatically erases items that have been in the Trash for more than 30 days.

Below that, categories such as Applications, Documents, iOS Files and Trash have an Info button. Open one, select a file and click Delete, or click Show in Finder to look first. Apple’s guide doesn’t say whether that Delete goes through the Trash, so read the confirmation before you click. System Data is managed by macOS, and you can’t clear it from here.

• Suits: everyone, as a first look.
• Explains items: by category, not folder by folder.
• Price: free, built in.
• Needs: Apple documents this layout for macOS 13 and later.

CleanMyMac

CleanMyMac is MacPaw’s all-in-one Mac maintenance app. Alongside cleanup it covers uninstalling apps, malware scanning, performance tools, duplicate and similar files, cloud storage cleanup and Space Lens, a visual map of your storage. If you want one app for general Mac upkeep and not only disk space, it’s built for that.

• Removes: system junk such as caches, logs and language files, plus large and old files, and apps with their leftovers. Its System Junk scan pre-selects items by rule: for example, all Xcode junk except module caches and archives, and user caches except the Gradle cache. MacPaw’s guide for Large & Old Files says those files are deleted permanently, bypassing the Trash. Its other guides don’t say.
• Explains items: results are grouped by type, and a Smart Insights button gives more detail on an unfamiliar item on macOS Tahoe 26 or later with Apple Intelligence turned on.
• Price: a subscription or a one-time purchase, with a 7-day free trial and a 30-day money-back guarantee. MacPaw’s US site lists plans from $3.33 a month, billed yearly. The Mac App Store listing is a free download with yearly access at $39.99 and monthly at $9.99. Prices vary by plan, region and number of Macs (see the store).
• Needs: macOS 11 or later.

DaisyDisk

DaisyDisk, from Software Ambience, draws your disk as an interactive sunburst: rings of folders sized by what they hold. You click into the biggest segment, then the next, until you find what’s using the space. It can also reveal hidden space when it scans as administrator, purge purgeable space, and scan cloud storage such as Dropbox and Google Drive. It suits anyone who thinks in pictures.

• Removes: anything you drag into its Collector, once you click Delete. DaisyDisk deletes permanently by design, so the space comes back at once: it doesn’t use the Trash, and you get 5 seconds to cancel.
• Explains items: it shows sizes and lets you preview files; deciding what’s safe is up to you.
• Price: $9.99 one-time for up to 5 personal Macs, with minor updates included. The free trial scans and browses the map but can’t delete. The Mac App Store edition is also $9.99, has no trial and can’t scan as administrator.
• Needs: macOS 10.13 or later for the direct download, or macOS 12 or later from the App Store. Apple silicon and Intel.

OmniDiskSweeper

The Omni Group’s OmniDiskSweeper is the plainest tool here: a list of your files and folders, largest first, that you drill down through. Omni made it freeware in 2009 and still updates it. It suits anyone who wants a free, no-frills list.

• Removes: whatever you select, by moving it to the Trash.
• Explains items: no. It shows names and sizes.
• Price: free.
• Needs: Omni lists version 1.16 as supported on macOS 11 through macOS 26, with older versions for older systems.

GrandPerspective

GrandPerspective, by Erwin Bonsma, draws your disk as a tree map: each file is a rectangle with an area proportional to its size, so large files stand out at a glance. It’s open source under the GPL. If you want a visual map without paying, this is the one to try.

• Removes: files or folders straight from the map, if you turn deletion on in Preferences (off, single files or whole folders, with optional confirmation). Deleted items go to the Trash.
• Explains items: no. It shows sizes.
• Price: free from SourceForge, or $2.99 on the Mac App Store, which adds automatic updates.
• Needs: macOS 14 or later, Apple silicon or Intel. Version 3.8.1 came out in September 2026.

DevCleaner for Xcode

DevCleaner, by Konrad Kołakowski, does one job for anyone who builds with Xcode: it finds the caches Xcode leaves behind, which can run to tens of gigabytes. It’s open source under GPL-3.0.

• Removes: device support files, old archives, DerivedData, documentation caches, old simulator and device logs, and old documentation downloads. Its source code deletes items directly rather than using the Trash, and a dry-run mode lets you rehearse first.
• Explains items: it groups files by Xcode category, and its README says what each category holds. The author notes it relies on Xcode’s internal folder layout, so a new Xcode can change what it finds.
• Price: free on the Mac App Store, with optional tips from $1.99.
• Needs: macOS 14 or later. The latest version, 2.8.0, came out in November 2025.

Mole

Mole is an open-source command-line Mac cleaner by the developer Tw93, licensed under GPL-3.0. You install it with Homebrew (brew install mole) and run mo. Its commands include mo clean for caches, logs and leftovers, mo uninstall for apps and their related files, mo analyze for a disk explorer in Terminal, and mo purge for project build folders such as node_modules, target and dist. If you’re at home in Terminal, it covers a lot in one free tool.

• Removes: it depends on the command. mo uninstall and mo analyze move items to the Trash after you confirm; mo clean, mo purge and mo installer delete permanently. mo clean also empties your Trash by default, unless you protect it with mo clean --whitelist. clean, uninstall, purge and installer all take --dry-run to preview first, and mo purge leaves anything with activity in the last 7 days unselected.
• Explains items: it groups results by category and gives a reason when it skips something.
• Price: the command-line tool is free. The same developer sells a separate native app, Mole for Mac, at $19 one-time for 2 Macs. Scanning in it is free, and each paid tool works twice before you need a license.
• Needs: macOS 12 or later for the command-line tool, Apple silicon or Intel. The Mac app needs macOS 14.

Disk Whisk

Disk Whisk is our app. It explains what’s filling a Mac, including developer storage that disk maps show only as large folders: OrbStack, Docker Desktop, Colima and Lima, virtual machines, build folders and AI models. It’s in public beta.

• Removes: only what you approve. Scans are read-only: you approve a plan, each item is checked again just before it moves, and approved items go to the Trash with a receipt you can restore from in History. A few steps are permanent and say so before they run: container images and stopped virtual machines are removed through each tool itself, and Empty Trash deletes for good.
• Explains items: yes. Each item says why it’s there and what happens if it goes, and carries one of three labels: Safe to remove, Review first or Protected.
• Price: free to scan, explore, read every explanation and plan a cleanup. Pro runs cleanups and adds Compress (macOS’s built-in file compression), Storage Story and Maintain. Pro is $20 one-time for the first 500 licenses, then $40, or $20 a year, or $3 a month. Every plan covers 2 Macs. There’s a 7-day Pro trial with no card, and a 30-day refund on one-time and yearly plans (license policy).
• Needs: macOS 14 or later, Apple silicon or Intel.

Where others fit better: Disk Whisk covers storage only, so for malware scanning, app uninstalling and performance tools, CleanMyMac does more. If a visual map is the main thing you want, DaisyDisk is built around one, and GrandPerspective and OmniDiskSweeper do the looking for free. On a Mac older than macOS 14, Disk Whisk won’t run.

Side by side

Which one should you use?

You want space back today without installing anything

Use Storage settings, then Finder. Turn on the recommendations that suit you, open the largest categories, and empty the Trash when you’re done.

You want to see where the space went

DaisyDisk, if $9.99 is fine and you like a map. GrandPerspective, if you’d rather not pay and you’re on macOS 14 or later. OmniDiskSweeper, if you want a free list that moves things to the Trash.

Xcode is filling your disk

DevCleaner. It’s free and focused, and its dry-run mode lets you rehearse a cleanup first.

You live in Terminal

Mole’s command-line tool. Run --dry-run first, and decide whether you want mo clean to empty your Trash.

You want one app for general Mac upkeep

CleanMyMac. It’s the only option here with malware scanning, alongside cleanup, app uninstalling and performance tools.

Containers, VMs and build folders are the problem

Disk Whisk, if you want each item explained and cleanups that go to the Trash first. If you prefer free tools, Mole’s mo purge handles build folders, and Docker’s own commands handle Docker (see below).

You want to be able to undo

Pick a tool that uses the Trash: OmniDiskSweeper, GrandPerspective, Disk Whisk, or Mole’s uninstall and analyze. DaisyDisk and DevCleaner delete directly, and DaisyDisk does so on purpose so the space comes back at once.

You’re on an older Mac

On macOS 13 or earlier, look at DaisyDisk (10.13 or later from its own site), CleanMyMac and OmniDiskSweeper (macOS 11 or later) and Mole’s command-line tool (macOS 12 or later). GrandPerspective, DevCleaner and Disk Whisk need macOS 14.

When you don’t need any of these

If this is a one-off, the free route is usually enough:

• Follow the Storage recommendations and open the biggest categories. Old iOS backups, apps you no longer use and the Trash are common wins.
• Sort folders by size in Finder. In List view, choose View → Show View Options and turn on Calculate all sizes, then sort by Size.
• Leave caches alone unless they’re huge. Apple says macOS already clears caches and logs that are safe to delete when space is needed, and apps rebuild their caches as you use them, so clearing them by hand buys less than it seems.
• Use Docker’s own tools for Docker. docker system df shows what images, containers and build cache use. docker system prune removes unused containers and networks, dangling images and build cache after asking, and leaves volumes alone unless you add --volumes.
• Empty the Trash. Moving files to the Trash doesn’t free any space until you empty it, whichever tool moved them there.

We make Disk Whisk, and we’d rather you pick the tool that fits your Mac than the one we sell.

What Apple counts as System Data

Apple’s Storage settings guide puts System Data in a group with macOS and Other Users & Shared: categories that only show how much space they use. There’s no info button and no Delete. In Apple’s words, “You can’t manage the contents of this category.” The guide adds that macOS manages the contents, and that the size varies with the current state of your Mac. The wording is the same in the guides for macOS Sequoia 15, macOS Tahoe 26 and macOS 27, the current version as this is written.

It helps just as much to know what isn’t System Data. Storage settings gives these their own categories:

• iOS Files holds iPhone and iPad backups and firmware.
• Applications holds the apps you installed, including any “Install macOS” app you downloaded.
• Documents holds the other files in your home folder and has a Downloads button, so leftover disk images and installer packages in your home folder show up there.
• Mail, Messages, Photos and Trash each have their own bar.

So if you’ve been told to delete old iPhone backups or installers to shrink System Data, look at those categories instead.

You may also see purgeable space in Disk Utility. Apple describes it as space macOS can free when needed by removing files, and counts it as available. You can’t remove purgeable files yourself; macOS removes them as space is required.

Why the bar shrinks on its own

Much of what macOS keeps for itself is temporary by design:

• Time Machine local snapshots. Time Machine saves a snapshot about every hour, keeps it for 24 hours, and deletes snapshots as they age or when space is needed (Apple).
• Caches. Apple’s developer documentation defines them as data that can be regenerated as needed. Starting up in safe mode clears certain system caches, and Apple suggests it when you need room only for a while, such as during a macOS update (Apple).
• Swap. When apps need more memory than your Mac has, macOS writes some of it to disk, and that use rises and falls with what you have open.

That’s why System Data can be smaller after a restart, or a day later, without you doing anything. Before you delete anything, restart, wait a day if you can, and look again.

Find out what’s in your System Data

Here’s a method that uses only Storage settings, Finder, Disk Utility and a few read-only Terminal commands. It starts with items that can be very large on their own, then works through the folders where the rest collects. By the end you’ll have a short list.

Step 1: Write down the starting numbers

Open System Settings > General > Storage and wait for the bar to finish. Note the System Data figure. Click the info button next to iOS Files, Applications and Documents to see what’s in them: anything there is already counted outside System Data. Then click All Volumes, which shows a bar for each volume on your internal disk.

Step 2: Check Time Machine local snapshots

Local snapshots exist only on APFS disks with automatic Time Machine backups turned on. To list them, open Terminal and run:

tmutil listlocalsnapshots /

Time Machine’s snapshots are named com.apple.TimeMachine followed by a date. To see their sizes, open Disk Utility, choose View > Show APFS Snapshots and select your startup volume. The table at the bottom lists each snapshot, and Show Columns in its menu adds Private Size and Cumulative Size.

Apple says your Mac counts snapshot space as available storage, so snapshots shouldn’t stop you downloading files or installing software. Apple doesn’t say whether Storage settings includes them in System Data, so use this step to rule snapshots in or out, not to match numbers exactly.

Step 3: Check container and virtual machine disks

Docker Desktop stores all its Linux containers and images in one large disk image file. Its own Settings > Resources > Advanced shows where that file is and how much space it actually uses; Docker warns that other tools may report its maximum size instead. From Terminal:

docker system df

Virtual machine apps need a virtual disk for each machine, and it lives on your Mac unless you put it elsewhere. Check each machine’s size in the app that runs it.

Step 4: Size your Library folder

The caches, logs and app support files Apple mentions live in Library folders, and the one you control is the Library in your home folder.

In Finder, choose Go > Go to Folder, type ~/Library and press Return. Switch to List view, choose View > Show View Options, select “Calculate all sizes”, then click the Size column header to sort. Folder sizes take a while to fill in.

Or in Terminal:

du -sh ~/Library/Caches ~/Library/Logs ~/Library/Application\ Support 2>/dev/null
du -hd 1 ~/Library 2>/dev/null | sort -h | tail -n 15

The first line totals three folders. The second lists the 15 biggest folders in your Library, largest last. Both only read. On a big Library they can take minutes. macOS privacy protections cover some folders, so you may get a prompt asking whether Terminal can access other apps’ data. You can say no: du skips those folders, and 2>/dev/null hides the “Operation not permitted” lines.

Skip Mail and Messages in the results, since Storage settings counts them separately. Also, du -h counts in units of 1,024, while macOS reports storage in decimal units (a gigabyte is a billion bytes), so du figures look about 7% smaller. Use du -s --si instead of du -sh if you want them to line up.

Step 5: Look inside Caches and Logs

Open the biggest folders from Step 4. Apple’s convention is for each app to keep its cache in a folder named after its bundle identifier, which looks like com.company.AppName, so you can usually tell whose cache is big. ~/Library/Logs holds log files apps write, which you can read in the Console app. The system’s own log store sits in /var/db/diagnostics (see man log), and macOS looks after it.

Step 6: Read, but don’t touch, swap and the sleep image

sysctl vm.swapusage
pmset -g | grep hibernatefile

The first shows how much swap is in use. The swap files live on a hidden VM volume (Apple Platform Security). The second shows where macOS writes its sleep image: by default, Mac laptops store a copy of memory on disk when they sleep (man pmset). Both are part of how macOS runs.

Your list

You now know which of these matter on your Mac:

What’s safe to remove, and how

Time Machine local snapshots

Usually you don’t need to do anything. To clear them now, Apple’s method is to pause automatic backups: go to System Settings > General > Time Machine, click Options, set Backup Frequency to Manually, click Done, wait a few minutes, then turn automatic backups back on. Time Machine remembers your backup disks.

From Terminal, tmutil can thin them:

tmutil thinlocalsnapshots / 20000000000 4

That asks macOS to try to reclaim 20 GB (the amount is in bytes) by thinning snapshots, at urgency level 4 on the manual’s scale of 1 to 4. If it reports a permissions error, run the same command with sudo in front; this one only asks Time Machine to thin its own snapshots.

Docker and virtual machines

Use the tool, not Finder. docker system prune removes stopped containers, unused networks, dangling images and build cache, and Docker says freeing the space can take a few minutes. Don’t move or delete the disk image file by hand: it holds every container and image. For virtual machines, delete the ones you no longer need from inside the app that runs them.

Caches and logs

Quit the app, move its folder in ~/Library/Caches to the Trash, then empty the Trash; space isn’t freed until you do (Apple). Expect the cache to grow back as you use the app. Do the same for an app’s old files in ~/Library/Logs.

Mail downloads

Mail keeps some attachments temporarily in a Mail Downloads folder in your Library. In Mail > Settings > General, “Remove unedited downloads” controls when they’re deleted; by default an unedited attachment goes when you delete its message (Apple).

App support data

Apple’s developer documentation says Application Support can hold files with user data, so don’t clear it wholesale. Remove a folder only when you’ve removed its app and know you don’t want what’s inside.

Device backups, installers and updates

These usually aren’t System Data, but they’re often what people mean. Delete old iPhone and iPad backups in Finder: connect the device, select it, click Manage Backups in the General tab, then right-click a backup and choose Delete (Apple). Remove installers from the Applications or Documents category in Storage settings. Leave macOS update files to Software Update; if there isn’t room to install, Apple suggests starting up in safe mode.

What not to do

• Don’t delete anything in /System. By default, no process can write to the system volume, not even Apple’s own, and on macOS 11 and later your Mac starts up from a snapshot of it (Apple Platform Security).
• Don’t delete things in /private/var by hand. It holds working data macOS manages, including the system log store and, on Macs that use one, the sleep image.
• Don’t use sudo rm on anything you don’t recognise. sudo runs the command as root, past the permission checks that normally stop you, and rm skips the Trash, so there’s no undo.
• Don’t delete other snapshots. In Disk Utility, only snapshots named com.apple.TimeMachine belong to Time Machine. Leave anything else alone.
• Don’t change sleep settings to save space. The pmset manual asks you to use caution with its hibernation settings.

If you’d rather see all of this on one map, Disk Whisk scans without changing anything, explains each item it finds, and moves only what you approve to the Trash.

Here’s where each tool keeps its models on macOS, how to measure and remove them, and how to prove two files are the same before you delete either.

Where each tool keeps its models

A few details change where you should look:

• LM Studio moved its home folder from ~/.cache/lm-studio to ~/.lmstudio in version 0.3.6, but only for first-time installs, and it doesn’t move existing data. If you’ve used it since before then, your models may be in ~/.cache/lm-studio/models. Check both.
• Ollama keeps small manifests in manifests and the actual weights in blobs.
• Hugging Face keeps one cache for the Python libraries that download from the Hub, such as transformers and diffusers. mlx-lm downloads into it too, so MLX models you run from Python live here. If you set HF_HOME, the cache is $HF_HOME/hub.
• ComfyUI sorts models into folders by type (checkpoints, loras, vae and so on). A manual install keeps them in ComfyUI/models inside the folder you installed it in. In Comfy Desktop, ~/ComfyUI-Shared also holds output, which is where your generated images go, so never clear that folder wholesale.

Measure what you have

Start with totals. du reports what’s actually on disk, and 2>/dev/null hides the errors for folders you don’t have:

du -sh ~/.ollama/models ~/.lmstudio/models ~/.cache/lm-studio/models ~/.cache/huggingface/hub ~/ComfyUI-Shared/models ~/.cache/torch/hub 2>/dev/null

If you’ve moved a folder, ask the tool where it is. hf env prints the HF_HUB_CACHE in use, and the Ollama app shows its folder under Model location in Settings.

Then list what’s inside, model by model:

ollama list
lms ls
hf cache ls --sort size

ollama list shows each model’s size, lms ls lists the models LM Studio sees on disk, and hf cache ls --sort size lists cached Hugging Face repos, largest first. The hf cache commands arrived in huggingface_hub 1.0 (--sort in 1.1); older versions use huggingface-cli scan-cache.

Find the same model stored twice

No tool tells you when another tool holds the same file. But two of them name their large files after a SHA-256 hash of the contents, which makes duplicates easy to spot:

• Ollama names every blob sha256-<hash>. Its source computes the hash while writing the file, and the name is that hash.
• The Hugging Face cache names each large file in a repo’s blobs folder after its SHA-256 (small text files get a shorter Git hash). The readable file names under snapshots are symlinks to those blobs.

LM Studio and ComfyUI keep the original file names, so for those you compute the hash yourself with shasum, which comes with macOS.

Check one file

Say LM Studio has a GGUF and you suspect Ollama or the Hugging Face cache has it too. Hash it, then search the other two folders for that hash:

hash=$(shasum -a 256 ~/.lmstudio/models/bartowski/Llama-3.2-1B-Instruct-GGUF/Llama-3.2-1B-Instruct-Q4_K_M.gguf | cut -d' ' -f1)
find ~/.ollama/models/blobs ~/.cache/huggingface/hub -name "*$hash" 2>/dev/null

Any path it prints holds the same bytes.

A real example: the Q4_K_M file in the bartowski/Llama-3.2-1B-Instruct-GGUF repo on Hugging Face is 807,694,464 bytes, with a SHA-256 starting 6f85a640. For ollama pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF:Q4_K_M, the manifest Hugging Face serves lists the model layer with that same digest and size, so Ollama saves it as blobs/sha256-6f85a640…. LM Studio downloads the same file from Hugging Face under its original name, and a Python download adds a third copy to the Hugging Face cache. That’s about 808 MB, stored three times.

You can read a Hub file’s SHA-256 without downloading it, from the X-Linked-Etag header:

curl -sI https://huggingface.co/bartowski/Llama-3.2-1B-Instruct-GGUF/resolve/main/Llama-3.2-1B-Instruct-Q4_K_M.gguf | grep -i x-linked-etag

Check every folder at once

Hashing reads every byte, so it’s slow on files this size. Identical files must be the same size, so this check lists sizes first and hashes only files that share one. It only reads. Run the three parts in order:

find ~/.ollama/models/blobs ~/.cache/huggingface/hub ~/.lmstudio/models ~/.cache/lm-studio/models ~/ComfyUI-Shared/models -type f -size +100M -exec stat -f '%z %d:%i %N' {} + 2>/dev/null | awk '!seen[$2]++' | sort -n > /tmp/model-files.txt

awk '{print $1}' /tmp/model-files.txt | uniq -d | while read -r size; do
  grep "^$size " /tmp/model-files.txt | cut -d' ' -f3- | while IFS= read -r file; do
    shasum -a 256 "$file"
  done
done | sort > /tmp/model-hashes.txt

awk '{print $1}' /tmp/model-hashes.txt | uniq -d | while read -r hash; do
  grep "^$hash" /tmp/model-hashes.txt; echo
done

The first part lists every file over 100 MB with its size and a disk-and-inode ID, the second hashes files whose size matches another’s, and the third prints each hash that appears more than once, with its paths. Add any other folder where you keep .gguf or .safetensors files, such as ~/Downloads, to the find line. A few notes:

• -type f skips symlinks, so Hugging Face snapshots links aren’t counted twice.
• awk '!seen[$2]++' keeps one path per file, so hard links (two names for one file, stored once) don’t show up as duplicates.
• It works for safetensors shards as well as GGUF files, which covers MLX models you may have in both LM Studio and the Hugging Face cache.

What a match tells you, and what it doesn’t

A matching hash means identical bytes. A different hash doesn’t mean a different model. Models from Ollama’s own library come from Ollama’s registry, not a Hugging Face repo, so they won’t necessarily match a Hugging Face GGUF with the same name and quantization. And one model in two quantizations, say Q4_K_M in Ollama and Q8_0 in LM Studio, is two files by design. Whether you need both is your call.

To map an Ollama blob back to a model, run ollama show --modelfile <model>: for GGUF models, the FROM line is the blob’s path. Models Ollama stores in its Safetensors format (the ones it runs with MLX) are split across many smaller blobs, and their FROM line shows a model name instead, so this check won’t match them to anything.

Keep one copy

Once you know two tools hold the same bytes, these are the options the tools support.

Share a file between Ollama and LM Studio

A hard link gives one file two names. Both tools see an ordinary file, the data is stored once, and removing one name (with ollama rm, say) leaves the other working. The space comes back only when both names are gone. Both folders must be on the same disk.

First delete LM Studio’s copy in the My Models tab, from the model’s menu. Then recreate it as a hard link to Ollama’s blob, at the publisher/model/file.gguf path LM Studio expects inside its models folder:

mkdir -p ~/.lmstudio/models/bartowski/Llama-3.2-1B-Instruct-GGUF
ln ~/.ollama/models/blobs/sha256-<hash> ~/.lmstudio/models/bartowski/Llama-3.2-1B-Instruct-GGUF/Llama-3.2-1B-Instruct-Q4_K_M.gguf

ls -li on both paths should show the same inode number and a link count of 2. Use a hard link, not a symlink: a symlink into Ollama’s blob folder breaks as soon as Ollama removes that model.

lms import --hard-link also makes hard links, but it keeps the source file’s name, and an Ollama blob has no .gguf extension. Without --copy, --hard-link or --symbolic-link, lms import moves the file into LM Studio’s folder.

Import a GGUF into Ollama

If LM Studio already has a GGUF that you want in Ollama, put FROM /path/to/model.gguf in a file called Modelfile and run:

ollama create my-model -f Modelfile

This saves a download, not disk space: ollama create copies the file into its blob store (you’ll see “copying file” as it runs). The hard-link step above brings it back to one copy.

Point mlx-lm at a folder you already have

mlx-lm takes a local folder anywhere it takes a repo ID; its --model option accepts “the path to the local model directory or Hugging Face repo”. If LM Studio already holds a complete MLX model folder (weights, config and tokenizer files), you can point mlx-lm at it and remove the cached copy with hf cache rm.

Share models across ComfyUI installs

In Comfy Desktop, open the capsule menu at the top of the app and add model folders in the Storage tab. A manual install reads extra folders from extra_model_paths.yaml in its root folder; copy extra_model_paths.yaml.example to start. Restart ComfyUI after changing either.

Keep one Hugging Face cache

Hub-based libraries share one cache unless something overrides it, so check that your projects don’t each set their own HF_HOME or cache_dir. Since huggingface_hub 1.32, the cache also stores identical Xet-backed files once across repos.

Remove models with each tool’s own command

Deleting files inside these folders by hand can leave a tool pointing at files that are gone. Use the tool instead:

• Ollama: ollama rm <model> removes the model and any blobs no other model still uses.
• Hugging Face: hf cache rm model/<org>/<name> --dry-run shows what would go and how much space it frees; run it again without --dry-run to delete. hf cache prune removes revisions no branch or tag points to, plus interrupted downloads. Before huggingface_hub 1.0, the command is huggingface-cli delete-cache.
• mlx-lm: mlx_lm.manage --scan lists cached repos with “mlx” in the name, and mlx_lm.manage --delete --pattern <text> removes matching ones after asking.
• LM Studio: in My Models, open the model’s menu and choose Delete. lms has no remove command yet; there’s an open request for one.
• ComfyUI: models are plain files in their type folders, so move the ones you don’t want to the Trash in Finder.

ollama rm and hf cache rm delete permanently. They don’t use the Trash.

What you can’t download again

Most of what these folders hold is a download and can come back. These can’t, so check before you delete:

• Fine-tunes, LoRAs and adapters you trained. mlx-lm saves adapters to adapters and fused models to fused_model, in the folder you ran it from, outside the cache.
• Merges, conversions and quantizations you made yourself, such as mlx_lm.convert output in mlx_model. You can redo them, but not by downloading.
• Ollama models you created from a local file you’ve since deleted. The blob is then the only copy.
• Files you added with a plain lms import. It moves the file, so LM Studio’s copy may be the only one.
• ComfyUI’s output folder and any LoRAs you trained.
• Models from gated, private or deleted repos, which may not download again.

Other caches worth a look

Python environments for local AI pull in large packages, and their download caches grow quietly. Everything in them downloads again when needed. To see each cache’s folder and size:

pip cache dir
pip cache info
uv cache dir
uv cache size
conda clean --all --dry-run

To clear them, use pip cache purge, uv cache prune (which removes unused entries; uv cache clean removes everything) and conda clean --all. PyTorch hub downloads are plain files, with weights in ~/.cache/torch/hub/checkpoints; remove the ones you no longer use in Finder.

If you’d rather see all this in one place, Disk Whisk’s Overview groups Ollama, LM Studio, Hugging Face and ComfyUI storage under “AI models & datasets” and explains each item, and anything you approve for cleanup goes to the Trash.