Lớp runtime an toàn trên Mac là gì?

Lớp runtime an toàn cho công việc AI trên Mac là một hệ thống giữ máy thức (keep-awake) nhưng đồng thời theo dõi pin, nhiệt độ và trạng thái tiến trình — rồi tự động cho Mac ngủ lại ngay khi công việc hoàn tất hoặc vượt một ngưỡng an toàn nào đó. Đây là con đường ở giữa hai lựa chọn tệ: để Mac ngủ giữa chừng lúc agent đang chạy và mất hết công sức, hoặc ép máy thức suốt đêm rồi cầu mong không có gì xảy ra. LidRun được xây dựng đúng theo mẫu hình này — agent đang chạy → giữ máy thức; agent xong hoặc mất an toàn → nhả khóa, để Mac ngủ lại — dành cho các phiên chạy AI và dev dài trên macOS 13 (Ventura) trở lên.
Lớp runtime an toàn thực sự làm gì
Lớp runtime an toàn kết hợp ba thứ: một assertion giữ máy thức, việc theo dõi liên tục, và một cơ chế tự nhả khi cần. Phần assertion là nửa dễ — bất kỳ công cụ nào cũng có thể gọi IOPMAssertionCreateWithName và giữ khóa kIOPMAssertionTypePreventUserIdleSystemSleep; macOS chỉ làm đúng theo lệnh được đưa. Nửa khó hơn là quyết định khi nào nên nhả khóa đó: khi pin xuống quá thấp, khi chip nóng lên, khi công việc vốn là lý do giữ máy thức đã thực sự xong.
LidRun là một cách hiện thực hóa mẫu hình này. Nó giữ assertion đó, theo dõi phần trăm pin và trạng thái cắm sạc/dùng pin, đọc tín hiệu nhiệt từ macOS, và theo dõi trạng thái tiến trình — rồi nhả assertion ngay khi một ngưỡng đã cấu hình bị vượt qua. Mac ngủ đúng lúc cần ngủ, theo một quy tắc do bạn (hoặc giá trị mặc định của app) đặt ra — không phải nhờ may mắn, cũng không phải không bao giờ ngủ.
Mức độ cần thiết tùy vào công việc. Một lần compile 20 phút trên Mac để bàn đang cắm điện thì gần như không cần gì trong số này — máy vốn dĩ chẳng bao giờ ngủ giữa chừng. Nhưng một phiên chạy AI agent kéo dài sáu tiếng trên laptop dùng pin, có thể nóng lên, có thể bị rút sạc, và chẳng ai theo dõi lúc 2 giờ sáng — đó là một tình huống hoàn toàn khác, và chính là tình huống mà mẫu hình này được dựng ra để xử lý.
Vì sao Mac của bạn ngủ giữa chừng ngay từ đầu
macOS không phân biệt được giữa "không có gì đang diễn ra" và "một tiến trình agent chạy nền đã âm thầm suy nghĩ suốt 40 phút mà không có thao tác bàn phím hay chuột nào." Cả hai trông giống hệt nhau dưới con mắt của bộ đếm idle-sleep — thứ vốn sinh ra để tiết kiệm pin đúng trong những lúc không hoạt động kiểu đó. Nếu cứ để mặc định, nó sẽ kích hoạt ngay giữa lúc job đang chạy.
Đóng nắp máy là một tác nhân riêng và mạnh tay hơn nhiều. Nếu không có màn hình ngoài gắn kèm — hoặc không có gì báo rõ cho macOS bỏ qua cảm biến nắp máy — thì việc gập nắp lại sẽ khiến Mac ngủ gần như ngay lập tức, bất kể bên dưới còn gì đang chạy.
Và nếu cả hai điều trên đều không xảy ra, một chiếc Mac bị bỏ mặc chạy bằng pin rồi cũng sẽ đụng tới ngưỡng tự tắt máy vì pin gần cạn — không phải một cú dừng sạch sẽ, mà chỉ là bất kỳ trạng thái nào công việc đang ở khi hết điện.
Hướng dẫn liên quanBộ điều tiết an toàn khi giữ Mac thức: vì sao LidRun để một chiếc Mac quá nóng hoặc không hoạt động đi ngủGiải pháp miễn phí có sẵn: caffeinate và pmset
macOS thực ra đã có sẵn một câu trả lời tử tế cho trường hợp đầu tiên. caffeinate -i python train.py bọc quanh một lệnh, giữ assertion chống idle-sleep đúng bằng thời gian lệnh đó chạy, và tự động nhả ra ngay khi lệnh kết thúc — không cần cài đặt, không cần cấu hình gì. CLI wrapper của chính LidRun thực ra mượn đúng hình dạng này: lidrun -- python train.py --epochs 100 bọc quanh một lệnh theo cách y hệt; điểm khác biệt nằm ở việc LidRun làm gì với cái khóa đó trong lúc nó còn hiệu lực, sẽ nói ở phần dưới.
Với trường hợp đóng nắp máy, con đường miễn phí là sudo pmset -a disablesleep 1 cùng với một màn hình ngoài đang gắn kèm — chiêu clamshell-mode kinh điển — rồi sudo pmset -a disablesleep 0 để tắt lại khi xong việc. Đây chính là cài đặt hệ thống mà chế độ Closed-Lid của LidRun cũng dùng bên dưới; khác biệt là LidRun luôn ghép cặp số 1 với một số 0 tương ứng — lúc dừng, lúc thoát app, và lại một lần nữa khi khởi động lần sau — để dọn lại bất kỳ thứ gì còn sót lại sau một lần crash.
Cả hai đều là cách làm chính đáng, và với những công việc ngắn, có người theo dõi, đang cắm điện, thì một trong hai thường là đủ tất cả những gì bạn cần. Đừng lôi ra nhiều công cụ hơn mức công việc đòi hỏi.
Giải pháp miễn phí hết tác dụng ở đâu
caffeinate không hề biết pin của bạn đang ra sao. Bọc một job kéo dài nhiều tiếng, rời đi, và nếu pin tụt xuống 2% lúc 3 giờ sáng, caffeinate vẫn cứ giữ assertion đó — nó chưa bao giờ được xây dựng để biết lúc nào nên buông.
pmset disablesleep rủi ro hơn theo một cách cụ thể: đây là một cài đặt hệ thống toàn cục, tồn tại lâu dài, chứ không giới hạn trong một phiên làm việc. Nó cần quyền sudo. Và nó không tự ghép cặp trở lại về 0 — nếu chương trình đặt nó bị crash, hoặc bạn đơn giản là quên mất, Mac sẽ mắc kẹt trong trạng thái nhất quyết không chịu ngủ, âm thầm hút cạn pin, cho tới khi có ai đó chạy tay lệnh đảo ngược.
Cả hai công cụ đều không đọc áp lực nhiệt. Cả hai đều không biết tiến trình vốn là lý do giữ máy thức còn đang làm việc có ích hay đã âm thầm treo. Chúng giữ; chúng không theo dõi. Khoảng trống đó — không phải lỗi của công cụ nào, chỉ đơn giản là nằm ngoài những gì chúng được xây dựng để làm — chính là thứ mà một lớp runtime an toàn bổ sung thêm vào.
Ba tín hiệu mà một lớp runtime an toàn thực sự theo dõi
Trạng thái pin được chia theo cấp độ, không phải một ngưỡng cắt duy nhất. Mặc định của LidRun: qua mốc 15% khi rút sạc, có thông báo nhắc nhở; qua mốc 5%, cảnh báo mạnh hơn; qua mốc khoảng 4% — một sàn cứng không thể cấu hình thấp hơn 4% dù bạn chỉnh gì đi nữa — LidRun nhả mọi khóa giữ máy thức và yêu cầu Mac đi ngủ, thay vì để nó tắt cứng giữa lúc đang ghi dữ liệu. Sàn đó tồn tại để chừa cho macOS đủ khoảng trống ghi trạng thái xuống đĩa và ngủ một cách sạch sẽ.
Tín hiệu nhiệt được đọc từ ProcessInfo.thermalState — một API công khai (nominal / fair / serious / critical), không cần entitlement đặc biệt, có sẵn từ macOS 12. Đây là tín hiệu thực sự chi phối quyết định tự dừng. Tuy vậy nó có thể trễ so với thực tế: trong lúc LidRun tự kiểm thử, tín hiệu này báo "fair" trong khi một chiếc Mac để trong túi đã throttle xuống còn 24%. Vì vậy, ở những chỗ khác — trên các Mac mà cảm biến SMC đọc được — LidRun còn đối chiếu nhiệt độ SoC thực tế và phần trăm throttle của CPU với các ngưỡng đã hiệu chỉnh, như một ý kiến thứ hai mà riêng cái bucket thô của hệ điều hành không phải lúc nào cũng đưa ra được. Khi SoC thực sự chạm mức "critical," LidRun nhả khóa ngay lập tức; nếu trạng thái critical kéo dài hai phút trong khi bạn đã rời bàn phím từ năm phút trở lên, hoặc nắp máy đang đóng vật lý, LidRun leo thang lên mức thực sự cho Mac đi ngủ, vì một chiếc Mac đang cắm điện chưa chắc sẽ tự idle-sleep.
Trạng thái tiến trình gắn cái khóa giữ máy thức vào chính công việc đó. Auto Mode theo dõi một tiến trình cụ thể — một phiên Claude Code, một agent Cursor, một lần build — và nhả khóa ngay khi tiến trình được theo dõi cuối cùng thoát ra. Bên dưới đó, một Safety Governor độc lập có thể nhả bất kỳ phiên giữ máy thức nào, kể cả phiên được bật thủ công, nếu Mac đang chạy pin, offline, và không cho thấy có workload đang hoạt động được xác nhận trong 15 phút, hoặc đứng yên không có workload xác nhận trong 20 phút. Nó cố tình chỉ fail-safe theo một chiều duy nhất: những lần nhả khóa đó chỉ kích hoạt khi có sự vắng mặt công việc đã được xác nhận, không bao giờ dựa trên một trạng thái chưa rõ — một bản build trước đây từng nhả khóa cả khi trạng thái "chưa rõ," và nó đã cho Mac ngủ ngay giữa lúc một phiên Claude Code đang chạy; đó giờ là một quy tắc học được bằng cái giá thật, không phải một phỏng đoán.
Những gì một lớp runtime an toàn không làm
Nó không làm giảm mức hao pin thực tế. Giữ một chiếc Mac thức và chạy luôn tốn điện hơn để nó ngủ — điều này đúng với bất kỳ công cụ giữ máy thức nào, kể cả LidRun. Mục tiêu không phải là hao pin bằng 0; ngủ vẫn là trạng thái tiết kiệm điện nhất mà một chiếc Mac có thể ở. Mục tiêu là để phiên chạy dừng lại ở một sàn do ai đó chủ động chọn, thay vì hao pin không kiểm soát cho tới 0%.
Nó không cứu được một tiến trình bị treo. Auto Mode và CLI wrapper nhả khóa khi tiến trình thoát, chứ không phải khi tiến trình "ngừng tiến triển." Một script bị đơ nhưng chưa crash vẫn được tính là đang chạy. Với một job dài không người theo dõi, hãy kết hợp process-watch với một sàn pin hoặc một hẹn giờ làm lớp dự phòng — đừng chỉ dựa vào mỗi process-watch để nhận ra có gì đó thực sự đang sai.
Và nó không điều khiển việc làm mát. Xét từ góc độ của lớp này, tín hiệu nhiệt chỉ để đọc: nó có thể chọn ngừng giữ máy thức để macOS được throttle và hạ nhiệt, nhưng — đặc biệt trên Apple Silicon — nó không thể tăng tốc quạt để làm mát máy nhanh hơn. Hãy đặt Mac ở nơi thoáng khí; một lớp runtime an toàn là hàng rào bảo vệ cho việc khi nào nên dừng, không phải vật thay thế cho luồng gió.
Lớp runtime an toàn so với caffeinate, Amphetamine và pmset
caffeinate đi kèm sẵn trong macOS, bọc quanh một lệnh, và giữ một power assertion trong một khoảng thời gian cố định hoặc cho tới khi tiến trình con thoát ra. Theo thiết kế, nó không hề nhận biết về pin, nhiệt độ, hay tình trạng offline — đó chưa bao giờ là việc của nó. Với công việc ngắn, có người theo dõi, đang cắm điện, nó làm đúng những gì nó hứa.
pmset disablesleep là con đường miễn phí duy nhất để có một chiếc Mac thực sự đóng nắp cùng màn hình ngoài. Đây là một cài đặt thô, chỉ dành cho admin, áp dụng cho toàn hệ thống và hoàn toàn không có khái niệm phiên làm việc — nó không biết cái gì đã kích hoạt nó, và nó sẽ không tự tắt lại.
Amphetamine là một ứng dụng menu-bar được chăm chút kỹ, có lịch trình, tác nhân kích hoạt, và danh sách app được phép — nó có thể bắt đầu và dừng phiên theo khung giờ trong ngày hoặc theo app nào đang ở tiền cảnh. Điều nó không làm là theo dõi phần trăm pin theo thời gian thực như một hàng rào bảo vệ, hay phản ứng với áp lực nhiệt của macOS giữa phiên chạy; đó đơn giản là nằm ngoài những gì nó được xây dựng để theo dõi.
Một lớp runtime an toàn bổ sung thêm tầng theo dõi lên trên bất kỳ công cụ nào trong số này: sàn pin, tín hiệu nhiệt, tiến trình thoát, và các kiểm tra offline/không người theo dõi — tất cả cùng góp phần quyết định khóa có nên tiếp tục giữ hay không. Với một lần build 20 phút đang cắm điện, caffeinate hay Amphetamine là thực sự đủ rồi — đừng tìm thêm gì khác. Mẫu hình này chứng minh giá trị của nó ở những phiên chạy dài, không người theo dõi, trên phần cứng có thể đổi trạng thái — pin, nhiệt, mạng — theo những cách mà chẳng ai theo dõi theo thời gian thực.
LidRun phù hợp ở đâu
Keep Awake, Timer, và Charging-Only đều miễn phí trên LidRun — không giới hạn, không dùng thử, không giới hạn số phiên — và chúng đã chạy sẵn vòng lặp lõi: giữ assertion, theo dõi các mốc leo thang pin theo cấp độ (15% / 5% / ~4%), đọc tín hiệu nhiệt, tự dừng khi chạm một trong hai. Đó là lớp runtime an toàn cơ bản, có sẵn ngay từ lúc cài đặt.
Auto Mode (gắn khóa giữ máy thức vào một tiến trình được theo dõi như Claude Code hay Cursor) và chế độ Clamshell đóng nắp nằm trong gói Pro, cùng với khả năng chỉnh lại các ngưỡng pin và nhiệt mặc định thay vì dùng giá trị có sẵn của LidRun.
Nếu công việc của bạn vừa vặn với gói miễn phí — một phiên giữ máy thức, đang cắm điện hoặc có người theo dõi bằng tay — thì thực sự là đủ rồi; cứ dùng vậy. Nếu đó là một phiên agent kéo dài nhiều tiếng, không người theo dõi, gắn với một tiến trình cụ thể, hoặc nắp máy cần đóng lại, thì đó là lúc phần còn lại của mẫu hình này (và gói trả phí) bắt đầu chứng minh giá trị. Xem bảng giá chi tiết, hoặc đọc cách Safety Governor quyết định nhả một phiên mà nó không phải là bên khởi động, để hiểu cơ chế đứng sau tất cả những điều này.
LidRun giữ công việc của bạn chạy tiếp khi đóng nắp, với cơ chế bảo vệ pin và nhiệt tích hợp sẵn.
Đã có LidRun? Đọc hướng dẫn thiết lập →
Mới biết đến LidRun? Xem bảng giá →
Câu hỏi thường gặp
Đó là một hệ thống giữ máy thức nhưng đồng thời theo dõi pin, nhiệt độ và trạng thái tiến trình, rồi tự động buông ra — hoặc khi công việc hoàn tất, hoặc khi một ngưỡng an toàn đã cấu hình bị vượt qua. Đó là sự kết hợp giữa giữ, theo dõi, và tự dừng — chứ không phải một wake lock đơn thuần cứ giữ mãi bất kể chuyện gì đang thực sự diễn ra trên máy.
Không hoàn toàn. caffeinate -i <command> giữ một power assertion và nhả nó ra khi lệnh được bọc kết thúc, nhưng nó không bao giờ kiểm tra phần trăm pin hay đọc tín hiệu nhiệt của macOS trong lúc chạy. Với công việc ngắn, có người theo dõi, đang cắm điện, đây là một lựa chọn vững chãi và chính đáng. Còn với một phiên chạy nhiều tiếng không người theo dõi, nó để mặc chiếc máy không được bảo vệ đúng ở những tín hiệu quan trọng nhất suốt đêm.
Có — chạy và giữ một assertion luôn tốn điện hơn so với ngủ; không công cụ giữ máy thức nào thay đổi được điều đó. Mục tiêu của một lớp runtime an toàn không phải là hao pin bằng 0, mà là hao pin có kiểm soát: phiên chạy dừng lại ở một sàn pin, thay vì chạy không kiểm soát cho tới 0% rồi tắt cứng.
Process-watch (Auto Mode, hoặc lidrun -- <command> của CLI) nhả khóa khi tiến trình thoát ra — một tiến trình bị treo nhưng chưa crash vẫn được tính là đang chạy, nên khóa vẫn được giữ. Với những job dài không người theo dõi, hãy kết hợp process-watch với một sàn pin hoặc một hẹn giờ làm lớp dự phòng, thay vì chỉ dựa vào mỗi nó để nhận ra tình trạng đứng máy.
Phần trăm pin và trạng thái cắm sạc/dùng pin (chia theo cấp độ: 15% nhắc nhở, 5% cảnh báo mạnh, ~4% sàn cứng luôn nhả mọi khóa), tín hiệu nhiệt của macOS (nominal/fair/serious/critical, được đối chiếu với nhiệt độ SMC thực tế ở những nơi cảm biến đọc được), và — khi Auto Mode hoặc CLI wrapper đang hoạt động — liệu tiến trình kích hoạt có còn chạy hay không. Một Safety Governor độc lập cũng có thể nhả một phiên nếu không có workload đang hoạt động được xác nhận sau 15–20 phút chạy pin, nhưng không bao giờ dựa trên một trạng thái chưa rõ.
Khi macOS báo SoC ở mức "critical," LidRun nhả khóa giữ máy thức ngay lập tức. Nếu trạng thái critical kéo dài hai phút trong khi bạn đã rời bàn phím từ năm phút trở lên, hoặc nắp máy đang đóng vật lý, LidRun leo thang lên mức thực sự cho Mac đi ngủ, vì máy có thể sẽ không tự idle-sleep khi đang cắm điện. Điều này giúp giảm bớt rủi ro bị throttle kéo dài; nó không ngăn được mọi sự tích nhiệt hay hứa hẹn một trần nhiệt độ cụ thể nào — hãy giữ Mac ở nơi thoáng khí.
Có, trên cả hai dòng chip. LidRun nhắm tới macOS 13 (Ventura) trở lên; tín hiệu nhiệt (ProcessInfo.thermalState) và power assertion API đều có sẵn trên cả Intel lẫn mọi thế hệ Apple Silicon. Việc đối chiếu nhiệt độ SMC thực tế phụ thuộc vào cảm biến mà từng chiếc Mac cụ thể lộ ra, và điều này khác nhau tùy model.