- เมื่อเปิดใช้งาน ฟีเจอร์ Cowork บน macOS ระบบจะสร้าง virtual machine (VM) bundle ขนาดราว 10GB โดยอัตโนมัติ ทำให้ประสิทธิภาพลดลงอย่างมาก
- ไฟล์นี้ถูกเก็บไว้ใต้
~/Library/ และแม้จะลบออกแล้วก็จะ ถูกสร้างขึ้นใหม่อีกในวันถัดไป
- เมื่อมีไฟล์นี้ จะเกิดอาการประสิทธิภาพลดลงต่อเนื่อง เช่น การใช้ CPU สูงขึ้น (24~55%), swap เพิ่มขึ้น, UI หน่วง
- วิธีแก้ชั่วคราวคือการลบ VM bundle และโฟลเดอร์แคช ซึ่งช่วย ปรับปรุงประสิทธิภาพได้ราว 75% แต่เมื่อเวลาผ่านไปก็จะช้าลงอีก
- ผู้ใช้หลายรายชี้ให้เห็นถึง การขาดความโปร่งใสและการสิ้นเปลืองพื้นที่จัดเก็บ พร้อมเรียกร้องให้มีการตั้งค่าเพื่อเลือกว่าจะสร้าง VM หรือไม่ และมีการแจ้งล่วงหน้า
ภาพรวมของปัญหา
- หลังใช้ฟีเจอร์ Cowork แล้ว Claude Desktop ช้ามาก และเกิดอาการเริ่มต้นช้า, UI กระตุก, การตอบสนองล่าช้า
- ประสิทธิภาพลดลงจะค่อย ๆ รุนแรงขึ้นระหว่างเซสชัน และ ไฟล์ VM bundle ขยายได้ถึง 10GB พร้อมถูกสร้างใหม่อัตโนมัติ
- ปัญหานี้สามารถเกิดซ้ำได้บน macOS (RAM 8GB)
ผลการตรวจสอบ
- VM bundle ที่ฟีเจอร์ Cowork สร้างอยู่ที่
~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img
- แม้จะลบไฟล์นี้แล้ว ก็จะถูกสร้างใหม่ภายในหนึ่งวัน และไม่มี การล้างข้อมูลอัตโนมัติ (cleanup)
- เมื่อลบ VM bundle และแคช พื้นที่จัดเก็บจะลดจาก 11GB → 639MB และ ความเร็วในการทำงานดีขึ้นราว 75%
- อย่างไรก็ตาม หลังรีสตาร์ตเพียงไม่กี่นาที การใช้ CPU จะเพิ่มจาก 24% → 55% และ swapins 20K → 24K+
- สิ่งนี้บ่งชี้ว่าอาจมี memory leak หรือภาระงานสะสม ที่ทำให้ประสิทธิภาพลดลง
พฤติกรรมที่สังเกตได้
- การใช้ CPU 24~55% แม้ขณะ idle
- กิจกรรม swap เพิ่มขึ้นต่อเนื่อง และประสิทธิภาพตกลงภายในไม่กี่นาที
- มีการสร้าง VM bundle ขนาด 10GB ใหม่ทุกเซสชันของ Cowork
- ดีขึ้นชั่วคราวหลังล้างข้อมูล (75%) แต่เมื่อเวลาผ่านไปก็กลับมาลดลงอีก
วิธีแก้ชั่วคราว
เสียงตอบรับจากผู้ใช้
- แม้จะปิดการใช้งาน Cowork อยู่ VM ก็ยังทำงานและใช้หน่วยความจำ
- ผู้ใช้บางรายรายงานว่า VM bundle ขยายเกิน 21GB
- VM จะถูก reprovision ใหม่อัตโนมัติเมื่อเปิดแอป และยังเหลือไฟล์บีบอัด (
rootfs.img.zst) ไว้ด้วย ทำให้ เปลืองพื้นที่ซ้ำซ้อน
- แม้แต่ผู้ใช้ที่ไม่เคยใช้ Cowork เลยก็ยังพบ bundle ขนาด 10GB และมองว่าเป็น memory leak
- ผู้ใช้ Mac ที่มีพื้นที่จัดเก็บจำกัดย้ำถึง ความจำเป็นของตัวเลือกปิดใช้งาน
ประเด็นด้านความโปร่งใสและความน่าเชื่อถือ
- ผู้ใช้ชี้ว่าการที่แอปใช้ ดิสก์ 12~20GB และ RAM 2GB โดยไม่แจ้งล่วงหน้า เป็นปัญหา
- มีข้อเสนอให้ แจ้งเตือนตอนติดตั้งหรือเปิดใช้งานครั้งแรก, ให้เลือกว่าจะดาวน์โหลด VM ล่วงหน้าหรือไม่, และ เพิ่มสวิตช์ปิด Cowork
- บางคนระบุว่า เข้าใจเจตนาของการออกแบบ sandbox ด้วย VM แต่การขาดคำอธิบายทำลายความเชื่อมั่นของผู้ใช้
- มีความเห็นจำนวนมากว่า “แอปที่ใช้ทรัพยากรระบบโดยที่ผู้ใช้ไม่รู้ตัว ทำให้ความเชื่อมั่นลดลง”
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สวัสดี Felix จาก Anthropic เอง ฉันรับผิดชอบ Claude Cowork และ Claude Code
Cowork ถูกสร้างขึ้นบน agent harness ของ Claude Code ที่ทำงานอยู่ภายใน Linux VM และรันผ่าน Apple Virtualization Framework หรือ Microsoft Host Compute System
เหตุผลที่ทำแบบนี้มีสามข้อ
(1) เพื่อมอบ สภาพแวดล้อมคอมพิวเตอร์ที่แยกอิสระ ให้ Claude สามารถเขียนโค้ดแทนผู้ใช้ได้อย่างอิสระ
(2) เพื่อให้ การรับประกันขอบเขตด้านความปลอดภัย ชัดเจนกว่าทางเลือกด้าน sandboxing อื่น ๆ
(3) เพื่อมอบประสบการณ์การใช้งานที่ปลอดภัยยิ่งขึ้นแก่ผู้ใช้ที่ไม่เชี่ยวชาญด้านเทคนิค
อย่างไรก็ตาม เราทราบดีว่ามี trade-off อยู่ และกำลังพิจารณาแนวคิดปรับปรุงสำหรับคนที่ไม่ต้องการใช้ Cowork หรืออยากใช้งานโดยไม่มี VM
การลด “approval fatigue” อาจเป็นประโยชน์ต่อ Anthropic ในระยะสั้น แต่ในระยะยาวไม่ได้เป็นผลดีต่อผู้ใช้
น่าจะดีกว่าถ้าหยุดรูปแบบนี้ก่อนที่มันจะกลายเป็นเรื่องปกติ
ดูเหมือนว่าจะเกิด nested virtualization error เพราะตัวมันเองก็รันอยู่ใน VM แล้ว น่าจะปรับปรุงข้อความ error หรือถ้าตรวจพบว่าอยู่ใน VM อยู่แล้ว ให้ Cowork ข้ามการสร้าง VM ของตัวเองไป
ช่วงนี้น่าตกใจที่แอปต่าง ๆ ใช้การเข้าถึงดิสก์กันเกินจำเป็น
ตัวอย่างเช่น Apple Podcasts ดาวน์โหลด ไฟล์พอดแคสต์ 120GB โดยไม่มีเหตุผลและไม่ยอมลบออก มันถูกแสดงเป็น “System Data” จนต้องไปไล่หาในไดรฟ์ภายนอก
~/Library/Messagesจะพบว่าการซิงก์ iMessage กินเกิน 100GB เรื่องแบบนี้ควร โยนไปเก็บบนคลาวด์ตอนนี้กำลังสัมผัสทั้งพรและคำสาปของ “vibe coding” ไปพร้อมกัน เรียกได้ว่าเป็น สองด้านของการเขียนโค้ดตามฟีล อย่างแท้จริง
VM sandbox คือแกนหลักของ Cowork ถ้าจะให้ความสามารถสร้างโค้ดได้อย่างปลอดภัย ก็จำเป็นต้องมี สภาพแวดล้อมแบบแยกส่วน
ขอเสนอ UI ที่ให้ผู้ใช้กำหนดสิทธิ์เข้าถึงได้เฉพาะบางโฟลเดอร์ และแสดงคำเตือนเมื่อจำเป็นต้องใช้สิทธิ์เขียน
จริง ๆ แล้วต่อให้ไม่มี LLM การพัฒนาก็ควรทำใน VM อยู่ดี
เครื่องมืออย่าง Vagrant ก็ยังมีประโยชน์อยู่
กลุ่มเป้าหมายหลักของ Cowork คือผู้ที่ไม่ใช่นักพัฒนา และควรมองมันเป็น AI ผู้ช่วยที่เขียนโค้ดได้
ผู้เชี่ยวชาญอาจทำงานบน Mac Mini แยกต่างหาก แต่ผู้ใช้ทั่วไปทำแบบนั้นไม่ได้ ดังนั้น VM จึงเป็นทางออกที่สมจริง
ได้ยินมาว่าพนักงาน Anthropic กำลังใช้ Claude Code เพื่อพัฒนา Claude Code
AI ช่วยเพิ่มความสมบูรณ์ของผลิตภัณฑ์ได้ แต่ปัญหาคือ คุณภาพที่ลดลง สุดท้ายก็ยังต้องพึ่งนักพัฒนาที่มีทักษะอยู่ดี
ผู้ใช้กลุ่มแรก ๆ ต้องรับบทเป็นหนูทดลองเพื่อช่วยทดสอบผลิตภัณฑ์
ช่วง 30 นาทีที่ผ่านมา ฉันกำลังจัดระเบียบโน้ตบุ๊กด้วย DaisyDisk แล้วก็เจอ VM 10GB ของ Cowork
หลายแอปมักกินพื้นที่เก็บข้อมูลโดยไม่จำเป็น และแทบไม่มีฟังก์ชันช่วยจัดการเลย
Xcode เองก็ยังเก็บ SDK และ simulator สำหรับหลาย OS ไว้ ทั้งที่ไม่ได้เปิดใช้งานมานานแล้ว
crondกับfindอยู่แล้ว เลยสงสัยว่าทำไมไม่ทำงานล้างพวกนี้ให้เป็นอัตโนมัติเนื่องจาก Cowork ใช้ Apple Virtualization Framework จึงเกิด nested VM error ได้
ส่งผลให้มีข้อจำกัดของฟีเจอร์ เปลืองพื้นที่ และเกิดความหน่วง ทางเลือกที่ดีกว่าอาจเป็น Seatbelt sandbox ที่ OpenAI ใช้อยู่
ลิงก์ที่เกี่ยวข้อง
แม้จะไม่สะดวก แต่วิธีทำ sandbox แบบนี้แหละคือ แก่นแท้ของเครื่องมือแบบ agent
เครื่องมือที่รันโดยไม่มี sandbox ในตัว สักวันหนึ่งจะนำไปสู่ การสูญหายของข้อมูล
เดาว่าข้างใน Anthropic คงมีคนโยนพรอมป์ต์แนว “ปรับปรุงประสิทธิภาพแอป” เข้าไป แล้วผลลัพธ์ถึงออกมาเป็นแบบนี้