Vì sao caffeinate không đủ cho các workflow AI closed-lid

caffeinate thực sự chặn được những gì

caffeinate là một công cụ nhỏ, đáng tin cậy đi kèm sẵn trong macOS, nằm ở /usr/bin/caffeinate. Chạy caffeinate -i, nó sẽ tạo một assertion ngăn hệ thống ngủ khi rảnh; -d giữ màn hình luôn sáng; -s giữ hệ thống không ngủ, nhưng chỉ khi Mac đang cắm nguồn AC; -m ngăn ổ đĩa ngủ khi rảnh. Bọc một lệnh bằng nó — caffeinate -i make — và nếu bạn không chỉ định flag nào, caffeinate sẽ tự hiểu là -i, giữ assertion đó trong đúng khoảng thời gian tiến trình đó chạy.

Ở tầng dưới, đó là một lệnh gọi tới IOPMAssertionCreateWithName, yêu cầu một loại assertion như PreventUserIdleSystemSleep — cùng cơ chế nền tảng cấp thấp mà chính chế độ Keep Awake khi mở nắp của LidRun cũng được xây dựng trên đó. Đây không phải là lời chê caffeinate; nó là công cụ đúng, được làm đúng, cho đúng việc nó nhắm tới.

Với một build dài, một lượt tải nặng, một bộ test, hay một phiên chạy Codex hoặc Claude Code qua đêm khi vẫn mở nắp máy, chỉ một dòng lệnh đó là thực sự đủ. Không có lý do gì để tìm đến thứ gì nặng nề hơn.

Từ đáng chú ý ở đây là rảnh (idle). caffeinate chặn kiểu ngủ xảy ra khi bạn rời khỏi một chiếc laptop đang mở nắp và macOS quyết định rằng bạn không còn dùng nó nữa. Đó chỉ là một kiểu ngủ cụ thể — không phải tất cả các kiểu ngủ.

Vì sao đóng nắp máy lại là một vấn đề khác

Đóng nắp máy không kích hoạt ngủ khi rảnh — nó kích hoạt ngủ clamshell, một hành vi riêng, ở tầng thấp hơn của macOS. Trừ khi có một màn hình ngoài, nguồn AC, và bàn phím hoặc chuột đang thực sự vận hành một cấu hình desktop với màn hình đóng thực thụ, macOS sẽ đưa máy vào trạng thái ngủ chỉ trong vài giây sau khi nắp đóng lại, bất kể có assertion hay không.

Không có assertion nào dựa trên IOPMAssertionCreateWithName chạm được tới đường đó — không phải của caffeinate, và cũng không phải của bất kỳ app nào xây trên cùng cơ chế nền đó. Ngay cả -s, flag mạnh nhất của caffeinate, cũng được chính man page của nó giới hạn rõ là "chỉ có hiệu lực khi hệ thống đang chạy bằng nguồn AC," và vẫn không hề nhắc gì đến chiếc nắp máy.

Vì vậy, một tình huống ngày càng phổ biến — khởi chạy một agent hoặc một tác vụ fine-tune, gập laptop lại, rồi đi sang phòng khác — sẽ khiến phiên chạy đó bị treo ngay khi nắp máy vừa đóng. caffeinate vẫn đang trung thành giữ assertion của nó; nhưng chiếc nắp máy vẫn thắng, vì ngủ khi rảnh và ngủ clamshell là hai câu hỏi hoàn toàn khác nhau.

Cách khắc phục miễn phí: pmset disablesleep

Cần gạt duy nhất được ghi nhận công khai, có thể thay đổi hành vi khi đóng nắp lúc dùng pin, mà không cần màn hình ngoài, là tùy chọn pmset disablesleep. Lệnh cụ thể là: sudo pmset -a disablesleep 1 cho phép đóng nắp mà Mac không ngủ, còn sudo pmset -a disablesleep 0 đưa việc ngủ khi đóng nắp trở lại bình thường.

Nó sẽ hỏi mật khẩu admin khi bạn tự chạy lệnh này (flag -a khiến nó áp dụng cho toàn hệ thống), và có hiệu lực ngay lập tức — không cần khởi động lại máy.

Đó chính là cơ chế mà chế độ Closed-Lid của LidRun bật/tắt ở tầng dưới, và nếu bạn tự chạy lệnh này cho một tác vụ qua đêm duy nhất thì hoàn toàn miễn phí và vẫn hiệu quả. Nếu chỉ dùng một lần, vậy là thường đã đủ thật sự.

Rủi ro khi tự làm bằng tay — và vì sao các ứng dụng giữ máy thức khác cũng gặp bức tường tương tự

Vấn đề nằm ở chỗ pmset disablesleep tự nó không làm được gì thêm: đây là một cài đặt toàn cục, tồn tại lâu dài. Nó không giới hạn trong phiên Terminal hay tiến trình mà bạn đặt cho nó — nó vẫn giữ giá trị 1 cho đến khi bạn tự tay chuyển lại về 0 hoặc khởi động lại Mac. Chỉ cần quên chạy lệnh thứ hai, hoặc cửa sổ Terminal hay app bạn dùng để chạy nó bị crash trước khi bạn kịp tắt, thì Mac sẽ từ chối ngủ khi đóng nắp — kể cả khi đang nằm im trong balo — cho tới khi bạn nhận ra và tự tay khắc phục.

Và khi nắp đã đóng, một chiếc Mac vẫn đang thức sẽ không tản nhiệt được như lúc mở nắp. Chạy một phiên làm việc bên trong một chiếc balo kín là trường hợp đáng để cẩn trọng, bất kể công cụ nào đã bật disablesleep — quy tắc trung thực ở đây là giữ cho một chiếc Mac đang chạy được thông thoáng, không bị bịt kín.

Đây cũng không phải khoảng trống mà một bản thay thế caffeinate đẹp hơn có thể lấp được. Amphetamine, KeepingYouAwake, Lungo, và Caffeine đều là những công cụ menu bar chắc chắn, làm tốt, với những điểm mạnh thực sự — giao diện gọn hơn, hẹn giờ theo phiên, quy tắc kích hoạt theo app — nhưng tất cả đều hoạt động qua cùng một cơ chế assertion IOKit dạng ngủ-khi-rảnh mà caffeinate dùng. Không app nào trong số đó ghi đè được ngủ clamshell: một chiếc nắp đóng khi dùng pin vẫn khiến Mac ngủ dưới Amphetamine hay KeepingYouAwake y hệt như dưới một lệnh caffeinate -i trần trụi. Đó không phải vì các app đó thiếu tính năng — ghi đè ngủ khi đóng nắp cần đến bước leo thang pmset disablesleep (hoặc một cấu hình clamshell với màn hình ngoài), chứ không phải một lớp bọc assertion đẹp hơn.

Một workflow AI closed-lid an toàn hơn thực sự cần những gì

Tự tay bật disablesleep có thể giúp một tác vụ chạy qua đêm trót lọt, nhưng "thức bất kể chuyện gì" lại là mục tiêu sai cho một thứ đang chạy khi đóng nắp, dùng pin, và có thể không ai trông chừng. Điều mà cài đặt đó thực sự cần thêm là một cơ chế dọn dẹp đáng tin cậy, cùng các giới hạn biết tôn trọng cả pin lẫn nhiệt độ.

Về khoản dọn dẹp: LidRun luôn đi kèm việc bật disablesleep với việc tắt nó lại ở mỗi lần dừng, thoát app, hay kết thúc bình thường, và — sau khi bạn đã cấp quyền cho helper đặc quyền của nó — làm việc đó mà không cần hỏi mật khẩu admin mỗi lần. Nếu app bị kill trước khi kịp dọn dẹp, một file heartbeat nhỏ sẽ ghi lại rằng Closed-Lid đã được kích hoạt; lần tới khi LidRun khởi động lại, nó sẽ kiểm tra trạng thái còn sót lại đó và đưa disablesleep về 0. Việc reset này diễn ra ở lần khởi động tiếp theo, chứ không phải ngay lúc app crash — đây là điều đáng biết chứ không nên mặc định.

Về khoản pin: tính năng giữ máy thức sẽ tự động dừng khi pin xuống dưới một ngưỡng bạn tự đặt, mặc định là 20% và có thể chỉnh trong khoảng 15–50%. Bên dưới đó còn có một ngưỡng ép ngủ khẩn cấp riêng — mặc định 4%, chỉnh được trong khoảng 4–8% — hoạt động bất kể cài đặt tự-dừng ở trên là gì, vì macOS cần một khoảng đệm để thực sự hoàn tất việc ngủ trước khi pin cạn hẳn.

Về khoản nhiệt: khi tín hiệu nhiệt thô của chính macOS báo chip đang nóng ở mức nghiêm trọng, LidRun mặc định sẽ tắt chế độ Closed-Lid và cho bạn biết lý do — Mac quá nóng, hãy mở nắp ra hoặc cải thiện luồng gió — thay vì để một chiếc Mac đóng kín tiếp tục "nấu" bên trong. Đó là một bước lùi để an toàn, không phải một tuyên bố rằng Mac đóng nắp thì không thể quá nhiệt; quy tắc nền tảng vẫn là giữ cho một chiếc Mac đang chạy được thông thoáng.

Ngoài ra còn có chế độ chỉ-khi-đang-sạc và chế độ hẹn giờ, dành cho những phiên chạy mà bạn muốn assertion chỉ tồn tại khi đang cắm sạc, hoặc tự hết hạn sau một khoảng thời gian cố định, thay vì trông chờ vào việc bạn nhớ tắt nó. Gộp lại, đó chính là hình dạng của lời hứa này: agent còn chạy thì giữ máy thức; agent xong việc, hoặc phiên chạy trở nên không an toàn, thì thả assertion ra và để Mac ngủ. Không phải một wake lock mù quáng cãi nhau với pin và cảm biến nhiệt — khi hai thứ đó mâu thuẫn nhau, an toàn luôn thắng sự tiện lợi.

Dùng caffeinate (hoặc Amphetamine) cùng với LidRun

Đây vẫn không phải chuyện caffeinate đấu với LidRun. caffeinate xuất sắc ở đúng việc nó được sinh ra để làm, và rất nhiều workflow chẳng bao giờ cần hơn một dòng lệnh của nó — điều này cũng đúng với Amphetamine, KeepingYouAwake, hay Lungo khi cần giữ máy thức lúc mở nắp với một giao diện menu bar đẹp hơn.

Nếu bạn giữ nắp máy mở, caffeinate -i (hay bất kỳ app nào trong số trên mà bạn đã quen dùng) thường là câu trả lời đơn giản nhất. Nếu bạn đóng nắp trong các phiên chạy AI và dev dài, và muốn có rào chắn an toàn về pin và nhiệt độ xung quanh việc đó, thì đó chính là khoảng trống mà LidRun lấp vào.

Rất nhiều người dùng cả hai: caffeinate cho các tác vụ nhanh, gói gọn trong một lệnh ở Terminal, LidRun cho các phiên chạy closed-lid không ai trông chừng, nơi việc quên tắt lại một cài đặt toàn hệ thống thực sự gây hậu quả.