A disk cleaner that asks a model which files you can spare

Letting a model decide which files are junk

This is a desktop application that scans a drive, asks a language model which files are disposable, and presents the result. A second feature manages symbolic links, offering to move files to another drive and leave a link behind.

The problem is familiar. A disk usage tool tells you a folder is forty gigabytes; it cannot tell you whether that folder is a cache you can delete, a dependency directory that will rebuild itself, or the only copy of something. Making that judgement means recognising what a directory is for, which is pattern recognition over names and structure, and is plausibly something a language model is good at.

The architecture is described in three steps and is refreshingly plain. An existing disk usage scanner walks the location and loads the file tree into memory. A file-tree reading tool is exposed to the model, which explores and marks anything it considers disposable through a dedicated marking tool. The marks are then combined and displayed.

The audience is Windows users with a full drive who want a second opinion before deleting things, and who are comfortable configuring a model provider to get it.

Reusing a scanner rather than writing one

One decision deserves credit before anything else. The scanning is delegated to an established disk usage tool rather than reimplemented.

That matters more than it sounds. Walking a filesystem correctly is unglamorous and full of traps: junction points, permission failures, files that vanish mid-walk, hard links counted twice. A project that writes its own walker spends its first year finding those, and every bug produces wrong numbers that look plausible. Building on something already hardened means the sizes are as trustworthy as that tool's, which is a much better starting point than anything written to get a demonstration working.

The model's role is correspondingly narrow, and the narrowness is the good part. It is not given the filesystem, it is given a reading tool over an in-memory tree and a marking tool to record a verdict. Bounding a model to exploration and annotation, rather than action, is the right shape for this problem.

The repository is a Go application with a web-technology front end judging by its layout, with the application entry point, a backend package, a build directory and a test file at the root, plus agent instruction files, so the project is itself developed with coding agents.

Running it, and the two lines to read carefully

There is no package manager or build step documented. The quick start is five numbered steps: download the executable from the releases page, place it in a dedicated folder, launch it, configure the model settings, and scan.

Two of those steps carry more weight than their length suggests.

The first is that the application creates its data files in the executable's own directory after startup, which is why the README says to put it in a folder of its own. Ignoring that leaves state files scattered wherever you happened to save the download.

The second is the one to weigh properly: the README recommends running as administrator, noting that some deletion or migration operations may otherwise fail. That is an honest statement of what the tool needs, and it describes a configuration where a language model's judgement is connected to file deletion with elevated privileges. Those two sentences deserve to be read together rather than separately.

Distribution is Windows only at present, as the README states directly, and configuring the model provider is a prerequisite rather than optional, so there is an account and a per-use cost behind the scan.

What the README does not say about confirmation

The architecture description ends by saying the model's analysis is combined and displayed to the user, which implies a person sees the proposal before anything happens. That is the correct design and the README does not go further.

What is not documented here is the part that would settle the safety question. There is no description of an explicit confirmation step before deletion, no mention of whether deletions go to the recycle bin or bypass it, and no description of undo. For a tool whose whole purpose is removing files on a model's recommendation, those are the three things a cautious reader most wants stated, and their absence from the README is the gap to note rather than an indication they are missing from the software.

The migration feature raises the same question in a different form. Moving files to another drive and leaving a symbolic link behind is a genuine technique for reclaiming space, and it changes the shape of the filesystem in ways some software handles poorly. An application that follows the link is fine; one that inspects the path, or a backup tool that treats links differently from files, may not be. Centralised management of those links is offered, which suggests the author understood they need tracking.

Anyone trying this should do so on a machine where a wrong answer is recoverable, and should confirm the confirmation behaviour themselves before pointing it at anything important.

A conventional disk usage tool is the alternative

The alternative is the tool this one is built on, or any of the established graphical disk usage analysers: scan, look at the treemap, decide yourself.

The difference is who supplies the judgement. A conventional analyser reports sizes accurately and offers no opinion, so you get a precise picture and still have to know what a directory is for. For an experienced user that is usually enough, since they recognise the cache directories on sight and the whole exercise takes ten minutes.

This project adds an opinion, which is worth something exactly when you lack that recognition: an unfamiliar machine, a directory belonging to software you do not know, a system administered by someone else. It also introduces a component that can be confidently wrong, and being wrong about whether a file is disposable is not symmetric with being wrong about its size.

Take the conventional analyser if you already know what your directories contain, which most developers do for their own machines. Take this when the judgement is the part you actually lack, and treat its output as a shortlist to review rather than a decision to execute, which is how the displayed-results design appears to intend it.

MIT terms, and the state of the project

The application is MIT licensed, which is the permissive choice and raises nothing. The scanning tool it builds on carries its own terms, worth checking before redistributing a bundled build. This is not legal advice.

The repository includes documentation in English and Chinese, screenshots of the overview, the identified-files table, the model output and the migration view, and instruction files for coding agents alongside a test file and a build directory.

Publishing screenshots of the model's output is a small thing done right, since the question a reader has about a tool like this is what the analysis actually looks like, and a picture of the results answers it faster than a description.

Before running it anywhere that matters, three things in order. Put the executable in its own folder, because it writes state beside itself. Understand that the recommended configuration combines elevated privileges with model-driven deletion, and decide whether you want that on the machine in question. And verify for yourself what happens between a suggestion and a deleted file, because the README describes results being displayed and does not document the confirmation, recycle bin behaviour or undo that a reader would want to rely on.

Editorial conclusion

This tool fits someone facing a full drive on an unfamiliar Windows machine, where the missing piece is knowing what a directory is for rather than how large it is, and where a model's shortlist saves genuine time. A conventional disk usage analyser remains the better choice when you already recognise your own cache and build directories, since it reports the same sizes without introducing a component that can be confidently wrong. Put the executable in its own folder because it writes state beside itself, weigh the README's recommendation to run as administrator against the fact that model judgement is driving deletion, and confirm for yourself what happens between a suggestion and a deleted file, since the README describes results being displayed without documenting confirmation or undo.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vudsen/ai-disk-cleaner on GitHub