Launching today
FindDiskKiller
See which apps are hammering your Mac's disk
62 followers
See which apps are hammering your Mac's disk
62 followers
FindDiskKiller is a native macOS disk activity monitor that reveals which apps and AI coding agents are driving reads and writes. Track per-process disk I/O, CPU and network activity, inspect live file access, trace folders, and view SMART/NVMe drive health. Completely free and open source.
FindDiskKiller
FindDiskKiller
@hannesh Hey, thanks so much for the kind words and for giving it a try!
Funny enough, alerts were actually in the initial build — but I ended up removing them because constant popups got annoying really fast. So your timing on this question is perfect.
Here's what I'm currently thinking for the next iteration: instead of generic alerts, I want to add dedicated AI agent disk usage profiling — giving you a clear breakdown of what agents like Cursor are doing to your disk. I'm also exploring batch management features that tap into official AI agent APIs. And yes, alerts will come back, but in a way that's genuinely useful without being intrusive.
The guiding principle I'm holding myself to is: every small feature should be intuitive, simple, and just work. Would love to hear your thoughts when the updates land — and if you have any other pain points with Cursor's disk usage, I'm all ears.
the AI coding agent angle is what sold me, Cursor and Claude Code do generate way more disk churn than people realize until they actually look. one thing I'm curious about beyond the live view - does it keep any history so you can look back after the fact? like if my Mac was crawling 20 minutes ago but I only notice now, is there a timeline to check what was hammering the disk at that point, or is it strictly a right-now view
FindDiskKiller
@galdayan Really appreciate this comment — and honestly, the AI coding agent angle is exactly what drove me to build this.
Your suggestion about history is a great one. I'll be honest — when I first built this, I was laser-focused on answering one question fast: "what is hammering my disk right now?" So no, it doesn't currently keep any history. But you're absolutely right that tracking disk wear and size consumption over a longer time window would lead to much more convincing analysis and insights. I'm going to seriously consider adding this.
Along those lines, I've also been thinking about attributing directory size growth and SSD lifespan wear directly to specific processes. The tricky part is balancing that with performance — a disk analysis tool that becomes a battery drainer itself would be... not great, haha. Definitely something I need to weigh carefully.
Thanks again for the thoughtful feedback — this kind of input really helps shape where the tool goes next.
The live file access view is especially useful for debugging unexpected churn from AI coding agents. Does it group activity by workspace or project, so I can separate normal build and cache writes from a runaway process touching unrelated files?
FindDiskKiller
@adityaharish2002 Thank you — this is a genuinely thoughtful product suggestion, and I really appreciate you taking the time to share it.
I'll be honest about where things currently stand: the live file access view right now only shows real-time I/O throughput — it doesn't yet break things down by directory or analyze file-level space consumption within specific folders. So grouping by workspace or project isn't there yet.
That said, your suggestion is going to be incredibly valuable guidance for me when I build out the dedicated AI Agents disk space analysis feature. The idea of being able to separate "normal build/cache writes within a project" from "a runaway process touching unrelated files" is exactly the kind of clarity I want that feature to provide. Your framing of this as a workspace-level grouping problem really helps me think about how to structure it.
I've noted this down — thanks again for the depth of feedback. It's input like this that pushes the tool in the right direction.
the AI agent angle is a good hook, Cursor and Claude Code do churn through disk more than people expect. question about the monitor itself - with live file access inspection running, does FindDiskKiller add noticeable CPU or battery overhead if you just leave it open in the background all day, or is it light enough that it's not a tradeoff. would hate to fix one problem and quietly cause a smaller version of the same one.
FindDiskKiller
@omri_ben_shoham1 This is a really sharp question — and honestly, one I've been asking myself.
You're right to be concerned, and I won't pretend it's perfect yet. I've actually noticed more performance overhead than I expected during my own testing, and I'm actively working on optimizing it right now. My benchmark is simple: I want FindDiskKiller to use less resources than macOS Activity Monitor itself.
I'm aiming to ship a noticeably improved version within the next day or two.
minimalist phone: reduce your screentime
This is extremely helpful. Lately, I had to restart my Mac many times. I am suspicious about one particular app that is responsible for that, let's see whether I am right. Good solution for that :) Is it accur8?
FindDiskKiller
@busmark_w_nika Hey Nika, really appreciate you taking the time to comment!
Glad to hear the tool might be useful for your situation. I've been using it myself to track disk activity during Codex sessions, and it's been working well in that context. That said, I'm actively testing it across more apps and scenarios to catch any issues — there's definitely room to improve.
I'd love to hear whether it helps you identify the culprit on your Mac. If you run into any problems or have suggestions, please don't hesitate to share — if it's within the app's scope, I can iterate and ship a fix pretty quickly.
They’ve made AI coding agents completely opaque about on-disk activity. You see either the fan spinning, an out of space warning, or a build taking ages, but you can't actually see it doing anything. I like that this tool is focused strictly on attribution and does not aspire to be another ubiquitous system monitoring tool. The fact that this is open source is also kind of important - if you actually found AI-driven processes that are eating up gigabytes, you’d want to know what precisely that process is looking at.