·
homebrew gradle maven go ruby macos disk-space developer-tools ide-caches

Homebrew, Gradle, and the Hidden Caches Eating Your Mac's Storage

Homebrew, Gradle, Maven, Go, Ruby, and IDE caches silently consume 20-40GB on developer Macs. Every path, command, and typical size.

Most developers know about the big offenders — Xcode’s DerivedData, Docker images, node_modules. But there’s a second tier of caches that almost nobody thinks about: Homebrew downloads, Gradle wrapper distributions, Maven repositories, Go module caches, Ruby gems, and IDE workspace storage.

None of these is massive on its own. Homebrew might be 3GB. Gradle caches, 8GB. Your IDE’s workspace storage, another 4GB. But stack five or six of these together and you’re looking at 20-40GB of disk space consumed by files you’ll never open, never reference, and never miss if they’re gone.

I built MegaCleaner specifically because I kept rediscovering these folders every few months, manually cleaning them, and then forgetting about them again. This article covers every location, every cleanup command, and the typical savings you can expect.

1. Homebrew Cache

Homebrew is installed on nearly every developer Mac, and it quietly caches every package it downloads. Upgrade a formula? The old tarball stays. Install something, try it, uninstall it? The download stays. Over time, these downloads pile up.

Where it lives:

~/Library/Caches/Homebrew/

This directory holds cached downloads, bottle tarballs, and formula metadata. Homebrew also stores build and install logs separately:

~/Library/Logs/Homebrew/

What most people don’t know about: Beyond the download cache, Homebrew keeps old versions of installed formulas in its Cellar directory. If you’ve had a formula installed through several upgrades, each old version sits in its own folder:

/opt/homebrew/Cellar/<formula>/<old-version>/    # Apple Silicon Macs
/usr/local/Cellar/<formula>/<old-version>/       # Intel Macs

These outdated kegs aren’t cleaned up automatically. If you’ve been running brew upgrade for a year or two, you may have dozens of old versions sitting idle.

How big it gets: 2-10GB, depending on how many packages you use and how often you upgrade. Heavy Homebrew users (those installing large casks like databases, language runtimes, or GUI apps) can see even more.

How to clean it:

Remove cached downloads (anything older than 120 days by default):

brew cleanup

Force-remove all cached downloads regardless of age:

brew cleanup -s

Remove packages that were installed only as dependencies and are no longer needed:

brew autoremove

For a full cleanup, run both:

brew cleanup -s && brew autoremove

Is it safe? Yes. Cached downloads are re-downloaded on next install. Old keg versions are only used if you explicitly brew switch to them, which almost nobody does. Homebrew logs are purely informational.

2. Gradle and Maven Caches

If you do any JVM development — Java, Kotlin, Android, Spring Boot — Gradle and Maven are downloading dependencies into local caches that grow without bound. These are some of the largest caches on a typical developer Mac.

Gradle

Where it lives:

~/.gradle/caches/

This is where Gradle stores downloaded dependencies, transformed artifacts, build cache entries, and metadata. It’s the main storage consumer.

Gradle also downloads full Gradle distributions for each version referenced by the wrapper in your projects:

~/.gradle/wrapper/dists/

Each Gradle version is roughly 100-200MB, and if you work across multiple projects using different Gradle versions, you might have 5-10 versions sitting here.

How big it gets: 5-20GB. Android developers tend toward the higher end because the Android build system downloads substantial support libraries, build tools, and transformed artifacts. If you’ve been doing Android development for a few years, 15-20GB is common.

How to clean it:

Delete the entire cache (dependencies will re-download on next build):

rm -rf ~/.gradle/caches/

Delete old wrapper distributions:

rm -rf ~/.gradle/wrapper/dists/

Gradle itself doesn’t provide a built-in cleanup command for the local cache. There’s a --no-build-cache flag, but it only prevents writing to the cache — it doesn’t remove existing entries.

Is it safe? Yes. Everything in ~/.gradle/caches/ is downloaded from remote repositories and will be fetched again when needed. The first build after cleaning will be slower as dependencies are re-resolved. Wrapper distributions are re-downloaded automatically.

Maven

Where it lives:

~/.m2/repository/

Maven’s local repository is a mirror of every dependency your projects have ever resolved. Unlike Gradle, Maven stores artifacts in a structured directory tree (groupId/artifactId/version/), which makes it easy to browse but doesn’t help with cleanup.

How big it gets: 2-10GB for most developers. If you work on large enterprise projects with extensive dependency trees, it can exceed 15GB.

How to clean it:

Delete the entire local repository:

rm -rf ~/.m2/repository/

Or use Maven’s dependency plugin to selectively purge:

mvn dependency:purge-local-repository

Is it safe? Yes. Everything is re-downloaded from Maven Central (or your configured repositories) on next build. The only risk: if you have locally installed artifacts (mvn install on local projects), those will need to be rebuilt.

3. Go Module and Build Caches

Go has two distinct caches that grow independently and are both safe to clean.

Module cache

Where it lives:

~/go/pkg/mod/

This is the default location when $GOPATH is not set (which is the case for most modern Go setups). If you’ve customized $GOPATH, the module cache lives at $GOPATH/pkg/mod/ instead.

The module cache stores downloaded source code for every version of every dependency your Go projects have ever used. Because Go modules are versioned, switching between dependency versions doesn’t remove old ones — they accumulate.

Build cache

~/.cache/go-build/

The build cache stores compiled object files so that unchanged packages don’t need recompilation. This is separate from the module cache and grows based on how many packages you compile.

How big they get: 1-5GB combined for most developers. Heavy Go users working on microservice architectures with many dependencies can see more.

How to clean them:

Clear the build cache:

go clean -cache

Clear the module cache (requires sudo since Go sets directories to read-only):

go clean -modcache

Clear both:

go clean -cache -modcache

Is it safe? Yes. Modules are re-downloaded via go mod download (triggered automatically on next build). Build artifacts are recompiled as needed.

4. Ruby Gems and Bundler

Ruby’s gem ecosystem creates multiple cache layers, and if you use version managers like rbenv or RVM, the storage multiplies across Ruby versions.

Gem cache

Where it lives:

~/.gem/

This directory contains downloaded gem files, compiled native extensions, and metadata for every gem you’ve installed. Each Ruby version gets its own subdirectory.

Bundler cache

~/.bundle/cache/

Bundler stores its own cache of downloaded gems separately from the system gem cache.

Version managers

If you use rbenv or RVM, each installed Ruby version is a full Ruby installation:

~/.rbenv/versions/     # rbenv
~/.rvm/                # RVM (entire installation)

Vendor bundles

Projects that use bundle install --deployment or bundle install --path vendor/bundle store a complete copy of all gems inside the project directory at vendor/bundle/. These are easy to overlook because they’re buried inside project folders.

How big it gets: 1-5GB for the gem and bundler caches alone. Add version managers and you can add 500MB-2GB per installed Ruby version. Vendor bundles add 200MB-1GB per project.

How to clean it:

Remove old gem versions (keeps only the latest version of each gem):

gem cleanup

Preview what would be removed:

gem cleanup --dryrun

Clear bundler cache:

rm -rf ~/.bundle/cache/

Is it safe? Gem cleanup is safe — old versions are rarely needed, and gem install restores them. Be careful with version manager directories if you actively use multiple Ruby versions. Vendor bundles can be restored with bundle install.

5. IDE Caches

Your code editor or IDE maintains its own caches, extensions, and workspace state. If you use multiple IDEs, this adds up fast.

VS Code

VS Code stores caches and workspace data across several locations:

~/Library/Application Support/Code/Cache/
~/Library/Application Support/Code/CachedData/
~/Library/Application Support/Code/User/workspaceStorage/
~/.vscode/extensions/

The Cache and CachedData directories are standard Electron app caches — safe to delete, rebuilt automatically. workspaceStorage holds per-project state for extensions (search history, git state, etc.) and grows with every project you open. The extensions directory holds your installed extensions and their data.

How big it gets: 2-8GB. Workspace storage alone can be 1-4GB if you’ve opened many projects. Extensions can be another 1-3GB depending on how many you have installed.

Cursor and Windsurf

If you use Cursor or Windsurf (VS Code-based AI editors), they maintain their own separate caches in the same structure:

~/Library/Application Support/Cursor/Cache/
~/Library/Application Support/Cursor/CachedData/
~/.cursor/extensions/

~/Library/Application Support/Windsurf/Cache/
~/Library/Application Support/Windsurf/CachedData/

These are independent from VS Code’s caches, so if you run multiple editors you’re paying the storage cost for each.

JetBrains IDEs

IntelliJ IDEA, WebStorm, PyCharm, CLion, GoLand, Android Studio, RustRover, and every other JetBrains IDE stores caches and logs in versioned subdirectories:

~/Library/Caches/JetBrains/<IDEVersion>/
~/Library/Logs/JetBrains/<IDEVersion>/

For example, ~/Library/Caches/JetBrains/IntelliJIdea2024.1/. Each IDE version gets its own folder, and caches from old versions remain after you upgrade. If you’ve used IntelliJ through several yearly releases, you might have 4-5 old cache directories.

How big it gets: 1-5GB per IDE, multiplied by the number of versions you’ve had installed. Two JetBrains IDEs across three version upgrades can easily be 10-15GB of stale caches.

Sublime Text and Zed

Smaller editors leave smaller footprints, but they still cache:

~/Library/Caches/com.sublimetext.3/
~/Library/Caches/com.sublimetext.4/
~/Library/Caches/Zed/

How to clean IDE caches:

VS Code — clear caches (extensions stay intact):

rm -rf ~/Library/Application\ Support/Code/Cache
rm -rf ~/Library/Application\ Support/Code/CachedData

JetBrains — remove old version caches (check which versions you actually use first):

ls ~/Library/Caches/JetBrains/
rm -rf ~/Library/Caches/JetBrains/IntelliJIdea2023.*/

Is it safe? Cache and CachedData directories are safe — IDEs rebuild them on launch. Workspace storage is safe to clear but you’ll lose per-project editor state. Extensions directories should be handled with care — deleting them means reinstalling your extensions.

6. The Combined Impact

Here’s what all of these look like together. On a developer Mac that’s been in use for a year or more, these are typical numbers:

ToolCache PathTypical Size
Homebrew cache~/Library/Caches/Homebrew/2-5 GB
Homebrew logs~/Library/Logs/Homebrew/100-500 MB
Homebrew outdated kegs/opt/homebrew/Cellar/*/500 MB-3 GB
Gradle caches~/.gradle/caches/5-15 GB
Gradle wrapper~/.gradle/wrapper/dists/500 MB-2 GB
Maven repository~/.m2/repository/2-10 GB
Go module cache~/go/pkg/mod/1-3 GB
Go build cache~/.cache/go-build/500 MB-2 GB
Ruby gems~/.gem/500 MB-2 GB
Bundler cache~/.bundle/cache/200 MB-1 GB
VS Code caches~/Library/Application Support/Code/2-5 GB
JetBrains caches~/Library/Caches/JetBrains/2-10 GB
Total~20-50 GB

That’s 20-50GB of disk space consumed by caches from tools that aren’t even your primary development stack in many cases. And none of these clean themselves up automatically.

The uncomfortable truth: even if you’re diligent about running cleanup commands, you have to remember to do it. For each tool. Regularly. Most developers run brew cleanup once, feel good about it, and then forget for six months.

7. The Automated Way

This is the problem I built MegaCleaner to solve.

MegaCleaner is a native macOS app with 29 specialized scanners — 21 for developer tools (including dedicated scanners for Homebrew, Gradle/Maven, Go, Ruby, and IDE caches) and 8 for general macOS cleanup. It scans every path covered in this article, plus Xcode, Docker, Node.js, Python, Rust, Cocoapods, SPM, and more.

What it does that manual cleanup doesn’t:

  • Scans all tools at once — no switching between terminals and remembering paths.
  • Shows you exactly what’s stale — MegaCleaner tracks file modification dates and flags caches that haven’t been touched in weeks or months, so you can keep recent caches and clean only what’s truly idle.
  • Handles outdated Homebrew kegs — it identifies old formula versions in the Cellar, keeping only the latest version of each package.
  • Finds IDE caches across editors — VS Code, Cursor, Windsurf, JetBrains (all IDEs, all versions), Sublime Text, Zed, even Vim/Neovim undo files. If you use more than one editor, this adds up.
  • Discovers vendor bundles in projects — finds vendor/bundle directories buried inside Ruby projects across your codebase.
  • Respects $GOPATH — automatically resolves custom Go paths instead of assuming the default.

Pricing: $49 one-time purchase. No subscription. Free updates.

Download MegaCleaner

8. Quick Reference Commands

Bookmark this section. Here’s every cleanup command from this article in one place:

Homebrew

brew cleanup -s          # Remove all cached downloads
brew autoremove          # Remove unused dependencies

Gradle

rm -rf ~/.gradle/caches/         # Delete dependency cache
rm -rf ~/.gradle/wrapper/dists/  # Delete wrapper distributions

Maven

rm -rf ~/.m2/repository/         # Delete local repository

Go

go clean -cache       # Clear build cache
go clean -modcache    # Clear module cache

Ruby

gem cleanup              # Remove old gem versions
rm -rf ~/.bundle/cache/  # Clear Bundler cache

VS Code

rm -rf ~/Library/Application\ Support/Code/Cache
rm -rf ~/Library/Application\ Support/Code/CachedData
rm -rf ~/Library/Application\ Support/Code/User/workspaceStorage

JetBrains

ls ~/Library/Caches/JetBrains/
ls ~/Library/Logs/JetBrains/
# Then remove old versions selectively

Nuclear option (everything at once)

brew cleanup -s && brew autoremove
rm -rf ~/.gradle/caches/ ~/.gradle/wrapper/dists/
rm -rf ~/.m2/repository/
go clean -cache -modcache
gem cleanup
rm -rf ~/.bundle/cache/
rm -rf ~/Library/Application\ Support/Code/Cache
rm -rf ~/Library/Application\ Support/Code/CachedData

Fair warning: the nuclear option means slower first builds across all your projects as dependencies are re-downloaded. It’s safe, but plan for it.

Wrapping Up

Developer tool caches are a death-by-a-thousand-cuts storage problem. No single one is outrageous, but they compound. And they all share the same characteristic: they grow without limit and never clean themselves up.

You have two options. You can bookmark this article and run through the commands every few months. Or you can let MegaCleaner scan everything in one pass and show you exactly what’s safe to remove, with size and staleness information for every item.

Either way, go check ~/Library/Caches/Homebrew/ and ~/.gradle/caches/ right now. You might be surprised.