I use OMLX to run my local AI and everyone in the comment section keeps telling me that it is going to kill my SSD and what is the status on it. So, I measured it. I built a simple web app over the course of 24h and it wrote 357 GB to my SSD. And I will show you why. That is about 15 years worth of usage before it gives up the ghost. OMLX will not kill your SSD. Now, you might have heard some sound effects in the intro to this video, and that is due to 11 Labs sound effects feature. I can prompt pretty much any sound effect that my heart desires. I can set the duration. I can even start directing it with 11 Labs helpful prompts. Here I am able to generate a ticker, a charging up sound and a deep bass drum for dramatic effect. It is available in their dashboard under sound effects and you can get started now in the link in the description. Thanks to 11 Labs for sponsoring this video. Local models are finally good enough for real agent work on a Mac and a lot of people are running them through OMLX. That is the video that I made. That is the one that I choose. It is fast because it saves the models working memory to a disc. And on a Mac, that disc is soldered to the board. If it wears out, you are buying a new Mac. And after running a real world test with SSD cache on versus off, the performance gains are very noticeable. This is the cache folder filling up while I work. OMLX keeps a recent context in RAM. When the RAM fills up, the oldest chunks get written to the SSD files. Coding agents send the same long prompt again and again. When that happens, OMLX reads those files back instead of working everything out from scratch. That is the difference between waiting 1 minute and waiting 1 second. Reading does not wear out your SSD. It is the writing. If a chunk is already on the disc, OMLX reads it. It does not write. So, the writes come from new context and not from chunks getting pushed out to RAM. But do not take my word for it or anyones forum posts. Measure it. Install smartmon tools with homebrew and run sudo smartctl -a disk0. You will only need 2 lines: data units written. It is everything this drive has ever written to it. Percentage used is the drives own guess at how much its life has used up. Write both down and use your Mac as normal with OMLX for 1 day and then run it again. The difference is your number. If you want to watch it live for some reason, Activity Monitors disc tab shows write as they happen. But if that just saved you an evening of burning forums, the like helps more than any of these. But here is my 24h. About 10h of Claude code on Qwen 3.8 27B. SSD cache capped off, so every cache chunk went straight to the SSD. This is pretty much worst case. While it was working, my Mac wrote for about 32 GB an hour. The whole day, 357. That sounds like a lot. So, how much can the drive actually take? Apple does not publish its numbers, but Samsung rates its 990 Pro at 600 TB written for every 1 TB of storage, and those ratings are quite cautious in my opinion. The tech report ran 6 consumer SSDs flat out for 18 months. The first one died at about 700 TB. The last one kept going to 2.4 PB. Here is the report to back it up. If I had a day like that every weekday, that is about 82 TB a year. On my 2 TB drive, I would hit that rating in about 15 years. Even every single day, it is about 9. But I will have to replace this Mac long before then. So, if you have got a 512 GB Mac and you work like this every single day, you will hit the rating in under 4 years. On a 1 TB, it is about 7. And that is about where it won't kill your SSD stops being true. So, I want to know which Mac and what size SSD are you running local models on, especially if you are on the 256 or the 512. Tell me in the comments. It decides whether I do an external SSD setup next. So, where did all this confusion come from? If you remember back in 2021, M1 owners ran the same smartctl command and saw huge numbers. One Mac Mini owner reported 165 TB written in just 2 months. The headlines said M1 Macs were killing their own SSDs. Apple said the wear figures the third party tools were showing were wrong. Hector Martin, who kicked the whole thing off, said there was a real bug as well. Apple fixed it in macOS 11.4. So, it was half reporting a mistake and half a real problem. The usual explanation was swap memory. That is your Mac using the SSD as spare RAM when it runs out. And it was worse on the 8 GB machines. Swap matters for OMLX 2 because during my tests, OMLX hit its memory limit and my Mac pushed nearly 1.5 GB into swap in a single minute. That is on top of the cache. So keep an eye on memory pressure and activity monitor. If you are close to the limit, set to handle 1 run request at a time. You can do that in these settings here. Right. The thing that I teased in the beginning, the default cache size is auto. One user on a Mac with not much free space sent 4 8k token requests and watched it write 6.5 GB. No warning. The cap does not always hold either. People have seen 83 GB in a cache capped at 64. It goes over when you switch models because the old models chunks cannot be re-used and nothing clears them out. And the clear button in the dashboard has left gigabytes of files sitting there. And one more thing, the cache is made up from your prompts. It is not encrypted and it survives a reboot. If you paste the client code into an agent, it is on your disc. So, here is what I would do. 1, set a hard drive cap on the SSD cache in the settings. 2, if you have got a 256 or 512 GB Mac, point the cache at an external SSD. It is slower, but you can replace it. 3, if you want it gone, stop the server and delete the folder yourself. 4, turn on FileVault. And if you do not need the cache to survive a restart, hot cache only mode does not write to the SSD at all. So, to summarise, measure your writes, cap the cache. On a 2 TB Mac, the SSD will outlast the Mac. On a 512, move the cache to an external drive. OMLX will not kill your SSD. Leave it on the defaults and it will just fill it. If you are on a small drive and want to cache off your internal SSD, this next video shows how fast an internal drive really is for this. Now, I hope that clears everything up in the comments. Like, subscribe if you haven't already. Till next time, keep on vibing.