Kontrol kipas Mac untuk developer
Jawaban singkat: di Mac modern, developer tidak bisa mengatur kurva kipas kustom — firmware Apple yang memegang kendali RPM kipas, dan di Apple Silicon, bahkan cara-cara akal-akalan yang dulu diandalkan tool lama akan direbut kembali dalam hitungan detik oleh thermal daemon bawaan macOS. Yang bisa Anda kendalikan adalah visibilitas dan waktu: lihat panas datang, lalu bertindak (atau biarkan sesuatu bertindak untuk Anda) sebelum build panjang, tumpukan container, atau proses model lokal kena throttle atau Mac harus melindungi dirinya sendiri. Panduan ini membahas apa arti sebenarnya kontrol kipas di Mac hari ini pada Intel vs Apple Silicon, perintah native gratis yang menunjukkan apa yang sedang terjadi saat ini, di mana batas jalur DIY berakhir, dan workflow sadar-suhu yang dipakai LidRun sebagai gantinya.
Kenapa beban kerja developer membuat Mac panas
Mengompilasi proyek besar, menjalankan tumpukan container Docker, atau menyajikan model lokal membuat CPU — dan di Apple Silicon, sering juga GPU dan Neural Engine — tertahan dekat batas atasnya selama beberapa menit atau jam, bukan detik. Beban berkelanjutan seperti inilah, bukan lonjakan sesaat, yang benar-benar menaikkan suhu chip.
Begitu SoC cukup panas, macOS akan men-throttle-nya untuk melindungi diri: clock speed turun, dan build yang tadinya melaju kencang sepuluh menit lalu jadi melambat di tengah proses. Anda bisa menyaksikan ini sendiri, gratis, di Terminal: jalankan pmset -g therm dan lihat baris CPU_Speed_Limit. Jika angkanya 100, Anda berjalan di kecepatan penuh; berapa pun di bawah itu berarti Anda sedang di-throttle, saat ini juga, tanpa perlu aplikasi pihak ketiga.
Naluri pada titik itu adalah ingin memutar kipas lebih kencang dan memaksa terus jalan. Di Mac modern, naluri itu langsung berbenturan dengan betapa ketatnya hardware ini dikunci — dan itulah bagian yang sering dilewatkan begitu saja oleh kebanyakan saran soal kontrol kipas.
Apa yang benar-benar bisa dikendalikan macOS (dan apa yang tidak)
Dua hal berbeda sama-sama disebut "kontrol kipas," dan mencampuradukkan keduanya adalah sumber sebagian besar kebingungan. Membaca kipas — RPM saat ini, rentang min/maks, suhu chip — diizinkan di semua Mac, baik Intel maupun Apple Silicon. Menulis target RPM baru, yaitu benar-benar memerintahkan kipas berputar lebih cepat dari yang diinginkan firmware, adalah operasi hardware yang bersifat privilese, dan di Apple Silicon hal ini sebagian besar tidak tersedia untuk aplikasi apa pun, apa pun cara aplikasi itu dibangun.
Di balik layar, menggerakkan kipas di Intel adalah proses penulisan SMC (System Management Controller) dua langkah: mengubah mode key menjadi "manual," lalu menulis target RPM. Mac Intel pra-T2 umumnya menerima penulisan itu langsung tanpa masalah. Mac dengan chip T2 (generasi MacBook Pro/Air sekitar 2018–2020, iMac Pro, Mac Pro) adalah jebakan khusus: mereka menerima peralihan ke mode manual tapi diam-diam menolak penulisan target-RPM yang sebenarnya — jadi tool yang hanya memeriksa langkah pertama akan melaporkan "kontrol kipas aktif" pada hardware yang sebenarnya tidak pernah benar-benar berputar berbeda. Di Apple Silicon, kipas berada dalam "system mode" milik firmware sendiri, dan penulisan mode-manual langsung akan ditolak mentah-mentah. Beberapa tool mengakalinya dengan unlock key yang tidak terdokumentasi, tapi bahkan dengan cara itu, daemon thermalmonitord milik macOS akan merebut kembali kendali ke kurva firmware dalam hitungan detik kecuali unlock tersebut terus-menerus dipertahankan — jalur yang rapuh, tidak didukung resmi, dan bisa ditutup Apple kapan saja lewat pembaruan OS, bukan API sungguhan.
Ini perlu dikatakan terus terang, karena banyak materi pemasaran kontrol kipas tidak melakukannya: tool mana pun yang menjanjikan kontrol kipas manual penuh dan andal di Mac seri-M sebenarnya melebih-lebihkan apa yang diizinkan platform ini saat ini. LidRun tidak menjanjikan kontrol RPM kipas di Apple Silicon, dan akan tidak jujur jika menyiratkan sebaliknya — probe kemampuan milik LidRun sendiri tidak pernah mengasumsikan penulisan berhasil, dan pada hardware M1 hingga M4/M5, hasilnya jauh lebih sering kembali sebagai monitor-only saja.
Panduan terkaitAlternatif Macs Fan Control untuk developerCara gratis dan native untuk memeriksa apa yang sedang terjadi
Sebelum mencari aplikasi apa pun, ada baiknya tahu bahwa macOS sudah menyediakan dua cara gratis untuk melihat kondisi suhu sebenarnya, tanpa perlu instal apa pun. pmset -g therm di Terminal menampilkan CPU_Speed_Limit dan CPU_Scheduler_Limit — jika salah satunya turun di bawah 100, Anda sedang di-throttle. Perintah ini berjalan sama persis di Intel maupun Apple Silicon dan tidak memerlukan izin khusus.
sudo powermetrics --samplers smc -i1000 -n1 masuk lebih dalam lagi dan menampilkan suhu die CPU yang sebenarnya, serta RPM kipas secara langsung pada sebagian besar Mac Intel. Perintah ini butuh sudo karena membaca data sensor mentah. Di Apple Silicon, bagian RPM kipas dari output tersebut tidak konsisten dari satu rilis ke rilis lain; pembacaan suhulah yang tetap dapat diandalkan di sana.
Yang tidak disediakan macOS adalah GUI untuk semua ini — Activity Monitor hanya menampilkan persentase CPU dan skor Energy, tidak pernah suhu atau kecepatan kipas, dan celah itulah yang diisi oleh tool menu-bar pihak ketiga. Opsi gratis seperti Stats (monitor menu-bar open-source yang populer) membaca suhu dan RPM kipas tanpa menulis apa pun; Macs Fan Control membaca sensor secara gratis di semua Mac dan menambahkan preset RPM plus kontrol manual pada hardware Intel lama yang masih menerima penulisan tersebut. Keduanya tidak mengubah batas Apple Silicon di atas — mereka membaca pintu terkunci yang sama, hanya dengan jendela yang lebih baik untuk mengintipnya.
Di mana jalur DIY berakhir
Memantau jendela Terminal atau tampilan menu-bar cukup efektif untuk build lima menit yang Anda pelototi langsung. Cara ini berhenti berfungsi begitu prosesnya panjang atau ditinggal tanpa pengawasan — build Xcode yang lama, fine-tune semalaman, atau tumpukan Docker Compose yang Anda jalankan lalu ditinggal pergi. Tidak ada yang benar-benar menjalankan ulang pmset -g therm setiap tiga puluh detik selama satu jam penuh.
Pada Mac Intel yang penulisan RPM-nya benar-benar berhasil, memaksa kipas sendiri membawa risiko yang lebih kecil tapi nyata: jika proses yang melakukan penulisan crash atau dimatikan paksa tanpa mengembalikan kipas ke mode "auto," kipas bisa tertahan di kecepatan tetap — mengganggu karena kencang saat idle, atau macet rendah jika proses mati di tengah proses menaikkan kecepatan saat Mac masih bekerja keras. Ini adalah mode kegagalan yang sudah dikenal dari penulisan SMC secara ad hoc, bukan sekadar kemungkinan teoretis — itulah sebabnya tool mana pun yang melakukan hal ini seharusnya selalu mengembalikan kurva otomatis firmware saat keluar atau crash, bukan hanya saat ditutup dengan normal.
Khusus pada Mac Intel dengan T2, jebakannya berjalan ke arah sebaliknya: sebuah tool bisa melaporkan "kontrol kipas aktif" karena penulisan mode berhasil, sementara penulisan RPM yang sebenarnya diam-diam ditolak di baliknya — jadi Anda mengira punya kendali padahal tidak. Menutup celah ini berarti memastikan penulisan target-RPM benar-benar berhasil sebelum menyebut sebuah Mac "bisa dikendalikan," bukan sekadar memeriksa bahwa peralihan mode tidak menghasilkan error.
Workflow sadar-suhu, bukan mengejar RPM
Jika Anda tidak bisa memerintah kipas secara andal — dan pada sebagian besar Mac yang beredar saat ini, memang tidak bisa — tujuan praktisnya bergeser dari kontrol menjadi kesadaran plus waktu yang tepat: tahu kapan sebuah proses mulai memanas, lalu bertindak sebelum kena throttle atau Mac harus melindungi dirinya sendiri.
LidRun membaca suhu dan status kipas secara terus-menerus dan menampilkannya di menu bar, jadi build yang memanas jadi terlihat, bukan kejutan tiba-tiba. Pada Mac yang penulisan RPM kipasnya benar-benar terkonfirmasi bisa ditulis — kebanyakan hardware Intel lama dan T2 — LidRun menaikkan kipas mengikuti kurva proporsional: tenang di bawah sekitar 62°C (56°C setelah lid ditutup dan panas punya lebih sedikit jalan keluar), naik secara halus seiring chip memanas, dan didorong ke maksimum begitu suhu melewati sekitar 90°C atau batas kecepatan CPU sendiri anjlok ke 60% atau lebih rendah — dengan alasan bahwa build yang macet lebih penting daripada kipas yang tenang pada titik itu. Preset Quiet, Balanced, AI Workload, dan Emergency Max berada di atas kurva tersebut untuk saat Anda ingin mengaturnya sendiri secara manual.
Peningkatan kipas ini sengaja tidak diposisikan sebagai mekanisme keamanan — kipas adalah bantuan kenyamanan dan pemulihan dari throttle, bukan yang menjaga Mac dari overheating. Ada pemeriksaan terpisah dan independen, digerakkan oleh suhu SMC ditambah sinyal thermal-pressure bawaan macOS, yang menganggap panas berkelanjutan di kisaran 98–100°C, atau batas kecepatan CPU yang anjlok di bawah sekitar 30–50%, cukup serius untuk ditindaklanjuti terlepas dari apa yang sedang dilakukan kipas. Dan jika penulisan kipas pernah tertinggal di tengah jalan — karena crash, proses yang dimatikan paksa — lease 90 detik membuatnya otomatis kembali ke kurva firmware sendiri, bukan tetap macet.
Di mana LidRun berperan — dan di mana sejujurnya tidak
Di Apple Silicon, LidRun tidak menggerakkan kipas Anda. LidRun mengamati kondisi suhu — suhu SMC di mana bisa dibaca, throttle CPU, dan sinyal thermal-pressure bawaan macOS — lalu mundur sebagai gantinya: pengaturan berlabel "Don't hold when the Mac is hot" (aktif secara default) tidak akan membiarkan proses yang diawasi baru dimulai selagi Mac sudah berjalan panas, dan jika Anda memakai mode Closed-Lid, pengaturan kedua, "Drop Closed-Lid if the Mac gets too hot" (juga aktif secara default), menghentikan override tersebut pada panas yang benar-benar kritis sehingga Mac bisa throttle dan tidur sebagaimana mestinya, alih-alih tetap panas dan tidak terawasi di balik layar yang tertutup.
Pada Mac Intel dan T2 yang penulisan kipasnya terkonfirmasi benar-benar berfungsi, pembacaan suhu yang sama ini juga menggerakkan kurva kipas proporsional yang dijelaskan di atas — satu gambaran suhu, dua tuas berbeda, tergantung apa yang sejujurnya diizinkan oleh hardware.
Janji di balik kedua jalur itu sama: selama agent berjalan, tetap terjaga; begitu agent selesai atau Mac tidak aman, lepaskan dan biarkan tidur. Itu standar yang berbeda dari sekadar tampilan pendinginan saja — tujuannya bukan kipas yang lebih pelan, melainkan tidak kehilangan build atau proses agent yang ditinggal tanpa pengawasan karena panas yang tidak Anda lihat datang, tanpa berpura-pura LidRun bisa memaksa kipas yang tidak mau bergerak. Jika Anda menjalankan build panjang, container, atau model lokal tanpa pengawasan, ada baiknya mencoba LidRun di mesin Anda sendiri untuk melihat apa yang sebenarnya sedang dilakukan Mac Anda saat Anda tidak mengawasinya.
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
Pada Mac Intel dan T2 yang penulisan RPM kipasnya terkonfirmasi benar-benar berfungsi, ya — LidRun menaikkan kipas mengikuti kurva proporsional dan menawarkan preset Quiet, Balanced, AI Workload, dan Emergency Max. Di Apple Silicon, tidak: LidRun tidak menjanjikan kontrol RPM kipas di sana. Sebagai gantinya, LidRun membaca suhu dan status throttle secara terus-menerus dan menjadikannya syarat bagi sesi keep-awake Anda.
Apple Silicon menjaga kipas tetap berada dalam "system mode" milik firmware sendiri. Penulisan langsung untuk memaksa kontrol manual akan ditolak mentah-mentah, dan bahkan unlock tidak terdokumentasi yang dipakai sebagian tool akan direbut kembali oleh thermal daemon macOS dalam hitungan detik kecuali terus-menerus dipertahankan — jalur yang rapuh, tidak didukung resmi, bukan API sungguhan. Membaca suhu dan RPM kipas berjalan lancar di mana saja; yang diblokir adalah menulis target RPM baru.
Ada. Jalankan pmset -g therm di Terminal — jika CPU_Speed_Limit menunjukkan angka di bawah 100, Anda sedang di-throttle saat ini juga. sudo powermetrics --samplers smc -i1000 -n1 masuk lebih dalam lagi dan menampilkan suhu die CPU yang sebenarnya, plus RPM kipas pada sebagian besar Mac Intel. Keduanya sudah tersedia bawaan di macOS; tidak satu pun membutuhkan aplikasi pihak ketiga.
LidRun membaca suhu dan throttle secara terus-menerus dan menampilkannya di menu bar, jadi proses yang memanas jadi terlihat, bukan kejutan tiba-tiba. "Don't hold when the Mac is hot" (aktif secara default) memblokir proses baru yang diawasi agar tidak mulai selagi Mac sudah berjalan panas, dan jika panas melewati ambang kritis, LidRun bisa menghentikan override Closed-Lid sehingga Mac bisa tidur alih-alih terus dipaksa jalan.
LidRun mendukung macOS 13 Ventura ke atas pada keduanya. Pemantauan suhu — pembacaan temperatur dan throttle — bekerja dengan cara yang sama di keduanya. Kontrol RPM kipas terbatas pada Mac Intel dan T2 yang benar-benar terkonfirmasi bisa ditulis; Apple Silicon tetap monitor-only.