A long task may need sleep prevention, but a portable Mac should not ignore its remaining battery when external power disappears.
During a MacBaram experiment, external power disappeared while a keep-awake state continued without watching the remaining battery. The MacBook kept running until complete discharge. That made a battery boundary essential: while power is available or the battery remains above the safety band, MacBaram can honor the user's request to stay awake. At the lower boundary, it releases its sleep-prevention intervention and returns the machine to normal macOS power behaviour. The user's intention remains saved, and a separate recovery boundary prevents repeated switching before that intention can be restored. This policy does not guarantee task completion or longer battery life.
You start a local LLM job, a render, or a long build before going to bed. The first requirement sounds simple: do not let the Mac sleep while the job is running.
A basic keep-awake switch solves that immediate problem. The display can turn off while work continues. But a second question matters when nobody is watching: what should happen if a cable is removed, a dock stops supplying power, or the MacBook is left running on battery?
During our testing, a keep-awake state continued doing exactly what it had been told to do after external power disappeared. Because it did not watch the remaining battery, the MacBook kept running until it reached complete discharge.
Apple explains that delaying or preventing sleep can increase power consumption. Apple's power-management assertions are not absolute commands either; macOS can still sleep under low-power or thermal conditions. This reveals an important distinction: “the user wants this job to continue” and “the machine should remain awake right now” are not always the same decision.
If sleep prevention and battery management are separate switches, each can behave correctly on its own while the combined result is wrong. Sleep prevention keeps the job alive. Battery management watches the remaining charge. Without a shared rule, the first switch can remain active after the second condition has become more important.
The user chooses a battery cutoff for long-running work. While external power is available or the battery remains above the safety band, MacBaram can continue honoring the request to stay awake. If the battery reaches the lower boundary, MacBaram releases its runtime sleep-prevention intervention and returns the machine to normal macOS power behaviour. From that point, MacBaram is no longer the reason the Mac remains awake.
MacBaram does not erase the user's intention. It keeps “I want this job to stay awake” separate from “it is safe to enforce that request right now.” When power conditions recover, the runtime can restore the original intention instead of requiring the user to configure everything again.
MacBaram uses a small gap around the cutoff rather than switching at one percentage. Without that gap, a battery hovering near the boundary could repeatedly turn sleep prevention off and on. The lower boundary is used to step back; the upper boundary is used to restore. This simple control principle turns two unrelated toggles into one operating policy.
To verify the behaviour, test with a short, observable workload before leaving the Mac unattended. Confirm that the runtime intervention stops below the configured boundary, that macOS can resume its normal power decision, and that the saved intention is restored only after power conditions recover above the separate recovery boundary.
This design does not promise that every overnight job will finish, and it does not promise longer battery life. It makes a narrower claim: MacBaram does not treat “stay awake” as permission to ignore the battery.
That is what we mean when we say, “Sleep should understand battery.”
The story did not begin with a new sleep button. It began with a conflict between two valid goals: protect the user's long-running work and avoid keeping a portable Mac awake without regard for its remaining power. MacBaram's answer is to let the decision change with the condition of the machine.
If external power disappears, a keep-awake request can continue consuming the remaining charge while nobody is watching. A battery boundary lets MacBaram stop enforcing that request and return the decision to macOS.
No. MacBaram separates the user's saved intention from whether it is safe to enforce that intention right now. The runtime intervention can stop while the preference remains available for recovery.
A small gap prevents repeated off-and-on switching when the battery percentage moves around one boundary. MacBaram steps back at the lower side and can restore the saved intention only after conditions recover above the upper side.
No. The workload, network, storage, power source, macOS, and hardware can still interrupt work. This policy only limits when MacBaram itself enforces sleep prevention; it does not promise task completion or longer battery life.
