Over the past few days, especially after the macOS 15.4 update, I encountered a frustrating power management issue with the Mac mini and Apple Studio Display. When the Mac mini entered sleep mode, after a while (1–2 hours), it would wake up to check for updates (legitimately), but then, rather than returning to the usual 1–2W while asleep, it continued to consume 14–15W. I couldn’t understand why, since the screen was off and the Mac appeared to be in sleep mode.
From my Grafana dashboard, you can clearly see the power-on pattern over the past 90-day period: after the macOS 15.4 update, it’s obvious that the computer (the Meross plug connected to the Mac Mini + Cinema Display) stays on for much longer periods compared to before (green = ON, gray = OFF).
And I’ve also created a Grafana alert that sends me a push notification if the Mac’s power drain stays over 10W for more than 2 hours. As you can imagine, it has been triggered a lot of times:
The Meross smart plug I’m using to monitor the computer’s power drain:
I began extensive debugging using the Terminal, smart plugs, and logs… and eventually identified the main issue: the Apple Studio Display, not the Mac mini, as I initially thought and I had wrongly assumed the problem was related to the Mac’s sleep behavior.
Symptoms and Observations
When the Mac mini went to sleep, the Studio Display didn’t behave as expected. Although the screen was black, my smart plug connected to the Mac Mini and Cinema Display, consistently reported 14-15W of power draw. This was far above the normal standby power usage, which should have been around 1–2W.
So, to identify whether anything was preventing proper sleep, I started checking the power settings I had configured:
Giulio@MacMini ~ % pmset -g
System-wide power settings:
Currently in use:
standby 0
Sleep On Power Button 1
autorestart 0
SleepServices 0
powernap 0
networkoversleep 0
disksleep 10
sleep 1 (sleep prevented by coreaudiod, bluetoothd, powerd)
ttyskeepawake 0
displaysleep 5 (display sleep prevented by Friendly Streaming)
tcpkeepalive 0
lowpowermode 0
womp 0
(note that these aren’t the standard settings, for example I disable the ttyskeepawake or tcpkeepalive)
And: pmset -g assertions
Giulio@MacMini ~ % pmset -g assertions
2025-04-11 13:19:27 +0200
Assertion status system-wide:
BackgroundTask 0
ApplePushServiceTask 0
UserIsActive 1
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
ExternalMedia 0
InternalPreventDisplaySleep 1
PreventUserIdleSystemSleep 1
NetworkClientActive 0
Listed by owning process:
pid 382(bluetoothd): [0x000014a400019cf2] 00:00:14 PreventUserIdleSystemSleep named: "com.apple.BTStack"
pid 382(bluetoothd): [0x0000140100099c0e] 00:02:57 UserIsActive named: "Bluetooth HID Activity"
Timeout will fire in 423 secs Action=TimeoutActionRelease
pid 663(sharingd): [0x0000145d00019cd0] 00:01:25 PreventUserIdleSystemSleep named: "Handoff"
pid 390(WindowServer): [0x0000140100099c0f] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:10000105b service:AppleHIDKeyboardEventDriverV2 product:Mac Mini Magic Keyboard eventType:3"
Timeout will fire in 600 secs Action=TimeoutActionRelease
pid 333(powerd): [0x0000140100019c11] 00:02:57 PreventUserIdleSystemSleep named: "Powerd - Prevent sleep while display is on"
pid 333(powerd): [0x000014a600109cf4] 00:00:12 InternalPreventDisplaySleep named: "com.apple.powermanagement.delayDisplayOff"
Timeout will fire in 288 secs Action=TimeoutActionTurnOff
Kernel Assertions: 0x24=USB,THNDR
id=549 level=255 0x20=THNDR mod=11/04/25, 13:18 description=acio0 owner=AppleThunderboltHALType5
id=559 level=255 0x4=USB creat=09/04/25, 23:59 description=com.apple.usb.externaldevice.04300000 owner=USB3 Gen2 Hub
id=561 level=255 0x4=USB creat=10/04/25, 00:02 description=com.apple.usb.externaldevice.04100000 owner=USB2 Hub
All these logs seem legitimate, there’s nothing unusual, except for a few entries related to the Studio Display:
Kernel Assertions: 0x24=USB,THNDR
id=549 level=255 0x20=THNDR mod=11/04/25, 13:18 description=acio0 owner=AppleThunderboltHALType5
id=559 level=255 0x4=USB creat=09/04/25, 23:59 description=com.apple.usb.externaldevice.04300000 owner=USB3 Gen2 Hub
id=561 level=255 0x4=USB creat=10/04/25, 00:02 description=com.apple.usb.externaldevice.04100000 owner=USB2 Hub
So I started checking hardware-level assertions:
pmset -g assertions | grep -i 'usb\|thndr\|display'
id=561 level=255 0x4=USB description=com.apple.usb.externaldevice.04300000 owner=USB3 Gen2 Hub
id=563 level=255 0x4=USB description=com.apple.usb.externaldevice.04100000 owner=USB2 Hub
id=539 level=255 0x20=THNDR description=acio0 owner=AppleThunderboltHALType5
This confirmed that the Thunderbolt interface (used by the Studio Display) remained active. But I absolutely couldn’t figure out why (spoiler: and I still haven’t).
I tried updating to the 15.5 beta but nothing changed and the same issue persisted. So I decided to do a clean install from scratch, since I just couldn’t figure out the problem. But even in this case, nothing changed: right after the first reboot, once the Mac mini went to sleep (1–2W power drain), it woke up and continued drawing a steady 14–15W.
Knowing that the Studio Display basically has an iPhone inside (it has an A13 chip), I thought that might be the issue but unfortunately there’s not much to investigate: there isn’t even a power button!
I tried leaving it powered off with the plug disconnected for several hours (which should reset it), but that turned out to be useless too.
To gain better insight, I connected the Studio Display to a smart outlet that logs real-time power usage. After several wake/sleep cycles, a pattern emerged: any brief wake (caused by cloudd, sharingd, Bluetooth events, etc.) would power up the Mac mini and the connected Studio Display. But while the Mac mini re-entered sleep mode, the Studio Display wouldn’t fully return to sleep afterward. Power draw remained consistently high until manually unplugged.
Final confirmation
By manually powering off the smart plug under the Studio Display after it woke up, I confirmed the system’s behavior: the Mac was asleep, and the display was the only device continuing to draw significant power (14–15W). After turning off the smart plug, the power drain dropped again to 1–2W. So the Mac Mini was correctly re-entering sleep mode—but not the display.
This power drain wasn’t due to external USB devices or peripherals connected to the display, and nothing was plugged into it other than the Thunderbolt cable. It appeared the Studio Display stayed semi-awake due to Thunderbolt activity, even when the Mac itself correctly entered sleep.
Conclusion and workaround
This issue highlights how the latest macOS release (15.4) interacts with Thunderbolt displays: while the Mac itself goes to sleep correctly, the Studio Display continue consuming power silently in the background. Over time, this can lead to significant energy waste, especially on desktop setups that remain plugged in 24/7.
Recommended workaround: use a HomeKit-enabled or other smart plug to cut power to the Studio Display when the Mac enters sleep. You can automate this behavior using Shortery for macOS, which can run shortcuts when the Mac goes to sleep or wakes up.
Until Apple offers more transparency or firmware improvements, this seems to be the most reliable method to truly reduce energy consumption and keep the display off.
Let me know if you’re experiencing the same issue. Unfortunately, you can only detect it if you’re using a smart plug with power consumption monitoring attached to your Mac + Studio Display. Otherwise the display could be on and drawing power while appearing off.