How Hedroom works, step by step

Hedroom reads a few numbers from macOS, notices when one app has gone wrong, suggests one fix, and measures what happened after you accept it. Here is each step, with the thresholds it uses.

The numbers on this page come from Hedroom's own design documents and code. Where a number is a measurement, it says when and on which Mac. Hedroom has not been released yet, so none of this describes a public version.

1. Sample: what it reads and how often

All readings come from one sampler that runs off the main thread, so the app stays responsive. Each source is a separate piece of code behind an interface, which is also how it is tested with fake data. These are the sources:

The tick

A "tick" is one round of readings. How often it happens depends on what you are doing:

Settings has a "Check my Mac every" choice of 2, 5 or 10 seconds for the open-window rate; the background rates scale from it. Raw readings are kept for 48 hours. Everything stays on your Mac, in one database file in your Library folder. See Privacy.

2. Detect: what counts as a finding

Hedroom does not raise an alert because a number is big. It compares each app with how big that app usually is on your Mac, and it waits to see whether the change lasts.

Memory: Healthy, Strained, Critical

Hedroom shows one of three states. The thresholds are written down and tested.

Swap that is merely used never makes the Mac Strained, because macOS keeps old swap around. Only swap that is growing counts. High "used" memory with healthy pressure is Healthy. Why pressure, not used RAM explains the difference.

A leak: an app far past its usual size, for a while

For each app, Hedroom learns a usual size from your last 7 days of normal use. It flags a leak only when all of these hold:

• The app is at least 3 times its usual size. At 2.5 times it shows as "growing" and nothing more.
• It is at least 1 GB, or 6% of your RAM if that is larger.
• It has stayed there for 20 minutes in a row, or it keeps growing on a 30-minute trend.
• It is not on your never-touch list, not made by Apple (with a small exception for Apple apps you use yourself), and not an app the process library marks as normally large, such as a video editor or Docker.

Until Hedroom has learned an app for about 6 hours, it says it is still learning. For an app it knows by name it uses the typical size from the process library; for an unknown app it flags only a size of at least 15% of your RAM that is still growing, and says "unusually large" rather than a ratio.

Runaway CPU

A background app (not the one you are using) that averages 80% of one core or more for 3 minutes, and at least 3 times its own usual background CPU, is a runaway, unless the library marks it as normally busy (compilers, backups, video encoders, indexing) or it is on a call. It shows on Today after 3 minutes. A notification waits until it has lasted 10 minutes.

Noise control

The same finding about the same app notifies at most once every 6 hours. Non-urgent notifications stop at 3 a day. Dismiss one three times for an app, and Hedroom stops notifying about it and offers a never-touch entry.

3. Decide: one suggestion, then the safety gate

When there is more than one thing Hedroom could do, it ranks them by how much they would give back against how risky they are, and shows the top two. A force quit is never offered as a ranked fix.

Before any relaunch, quit, pause or move to efficiency cores, the request goes through one safety gate. The gate refuses when the target is:

• Hedroom itself (ignored silently).
• Made by Apple or living in a system folder, other than the Apple apps you use yourself, which you can relaunch or quit with a click.
• On your never-touch list.
• The app you are using right now, when a rule asks for a pause, move or quit.
• Playing audio, using the microphone, or a call app while a camera is on.
• A backup app while a backup is running.
• Not known to handle being paused, when a rule wants to pause or quit it and you did not pick the app yourself. Hedroom cannot reliably see unsaved work.
• An app that the library marks as unsafe to relaunch, during critical pressure.
• A force quit without a second, separate confirmation.

If Hedroom cannot check one of these (for example, the audio check fails), rules do nothing and a click asks you first. A refusal is shown with its reason, as a sentence like "Slack is on a call.", not as an error. Everything refused or done is logged. More in What Hedroom never does.

4. Act, with consent

The actions are small and reversible:

• Relaunch asks the app to quit, as ⌘Q does, waits, and opens it again.
• Efficiency cores lowers an app's priority so its work runs on the efficiency cores.
• Pause freezes an app until you switch back to it, or for 60 minutes at most. A small guard process resumes it even if Hedroom crashes.

A click on a button is consent for that action. A rule is consent you gave in advance, and every template ships off. A quit or a relaunch of an app that is not known to be safe always asks first. Nothing is ever deleted without your permission each time; cleanup moves files to the Trash. Fixes and Rules list every limit.

5. Receipt: before, after, and an honest verdict

Every action produces one receipt. Hedroom compares the readings from the 5 minutes before the action with the readings from 5 to 15 minutes after it, skipping the first 30 seconds (60 seconds after a relaunch) while things settle.

There are four honest outcomes:

• Measured. The change is at least the smallest Hedroom counts: 100 MB of memory, 10 percentage points of one CPU core, 0.3 W, or 50 MB of disk.
• No effect. The change was smaller than that, or in the wrong direction. The receipt says "No measurable effect." and takes no credit.
• Not measurable. Other apps changed too much at the same time (another app moved by more than 1 GB, a new app launched using over 500 MB, you quit other apps, the Mac slept, or power was plugged or unplugged). The receipt says so instead of taking credit, and it is left out of the totals.
• Cancelled. You undid the action, or Hedroom quit, before the measurement finished. Nothing is claimed.

Each receipt also carries a confidence level (high, medium or low). A low-confidence receipt is labelled "rough" and is not counted in totals. A receipt compares two time windows; it is not a controlled trial. To read one, see How to read a receipt.

Why memory pressure, not used RAM

A Mac that has been on for a while shows most of its memory as used, by design. macOS fills spare memory with cached files, because that makes the next thing you open faster, and hands it back the moment an app needs it. A full memory bar is not a problem. What matters is whether macOS is struggling to find room: that is memory pressure, together with how fast swap is growing. That is why Hedroom has no button that "clears" memory. Doing so forces macOS to throw away the useful cache. The guide on pressure and used RAM shows how to check this yourself in Activity Monitor.

What makes it cheap

Hedroom's budget is under 0.5% of one CPU core on average and under 80 MB of memory. What has been measured so far:

Read these as measured, not promised. It is one Mac, and parts of the runs were at the faster 2-second tick because that Mac was under memory pressure. The first run after install does a storage scan that takes a few minutes at up to one core, at low priority. Tabs other than Today were not all re-measured. Before the fixes recorded in the same notes, an open window cost 20 to 40% of a core; that was found by this testing and fixed. The raw files and the full write-up are in the repository's bench/results folder, and Settings shows Hedroom's own measured cost on your Mac. The release gate is the benchmark and an overhead run on the signed build, which has not happened yet.

What keeps it light: one sampler for everything, a slower tick when nothing is happening, per-app scans only every few ticks in the background, window content that is only built while a window is on screen, and animations that stop when the window is hidden.

What it refuses to touch

• macOS itself: anything signed by Apple or in a system folder. Hedroom explains these processes, such as kernel_task and WindowServer, and never pauses, slows or quits them. See kernel_task, WindowServer and other processes explained.
• The app in front of you, apps on a call, apps playing audio or using the microphone or camera, backup apps during a backup.
• Apps on your never-touch list.
• Your files, unless you confirm each deletion yourself. Cleanup goes to the Trash first.

The full list, with tests behind each line, is on What Hedroom never does. Next: every feature and its limits, how Hedroom compares, and the glossary.