BÀI VIẾT
Claude Cowork vừa làm đúng cái mình từng nói Remote Control không làm
Tháng 8 mình viết rằng Remote Control của Claude Code chỉ là một lớp đồng bộ, không phải di chuyển lên cloud, và việc giữ execution ở local chính là điểm cốt lõi. Tuần này Anthropic chuyển hẳn execution của Cowork lên cloud làm mặc định. Đây là lý do cả hai quyết định đều đúng — cho hai sản phẩm khác nhau.

Trong bài viết
Ngày 19/8, mình viết một bài lập luận rằng tính năng Remote Control của Claude Code, dù demo trông có vẻ vậy, không phải là chuyển lên cloud. Lúc đó mình khẳng định rất cụ thể: “execution vẫn ở local; chỉ có session state được đồng bộ” — và coi đó là một ranh giới bảo mật có chủ đích: credential, filesystem, quyền truy cập tool đều ở nguyên trên máy bạn, lớp sync chỉ di chuyển hội thoại và các event approval. Mình gọi đó là một pattern mình sẽ dùng lại.
Sáu tuần sau, Anthropic ship kiến trúc ngược lại cho một sản phẩm anh em, và cách báo chí đưa tin nghe như một sự đảo ngược. Không phải vậy. Nhưng phải viết ra rõ sự khác biệt mới chắc được điều đó.
Cái gì thực sự thay đổi, và khi nào
Ngày 5/10, Simon Willison đăng lại một câu nói của Felix Rieseberg (Anthropic) mô tả rất rõ kiến trúc cũ của Cowork: inference chạy trên cloud, nhưng VM thực thi lại chạy local, trên máy bạn — tốn dung lượng đĩa, tốn pin, và dừng thẳng nếu bạn gập laptop lại. Bản mới, rollout từ 6/10 làm mặc định cho plan Pro và Max, chuyển cả inference và VM lên cloud. Tài liệu hỗ trợ của chính Anthropic nói rõ ranh giới: phía cloud giờ phụ trách thực thi task, scheduled task (không cần thiết bị nào phải mở máy để nó kích hoạt), và đồng bộ session/file qua nhiều thiết bị. Phần vẫn ở local, cần app desktop đang mở, chỉ gồm 4 việc cụ thể: đọc/ghi file trong các folder đã kết nối, các MCP connector/plugin local, dùng browser trong app, và computer use — click/gõ trực tiếp trên màn hình máy bạn. Khi một session trên cloud cần thứ gì từ máy local, app desktop xử lý đúng một tool call đó, và bản copy lấy về bị xóa ngay sau, theo chính sách lưu trữ của Anthropic.
Đây không phải “chúng tôi quyết định execution local không còn quan trọng.” Đây là một khẳng định hẹp hơn: với sản phẩm này, nhóm thứ thực sự cần máy của bạn rất nhỏ và được định nghĩa rõ, còn mọi thứ ngoài nhóm đó chuyển sang một sandbox chẳng quan tâm laptop bạn có mở hay không.
Câu hỏi thiết kế thực sự, nói lại cho rõ
Bài tháng 8 của mình ngầm hỏi: “execution nên nằm ở nơi tài nguyên của user nằm, hay nơi compute của agent nằm?” Mình trả lời như thể chỉ có một câu trả lời đúng. Không phải vậy — có một câu trả lời đúng cho mỗi loại tải việc, và biến quyết định nó là: tài nguyên chính của task có thường xuyên là thứ chỉ máy bạn mới có không.
Với Claude Code chạy một coding session, tài nguyên chính gần như luôn là local: repo thật của bạn, toolchain build thật, credential gắn với máy thật, một process chạy dài mà bạn muốn xem và can thiệp theo thời gian thực. Việc của Remote Control là cho bạn giám sát cái thứ local đó từ xa, không phải thay thế nó. Giữ execution ở local trong trường hợp này không phải bảo thủ, mà chỉ là nói đúng sự thật về nơi việc thật sự phải xảy ra.
Với Cowork, tài nguyên chính thường chỉ là ngẫu nhiên: lấy file này, check calendar này, soạn email này, chạy một task nhiều bước qua đêm. Máy local chỉ xuất hiện như một phụ thuộc đôi lúc, không phải nền tảng mà cả task chạy trên đó. Gắn execution vào một laptop có thể đang gập, đang ngủ, hoặc hết pin là một lựa chọn tệ hơn cho dạng việc này, so với một sandbox cloud theo từng session cùng một proxy gọi local mỏng cho những lúc hiếm hoi cần đến đĩa của bạn.
So với phần còn lại của thị trường
Kiểu “sandbox cloud cách ly theo từng session, với một điểm handoff local hẹp cho tài nguyên riêng của thiết bị” rất gần với cái GitHub cloud coding agent và OpenAI Codex cloud đang làm, và cả background agent của Cursor — cả ba đều tách execution của agent ra khỏi máy user, chạy trong một container agent sở hữu hoàn toàn. Chi tiết khác biệt trong bản của Anthropic, theo đúng tài liệu của họ, là ranh giới ở cấp tool-call rất rõ: thay vì đồng bộ một bản snapshot filesystem hay cần checkout kiểu git để chuyển state qua lại, app desktop chỉ trả lời đúng một request cụ thể mỗi lần, chỉ khi đang mở, và không gì còn lại ở local sau đó. Đây là một dấu chân local hẹp hơn, dễ kiểm chứng hơn so với “clone cả repo vào VM cloud” — điều này quan trọng nếu bạn nghĩ đến pattern này cho thứ gì nhạy cảm hơn soạn email.
Điều mình thực sự sẽ sửa trong kết luận tháng 8
Không phải luận điểm gốc — mình vẫn tin ranh giới “sync state, không sync execution” của Remote Control là lựa chọn đúng cho một công cụ mà toàn bộ giá trị là giám sát code phải chạy trên máy bạn. Cái mình sẽ sửa là câu nói thêm, lúc mình bảo pattern đó “generalize tốt ra ngoài coding agent, cho bất kỳ công cụ nào muốn giám sát từ xa một process phải ở local.” Chữ mình lướt qua chính là chữ quan trọng nhất: phải ở local. Cowork chứng minh rất nhiều tải việc của agent chỉ đôi lúc chạm đến thứ gì local, và với nhóm đó, lớp sync không phải là giới hạn trên của kiến trúc — nó chỉ là một lựa chọn trong vài lựa chọn, và execution nằm trên cloud với một handoff local hẹp có thể là mặc định tốt hơn.
Bài test thực tế mình sẽ áp trước khi chọn kiểu nào cho thứ mình đang xây: liệt kê task thực sự cần gì từ máy user, rồi hỏi nhu cầu đó là liên tục hay chỉ đôi lúc. Liên tục — một process đang sống, một credential không thể ra khỏi máy, một repo bạn đang sửa trực tiếp — giữ execution ở local, chỉ sync control plane, kiểu Remote Control đang làm. Đôi lúc — một lần tra file, một screenshot, một hành động local lẻ tẻ trong một task vốn đã tự chứa — một sandbox cloud với một callback hẹp, kiểu Cowork đang làm bây giờ, sẽ chịu đựng tốt hơn trước một cái laptop đang gập, hơn bất kỳ relay sync nào.
Nguồn: Felix Rieseberg qua Simon Willison, 5/10/2026, Anthropic support — Use Claude Cowork on web, desktop, and mobile



Thảo luận
Bình luận được duyệt trước khi công khai. Email của bạn được giữ riêng tư.