Latent English한국어日本語简体中文繁體中文EspañolFrançaisDeutschItalianoPortuguês Home

The three safety tiers

Every item Latent tracks wears one of three badges for what happens if you delete it:

• R · Recoverable — it comes back: either re-downloaded from its source (proven against the registry at deletion time, where it matters) or rebuilt by the owning tool on next use. How it returns is on hover; it is not a decision you have to make. A green badge means exactly that — proven, and ready to tick.
• I · Irrecoverable — your work: chat transcripts, generated images, release records. Shown, never preselected.
• P · Protected — things Latent refuses to touch: signing keys, device backups, installed CLI binaries.

And a lock, which is not a fourth badge. An amber R with a lock is one whose class is a claim nobody has verified — usually an OS or tool cache. It is not your work and it is not promised to come back, so Latent will not take it without you opening the lock first.

So the letter and the colour answer different questions. The letter says what happens if the row goes — R comes back, I does not, P is never offered. The colour says who decides: green when Latent can act on its own evidence, amber when the call is yours. That is why an unproven cache stays R rather than becoming I — claiming it will not come back would be a guess in the pessimistic direction, with no more proof behind it than the optimistic one. Inside an expanded owner the green rows sit first, then a line reading yours to decide from here, then the rest; the owner's bar splits the same way.

Free to look, licensed to remove

Latent without a license is a full-strength viewer: scan as often as you like, explore the wheels and rings, watch growth over time, read the log. Nothing expires. Removing files is what a license unlocks — and recovery (undo, quarantine restore) always works either way, because the one thing this app will never do is hold your files hostage.

One-click Optimize

The Latent tab is the one-click action: the logo itself is the button, a progress ring wraps it while it runs, and the freed total lands when it's done. What it deletes passes two bars, not one: recovery must already be evidenced, and the item must be of the grade you wouldn't even notice losing — package caches whose vendor ships its own purge command, browser HTTP caches, thumbnail stores. Anything you'd have to re-earn (downloaded models, toolchains, plugins you installed) stays out of Optimize and waits in Space for a deliberate click. It is deliberately the same allowlist a connected AI assistant is limited to, so one click can never reach further than an assistant is allowed to.

Optimize never touches unverified rows, your own files, or protected paths; it never opens a lock for you; it never uninstalls apps or packages, unloads models, or empties the Trash. If some targets are held open by a running app, Optimize asks first — a checklist of the blocking apps, each quit politely (the app's own save prompts appear) only if you leave it checked; uncheck one and its files are simply skipped. Everything that moves goes to the Trash under a single undo manifest, and the guards re-run at the moment of deletion. The confirm sheet also lists what is being deliberately left alone, so the number you see is a floor, not a brag.

The proof ladder

"Safe to delete" is earned, never assumed. Latent uses four kinds of evidence, strongest first:

When a store mixes provable and unprovable content, Latent deletes only the proven part and tells you exactly what it kept and why. A custom fine-tune sitting next to downloaded models stays put, always.

The lock

Unverified items, your own files, and protected items carry a lock. Opening it is a deliberate act of consent: the row becomes selectable, the deletion is marked as forced in the record, and the confirm sheet flags it in red. Consent is scoped — a rescan clears every open lock. Latent never opens a lock for you, and connected AI assistants can't open one at all.

My files — Space's second pane

Caches are what Latent can prove things about; the space that's actually yours needs a different contract. The My files pane in Space surfaces six kinds of candidates, and every one of them follows the same rule: listed, never preselected, never touched by Optimize or an assistant.

• Old & Unused — files over 200 MB untouched for 6+ months (last-opened date when macOS has it, modification date otherwise). Managed media libraries — Music, TV, GarageBand — are never listed.
• Duplicates — byte-identical copies, proven by full checksum, not by name. The oldest copy is the keeper and is never listed — deleting every row shown always leaves one copy on disk.
• Screenshots — found by the flag macOS itself stamps on captures, so renamed screenshots are found and lookalike photos are not.
• Downloads — finished installers (.dmg/.pkg already past their purpose, in Downloads and on the Desktop) and abandoned partial downloads.
• Build artifacts — node_modules, Rust target, build/dist, virtualenvs inside your project folders. Claimed only next to their project marker (package.json, Cargo.toml, …), and a virtualenv without a requirements file stays locked — the package list would die with it. They carry R, but a rebuild costs time, so these never enter Optimize.
• iOS — device backups and downloaded iOS updates (IPSW). Both marked irrecoverable on purpose: an old backup can't be re-made, and Apple only serves currently-signed builds.

Quarantine

A few deletions are offered a safer route instead of the Trash — a 7-day quarantine — but only where the loss would be opaque or hard to reverse: protected items and unreadable "your data" stores. Everything else (unverified caches, your own listed files) goes straight to the Trash, where the Recovery row already states the risk. It is a recommendation, never imposed. During the window, restoring is one click from the Recovery tab. At expiry the item moves on to the Trash — and Latent records whether the owning tool recreated the path, building the evidence the claim never had. Prefer the direct route? Choose "Straight to Trash" in the confirm sheet; your call wins.

Getting it back — the Recovery tab

Everything that can come back lives in one sortable table, with the date it was removed:

• Quarantined — a protected or opaque store you chose to route through the 7-day window (recommended there, never imposed); one click puts it back exactly where it was.
• In the Trash — moved under an undo manifest; one undo restores an entire cleanup.
• Gone — the bytes are gone, but the exact command that brings them back was recorded the moment it went: a Docker image, a simulator runtime, an Ollama model, a Homebrew or pip package. Latent runs it for you — best-effort, honestly: if the registry no longer has it, needs a login, or the network is down, the failure says so in plain words and the recorded command stays in the list.

Green rows — a recorded re-fetch command, or a verified store the owning tool rebuilds on its own — can also be emptied right from Recovery — one row or all of them at once, behind an explicit no-undo confirmation — because their way back survives the bytes. Rows that would be gone for good never get that button; Finder keeps that decision.

Rows are grouped by stage — quarantine, Trash, gone — newest first, with the date an item entered each stage in that stage's column; sort by name, source or size, filter by stage, search by name, source or command. That last group is the point: the record outlives the Trash, so emptying the Trash costs you nothing you cannot deliberately get back. Commands only run in narrow, validated shapes; anything else is shown for you to copy.

The Trash stays yours

Latent moves things to the Trash and never empties it out from under you. It touches nothing it did not put there, and it discards nothing that has no way back. Overview's Trash card shows what's inside, and one button opens it in Finder.

Two places do offer to finish the job. Recovery empties rows one at a time, or all the safe ones at once — where "safe" means the row still carries a recorded re-fetch command, or the verified evidence that the tool rebuilds it. And Optimize offers it immediately after a run, for that run only. Optimize removes nothing but proven-safe items, so every row it moved re-fetches or rebuilds itself; sending you to Finder to reclaim the space would be the app losing its nerve about a decision it had already stood behind. The button names the count and the size, and asks once.

Everything else in the Trash — including whatever you picked yourself in Space — stays for you to judge, in Recovery or in Finder.

Reversible, or re-fetchable

File deletions go to the Trash, never straight to oblivion, and every run writes an undo manifest that restores exactly what moved. Simulator runtimes and Docker images are removed by their own tools, which have no Trash — those record the command that fetches them again before they go. Before a Space cleanup moves anything, four guards run: the owning tool isn't running, no running binary lives inside the target, no file inside is held open by any process, and nothing changed in the last 10 minutes. Guards re-check at the moment of deletion, not just at planning time. The Apps uninstaller runs its own pair — the app must not be running, and no file inside the target may be held open.

Apps — the uninstaller

Click an app to see every file its bundle identifier owns — bundle, caches, preferences, containers, launch agents. Latent pre-checks only what it can attribute with certainty; two kinds of rows are never pre-checked:

• "contains your data" (red) — the folder holds documents or databases, like a messenger's chat history — or anything Latent's own catalog classes as user assets, opaque disk images included: Docker's VM (every container and volume lives inside one file) is never pre-checked, no matter how certain the ownership. Owning a path and it being safe to delete are different questions.
• "name match — verify" (amber) — matched only by display name, which another app could share.

Checking an app's own box selects everything underneath it — after one question if any of it contains your data, and your answer is remembered for the session. An uninstall is one manifest: one undo restores the whole thing. If macOS demands admin rights for the bundle, Latent hands the job to Finder — you'll see the standard authentication prompt.

Docker & simulator runtimes — where nothing goes to the Trash

Docker keeps images, containers, volumes and build cache inside one opaque VM disk, so a file-level delete would be a factory reset — Latent lists that disk as your data and never preselects it. What the Docker pane offers instead is Docker's own removal of single items: an image, or the build cache. That removal is irreversible — it does not go to the Trash and there is no undo — so it has a confirm sheet that says so in those words, and Latent writes the record before running the command: what went, how big it was, and the exact docker pull line that gets it back. Images a container is using are refused, and volumes are never listed — a volume is somebody's database.

iOS simulator runtimes work the same way and for the same reason: a runtime is a signed Apple disk image, mounted live and tracked in Apple's own registry, so only simctl can remove it. Same contract — the sheet says it cannot be undone, the record keeps xcodebuild -downloadPlatform iOS, a runtime with a booted simulator is refused, and the one Xcode ships with is never offered.

Homebrew & pip

The uninstaller's other two sources manage what brew and pip --user installed — the stuff that quietly accumulates for years. A keg's symlinks and a wheel's scattered files make a Trash move a lie, so removal runs the vendor's own uninstall, and the undo manifest records the exact reinstall command instead. The same proof rule applies: before anything is removed, Latent checks that the registry (formulae.brew.sh / PyPI) still serves that name and version — no answer, no removal. Locked rows mean another package depends on it, it's pinned, or it came from a third-party tap. A Python user-site whose interpreter is gone (the classic ~/Library/Python/3.x leftover) is offered as one whole-folder Trash move with a normal undo.

Memory

No purge buttons, no health scores — macOS already compresses and pages idle memory, so "freeing RAM" mostly means paying to read it back. What's real is a forgotten app holding gigabytes, so the App memory card lists your own apps by actual footprint with a Quit button that is exactly Cmd-Q: the app raises its own save prompt, and nothing is ever force-killed. System processes are never listed. The tab also shows what unified memory is doing and which model daemons (Ollama, LM Studio, llama.cpp, ComfyUI…) hold weights resident. Every button runs the vendor's own command — ollama stop, lms unload --all, ComfyUI's /free, llama.cpp's router unload — so models simply reload on next use. Latent never force-kills anything.

AI assistants — MCP integration

Latent ships an MCP server, so any MCP-capable assistant can read your disk picture and propose cleanups. The server is the app binary itself:

Claude Code

Codex CLI

Gemini CLI

Grok CLI

The -- matters: it hands --mode mcp to Latent instead of letting Grok read it as its own flag. Grok can also check its side of the wiring for you — grok mcp doctor reports whether the server starts, whether the handshake completes, and how many tools it found.

Cursor, Claude Desktop, Windsurf, VS Code & anything else with a JSON config

Add this under the client's MCP servers section — ~/.cursor/mcp.json for Cursor, claude_desktop_config.json for Claude Desktop, .vscode/mcp.json for VS Code (VS Code nests it under "servers" instead of "mcpServers"):

{
  "mcpServers": {
    "latent": {
      "command": "/Applications/Latent.app/Contents/MacOS/Latent",
      "args": ["--mode", "mcp"]
    }
  }
}

The transport is plain stdio — no port, no daemon, nothing to keep running; the client launches the server on demand.

What to ask it

The server offers five tools, and you never call them by name — you ask in your own words and the assistant picks:

• latent_overview — “where has my disk gone?” Totals by owner and by tier.
• latent_items — “what could I clear over 500 MB?” Individual items with their size, tier and evidence.
• latent_clean — “clear the pip and npm download caches”. This is the only tool that moves anything, and it takes item keys the assistant got from latent_items — never a folder you named in passing.
• latent_duplicates — “any duplicate model weights?”
• latent_memory — “what is holding RAM right now?” Reading only; quitting an app is never the assistant's to do.

What leaves this Mac

An assistant sees paths, sizes, tiers and evidence labels — never file contents. But a path is information: if your assistant runs in the cloud, the names of folders under your home directory travel to it, the same as any file you paste into a chat. A local model keeps them on the machine. Latent itself sends nothing anywhere; it answers the client that launched it, over a pipe, and that client decides where the answer goes.

What an assistant can and cannot do

The assistant's powers are strictly smaller than yours: it can only touch verified R items — the same allowlist as one-click Optimize — and one rule is absolute: every deletion pops a confirmation panel on your screen, and only a human click approves it. No response, or nobody at the Mac, means no deletion. Ever. Assistants can never open a lock, never reach your own files, and never see file contents — only sizes, paths, and the evidence labels.

The panel counts down from two minutes in view. Let it run out and the answer is no — the assistant is told the human did not approve, and nothing moved. Nobody at the Mac has the same effect.

A removal an assistant proposed is a removal like any other: it goes to the Trash, it writes the same undo record, and it appears in the Recovery tab with the same one-click return. Nothing about the request coming from an assistant makes it harder to reverse.

Why do other cleaners promise bigger numbers?

Because they count everything that looks like a cache. Latent's number is smaller on purpose: every byte in it carries evidence — a registry answer, a recorded origin, a vendor contract, or an observed regeneration. The bytes without evidence are still shown; they're just yours to decide about, with the lock in your hand.

Activating a licence or beta key

Menu bar → Latent → Enter License…, paste your key, done. One key covers more than one Mac (a beta key activates on up to 2). Scanning never needed the key in the first place; deletion unlocks the moment the key lands. No account, no email, nothing else to sign into.

Moving to another Mac, and refunds

A purchased key activates on up to 3 Macs. If you sell or retire one, open Latent → Enter License… on it and press Release — the slot goes straight back to your key and you can use it somewhere else. Nothing on that Mac is deleted, and you can activate it again any time.

If a purchase is refunded or charged back, the key stops working for deletion at the app's next launch. Recovery never stops working. Undo, quarantine restore and Put Back are outside the licence entirely — a refund can take the product away, but it can never leave your files stranded.

Shortcuts

• ⌘1–⌘6 — Latent, Overview, Space, Apps, Memory, Recovery
• ⌘7 — jump to Recovery's quarantine rows
• ⌘Z — undo the last cleanup
• ⌘R — rescan
• Drag cards on Overview and Memory to rearrange; right-click to hide; hover the wheel and every chart for details

Questions?

In the app: Help → Send Feedback…. It sends your message plus the app and macOS version; the activity log goes along only if you tick its box, with your home folder name stripped first. Nothing is ever sent in the background — only that button sends. Or write to fattaillabs.ceo@gmail.com — we read everything.