Jason Lee

Posted on Aug 11

DevCleaner Bets Your AI Coding Tools Are the New Disk Hogs, Not Xcode

#ai #productivity #macos #devtools

Every Mac cleanup tool on Product Hunt makes the same pitch: your disk is full of junk, click here to get it back. Most of them mean browser caches, old photos, and duplicate downloads. DevCleaner means something narrower and, if you're a developer, more interesting: the private stash every build tool keeps and never cleans. Xcode DerivedData. Gradle caches. Forgotten iOS simulators. npm's attic.

That pitch alone wouldn't be worth 4,000 words — "Mac cleaner but for devs" is not a new category. What makes DevCleaner worth a closer look in August 2026 is what its version history quietly reveals: it has spent the last two months racing to also clean up after your AI coding tools. ~/.claude, ~/.cursor, OpenAI Codex CLI, Cline, and downloaded model weights from Ollama and LM Studio all got added to the scanner list in the 1.8 and 1.9 releases. That's the actual story here: a solo indie developer watching, in near real time, agentic coding tools become one of the biggest sources of disk bloat on a working developer's machine — and building a business on being the first cleaner that knows the difference between a Gradle cache and a 40GB local model.

What happened

DevCleaner is a free macOS menu bar utility built by David Tereba, a solo maker based in Prague. It launched on Product Hunt on June 16, 2026 and, by the maker's own account on the product page, finished #12 on launch day — a respectable but unspectacular showing, not a chart-topper. That's worth stating plainly up front, because "Product Hunt launch" headlines often imply viral traction that the underlying numbers don't support; here the maker isn't claiming otherwise.

What's more telling than the launch-day rank is the cadence of updates since: version 1.6 added Project Hibernation (archiving idle projects instead of deleting them), 1.8.0 shipped on July 14 with expanded scanning for ~/.npm, .claude, .cursor, Codex, and Cline caches plus JetBrains and Android Studio coverage, and 1.9.0 followed with SwiftPM source packages, browser-testing caches (Playwright, Electron, Cypress, Puppeteer), Android emulator snapshots, and a full simulator device manager. As of this writing the app is at 1.10.1. That's four meaningful releases in under two months from one person — a pace that says more about product-market signal than the launch-day leaderboard position does.

DevCleaner is also not a standalone bet. It's the middle app in a three-tool suite Tereba is building for the indie-developer lifecycle: Planelo for capturing and triaging project ideas, DevCleaner for the build phase, and TesterBuddy for collecting beta feedback from TestFlight and Google Play once you ship. None of the three appear to be venture-funded; all three are narrow, single-purpose utilities sold directly to developers. That context matters for how you should read the rest of this piece — this is bootstrapped indie software, not a category-defining platform play.

What it actually does

Under the hood, DevCleaner is a scanner-plus-risk-model. It ships with detectors for 23 developer ecosystems and lets you add arbitrary custom folders on top. The list spans the obvious build-tool suspects — Xcode (DerivedData, SPM cache, simulators, archives, device support), Android Studio (Gradle caches, AVDs, wrapper distributions), JetBrains IDEs (indexes, compilation caches, logs), Node.js package managers (npm, Yarn, pnpm, Bun, node-gyp), Python (pip and uv wheel caches, stale virtualenvs), Flutter, Rust (cargo registry and git checkouts), Go, CocoaPods, Homebrew, Docker (build cache, dangling images, stopped containers), Maven, Composer, and Unity — and then the newer, more interesting tier: VS Code, Claude desktop and Claude Code caches, ChatGPT desktop caches, Gemini CLI temp files, Cursor, Windsurf, Antigravity, and downloaded model weights from Ollama and LM Studio.

Every category is tagged Safe, Warning, or Danger, and only Safe items are pre-selected for deletion:

Safe (deleted by default): pure caches that regenerate on the next build — DerivedData, Gradle caches, pip cache. The stated cost of deleting them is "one slower compile, nothing more."
Warning (your call, never pre-selected): things that grow back slowly or that you might still need — old simulators, .xcarchives, AVDs.
Danger (hands off): SDKs and device symbols that can break your environment if removed — Android SDK components, iOS Device Support files. The app shows their size, asks twice, and never touches them on its own. Credentials and session files sit on what the FAQ describes as a hard deny-list, and the app checks whether the owning tool is still running before touching its cache.

Beyond one-shot cleanup, two features push DevCleaner past "glorified rm -rf":

Ghost Projects and Project Artifacts surface stale, forgotten project folders and their node_modules/build/.venv directories — the stuff you cloned six months ago and never deleted.

Project Hibernation (since 1.6) archives an entire idle project into a single compressed file, strips the regenerable junk (node_modules, build folders) while keeping lockfiles, and restores it later with dependencies reinstalled. It offers a dry-run restore that verifies the archive and previews exactly what will land where before writing anything — a real nod to the fact that you're one bad archive away from losing a project entirely.

The app itself is small: 4MB, no account required, native menu bar UI with no dock icon — just a badge showing reclaimable space near the clock.

It's worth being concrete about why these particular caches balloon, because the mechanics differ per tool and that's exactly what a risk-tiered scanner has to get right. Xcode's DerivedData grows because every build variant, every simulator target, and every incremental compile leaves its own subtree behind, and Xcode almost never prunes it itself — developers who haven't touched ~/Library/Developer/Xcode/DerivedData in a year routinely find tens of gigabytes there. Docker's build cache grows because layer caching is deliberately generous by default — it keeps intermediate layers around to speed up the next build, and "docker system prune" is a command most developers learn about only after docker.raw eats 80GB. node_modules duplication is the oldest offender in the list: every cloned repo gets its own full dependency tree, and unlike Python's shared site-packages-per-venv convention, Node's per-project install model means the same lodash gets downloaded and stored dozens of times across a machine. None of this is new information to anyone who's run du -sh in frustration, but it's the reason a tool that knows these patterns per ecosystem is doing something a generic "find big files" utility structurally can't.

How it works, architecturally

There isn't a public technical writeup of DevCleaner's internals, and the app doesn't appear to be open source — there's no linked repository on the product page, in the FAQ, or on the maker's two public GitHub repos (which are SDKs for TesterBuddy, not DevCleaner itself). So what follows is inferred from behavior described on the product page, not from source.

The design is straightforward: a background scanner walks a fixed table of known cache paths per ecosystem (the same approach an open-source alternative, k-angama/macOS-dev-cache-cleaner, documents openly in its Constants.swift file — a useful reference if you want to see what "known cache paths for Xcode, Gradle, CocoaPods, npm/Yarn/Bun" actually look like on disk). Sizes stream in live as the scan proceeds. Each path is mapped to a risk tier, Quick Clean acts on the Safe tier only, and everything else requires explicit selection. Workspace-level cleanup (matching package.json → node_modules, Package.swift → .build, settings.gradle → .gradle, and similar marker-file-to-generated-directory rules) is the same pattern used by that open-source project, which suggests it's close to industry-standard practice for this category rather than a DevCleaner invention.

The one place the architecture gets genuinely interesting is the AI-tool scanners, because they don't all behave the same way underneath, and the product page doesn't distinguish them. That's worth unpacking, because it's the piece a launch page has every incentive to gloss over.

Project Hibernation deserves a slightly closer look too, because it's the feature that separates DevCleaner from being "just" a cache sweeper. The problem it targets is real and specific: a side project you haven't opened in eight months isn't a cache, it's a whole working tree, and the instinct most developers have is to either leave it alone forever (disk creep) or delete the folder outright (data loss risk if you're wrong about needing it again). Hibernation's answer — strip the regenerable parts, keep the lockfile, compress the rest into one file, and offer a dry-run restore that verifies the archive without writing anything — is a reasonable middle path that neither general cleaners nor the open-source alternative referenced above attempt. Whether it holds up on a genuinely large monorepo with native build artifacts and symlinks is untested by anything in this research; it's a feature to try cautiously on a low-stakes project first, which is also what the dry-run restore step seems designed to encourage.

What changed vs. before — and the blurred line the launch page doesn't draw

General-purpose Mac cleaners like CleanMyMac treat your whole disk as undifferentiated clutter: system caches, browser data, language files, "junk" — categories a non-developer user recognizes. DevCleaner's whole premise, and its FAQ says this explicitly when asked how it differs from CleanMyMac, is that it "knows developer caches... and labels what's safe per toolchain instead of treating every folder like temp files." That's a legitimate differentiation for the classic build-tool caches: a general cleaner genuinely doesn't know that ~/Library/Developer/Xcode/DerivedData is safe to nuke while ~/Library/Developer/Xcode/DeviceSupport is not.

But the 1.8/1.9 expansion into AI tool caches muddies exactly the distinction DevCleaner is selling. .cursor and .claude editor caches are the same kind of thing as a JetBrains index — metadata and compiled artifacts that rebuild transparently. Ollama and LM Studio model weights are not. A quantized 70B model can be tens of gigabytes, took real time and bandwidth to pull down, and in many cases isn't reproducible instantly on a residential connection the way a Gradle cache is. Listing "Ollama: downloaded LLM models" in the same 23-ecosystem grid as "pip cache" — without the page stating which risk tier model weights land in — is the single biggest ambiguity in DevCleaner's current pitch. If those are filed under Warning (not pre-selected), the safety model holds up. If a future release starts treating them as Safe because "the app can just re-download it," that's a materially different risk than losing a build cache, and it deserves to be called out rather than folded into the same "reclaim gigabytes" framing as everything else. As of this research, the product page doesn't specify the tier for AI model weights explicitly enough to settle the question either way — which is itself worth flagging.

Why developers should care

Cost. The free tier is genuinely functional, not a crippled trial: scanning, Quick Clean, Ghost Projects/Project Artifacts discovery, and restoring a hibernated project are free forever with no account. Pro — Auto Clean, Smart Triggers (clean on app quit), and batch Project Hibernation — is $29 once (activatable on up to 3 Macs) or $19.99/year if you'd rather subscribe. Pricing a one-time purchase below roughly 1.5 years of the subscription option is a deliberately anti-subscription-fatigue stance, and it's worth noting because most 2026-era dev tools default to recurring billing by design.

DX. No account, no cloud sync, no telemetry dashboard to configure — you download a 4MB app and it works. For a category of tool whose entire value proposition is "trust me with delete permissions on your home directory," minimal friction to start is also minimal friction to abandon if something feels off, which is a reasonable trade.

Security and trust. This is the category's real cost, and it's not DevCleaner-specific: any tool that walks your home directory and deletes files needs your trust, and DevCleaner asks for that trust without a public source repository to audit. The FAQ's claims about a "hard deny-list" for credentials and session files are reassuring in wording but unverifiable from the outside. If you're the kind of developer who reads the diff before merging a dependency bump, that's a real gap — not a dealbreaker, but a reason to start with manual category selection rather than Auto Clean on day one.

Lock-in. Effectively none. It's a local utility with local config; there's no data to migrate out of and no subscription trap if you stop paying (Pro features simply stop, Free features keep working).

There's a broader economic point worth naming, too. DevCleaner is a single-purpose, bootstrapped utility competing in a category where the incumbent — CleanMyMac — is a much larger, subscription-first product with a marketing budget and a general-consumer audience to fund it. DevCleaner can't out-market that, so it's competing on specificity instead: knowing what a .claude cache is, what an Xcode archive costs to lose, what a stale Android emulator snapshot looks like. That's a defensible niche as long as the maker keeps pace with what developers are actually installing — which, per the version history, is exactly what's happened so far. It's also a fragile one: the moment a general cleaner adds a "developer mode" with even half this granularity, DevCleaner's differentiation narrows to Project Hibernation and whatever ecosystem coverage it ships next.

Practical use cases

Reclaiming space before a big local model download or a large Xcode/Android SDK update, when you need headroom now and don't want to hand-audit ~/Library/Developer yourself.
Auditing what your AI coding tools are actually costing you in disk, if you've adopted three or four agentic editors (Cursor, Windsurf, Claude Code) plus a local-inference setup and have never actually measured the aggregate footprint.
Archiving side projects you're not actively shipping via Project Hibernation instead of leaving node_modules folders rotting on disk indefinitely or deleting a repo you might want back.
Onboarding a new machine or doing periodic hygiene as a Homebrew-adjacent habit — run Quick Clean monthly the way you'd run brew cleanup.

Limitations the launch page doesn't emphasize

macOS only. No Windows, no Linux — which quietly excludes a large share of backend and DevOps engineers who don't touch a Mac.
No public source code, for a tool whose entire function is deleting files based on internal path tables you can't inspect.
The AI-model-weights ambiguity described above — the page doesn't clearly separate "cache that regenerates in seconds" from "multi-gigabyte download that doesn't."
Thin, self-reported social proof. The five Product Hunt launch-day quotes and the 5.0-star in-app rating are both drawn from small samples (the star rating explicitly comes from 13 total ratings); treat both as early signal, not a verdict.
Solo-maintainer risk. One person, three products, no visible team. That's not a criticism of the software's current quality, but it's a real bus-factor consideration for anything you'd want long-term support on.
The headline "23.7 GB of build artifacts" claim on the landing page is DevCleaner's own marketing number, not an independently measured average — treat it as an anchor for what's possible on a heavy dev machine, not a guarantee of what you'll personally reclaim.

Competitive comparison

Tool	Scope	Dev-toolchain awareness	Price	Open source
DevCleaner	Dev caches + AI tool caches, project hibernation	High — 23 ecosystems, risk-tiered	Free core / $29 lifetime Pro	No
CleanMyMac	Whole-system cleanup	Low — treats most folders as generic junk	Subscription	No
DaisyDisk	Visual disk-usage mapping	None — shows you what's big, doesn't judge safety	One-time purchase	No
OmniDiskSweeper	Visual disk-usage mapping	None	Free	No
k-angama/macOS-dev-cache-cleaner	Dev caches (Xcode, Gradle, CocoaPods, npm/Yarn/Bun, browsers, design apps, workspaces)	Moderate — fixed category list, transparently documented	Free	Yes

The open-source alternative is the most useful comparison point precisely because it's transparent about exactly what it touches — its cache-path tables live in a single readable Swift file — at the cost of not covering AI tool caches or offering anything like Project Hibernation. If auditability matters more to you than breadth or polish, that trade is worth knowing about before you reach for DevCleaner.

Independent read

DevCleaner is a well-scoped, honestly priced utility solving a real and growing problem — and the growing part is the actual news here. Developer machines in 2026 don't just accumulate Xcode and Gradle cruft anymore; they accumulate Cursor indexes, Claude Code session data, and locally-hosted model weights, and general Mac cleanup tools have no idea any of that exists. DevCleaner shipping scanners for .claude, .cursor, Codex, and Ollama within weeks of each other in July 2026 is a decent signal that a solo maker is tracking where developer disk usage is actually heading, faster than the incumbents in the category are.

The trust question is the real open issue, and it's not really about DevCleaner specifically — it's structural to the category. A closed-source app with delete permissions on your home directory asks for a kind of trust that a documented risk model and warm launch-day quotes can gesture at but not fully substitute for. That's a reasonable trade for most people cleaning up Gradle caches. It's a less obviously reasonable trade the moment "delete" extends to a 40GB model you'd have to re-download on a slow connection, and the product page doesn't yet draw that line as clearly as its own safety-tier framework implies it should.

Who should try it, wait, or skip it

Try it now if you're a Mac-based developer running multiple heavyweight toolchains (Xcode plus Node plus Docker plus a couple of AI coding agents) and you want a fast, free way to see the aggregate damage before deciding what to delete by hand.

Wait if you're specifically trying to manage local LLM model storage — until DevCleaner's page explicitly states the risk tier it assigns to Ollama/LM Studio weights, do that cleanup manually and only let DevCleaner touch the classic build caches.

Skip it if you're not on macOS, if closed-source software with filesystem-delete access is a hard no for your threat model, or if your disk problem is general clutter rather than developer-specific — in which case a visual tool like DaisyDisk or a system-wide cleaner is the better fit.

Given how quickly the scanner list has grown to cover AI coding tools, the more interesting question by year-end might not be whether DevCleaner is worth using today, but whether "AI tool cache management" becomes its own recognized subcategory the way "dev cache cleaner" barely exists as one right now.

What's actually eating your disk in 2026 — is it still classic build artifacts, or have local model weights and agentic-editor caches become the bigger line item on your machine?

Sources:

DEV Community