Amphetamine menu bar icon: hide it or keep it

The menu bar has filled up again and every icon in it is being reviewed. The keep-awake app is sitting there, gets pressed maybe twice a day, and looks like an obvious candidate for removal. Before deciding, it is worth noticing that this particular icon is not only a button. It also reports something, and how much that reporting is worth decides which of four options makes sense.

Two kinds of icon are sitting in the same row

Everything in the menu bar falls into one of two categories, and they deserve different treatment.

Some icons are buttons. They matter at the moment they are clicked and do nothing the rest of the time. Most menu bar items are like this. Hiding one costs nothing as long as there is a fast way to reach it when needed.

Other icons are indicators. Their value is in being visible. They report whether something is connected, whether a sync finished, whether a microphone is live. Hiding one of these does not remove a click, it removes a glance and replaces it with a check.

The keep-awake icon sits closer to the second group, because its appearance is how the app reports whether a session is currently holding sleep off. That is why "it barely gets clicked" is not sufficient grounds for removing it.

The strength of that argument depends entirely on how sessions get started. Someone who only ever flips the switch manually already knows the state, since they set it. Someone using conditional triggers, where sessions begin and end on their own based on displays, apps, or power, genuinely cannot know without looking. The same icon is an indicator for one person and a button for the other.

What the app itself offers

Before reaching for anything external, check what is adjustable inside the app. Its published feature list includes several things that change how the icon behaves in a crowded bar.

The menu bar icon can be replaced with a custom one. This is more useful than it sounds. When a row of icons is all the same weight and roughly the same silhouette, the time cost is not clicking, it is finding. Making one item visually distinct shortens the search without freeing any space.

Session time remaining can be shown, with both 12 and 24 hour formats supported. This runs in the opposite direction: text is wider than a glyph, so turning it on pushes other items closer to the edge. It earns its width only for people who routinely run timed sessions.

Hotkeys can start and end sessions, and separate hotkeys cover things like toggling display sleep. AppleScript support is also documented. Both matter here because they decouple control from the icon. Once a session can be started with a key combination, the only remaining reason to look at the icon is to read state.

Custom notification sounds are on the list too, which is a small but real alternative to a visual indicator. A sound at session start and end conveys the same information as a changed icon, without occupying width.

What macOS does, and where it stops

Apple documents two menu bar gestures. Holding Command and dragging an icon rearranges it. Holding Command and dragging an icon out of the bar removes that status menu quickly.

Both are written about the status menus macOS itself provides. What happens when an item supplied by a third party app is dragged out depends on that app, and in most cases the item is not removed that way. Removing one usually means turning it off in the app's own preferences or quitting the app entirely.

Rearranging is still worth doing. Putting frequently used items toward the left end of the group narrows where the eye has to search. But rearranging changes order, not capacity. The number of items the bar can show is fixed by available width: items fill in from the right, the application menus grow from the left, and once they meet, anything further is not drawn.

That last detail is the source of a persistent misdiagnosis. An item that cannot be drawn does not appear dimmed or truncated. It is simply absent, indistinguishable from an app that crashed. People start troubleshooting a working app because the failure mode of running out of width looks identical to the failure mode of not running.

The notch changes the arithmetic

On a MacBook with a notch, the usable width is not one continuous run. The notch occupies the middle, so menus growing from the left and icons filling from the right both terminate against it rather than against each other. The ceiling arrives sooner, and on machines with many background apps it arrives well before the icons stop being useful.

There is a second effect that confuses people. The left side is not fixed: different applications have different numbers of menus, and some have long ones. Bring a text heavy application to the front and the menus extend further right, which can push one more icon out of view. An item that vanishes only while a particular app is frontmost is explained entirely by this, and nothing is wrong with the item.

The available responses are the same three in every case. Reduce the number of items competing for the space. Reorder so that whatever must stay visible sits where it will not be the first casualty. Or collapse the row so the count of visible items no longer tracks the count of running apps.

Clear the system's own items first

There is a step that usually precedes any decision about a specific app, and it costs nothing.

Not everything in the menu bar comes from an application. System Settings has a Control Center pane listing items such as Bluetooth, Sound, Focus, Screen Mirroring, and accessibility shortcuts, each with its own choice of always showing in the menu bar, showing only when active, or not showing at all. Turning off the ones that are never used frees space immediately, with no software installed.

Doing this first is not just tidiness. The number of slots it frees changes the decision that follows. Free three and the keep-awake icon can stay visible without crowding anything. Free none and the question moves on to whether background apps should be reduced or their icons collapsed.

The sequence worth following is system items first, then each app's own preference for showing its item, then a collapsing tool for whatever is left. Starting at the third step means solving with software what a settings pane would have solved for free.

Four options, and the two questions that choose one

With all of that established, there are four ways to handle this particular icon.

Quit the app and launch it when needed. The slot is fully freed. The cost is launching it every time, and any conditional triggers stop running, because an app that is not running cannot watch for conditions. This suits someone who needs a keep-awake session a few times a month.

Leave it visible. State is always readable and the click path is as short as possible. The cost is one permanent slot. If enough other icons can be hidden, this is a complete answer and requires no further work.

Control it by hotkey and AppleScript, and stop looking at it. Sessions start and end from the keyboard. Better still, AppleScript support means a session can be started at the top of a script that begins a long export and ended when the script finishes, so nothing needs pressing at all.

Keep it running and collapse the bar. The app stays resident, so triggers and closed-display behavior keep working, while the slot is only occupied when wanted. The thing to verify here is how a hidden item is reached, since implementations differ. Where a hidden icon can be pressed and its menu opened without expanding the bar first, hiding costs nothing at all in daily use.

Two questions pick among these. Are conditional triggers in use, which rules out quitting entirely. And is session state something that needs to be seen, which determines whether hiding requires a substitute way to check.

Option	Slot freed	Triggers keep working	State visible at a glance	Ongoing effort
Quit until needed	Yes, completely	No	Not applicable	Launch every time
Leave visible	No	Yes	Yes	None
Hotkeys and AppleScript	Only if also hidden	Yes	No, needs a substitute check	Set up once
Keep running, collapse the bar	Yes, while collapsed	Yes	Only when expanded	Set up once

Reading down the columns makes the trade explicit. Only one option frees the slot without giving something up, and it is the one that requires a decision about how hidden items get reached. Only one option requires no setup at all, and it is the one that keeps the slot. The middle two are for people whose sessions are started deliberately rather than by rule, which is the larger group than the feature lists suggest.

Nothing here is permanent. Collapsing the bar is reversible in a click, hotkeys can be unassigned, and the app can be relaunched. Trying the option that fits the answers to those two questions costs an evening at most, and the wrong choice announces itself quickly: either sessions get forgotten, or the bar is still too full.

Checking state without the icon

If the answer to that second question is yes, a substitute exists and does not require the icon.

macOS tracks every process currently holding sleep off. Running pmset -g assertions in Terminal prints the list, naming each owning process and which assertion type it holds. A session that is active shows up there whether or not any icon is visible, which makes it a reliable check after collapsing the bar.

That command answers the inverse question too. When a Mac refuses to sleep and the reason is unclear, the same list names the responsible process, which is frequently audio output or a backup agent rather than the keep-awake app.

One more habit prevents most regret about hiding things: hide in a defined order. Start with items not clicked in the past week. Then items that are clicked occasionally but carry no state worth glancing at. Keep visible only the ones whose visibility is doing work. Where the keep-awake icon lands in that order depends on the trigger question above, and on nothing else.

What to change first

Open System Settings, go to Control Center, and switch off the system items that are never used. That takes a few minutes, frees real space, and tells you whether anything further is needed. If it is, decide between the four options using the trigger question, and if collapsing is the answer, check how hidden items are reached before installing anything. Koffret documents that behavior, How it compares sets out the axes worth comparing across this category, and the FAQ page covers macOS requirements and the permissions this kind of tool asks for.