Apa Itu CubeSandbox untuk Agen AI?

Saya menghabiskan beberapa malam minggu lalu membaca repositori CubeSandbox. Bukan menjalankannya di produksi — proyek ini baru dipublikasikan sejak 21 April, dan penilaian yang biasa saya berikan pada sebuah alat membutuhkan lebih banyak waktu runtime. Namun keputusan arsitektur yang diambil cukup menarik untuk dicatat tentang apa yang mereka isyaratkan mengenai infrastruktur agen, sebelum siklus berita mengambil alih framing-nya.

Jika Anda membangun agen yang menjalankan kode yang tidak dipercaya — apa pun yang menyentuh interpretasi kode, otomasi browser, pelatihan RL, atau loop “berpikir → eksekusi → umpan balik” di mana model memutuskan apa yang harus dijalankan — infrastruktur sandbox bukan perhatian sampingan. Itulah hal yang pertama kali rusak di bawah beban. CubeSandbox adalah salah satu jawabannya. Artikel ini membahas apa itu, mengapa pilihan desain itu penting, dan tim mana yang harus mengevaluasinya. Bukan tentang apakah Anda harus beralih.

Apa Itu CubeSandbox dan Apa yang Tencent Open-Source-kan

Arsitektur inti dan positioning

CubeSandbox adalah layanan sandbox open-source untuk agen AI, dirilis oleh Tencent Cloud pada 21 April 2026 di bawah lisensi Apache 2.0. Repositori di GitHub menyertakan stack penuh: API gateway, orkestrator, agen per-node, lapisan jaringan, hypervisor. Bukan SDK, bukan pembungkus layanan yang di-hosting. Anda men-deploy-nya sendiri.

Klaim teknis, diambil langsung dari README:

Cold start di bawah 60ms untuk sandbox yang sepenuhnya dapat digunakan.
Overhead memori per-instance di bawah 5MB.
~2.000 sandbox bersamaan pada server 96-core.
Isolasi tingkat hardware via RustVMM + KVM, dengan setiap sandbox mendapatkan kernel tamu-nya sendiri.
Kompatibilitas protokol E2B SDK — cukup ubah satu variabel lingkungan untuk migrasi.

Codebase-nya sekitar setengah Rust, dengan Go dan C di lapisan pendukung. Dokumen gambaran umum arsitektur membaginya menjadi CubeAPI (gateway REST yang kompatibel dengan E2B), CubeMaster (orkestrator kluster), CubeProxy (router permintaan), Cubelet (manajer siklus hidup per-node), CubeVS (isolasi jaringan berbasis eBPF), dan CubeHypervisor + CubeShim (lapisan virtualisasi; CubeShim mengimplementasikan Shim v2 dari containerd). README mengakui Cloud Hypervisor, Kata Containers, virtiofsd, dan containerd-shim-rs upstream — tidak ada yang mengejutkan bagi siapa pun di bidang ini.

Secara praktis: ini adalah sandbox microVM dalam keluarga arsitektur yang sama dengan Firecracker, tetapi merupakan implementasi VMM yang terpisah. Apakah kualitas implementasi bertahan di luar testbed bare-metal Tencent adalah pertanyaan terbuka. Tidak dapat diketahui dari README.

Mengapa kompatibilitas E2B itu penting

Pilihan desain paling menarik dalam CubeSandbox bukan cold start 60ms. Melainkan kompatibilitas E2B SDK yang disengaja.

E2B telah menjadi hampir default dalam eksekusi kode agen. Manus menggunakannya. Sejumlah besar aplikasi LLM yang perlu menjalankan kode yang dihasilkan model menjangkaunya terlebih dahulu. Protokol SDK-nya — from e2b_code_interpreter import Sandbox, arahkan ke URL, jalankan kode — adalah hal yang paling mendekati antarmuka de facto yang dimiliki kategori ini.

Dengan mencerminkan protokol tersebut, CubeSandbox menghindari masalah yang dimiliki sebagian besar “alternatif”: membuat pengembang mempelajari SDK baru. Jalur migrasinya adalah satu variabel lingkungan. Kode agen yang ada tidak berubah. Jika Anda sudah membangun di atas E2B, hambatan untuk menguji CubeSandbox kira-kira satu sore, bukan satu kuartal.

Saya berhenti sejenak saat membaca repositori ini. Kompatibilitasnya bukan bertujuan membuktikan CubeSandbox “lebih baik.” Ini bertujuan membuat eksperimen menjadi murah. Itu taruhan yang lebih cerdas.

Mengapa Sandbox Penting dalam Infrastruktur Agen

Isolasi, waktu startup, dan konkurensi

Sebuah sandbox melakukan tiga hal sekaligus untuk sistem agen, dan Anda tidak bisa menukarkan satu tanpa merusak yang lain.

Isolasi. Ketika sebuah model menghasilkan kode, Anda tidak tahu apa yang dilakukannya sampai Anda menjalankannya. Container yang berbagi kernel host tidaklah cukup. Satu bug privilege-escalation di kernel tamu, atau satu Docker escape, dan agen telah mencapai filesystem host, kredensial host, jaringan host. MicroVM memecahkan ini dengan memberikan setiap sandbox kernel tamu-nya sendiri — batas yang divirtualisasikan secara hardware alih-alih batas namespace. Ini adalah argumen yang sama yang AWS buat ketika men-open-source Firecracker untuk Lambda: container terlalu tipis sebagai dinding untuk eksekusi kode multi-tenant.

Waktu startup. Agen yang memutuskan “Saya akan menjalankan skrip Python ini untuk memeriksa output” membuat keputusan itu dalam milidetik anggaran wall-clock. Jika sandbox membutuhkan dua detik untuk berjalan, loop umpan balik sudah rusak. Produk terasa lambat bahkan ketika model cepat. Firecracker mencapai waktu boot ~125ms dan membuat microVM layak untuk serverless. Layanan hosted E2B melaporkan sekitar 150–200ms dengan pool yang dipanaskan sebelumnya. CubeSandbox mengklaim di bawah 60ms melalui pool sumber daya yang telah diprovisi sebelumnya dan kloning snapshot. Angka itu, jika bertahan, mengubah jenis loop agen apa yang praktis. Saya akan memverifikasinya di hardware saya sendiri sebelum mengutipnya.

Konkurensi. Satu sandbox per pengguna adalah kasus yang mudah. Satu sandbox per langkah agen, per pengguna, dengan ribuan agen yang berjalan adalah yang sulit. Batasan bergeser dari “seberapa cepat satu dimulai” ke “berapa banyak yang bisa Anda jalankan di satu mesin.” Angka 5MB per-instance, dipasangkan dengan 2.000+ pada mesin 96-core, adalah argumen densitas. Apakah itu bertahan di beban kerja realistis — sandbox yang benar-benar memuat interpreter Python, browser, dependensi — sekali lagi merupakan pertanyaan terbuka.

Ketiga hal ini saling bertentangan. Isolasi yang lebih kuat biasanya berarti VM yang lebih berat, startup yang lebih lambat, densitas yang lebih rendah. Sistem microVM yang menarik menolak trade-off ini.

Mengapa ini menjadi bottleneck produk pada skala besar

Untuk prototipe pengguna tunggal, tidak ada yang penting. Letakkan container Docker di belakang agen Anda, terima utang keamanan, kirim. Biayanya tidak terlihat sampai tidak.

Menjadi terlihat di tiga titik, yang semuanya pernah saya saksikan:

Latensi per-langkah. Agen yang memanggil sandbox 20 kali dalam satu jejak penalaran mewarisi cold start 20 kali. Pada 200ms masing-masing, itu adalah 4 detik latensi infrastruktur murni yang ditambahkan ke waktu respons yang dirasakan pengguna. Modelnya tidak menjadi lebih lambat. Infrastrukturnya ya.

Konkurensi multi-tenant. Setelah pengguna berbayar menjalankan agen secara bersamaan, “satu VM per pengguna” berhenti menskalakan secara linier. Tagihan hosting tumbuh lebih cepat dari pendapatan. Anda berbagi kernel dan menerima risiko isolasi, atau menerima margin yang lebih buruk. Tidak ada opsi ketiga kecuali mengubah primitif yang mendasarinya.

Kesenjangan eksperimen-ke-produksi. Semuanya berjalan secara lokal dengan satu sandbox sekaligus. Produksi mengungkapkan bahwa pool warmup snapshot memiliki ukuran terbatas, bahwa di bawah beban cold start kembali lagi, bahwa kebijakan jaringan eBPF yang tidak Anda pikirkan mulai penting ketika sandbox berkomunikasi satu sama lain atau tidak seharusnya. Ini adalah bagian yang tidak glamor yang kurang terjual dalam posting peluncuran.

CubeSandbox bertaruh bahwa isolasi hardware, overhead memori rendah, dan start di bawah 60ms dapat dicapai secara bersamaan, dan bahwa tim produksi akan peduli setelah mereka menabrak tiga dinding tersebut. Apakah itu terbayar adalah fungsi dari eksekusi dan adopsi. Keduanya masih terbuka.

Siapa yang Harus Mengevaluasi CubeSandbox dan Siapa yang Tidak

Layak dilihat secara serius:

Tim yang sudah menggunakan E2B dan mencapai batas biaya atau konkurensi serta mempertimbangkan self-hosting. Migrasi benar-benar hanya perubahan satu baris.
Tim infra yang membangun platform agen internal dengan kepatuhan atau persyaratan data-residency yang mengesampingkan cloud pihak ketiga. Apache 2.0 + self-hosted adalah prasyaratnya.
Siapa pun yang menjalankan loop pelatihan RL dengan tingkat pembuatan sandbox yang tinggi, di mana biaya cold-start berada dalam loop pelatihan dalam. Peningkatan 100ms dikalikan jutaan episode adalah uang nyata.
Tim yang pengaturan saat ini adalah “Docker container dengan flag hardening” dan model ancamannya secara diam-diam telah melampaui itu. Momen jujur untuk beralih adalah sebelum insiden, bukan sesudahnya.

Mungkin skip untuk saat ini:

Prototipe dan demo pengguna tunggal. Biaya mendirikan kluster microVM tidak dibenarkan pada volume panggilan rendah.
Tim tanpa akses bare-metal atau VM yang mendukung KVM. Persyaratan hardware nyata — x86_64 Linux dengan KVM. VM cloud standar tanpa virtualisasi bersarang tidak memenuhi syarat secara langsung, meskipun jalur PVM memperluas ini.
Siapa pun yang stack-nya sudah dalam di SDK non-E2B di mana biaya migrasi melebihi penghematan runtime. Kompatibilitas membantu; tidak menghilangkan biaya perpindahan sepenuhnya.

Itu semua yang bisa saya konfirmasi dari membaca kode dan dokumen. Sisanya membutuhkan runtime produksi, dan saya belum menempatkannya di sana.

FAQ

Masalah apa yang diselesaikan CubeSandbox?

Ini adalah runtime untuk mengeksekusi kode yang dihasilkan AI dalam isolasi, dengan latensi rendah, konkurensi tinggi, tanpa berbagi kernel host. Masalah yang ditargetkannya adalah yang akhirnya dihadapi setiap platform agen: container terlalu bocor untuk kode yang tidak dipercaya, VM tradisional terlalu lambat dan berat, opsi microVM yang ada baik bersifat proprietary atau kompleks secara operasional.

Bagaimana perbedaannya dengan pendekatan container-only?

Pendekatan container-only berbagi kernel host. Eksploit kernel tamu mencapai host. CubeSandbox memberikan setiap sandbox kernel tamu-nya sendiri melalui virtualisasi hardware berbasis KVM — batas yang lebih kuat terhadap jenis kode yang mungkin dipancarkan LLM ketika sesuatu berjalan salah, atau ketika pengguna mencoba membuatnya. Overhead memori yang dilaporkan (di bawah 5MB per instance) juga menutup kesenjangan densitas yang secara historis membuat VM tidak ekonomis dibandingkan container.

Mengapa kompatibilitas E2B penting?

Karena biaya mencoba sandbox baru biasanya adalah proyek migrasi, bukan percobaan itu sendiri. SDK E2B memiliki adopsi yang cukup sehingga kompatibilitas memungkinkan tim menguji CubeSandbox dengan mengubah satu variabel lingkungan. Itulah perbedaan antara “Saya akan mengevaluasinya kuartal depan” dan “Saya akan menyalakannya malam ini.” Pilihan protokol melakukan pekerjaan berat dalam adopsi.

Tim mana yang harus mencobanya terlebih dahulu?

Tim yang sudah menggunakan E2B dengan volume yang tidak trivial, tim dengan batasan kepatuhan yang memerlukan self-hosting, dan tim yang menjalankan loop agen yang ketat di mana latensi cold-start muncul dalam waktu respons yang terlihat pengguna. Pengguna skala lebih kecil bisa menunggu — adopsi awal lebih mahal daripada yang dihemat.

Kesimpulan

Infrastruktur di bawah agen sedang menjadi kategori nyata. Selama sebagian besar 2024 dan memasuki 2025, sandboxing adalah perhatian sampingan — ditangani dengan apa pun yang nyaman. Tim yang kini menempatkan agen di depan pengguna nyata menemukan bahwa pilihan sandbox membentuk segalanya mulai dari latensi per-permintaan hingga margin per-pengguna.

CubeSandbox tidak mengubah fisika yang mendasarinya. MicroVM sudah merupakan jawaban arsitektur yang tepat; pertanyaan terbuka selalu tentang kualitas implementasi dan hambatan adopsi. Repositori ini mengklaim angka yang kompetitif pada yang pertama dan menangani yang kedua dengan berbicara protokol E2B secara native. Apakah angka-angka itu bertahan di tangan produksi di luar testbed Tencent adalah apa yang akan diungkapkan beberapa bulan ke depan.

Saya berencana men-deploy-nya di kluster uji dan memeriksa klaim cold-start terhadap beban kerja saya sendiri. Masih perlu diverifikasi. Saya akan kembali ke ini ketika saya sudah memiliki data.

Posting Sebelumnya: