MemBar
Chrome ate your RAM. MemBar shows you exactly who — then quits it before Activity Monitor even opens.
Activity Monitor buries the real offender under a dozen scattered “Helper” rows and takes
three clicks to reach. MemBar sits in the menu bar as compact text — 24.1G —
and turns orange, then red, the instant memory pressure says so. Open the dropdown and the top memory
hogs are already grouped the way Activity Monitor groups them: Chrome's forty-two helper processes show
up as one row, not forty-two. Click the ×. It's gone.
Nothing else to quit up here — nicely quiet.
Same formula as Activity Monitor. Read straight from the kernel.
Most menu-bar RAM meters guess. MemBar reads the same host_statistics64 counters Activity Monitor itself reads, widens each one to 64-bit so a high-RAM Mac can't overflow the math, and checks real memory pressure — not a heuristic — every time the status item needs to decide whether to turn orange.
There's no public API for “which process is this, really.”
Chrome's renderer, GPU, and network helpers don't know they belong to Chrome — the OS does, but doesn't say so through any documented call. MemBar asks anyway, and has two fallbacks ready if the answer isn't there.
Ask the private API
responsibility_get_pid_responsible_for_pid, resolved at runtime via dlsym — stable since macOS 10.14, never assumed present.
Walk the parent chain
If that symbol is missing, proc_pidinfo(PROC_PIDTBSDINFO) → pbi_ppid, up to the topmost non-launchd ancestor.
Give up gracefully
If even that fails, the process becomes its own one-member group — never dropped, never a crash.
A dozen “Google Chrome Helper (Renderer)” rows in Activity Monitor don't tell you anything you can act on. MemBar's answer is to not show them to you that way in the first place.
Same safety net as Activity Monitor — plus a guard it doesn't have.
Force-quitting the wrong process is how you lose unsaved work. Every kill goes through a confirmation, a live pid check, and a name-matched sweep for stragglers — automatically, every time.
Every kill starts with an alert, not a silent SIGKILL. It names the app, how many processes are grouped under it, and exactly how much memory closing it will free — escalated wording for anything whose death takes your whole session with it, like loginwindow or WindowServer.
A pid can be reused by an unrelated process in the seconds between a menu refresh and a click. MemBar checks the root pid is still alive — and still the same process — before it sends anything.
Small surface. No surprises.
One status item, one dropdown, nothing running in the background you didn't ask for.
Menu bar awareness
Compact text like 24.1G turns orange under Warning, red under Critical — so you notice before a beachball does.
Grouped like Activity Monitor
Chrome's dozen helper processes roll up under one “Google Chrome” row, sized by their combined footprint.
One-click force-quit
Click the ×, confirm, done — the same forceTerminate() Activity Monitor itself calls.
Per-process popup
Hover a multi-process row to see each process individually, with its own ×, plus a red “Force Quit All.”
30-minute history
A clickable sparkline opens NOW / AVG / PEAK stats and a full graph with gridlines, a peak marker, and a hover crosshair.
Launch at Login
One checkbox, backed by SMAppService — no separate helper app or login-item bundle.
CLI debug dump
MemBar --dump prints the same numbers the menu shows, with no status item or event loop involved.
See what's eating your RAM.
Free, open source, and honest about what it needs to work.
Not on the App Store, and can't be — proc_*, sysctl, and kill all require running outside the App Sandbox, and every one of them is load-bearing for this app to work at all. The GitHub repo above is private during early access — the link is kept here for later, and the build-from-source steps in the README work the same way the moment you're in.