The LLM in ai-disk-cleaner marks junk files, and gdu has to load the whole tree first

The Go module is spelled ai-disk-cleanner

The module line in go.mod reads module ai-disk-cleanner, with the two letters a and n transposed. Everything else uses the correct spelling: the repository slug, the description on both language versions of the README, and the feature headings. The consequence is not cosmetic. A Go module path is the prefix on every internal import, so the misspelling is baked into the source tree of a program whose job is deleting files from other programs. It also means the module cannot be resolved by name from a proxy, which is fine for a self-hosted desktop application and quietly wrong for anything that later wants to import it. The rest of the manifest declares go 1.25.0 and nine direct dependencies, among them the Wails v2.12.0 desktop framework, gdu v5.34.0 for scanning, the OpenAI Go SDK v3.50.0, GORM with the SQLite driver, and modernc.org/sqlite, the pure Go SQLite build.

State lives in the directory you launched the executable from

Step 2 of the quick start says to place the downloaded .exe in a dedicated folder, and that the application will create its data files in the executable's current directory after startup. Not the user profile, not AppData, not a per-user config directory: the current directory. The database behind that instruction is visible in the manifest, since GORM is paired with gorm.io/driver/sqlite and modernc.org/sqlite, the pure Go SQLite implementation that avoids a cgo toolchain. That makes moving the application a data operation rather than a file copy. Launch the same binary from a downloads folder, from a shortcut whose working directory was never set, or from a different drive and you get a second set of state files, with the scan history and whatever the model decided in the first location still sitting there. The dedicated folder instruction is not advice about tidiness; it is what keeps one database from becoming several.

Elevation is a requirement for the migration panel, not a convenience

The second named feature is migration management: centralized management of symbolic links plus one-click file migration to other drives. That is the half of the application that needs an administrator shell, and step 3 of the quick start says so plainly, recommending elevation because some deletion or migration operations may fail without it. A symlink-based move is not a copy and then a delete. It relocates the data and leaves a link standing where the file used to be, so every application holding a path to that file keeps working while the bytes live somewhere else. Doing that across drives means creating links that point off the original volume, which is exactly the class of operation a desktop process cannot perform without elevation. The README does not describe how a failed migration is rolled back, and it does not say whether the link list is exported before a move, so the safety of the operation depends on behaviour that the documentation leaves open.

Step one loads the entire file tree into memory before any model sees it

The architecture is three steps, and the first is the one with a capacity ceiling. gdu scans the specified location and loads the file tree into memory. Not a summary, not a depth-limited walk: the tree, held, before anything else happens. gdu is pinned at v5.34.0 and is a direct dependency rather than something invoked from a shell, so the scan runs in-process and its memory lands in the same process that will host the desktop window and the model client. On a drive with hundreds of thousands of entries, that resident tree is the floor under everything else. The location is chosen by the user, so the tool never has to walk a whole volume by default, but the step as written gives no guidance on which locations are safe. Anything below the chosen path is fair game for the tree, including the kind of directory trees where entry counts grow with the square of depth.

add_trash_file marks a path and the deletion stays on your side of the screen

Step 2 exposes a file tree reading tool to the model and lets it hunt for trash. When it finds a candidate, the model calls the add_trash_file tool, and the source path given for that tool is backend/service/analyzer/tools.go. Step 3 combines the analysis results and displays them. Read together, the three steps put the model in a narrow role: it reads, it decides, it marks, and a human still presses whatever the application does next. That is the right shape for a tool that deletes files, and it is enforced by where the write happens rather than by a prompt asking for caution. The schema machinery behind those tool definitions is also visible: invopop/jsonschema v0.14.0 is a direct dependency, which is what generates the JSON schemas an OpenAI-compatible function-calling endpoint expects, and openai-go/v3 v3.50.0 is the client. The README says the Settings page configures the LLM parameters without naming an endpoint.

Release tags are date shaped and there is no project homepage

Three releases are published: v26.5.1 on 2026-09-09, v26.4.1 on 2026-08-28 and v26.4.0 on 2026-08-13. The scheme reads as year, then a sequence within that year, then a patch, so v26.4.0 and v26.4.1 are two builds of the fourth 2026 release and v26.5.1 is the fifth, three weeks after the fourth. Four tagged builds landed between mid-August and mid-September 2026, and the default branch, master, was last pushed on 2026-09-10, the day after v26.5.1. The licence is MIT and the repository carries no homepage field, so there is no site outside GitHub to check a release against. The English README is 197 words and its Chinese counterpart, README-zh_CN.md, sits beside it; the English one links to the Chinese version at the top, which is the only navigational aid the file offers.

The dependency list is far wider than two features would need, and it is all Windows

The quick start says the download is currently Windows only, and go.mod agrees in a roundabout way. Marked as indirect are libraries that exist for one operating system: go-ole for OLE and COM, godbus for the message bus, jchv/go-winloader for loading the DLL a Windows debugger needs, and go-toast for desktop notifications. There are also indirect entries with no obvious connection to disk cleanup at all: a terminal UI library, two in-memory caching and database stores, an HTTP framework, a WebSocket library, a compression library, a FlatBuffers package, and a sed-like text processor. Some of that belongs to gdu, which is a terminal program with more features than this application uses. The direct entry github.com/pkg/browser is pinned to a pseudo-version dated 2024-01-02 rather than to a release, so the browser-launching helper is frozen at one commit while everything else moves on a version number.

openspec/, project.json and dlv-connect.ps1 have no section anywhere in the README

The top-level listing is longer than the documentation. Alongside app.go, main.go, app_test.go and the backend, frontend, build and test directories sit an openspec/ directory, a project.json, an AGENTS.md, a .codex/ directory and a docs/ directory. None of them appears in the 197 words of English documentation, and there is no section describing what openspec/ holds or what reads project.json. The debugger story is more concrete: dlv-connect.ps1 at the root is a PowerShell script for attaching a remote debugger, which is the one repository file that tells you how the project expects a Go developer to work on it. The two app files at the root, app.go and app_test.go, are the only test artifacts named anywhere, and neither the README nor any documented command runs them. For a repository whose companion artifacts are a Chinese README and a MIT licence, that is the whole support surface.

Editorial conclusion

ai-disk-cleaner fits a Windows user who wants an audit trail before deleting anything, since the model only tags paths and the deletion stays on your side of the screen, and the migration panel treats file moves as symbolic link rewrites that want administrator rights. It does not fit anyone who needs a measured before-and-after, because the repository publishes no benchmark, no disk size the tool copes with and no list of what it considers junk. Before you trust a scan, confirm which LLM endpoint the Settings page is pointed at, launch the executable from a dedicated folder so its database does not scatter, and read the symlink list the migration view shows before you move a drive, since both operations need elevation and neither is reversible from inside the app.

Frequently asked questions

Official sources

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