Apa Itu Lapisan Runtime yang Aman untuk Mac?

Apa yang sebenarnya dilakukan lapisan runtime yang aman

Lapisan runtime yang aman menggabungkan tiga hal: assertion keep-awake, pemantauan aktif, dan trigger pelepasan otomatis. Bagian assertion adalah separuh yang mudah — tool apa pun bisa memanggil IOPMAssertionCreateWithName dan menahan lock kIOPMAssertionTypePreventUserIdleSystemSleep; macOS tinggal menjalankan perintah itu. Separuh yang lebih sulit adalah memutuskan kapan tahanan itu harus dilepas: saat baterai terlalu rendah, saat chip kepanasan, saat pekerjaan yang jadi alasan Mac tetap menyala ternyata sudah selesai.

LidRun adalah salah satu implementasi dari pola ini. Ia menahan assertion tersebut, melacak persentase baterai dan status AC/baterai, membaca sinyal suhu dari macOS, dan memantau status proses — lalu melepaskan assertion begitu ambang batas yang dikonfigurasi terlampaui. Mac tidur saat memang seharusnya tidur, mengikuti aturan yang Anda (atau default bawaannya) tetapkan — bukan karena kebetulan, dan bukan pula tidak pernah tidur sama sekali.

Sesuaikan kebutuhan dengan jenis pekerjaannya. Proses compile 20 menit di Mac desktop yang tercolok listrik nyaris tidak butuh semua ini — sleep memang tidak akan pernah terpicu. Proses AI agent selama enam jam di laptop bertenaga baterai yang bisa jadi memanas, bisa dicabut dari colokan, dan tidak ada yang mengawasi jam 2 pagi adalah situasi yang sama sekali berbeda — dan justru itulah yang menjadi sasaran pola ini.

Kenapa Mac Anda bisa tidur di tengah proses

macOS tidak bisa membedakan antara "tidak ada apa-apa yang terjadi" dengan "proses agent di latar belakang sedang berpikir diam-diam selama 40 menit tanpa input keyboard atau mouse." Keduanya terlihat identik di mata timer idle-sleep, yang memang dibuat khusus untuk menghemat baterai pada jenis kelambanan seperti itu. Dibiarkan dengan pengaturan defaultnya, timer ini akan terpicu di tengah proses.

Menutup lid adalah trigger terpisah yang lebih agresif. Tanpa monitor eksternal yang terpasang — atau tanpa sesuatu yang secara eksplisit memberi tahu macOS untuk mengabaikan sensor lid — menutupnya akan membuat Mac tidur hampir seketika, apa pun yang masih berjalan di baliknya.

Dan jika kedua hal itu tidak menangkapnya lebih dulu, Mac yang dibiarkan tanpa pengawasan dengan baterai lama-lama akan mencapai shutdown daya rendahnya sendiri saat baterai nyaris habis — bukan penghentian yang rapi, hanya kondisi apa pun yang sedang berlangsung saat daya benar-benar habis.

Cara bawaan yang gratis: caffeinate dan pmset

macOS sebenarnya sudah punya jawaban nyata untuk kasus pertama. caffeinate -i python train.py membungkus sebuah perintah, menahan assertion prevent-idle-sleep persis selama perintah itu berjalan, dan melepaskannya secara otomatis begitu perintah tersebut selesai — tanpa instalasi, tanpa konfigurasi. CLI wrapper milik LidRun sendiri sebenarnya meminjam bentuk yang sama: lidrun -- python train.py --epochs 100 membungkus perintah dengan cara yang identik; bedanya ada pada apa yang dilakukan LidRun terhadap tahanan itu selama masih aktif, dibahas di bawah.

Untuk kasus lid tertutup, jalur gratisnya adalah sudo pmset -a disablesleep 1 dengan monitor eksternal terpasang — trik klasik mode clamshell — lalu sudo pmset -a disablesleep 0 untuk mematikannya kembali setelah selesai. Ini adalah pengaturan dasar yang sama yang dipakai mode Closed-Lid milik LidRun sendiri; bedanya, LidRun selalu memasangkan 1 dengan 0 yang sepadan, saat stop, saat quit, dan sekali lagi saat aplikasi dijalankan berikutnya, untuk merapikan sisa apa pun akibat crash.

Keduanya sah-sah saja, dan untuk pekerjaan singkat yang diawasi langsung dengan daya AC, salah satunya sering kali sudah cukup. Jangan pakai tool yang lebih rumit dari yang sebenarnya dibutuhkan pekerjaan itu.

Di titik mana cara gratis ini kehabisan jalan

caffeinate sama sekali tidak tahu apa yang terjadi pada baterai Anda. Bungkus pekerjaan yang berjalan berjam-jam, tinggalkan, dan kalau baterai turun ke 2% jam 3 pagi, caffeinate masih tetap menahan assertion-nya — ia memang tidak pernah dirancang untuk tahu kapan harus melepaskannya.

pmset disablesleep lebih berisiko dalam satu hal spesifik: ini adalah pengaturan sistem yang global dan persisten, bukan sesuatu yang terbatas pada satu sesi. Butuh sudo. Dan ia tidak akan memasangkan dirinya kembali ke 0 dengan sendirinya — kalau apa pun yang mengaktifkannya crash, atau Anda sekadar lupa, Mac akan terjebak menolak tidur sama sekali, diam-diam menguras baterainya, sampai seseorang menjalankan perintah revert-nya secara manual.

Tak satu pun dari kedua tool ini membaca tekanan suhu. Tak satu pun tahu apakah proses yang jadi alasan penahanan itu masih benar-benar bekerja atau diam-diam sudah hang. Keduanya hanya menahan; keduanya tidak mengawasi. Celah itu — bukan cacat pada salah satu tool, hanya di luar apa yang memang dirancang untuk mereka lakukan — adalah yang ditambahkan oleh lapisan runtime yang aman.

Tiga sinyal yang benar-benar dipantau lapisan runtime yang aman

Status baterai bertingkat, bukan satu titik potong tunggal. Default LidRun: di bawah 15% saat lepas dari colokan, muncul notifikasi peringatan awal; di bawah 5%, peringatan yang lebih kuat; di bawah kira-kira 4% — batas keras yang tidak bisa diatur lebih rendah dari 4% berapa pun pengaturan Anda — LidRun melepaskan semua tahanan keep-awake dan meminta Mac untuk tidur, alih-alih membiarkannya hard-shutdown di tengah proses penulisan data. Batas itu ada supaya macOS punya cukup ruang untuk menulis state ke disk dan tidur dengan rapi.

Suhu dibaca dari ProcessInfo.thermalState — API publik (nominal / fair / serious / critical), tanpa entitlement khusus, tersedia sejak macOS 12. Itulah sinyal yang benar-benar menggerakkan keputusan auto-stop. Meski begitu, sinyal ini bisa tertinggal dari kenyataan: dalam pengujian LidRun sendiri, sinyal ini melaporkan "fair" padahal Mac yang dimasukkan tas sudah throttle sampai 24%. Karena itu, di tempat lain — pada Mac yang sensor SMC-nya bisa dibaca — LidRun juga melakukan cross-check suhu SoC yang sebenarnya dan persentase throttle CPU terhadap ambang batas yang sudah dikalibrasi, sebagai opini kedua yang tidak selalu bisa diberikan oleh kategori kasar dari OS saja. Begitu SoC benar-benar mencapai "critical," LidRun langsung melepaskan tahanannya; jika kondisi critical itu bertahan selama dua menit sementara Anda sudah menjauh dari keyboard lima menit atau lebih, atau lid tertutup secara fisik, LidRun akan meningkat ke langkah membuat Mac benar-benar tidur, karena Mac yang tersambung daya AC belum tentu idle-sleep dengan sendirinya.

Status proses mengaitkan tahanan itu dengan pekerjaannya sendiri. Auto Mode memantau proses tertentu — sesi Claude Code, agent Cursor, sebuah build — dan melepaskan begitu proses terakhir yang dipantau berakhir. Di bawah itu, Safety Governor yang independen bisa melepaskan sesi keep-awake mana pun, bahkan yang dimulai secara manual, jika Mac sedang memakai baterai, offline, dan tidak menunjukkan beban kerja aktif yang terkonfirmasi selama 15 menit, atau diam tanpa beban kerja terkonfirmasi selama 20 menit. Ini sengaja dibuat fail-safe hanya ke satu arah: pelepasan itu hanya terpicu pada ketiadaan pekerjaan yang TERKONFIRMASI, tidak pernah pada status yang tidak diketahui — build sebelumnya pernah melepaskan juga pada status "tidak diketahui," dan itu membuat Mac tidur di tengah sesi Claude Code; itu sekarang jadi aturan yang dipelajari dengan cara yang sulit, bukan sekadar tebakan.

Apa yang tidak dilakukan lapisan runtime yang aman

Ia tidak mengurangi konsumsi baterai yang sebenarnya. Membuat Mac tetap menyala dan berjalan selalu memakan daya lebih banyak dibanding membiarkannya tidur — itu berlaku untuk tool keep-awake mana pun, termasuk LidRun. Intinya bukan menghilangkan konsumsi daya sepenuhnya; tidur tetap menjadi kondisi paling efisien yang bisa dimiliki Mac. Intinya adalah proses berhenti pada batas yang sudah dipilih seseorang, bukan terkuras tanpa pengawasan sampai 0%.

Ia tidak menyelamatkan proses yang hang. Auto Mode dan CLI wrapper melepaskan tahanan saat proses berakhir, bukan saat proses "berhenti membuat kemajuan." Skrip yang macet tapi belum crash tetap terbaca sebagai berjalan. Untuk pekerjaan panjang tanpa pengawasan, gabungkan process-watch dengan batas baterai atau timer sebagai cadangan — jangan mengandalkan process-watch saja untuk menyadari ada yang benar-benar tidak beres.

Dan ia tidak mengendalikan pendinginan. Sinyal suhu bersifat read-only dari sudut pandang lapisan ini: ia bisa memilih untuk berhenti menahan Mac tetap menyala supaya macOS bisa throttle dan mendingin, tapi — khususnya di Apple Silicon — ia tidak bisa memutar kipas lebih kencang untuk mendinginkan mesin lebih cepat. Tempatkan Mac di area yang punya ventilasi baik; lapisan runtime yang aman adalah guardrail soal kapan harus berhenti, bukan pengganti aliran udara.

Lapisan runtime yang aman vs caffeinate vs Amphetamine vs pmset

caffeinate sudah termasuk dalam macOS, membungkus sebuah perintah, dan menahan power assertion selama durasi tetap atau sampai proses turunannya berakhir. Ia memang sejak awal tidak dirancang punya kesadaran soal baterai, suhu, atau status offline — itu bukan tugasnya. Untuk pekerjaan singkat yang diawasi langsung dengan daya AC, ia melakukan persis seperti yang dijanjikan.

pmset disablesleep adalah satu-satunya jalur gratis menuju Mac yang lid-nya benar-benar tertutup dengan monitor eksternal. Ini pengaturan yang kasar, khusus admin, berlaku untuk seluruh sistem, dan sama sekali tidak punya konsep sesi — ia tidak tahu apa yang memicunya, dan tidak akan mematikan dirinya sendiri kembali.

Amphetamine adalah aplikasi menu-bar yang dipoles rapi dengan jadwal, trigger, dan allow-list aplikasi — ia bisa memulai dan menghentikan sesi berdasarkan jam atau aplikasi mana yang sedang aktif di depan. Yang tidak dilakukannya adalah memantau persentase baterai secara live sebagai guardrail atau merespons tekanan suhu macOS di tengah sesi; itu memang di luar apa yang dirancang untuk dilacaknya.

Lapisan runtime yang aman menambahkan lapisan pemantauan di atas semua ini: batas baterai, sinyal suhu, proses yang berakhir, dan pemeriksaan offline/tanpa pengawasan, semuanya ikut menentukan apakah tahanan itu tetap aktif. Untuk build 20 menit yang tercolok listrik, caffeinate atau Amphetamine sudah benar-benar cukup — tidak perlu yang lebih rumit. Pola ini baru pantas dipakai pada proses panjang tanpa pengawasan, di perangkat keras yang kondisinya bisa berubah — baterai, suhu, jaringan — dengan cara yang tidak ada yang mengawasi secara real time.

Di mana posisi LidRun

Keep Awake, Timer, dan Charging-Only gratis di LidRun — tanpa batas, tanpa trial, tanpa batas sesi — dan sudah menjalankan loop intinya: menahan assertion, memantau eskalasi baterai bertingkat (15% / 5% / ~4%), membaca sinyal suhu, dan auto-stop pada salah satunya. Itulah lapisan runtime yang aman dasar, tersedia sejak instalasi.

Auto Mode (mengaitkan tahanan itu dengan proses yang dipantau seperti Claude Code atau Cursor) dan mode Clamshell lid tertutup termasuk bagian dari Pro, bersama kemampuan untuk mengubah ambang batas baterai dan suhu default alih-alih memakai default bawaan LidRun.

Jika pekerjaan Anda cocok dengan jalur gratis — satu sesi keep-awake, tercolok listrik atau diawasi secara manual — itu sudah benar-benar cukup; pakai saja. Jika ini proses agent tanpa pengawasan selama berjam-jam yang terkait dengan proses tertentu, atau lid perlu tetap tertutup, di situlah sisa pola ini (dan tier berbayar) mulai sepadan dengan harganya. Lihat rincian harga, atau baca bagaimana Safety Governor memutuskan untuk melepaskan sesi yang bukan ia mulai sendiri, untuk mekanisme di balik semua ini.