MacBook Air Storage: The Silent Killer
Three days ago my MacBook Air had 2 GB of free space left. That is not “slightly uncomfortable”. That is end-of-runway territory. Applications were hesitating before opening. Browsers were freezing at random. Even simple tasks like previewing a PDF felt heavier than they should. The storage bar in macOS showed the usual vague culprit — “System Data” — occupying an alarming amount of space. It is very easy at that point to conclude that macOS has become inefficient, or that some mysterious background process is hoarding gigabytes.
But when numbers look suspicious, the answer is not emotion. It is measurement.
Instead of staring at the Storage UI, I opened Terminal and ran:
du -h -d 1 ~ | sort -hrThis command lists the size of everything in your home directory, sorted from largest to smallest. No categories. No storytelling. Just facts.
The first surprise was how misleading the visual storage breakdown had been. The real weight was not in “System” at all. It was inside my own user directory. From there, the process became forensic rather than reactive.
I drilled deeper:
du -h -d 1 ~/.*Hidden folders are where modern workflows leave their footprints. And I work with AI tools, Python environments, Node projects and CLI utilities. Each of these ecosystems is polite in isolation and greedy in aggregate.
The .cache directory alone was sitting at 16 GB. This is where pip downloads, transformer weights, temporary artefacts and miscellaneous application caches accumulate. Perfectly legitimate files. Perfectly unnecessary after a while. Clearing it was straightforward:
rm -rf ~/.cache/*Then there was .npm, carrying several gigabytes of package cache:
npm cache clean --forceThere were also traces of model environments I had experimented with earlier — folders created by local inference tools, each containing downloaded weights. Individually small. Collectively significant. The common pattern was clear: experimentation without pruning leads to silent expansion.
At this point, free space had improved meaningfully. But something still did not reconcile. The total size of visible folders did not add up to the disk usage being reported. That usually means one thing: something large is hiding one level deeper.
So I went back to the sorted list and looked carefully at the top entries. One folder stood out quietly: .gemini.
Inside it was a subdirectory called history. And inside that, a single session folder occupying 46 GB.
Forty-six gigabytes.
Not models. Not datasets. Not binaries. Just accumulated CLI history. One long, enthusiastic working session that had recorded every prompt, every response, every chunk of output. In AI workflows, especially when experimenting interactively, transcripts can grow without restraint. Nothing crashes. Nothing warns you. It simply keeps writing to disk.
Removing that one directory was almost anticlimactic:
rm -rf ~/.gemini/history/<hash_folder>When I ran df -h again, the number was clean and undeniable. From 2 GB free to 91 GB free. Same operating system. Same documents. Same applications. No reinstallation. No migration. No external cleanup software.
The experience reinforced something simple but important. Modern development environments — particularly AI-driven ones — are storage-heavy not because they are broken, but because they are productive. They cache aggressively. They log extensively. They preserve history faithfully. Over time, fidelity becomes accumulation.
The machine was never bloated. It was obedient. It stored everything I asked it to store.
The real lesson is not about deleting folders. It is about visibility. Storage problems are rarely dramatic failures. They are usually quiet arithmetic. Measure properly, inspect systematically, and remove what no longer has economic value.
In finance we audit balance sheets. On computers we should audit disk usage the same way — calmly, precisely, without blame.
My Mac did not need repair. It needed discipline.
And discipline, applied with a few well-placed commands, recovered 89 gigabytes of clarity.