Junie was still working.
Your Mac didn’t care.

Why your Mac sleeps while Junie is still going

macOS doesn’t decide when to sleep from CPU load. It goes by your idle time — how long since real keyboard or mouse input — plus the power assertions running processes hold. A Mac running a model flat out sleeps on exactly the same schedule as one sitting at an empty desktop, because from the sleep timer’s point of view they are identical: nobody has touched the keyboard.

That catches people out with cloud agents, where it at least looks plausible — the machine really is close to idle while it waits on a server, and a CPU meter says so. With Junie Local it is far less intuitive and much more expensive. The GPU is flat out, the fans are audible, the model is resident in memory, and the Mac still goes to sleep on schedule and freezes the run mid-token. Working hard has never protected a Mac from sleeping, and a local model makes that gap visible to you in a way a cloud one does not. To your tools it does the opposite — which is the next section.

Which one applies depends on how you run Junie, and JetBrains ships it in two forms:

• Junie CLI — use caffeinate. Launch it as caffeinate -i junie instead of junie. The Mac can’t idle-sleep while it runs, and the moment it exits, normal sleep is allowed again — nothing to remember to undo. Already on your Mac, free.
• Already started it? Find the process and hold sleep against that exact PID. Read the output before acting on it — Junie CLI can be installed several ways and the program name is worth confirming rather than assuming: ps -Awwo pid,comm,args | grep -i junie | grep -v grep, then caffeinate -i -w <pid>.
• Junie inside the IDE — caffeinate does not apply. There is no command to launch and wait on; the agent is a plugin inside a long-running application that stays open whether or not anything is running. A menu-bar tool like Amphetamine (free, Mac App Store) can keep the Mac awake while your IDE is open, which is a blunt instrument but a working one.

All of these are a fine choice if Junie runs for a few minutes here and there. The catch is the same as ever: none of them knows when the agent actually finished versus when it is sitting idle. You either stop it yourself, or it keeps your Mac awake — and your battery draining — long after the work is done. With a local model that second failure is the one to worry about, for the reason at the end of the next section.

JetBrains announced Junie Local on 2026-08-24: the agent runs a model on your own Mac instead of calling a server, switched on with /local inside Junie. Their requirements page asks for an M5 Mac, macOS 26 or newer (their table says >26), 64 GB of memory and roughly 40 GB of free disk; the weights themselves are about a 20 GB download. Check that page before assuming your machine qualifies — JetBrains say they are working the numbers down. The intuition most people have about this is backwards, in two ways that both cost money.

Backwards #1: it does not make the machine “obviously busy” to a keep-awake tool. The tempting assumption is that a local model pins the CPU, so anything watching CPU can finally tell working from idle. But JetBrains runs inference on the GPU, with specialised NPU optimisation on M5 — and a process’s CPU percentage, which is what ps reports and what any CPU-threshold rule reads, does not count GPU or NPU work at all. A Mac can be flat out on a local model without that showing up where such a rule is looking.

Backwards #2: there is still a server, it is just on your desk. JetBrains says the local server launches on its own and Junie switches over to it. So junie is a client talking to a separate local server process. What disappears is the network round-trip, not the client-waiting-on-a-server shape — and for detection that shape is the whole problem. Whether a CPU rule sees the work at all depends on how that server process is parented: a tool that sums the CPU of the agent and its children catches it if the server is a child, and misses it entirely if the server is launched independently.

The practical upshot: do not assume a local model is easier to detect, and do not trust a CPU-threshold rule with an unattended Junie Local run until you have watched it work on your own machine. Start it under caffeinate -i junie, which does not care about any of this.

And the safety half genuinely does get harder. Holding a laptop awake while it runs a local model is a different proposition from holding it awake while it waits on an API. You are keeping a machine from sleeping exactly when it is hottest and drawing the most power. The failure to plan for is not the Mac sleeping — it is the lid shut all night and the machine cooked: coming back to a laptop at 1%, or one that throttled itself to a crawl hours ago. Two settings matter and many tools in this category have both: a battery floor that releases the hold instead of draining to zero, and a thermal rule that backs off when macOS reports trouble. Free tools including Keepresso and LidRun ship both, and so do we — this is table stakes, not a differentiator. Refuse to run any of them unattended until you have found those two settings and seen what they are set to.

Junie Local details read from JetBrains’ announcement and requirements page, not measured on a Mac of ours — including the GPU/NPU and local-server points above, which is exactly why this page will not tell you a CPU rule works. Junie, including the CLI, reached general availability on 2026-06-17, and Junie has been a JetBrains IDE plugin for longer than that.