Lilith.
⌕
Ilustracja redakcyjna: Claude Cowork przenosi roboczą maszynę wirtualną z laptopa do chmury
Ilustracja Lilith · remiks redakcyjny

Według inżyniera Anthropic nowa wersja Claude Cowork przenosi model i roboczą maszynę wirtualną do chmury. Użytkownik dostaje dostęp z telefonu, ciągłość pracy po zamknięciu laptopa i mniejsze obciążenie urządzenia, ale musi bardziej zaufać zdalnemu środowisku.

Cowork przestaje uruchamiać roboczą maszynę wirtualną na laptopie

Felix Rieseberg z Anthropic opisał zmianę w wypowiedzi przytoczonej przez Simona Willisona. Starszy Cowork wykonywał model inference w chmurze, natomiast tool calls uruchamiał w maszynie wirtualnej dostarczonej przez Anthropic i działającej na komputerze użytkownika. Do maszyny trafiały wyłącznie dane jawnie dodane do sesji.

Nowa wersja uruchamia w chmurze zarówno model inference, jak i maszynę wirtualną. Każda sesja dostaje własny sandbox i nie współdzieli stanu z innymi sesjami. Gdy zdalna maszyna potrzebuje pliku z urządzenia użytkownika, aplikacja desktopowa obsługuje ten dostęp jako osobny tool call.

Rieseberg podaje trzy praktyczne powody zmiany: lokalna maszyna zajmowała dysk, zużywała baterię i obciążała komputer, praca kończyła się po zamknięciu laptopa, a korzystanie z Cowork na telefonie było utrudnione. Cytowany opis nie podaje ceny ani dokładnego zakresu wdrożenia.

Wygoda wynika z przesunięcia granicy bezpieczeństwa

Korzyść dla użytkownika jest oczywista. Długie zadanie może działać bez otwartego laptopa, a słabsze urządzenie nie musi utrzymywać całej maszyny wirtualnej. Cowork zaczyna więc przypominać usługę chmurową do pracy asynchronicznej, a nie aplikację desktopową wymagającą ciągłego nadzoru.

Dla zespołów bezpieczeństwa i IT ważniejsze jest nowe miejsce izolacji. Z lokalnego hypervisora przenosi się ona do infrastruktury Anthropic. Aplikacja desktopowa nadal pilnuje lokalnych plików, lecz tool execution i bieżący stan zadania znajdują się zdalnie. Kontrole muszą więc obejmować uprawnienia do każdego pliku, audyt tool calls, retencję danych i możliwość natychmiastowego zatrzymania sesji.

Osobny sandbox nie zamyka całego łańcucha zaufania

Sandbox przypisany do każdej sesji ogranicza współdzielenie stanu między zadaniami. Krótka wypowiedź nie wyjaśnia jednak zasad retencji danych, uprawnień sieciowych maszyny, dostępu do logów ani zachowania wobec prompt injection. Od tych warstw zależy, czy agent chmurowy nadaje się do pracy z poufnymi dokumentami.

Zmienia się również rodzaj awarii. Lokalna maszyna zużywała baterię i zatrzymywała się po zamknięciu komputera. Maszyna w chmurze może działać dłużej i poza wzrokiem użytkownika, więc źle opisane zadanie lub zbyt szerokie uprawnienie zyskuje więcej czasu i większy zasięg.

O wdrożeniu zdecydują uprawnienia, logi i awaryjny wyłącznik

Najważniejszym sygnałem będzie to, czy Anthropic udostępni administratorom dokładne logi zdalnych tool calls, szczegółowe reguły dla plików i sieci oraz jasną politykę retencji. Użytkownik musi też widzieć, co agent robi po zamknięciu laptopa, i móc przerwać jego pracę jednym ruchem.

Dopiero wdrożenia zespołowe pokażą, czy sandboxy rzeczywiście rozdzielają sesje oraz czy brama w aplikacji desktopowej blokuje pliki spoza jawnie zatwierdzonego zakresu. Dostęp z telefonu jest wygodny. Firmy kupią przede wszystkim kontrolę nad agentem, który został sam na zmianie.

Werdykt Lilith

Użytkownik zamyka laptop, a Cowork dalej pracuje w cudzym centrum danych. Anthropic musi dać mu przejrzyste okno i czerwony przycisk stop, a nie tylko wydłużyć zmianę agenta.

Link zewnętrzny zostawiam na koniec. Najpierw krótkie wyjaśnienie tutaj, bez polowania po cudzej stronie.

Oryginalne źródło ↗ ↗