Apple installed 84GB of jellyfish on my Mac. Duplicated.

Kimi K2 will have to wait

Yesterday I wanted to download the latest Moonshot model, Kimi K2 Instruct. A pretty promising model that I'd been wanting to test for days.

I went to make some space, checked the disk, and found this:

Disk: 927GB
Used: 644GB
Free: 283GB

Hmm. 283GB free isn't bad, but what the hell is taking up 644GB? I keep my Mac pretty clean, don't store movies locally, and use the cloud for almost everything.

I start investigating. And then I remember.

The 45GB of jellyfish

I already knew that Apple, in their infinite wisdom, had decided to include 45GB of animated wallpapers in macOS Sonoma. 4K videos at 240fps of floating jellyfish, breaking waves, northern lights, and various landscapes.

I didn't ask for them. I don't want them. But there they were.

What I DIDN'T know is what came next.

Plot twist: they're duplicated

Turns out macOS stores these videos in two different places:

# Copy 1: System
/Library/Application Support/com.apple.idleassetsd/Customer/4KSDR240FPS/
→ 42GB

# Copy 2: User
~/Library/Application Support/com.apple.wallpaper/aerials/videos/
→ 42GB

Eighty-four gigabytes. Of the same videos. Duplicated.

Because apparently Apple thought it was a good idea to have a system copy (owned by root) and a user copy (owned by fernando). The same 89 .mov files. The same UUIDs. The same content.

They're not hardlinks, they're real copies

I thought: "Okay, maybe they're hardlinks or APFS clones. Same files, same disk space, all good."

Nope.

# Different inodes = real copies
ls -i "/.../4KSDR240FPS/009BA758...mov"
→ 15543749

ls -i "~/.../aerials/videos/009BA758...mov"
→ 108602438

Copies. Real ones. Eighty-four gigs of jellyfish taking up real space on my SSD.

A 256GB SSD costs $200 extra

What pisses me off most is the context. Apple sells Macs with ridiculously small SSDs for the price they charge:

And then they go and install 84GB of duplicated wallpapers.

That's a third of a base MacBook Air SSD. A third of the disk for jellyfish videos nobody asked for.

The daemon that won't stop

The culprit behind this atrocity is a process called idleassetsd. It's the daemon that manages downloading and updating these wallpapers.

And here's the kicker: even if you switch to a static wallpaper, if you ever previewed the animated wallpapers at some point, idleassetsd downloads them all. And duplicates them. And if you delete them but the screensaver is still configured with aerials, it downloads them again.

There are people on Apple forums reporting that the process would fill their disk in an infinite loop. A restart would stop it temporarily, but it would start again.

Apple, of course, provides no way to manage this from the UI. You can choose which wallpapers you want, but you can't delete them from the same place.

The solution

Step 1: Make sure you don't have an aerial as your current wallpaper. I use a static image, so I'm safe.

osascript -e 'tell application "System Events" to tell every desktop to get picture'
# /Users/fernando/Documents/Wallpapers/once_more_into_the_fray.png

Step 2: Stop the daemon and delete everything.

# Stop the daemon
sudo launchctl bootout system/com.apple.idleassetsd

# Delete system copy
sudo rm -rf "/Library/Application Support/com.apple.idleassetsd/Customer/4KSDR240FPS"

# Delete user copy
rm -rf ~/Library/Application\ Support/com.apple.wallpaper/aerials/videos

# Restart the daemon (won't download anything if you don't use aerials)
sudo launchctl bootstrap system /System/Library/LaunchDaemons/com.apple.idleassetsd.plist

Step 3: Prevent it from happening again. This is optional but recommended if you're vindictive like me:

# Create empty and immutable directories
sudo mkdir -p "/Library/Application Support/com.apple.idleassetsd/Customer/4KSDR240FPS"
sudo chflags schg "/Library/Application Support/com.apple.idleassetsd/Customer/4KSDR240FPS"

mkdir -p ~/Library/Application\ Support/com.apple.wallpaper/aerials/videos
chflags uchg ~/Library/Application\ Support/com.apple.wallpaper/aerials/videos

The schg (system immutable) and uchg (user immutable) flags make it so even root can't write to those directories without removing the flag first. idleassetsd will try to write, fail silently, and go on with its life.

84GB recovered

After cleanup:

Before: 283GB free
After: 367GB free

Eighty-four gigs. A third of a base MacBook Air. Recovered.

Now I do have space for Kimi K2. And for Llama 3.3. And for Qwen 2.5. And for all the models I want to test.

There are too many models to test

And that's the point. We're in 2026. Every week a new model comes out that needs to be evaluated. DeepSeek, Kimi, Qwen, Llama, Mistral, Gemma... all competing for space on our disks.

I don't have time or SSD space for 4K jellyfish videos at 240fps.

Sorry Apple, but between your jellyfish and a 70B parameter model that helps me code, the choice is obvious.

The jellyfish are out.

The only good jellyfish is jellyfish salad. If you've ever tried 凉拌海蜇 at a decent Chinese restaurant, you know what I'm talking about. Crunchy, fresh, with that hint of vinegar and sesame. Now that's a good use of jellyfish.

4K videos taking up 84GB of my SSD, not so much.