Smart Rules: otomatisasi if-this-then-that untuk daya dan pendinginan Mac

Smart Rules adalah lapisan otomatisasi if-this-then-that dari LidRun untuk daya Mac: Anda menetapkan sebuah kondisi — proses tertentu berjalan, baterai di bawah persentase tertentu, bodi Mac tetap panas, jendela waktu tertentu — dan begitu kondisi itu terpenuhi, LidRun menjaga Mac tetap terjaga, membiarkannya sleep, beralih ke profil pendinginan, atau mengirim notifikasi, tanpa Anda perlu menyentuh saklar apa pun. Ini pergeseran yang sama seperti termostat menggantikan saklar lampu: Anda cukup mendeskripsikan kondisi target sekali, dan aplikasi yang terus memeriksanya, bukan Anda yang harus mengingat-ingat. Berikut ini persis apa yang bisa dipantau sebuah rule, apa yang boleh dilakukannya, bagaimana orang-orang saat ini menambal ini sendiri dengan caffeinate dan pmset, dan di titik mana jalan DIY itu diam-diam membiarkan Mac tetap terjaga — atau tertidur — lebih lama dari yang seharusnya.
Mengapa satu saklar keep-awake saja tidak cukup
Sebuah saklar manual hanya punya dua kondisi, sementara satu hari kerja punya lebih dari dua masalah yang perlu diatasi. Mac yang sama yang harus tetap terjaga penuh selama build 40 menit, seharusnya bebas untuk sleep satu jam kemudian begitu tidak ada proses yang berjalan dan baterai menunjukkan 18 persen.
Biarkan keep-awake menyala untuk menutupi periode sibuk, dan Anda juga menahan Mac tetap terjaga selama periode idle — baterai terbuang, dan di meja yang sudah hangat, kipas berputar kencang tanpa alasan. Matikan di antara pekerjaan, dan Anda kembali harus mengawasi saklar itu, menangkap momen tepat saat pekerjaan panjang dimulai. Rule adalah titik tengah yang selama ini hilang: Anda menulis kondisinya sekali, LidRun terus memeriksanya, dan aksi hanya terpicu ketika kondisi itu benar-benar terpenuhi.
Cara gratis dan native untuk mengotomatiskan ini — dan di mana caranya gagal
Kebanyakan orang tidak langsung mencari aplikasi khusus, dan untuk pekerjaan sekali pakai memang tidak perlu. macOS sendiri sudah menyediakan dua alat nyata. caffeinate -i some-command mencegah idle sleep terjadi persis selama some-command berjalan, lalu berhenti sendiri begitu selesai — benar-benar alat yang tepat untuk satu pekerjaan foreground. caffeinate -s melakukan hal yang sama, tapi hanya selama Mac tersambung ke daya AC, yang sesuai dengan kebutuhan kebanyakan skrip build. Khusus untuk lid, sudo pmset disablesleep 1 adalah saklar yang sama yang dipakai mode Closed-Lid milik LidRun sendiri — perintah ini memberi tahu macOS untuk sepenuhnya mengabaikan pemicu clamshell-sleep, dan sudo pmset disablesleep 0 mengembalikannya seperti semula. macOS juga punya cara gratis tanpa Terminal untuk "membiarkannya tetap menyala dengan lid tertutup": sambungkan ke daya, pasang monitor eksternal, hubungkan keyboard atau mouse berkabel atau nirkabel, dan mode clamshell bawaan Apple akan menjalankan Mac dengan lid tertutup pada daya penuh tanpa software pihak ketiga sama sekali. Jika Anda menginginkan sesuatu yang lebih mendekati rule, aplikasi Shortcuts bisa memicu aksi "Run Shell Script" dari otomatisasi berbasis level baterai atau waktu tertentu, sehingga kejadian baterai-di-bawah-20% bisa memicu skrip yang memanggil caffeinate atau pmset untuk Anda.
Semua itu tidak salah, dan untuk satu pekerjaan saja jujur saja itu sudah cukup. Masalahnya muncul begitu Anda menumpuk lebih dari satu kondisi, atau lupa menutup loop-nya. caffeinate -i & yang dibiarkan berjalan di terminal background tidak tahu kalau pekerjaan Anda sudah selesai — ia menahan Mac tetap terjaga sampai Anda ingat untuk mematikannya, atau sampai Anda menutup lid pada Mac yang masih menyala penuh di dalam tas. pmset disablesleep 1 justru lebih berbahaya kalau terlupa: ia tidak punya batas waktu, tidak memantau baterai, dan tidak tahu bodi Mac sedang panas — ia tetap dalam kondisi disabled di boot ini dan boot berikutnya sampai perintah 0 yang cocok benar-benar dijalankan. Tidak satu pun dari alat native ini yang membaca suhu CPU (macOS tidak mengeksposnya ke skrip shell tanpa pembaca pihak ketiga), jadi skrip yang dibangun di atasnya sama sekali tidak punya cara untuk mundur ketika mesin benar-benar panas, dan tidak ada catatan apa yang terpicu atau kapan.
Kondisi-kondisi yang bisa direspons oleh Smart Rule
Sebuah rule dimulai dari satu atau lebih kondisi, dan LidRun mensyaratkan semuanya terpenuhi sekaligus — tidak ada OR di dalam satu rule; kalau Anda butuh logika "salah satu", buat dua rule dengan aksi yang sama. Sebuah kondisi bisa mencocokkan nama proses atau aplikasi terhadap sebuah pola (jadi sebuah rule bisa dipicu oleh Claude Code, Codex, Cursor, Ollama, Docker, sebuah build Xcode, atau skrip python — mencocokkan proses atau aplikasi yang berjalan secara persis atau sebagai prefix, tidak peka huruf besar/kecil), baterai di bawah atau di atas persentase tertentu, suhu yang tetap di atas angka derajat tertentu selama durasi tertentu, kondisi on-battery vs. on-AC, lid dalam keadaan tertutup, tidak ada workload yang cocok berjalan selama N detik, atau jendela waktu tertentu.
Mesinnya memeriksa ulang setiap 5 detik. Kondisi berbasis durasi — "suhu di atas X selama Y detik", "tidak ada workload selama N detik" — hanya menghitung waktu selama semua kondisi dalam rule itu terpenuhi secara bersamaan. Jika salah satu di antaranya lepas, walau sebentar saja (AC tercabut sedetik, workload sempat berhenti sejenak di antara langkah-langkah), timer-nya reset dan hitungan mundur mulai dari awal lagi. Ini memang disengaja: sebuah rule seharusnya bereaksi terhadap kondisi yang bertahan, bukan kedipan sesaat.
"Tidak ada workload yang cocok selama N detik" diperiksa terhadap daftar pola Auto-Watch yang sama yang Anda atur di Settings, bukan pola spesifik yang Anda ketik di rule itu — penting untuk diketahui kalau Anda memakainya untuk auto-release setelah pekerjaan kustom: tambahkan juga nama proses pekerjaan itu ke pola Auto-Watch Anda, atau rule tidak akan punya apa pun untuk dipantau hilangnya.
Suhu berasal dari key sensor SMC yang dibaca langsung oleh LidRun. Karena tidak ada satu key pun yang ada di semua Mac, LidRun mencoba serangkaian kandidat key dan mengambil pembacaan valid yang paling panas, jadi yang dibandingkan oleh sebuah rule adalah bagian mesin yang paling panas yang benar-benar bisa dibacanya, bukan tebakan. Jika sebuah Mac tidak punya sensor yang bisa dibaca untuk perbandingan itu, kondisinya sederhana saja tidak pernah bernilai true — rule-nya tetap dorman, bukan error.
Apa yang boleh dilakukan sebuah rule
Aksi-aksinya berputar di sekitar kendali milik LidRun sendiri, dan batasan itu memang disengaja: menjaga Mac tetap terjaga, menghentikan keep-awake, beralih ke preset pendinginan (Quiet, Balanced, AI Workload, atau Emergency Max) sesuai batas yang diizinkan hardware, mengirim notifikasi (dengan opsi push ke ponsel Anda), men-sleep Mac, memulai atau menghentikan mode Closed-Lid, atau mencatat sebuah note. Tidak ada pura-pura melakukan hal yang memang tidak diizinkan macOS untuk dilakukan sebuah aplikasi.
Kendali tulis ke kipas sebagian besar dibatasi di Apple Silicon oleh firmware dan SIP, jadi aksi pendinginan mengandalkan apa yang diekspos oleh hardware, bukan memaksakan kurva kipas manual; jika kendali kipas tidak tersedia di Mac Anda atau tier lisensi Anda, langkah pendinginan pada rule itu cukup dilewati saja, sementara aksi-aksi lainnya — keep awake, notify, sleep — tetap terpicu. Aksi pendinginan juga hanya pernah menaikkan, tidak pernah menurunkan: kalau Anda sudah mengatur kipas secara manual ke Max, langkah "switch to Balanced" pada sebuah rule tidak akan menariknya turun lagi. Hanya rule emergency-thermal yang memaksa Max terlepas dari apa yang sudah diatur, dan itulah yang mencegah sebuah rule rutin diam-diam membatalkan pilihan yang sudah Anda tetapkan secara sengaja.
Tidak satu pun aksi dari sebuah rule yang meminta konfirmasi begitu rule-nya sudah Anda aktifkan — termasuk Sleep-the-Mac dan mode Closed-Lid, dan itulah sebabnya teks aplikasi sendiri di Smart Rules memperingatkan Anda untuk mengaktifkan keduanya dengan sengaja. Apa yang dilakukan sebuah rule memang terlihat, tapi belum diberi label sebagai rule: memicu "keep awake" atau "sleep the Mac" menghasilkan entri Activity Log yang sama seperti aksi manual ("Keep Awake started," misalnya) — entrinya tidak menyebutkan rule mana yang memicunya. Jika Anda sedang menyetel rule baru dan ingin memastikan rule itu benar-benar terpicu, subsystem com.lidrun.app di Console.app, kategori RuleEngine, mencatat nama rule setiap kali dijalankan — tempat yang lebih tepat untuk dilihat saat Anda menguji ambang batas.
Smart Rules sendiri adalah fitur Pro dengan saklar utamanya sendiri, off secara default bahkan pada lisensi Pro. Auto Mode, di tier gratis, sudah memulai dan melepaskan keep-awake mengikuti pekerjaan yang terdeteksi; Smart Rules adalah lapisan kondisional di atasnya — pendinginan ekstra, notifikasi, atau sleep yang terkendali saat ada risiko nyata.
Mana yang preset bawaan vs. apa yang bisa Anda kustomisasi sekarang
LidRun hadir dengan 15 rule bawaan yang mencakup AI coding agent, AI lokal, dev & build, dan safety. Anda bisa mengaktifkan atau menonaktifkan masing-masing, tapi tidak bisa menghapusnya, dan lima di antaranya nonaktif secara default — LM Studio, Python, Node/npm, Xcode build, dan ffmpeg — karena pola interpreter yang luas seperti "python" atau "node" mencocokkan terlalu banyak proses yang tidak berhubungan untuk dibiarkan aktif begitu saja untuk semua orang.
Di sinilah builder di dalam aplikasi masih lebih terbatas saat ini: menambahkan rule kustom dari jendela Smart Rules sekarang berarti mengetik pola nama proses, yang menghasilkan satu bentuk rule yang tetap — proses itu berjalan membuat Mac tetap terjaga dan beralih ke pendinginan AI Workload. Kondisi persentase baterai, suhu-dan-durasi, lid, dan jendela waktu yang dibahas di atas semuanya sudah ada sebagai preset bawaan yang bisa Anda aktifkan, tapi builder visualnya belum memungkinkan Anda mengetik ambang batas Anda sendiri untuk kondisi-kondisi itu. Kalau Anda ingin rule baterai atau suhu kustom hari ini, preset bawaan adalah cara untuk mendapatkannya; rule-rule itu sendiri disimpan dalam sebuah file JSON polos di Application Support, kalau Anda nyaman mengutak-atiknya langsung.
Rule yang benar-benar akan diatur seorang developer
Tetap terjaga selagi bekerja, mundur begitu selesai: preset Claude Code, Codex, Cursor, dan Ollama masing-masing menjaga Mac tetap terjaga dan beralih ke pendinginan AI Workload begitu proses itu berjalan, dengan cooldown 5 menit supaya rule tidak terpicu ulang setiap tick selama pekerjaan masih berlangsung. Docker mendapat perlakuan yang sama tapi dengan pendinginan Balanced, bukan AI Workload. Padukan salah satu dari itu dengan rule bawaan "tidak ada AI workload selama 10 menit → stop keep-awake", dan proses model pull semalaman atau agent run akan melepaskan Mac dengan sendirinya begitu benar-benar idle, alih-alih membiarkan keep-awake menyala sepanjang sisa malam.
Dua preset safety aktif secara default dan tidak butuh pengaturan apa pun: baterai di bawah 10 persen, saat memakai daya baterai, mengirim notifikasi baterai rendah; baterai di bawah 5 persen, saat memakai daya baterai, langsung men-sleep Mac. Keduanya berjalan independen dari apa pun yang sedang dilakukan sebuah rule workload, dan keduanya berada di atas safety governor level-aplikasi yang sudah membatasi keep-awake berdasarkan baterai dan kondisi termal di bawah setiap rule.
Dua preset suhu menunjukkan pembatasan durasi dalam praktiknya: di atas 90°C yang bertahan selama 5 menit beralih ke pendinginan Emergency Max dan mengirim notifikasi "Mac running hot"; di atas 95°C yang bertahan selama 2 menit langsung melompat ke men-sleep Mac. Keduanya membutuhkan pembacaan yang tetap tinggi secara terus-menerus selama itu, jadi lonjakan singkat yang normal selama build tidak akan memicu keduanya. Sirkulasi udara dan di mana Anda meletakkan Mac tetap menjadi tanggung jawab Anda — sebuah rule bereaksi terhadap angka, ia tidak bisa memperbaiki tas yang tertutup rapat.
Untuk apa pun di luar pola bawaan — vllm, Blender, skrip training dengan nama binary yang aneh — mengetik nama itu ke "Add a custom rule" langsung memberi Anda keep-awake plus pendinginan AI Workload dalam satu langkah. Kalau Anda juga ingin pekerjaan itu menghormati batas bawah baterai atau jendela waktu tertentu, aktifkan preset safety bawaan yang sesuai di sampingnya, alih-alih mengharapkan satu rule melakukan semuanya hari ini.
LidRun menjaga pekerjaan Anda tetap jalan saat layar tertutup, dengan perlindungan baterai dan suhu bawaan.
Sudah punya LidRun? Baca panduan setup-nya →
Baru kenal LidRun? Lihat harga →
Sering ditanyakan
Proses atau aplikasi yang cocok sedang berjalan, baterai di bawah atau di atas persentase tertentu, suhu di atas angka derajat tertentu selama durasi tertentu, kondisi on-battery vs. on-AC, lid dalam keadaan tertutup, tidak ada workload yang cocok selama N detik, dan jendela waktu tertentu. Semua kondisi dalam satu rule harus terpenuhi sekaligus — tidak ada OR di dalam satu rule; gunakan dua rule untuk logika salah satu.
Tidak. Aksi-aksinya adalah kendali milik LidRun sendiri — keep awake, stop keep-awake, beralih ke preset pendinginan sesuai batas yang diizinkan hardware, notify, sleep, atau toggle mode Closed-Lid. Kendali tulis ke kipas sebagian besar dibatasi di Apple Silicon oleh firmware dan SIP, jadi aksi pendinginan bekerja dalam batasan itu; jika kendali kipas tidak tersedia, langkah itu dilewati dan aksi-aksi lain pada rule tetap berjalan. Aksi pendinginan hanya menaikkan, tidak pernah diam-diam menarik turun kembali pengaturan Max yang sudah diatur manual.
Ya — preset bawaan men-sleep Mac saat baterai di bawah 5 persen dan mengirim notifikasi di bawah 10 persen, keduanya saat memakai daya baterai, independen dari apa pun yang sedang dilakukan sebuah rule workload. Safety governor milik LidRun sudah membatasi keep-awake berdasarkan baterai dan kondisi termal di bawah setiap rule, jadi ini bukan satu-satunya lapisan pengaman.
Gunakan "tidak ada workload yang cocok selama N detik". Kondisi ini menunggu sampai daftar pola Auto-Watch Anda (di Settings) menunjukkan tidak ada apa pun yang berjalan selama waktu itu sebelum terpicu, jadi jeda singkat di antara langkah-langkah tidak memicunya lebih awal. Kondisi ini memantau daftar Auto-Watch global Anda, bukan pola yang diketik ke rule spesifik itu — tambahkan juga nama proses pekerjaan itu ke Auto-Watch, atau kondisinya tidak akan punya apa pun untuk dipantau hilangnya.
Belum bisa dari rule builder. Mengetik rule kustom hari ini menghasilkan rule berbasis pola proses — proses itu berjalan membuat Mac tetap terjaga dan beralih ke pendinginan AI Workload. Kondisi baterai, suhu, lid, dan jendela waktu saat ini berasal dari preset bawaan, yang bisa Anda aktifkan atau nonaktifkan satu per satu.
Mesinnya memeriksa setiap 5 detik, tapi hanya mendaftar proses yang sedang berjalan — bagian yang paling berat — ketika setidaknya ada satu rule aktif yang benar-benar membutuhkan informasi proses. Kalau yang aktif hanya rule baterai, termal, sumber daya, lid, atau jendela waktu, pemeriksaannya tetap nyaris tanpa biaya (near-free no-op).