Qu'est-ce que CubeSandbox pour les agents IA ?

J’ai passé quelques soirées la semaine dernière à lire le dépôt CubeSandbox. Pas à l’exécuter en production — le projet n’est public que depuis le 21 avril, et le jugement que j’accorde habituellement à un outil nécessite plus de temps d’exécution. Mais les choix d’architecture sont suffisamment intéressants pour noter ce qu’ils signalent sur l’infrastructure des agents, avant que le cycle de l’actualité ne s’empare du cadrage.

Si vous construisez des agents qui exécutent du code non fiable — tout ce qui touche à l’interprétation de code, l’automatisation de navigateur, l’entraînement par renforcement, ou tout boucle “réflexion → exécution → retour” où le modèle décide ce qu’il faut exécuter — l’infrastructure sandbox n’est pas une préoccupation secondaire. C’est ce qui cède en premier sous la charge. CubeSandbox est une réponse. Cet article porte sur ce que c’est, pourquoi les choix de conception sont importants, et quelles équipes devraient l’évaluer. Pas sur si vous devriez switcher.

Ce qu’est CubeSandbox et ce que Tencent a rendu open-source

Architecture centrale et positionnement

CubeSandbox est un service sandbox open-source pour agents IA, publié par Tencent Cloud le 21 avril 2026 sous licence Apache 2.0. Le dépôt sur GitHub inclut la stack complète : passerelle API, orchestrateur, agents par nœud, couche réseau, hyperviseur. Pas un SDK, pas un wrapper autour d’un service hébergé. Vous le déployez vous-même.

Les affirmations techniques, tirées directement du README :

Démarrage à froid en moins de 60ms pour un sandbox pleinement opérationnel.
Surcharge mémoire par instance inférieure à 5MB.
~2 000 sandboxes concurrents sur un serveur à 96 cœurs.
Isolation au niveau matériel via RustVMM + KVM, chaque sandbox disposant de son propre noyau invité.
Compatibilité du protocole SDK E2B — une seule variable d’environnement à modifier pour migrer.

La base de code est approximativement moitié Rust, avec Go et C dans les couches de support. Le document de présentation de l’architecture la décompose en CubeAPI (passerelle REST compatible E2B), CubeMaster (orchestrateur de cluster), CubeProxy (routeur de requêtes), Cubelet (gestionnaire de cycle de vie par nœud), CubeVS (isolation réseau basée sur eBPF), et CubeHypervisor + CubeShim (la couche de virtualisation ; CubeShim implémente le Shim v2 de containerd). Le README crédite Cloud Hypervisor, Kata Containers, virtiofsd et containerd-shim-rs en amont — rien qui ne devrait surprendre quiconque dans ce domaine.

Concrètement : c’est un sandbox microVM de la même famille architecturale que Firecracker, mais une implémentation VMM distincte. Si la qualité de l’implémentation tient en dehors du testbed bare-metal de Tencent, c’est la question ouverte. Impossible à déterminer à partir d’un README.

Pourquoi la compatibilité E2B est importante

Le choix de conception le plus intéressant dans CubeSandbox n’est pas le démarrage à froid en 60ms. C’est la compatibilité délibérée avec le SDK E2B.

E2B est devenu un quasi-standard dans l’exécution de code pour les agents. Manus l’utilise. Une longue traîne d’applications LLM nécessitant d’exécuter du code généré par des modèles y ont d’abord recours. Son protocole SDK — from e2b_code_interpreter import Sandbox, pointer vers une URL, exécuter du code — est ce qui se rapproche le plus d’une interface de facto dans cette catégorie.

En reproduisant ce protocole, CubeSandbox contourne le problème que la plupart des « alternatives » ont : amener les développeurs à apprendre un nouveau SDK. Le chemin de migration est une variable d’environnement. Le code agent existant ne change pas. Si vous avez déjà développé contre E2B, la friction pour tester CubeSandbox est approximativement un après-midi, pas un trimestre.

Je me suis arrêté ici en lisant le dépôt. La compatibilité ne vise pas à prouver que CubeSandbox est « meilleur ». Elle vise à rendre l’expérience bon marché. C’est le pari le plus intelligent.

Pourquoi les sandboxes sont importants dans l’infrastructure des agents

Isolation, temps de démarrage et concurrence

Un sandbox fait trois choses à la fois pour un système d’agents, et vous ne pouvez pas en sacrifier une sans nuire aux autres.

Isolation. Quand un modèle génère du code, vous ne savez pas ce qu’il fait avant de l’exécuter. Un conteneur partageant le noyau hôte ne suffit pas. Un seul bug d’escalade de privilèges dans le noyau invité, ou une évasion Docker, et l’agent a atteint le système de fichiers hôte, les identifiants hôte, le réseau hôte. Les microVMs résolvent cela en donnant à chaque sandbox son propre noyau invité — une frontière matériellement virtualisée plutôt qu’une frontière de namespace. C’est le même argument qu’AWS a avancé en open-sourcant Firecracker pour Lambda : les conteneurs sont trop minces comme barrière pour l’exécution de code multi-locataire.

Temps de démarrage. Un agent qui décide « je vais exécuter ce script Python pour vérifier la sortie » prend cette décision dans un budget en millisecondes de temps réel. Si le sandbox met deux secondes à démarrer, la boucle de rétroaction est déjà brisée. Le produit paraît lent même quand le modèle est rapide. Firecracker a atteint des temps de démarrage de ~125ms et a rendu les microVMs viables pour le serverless. Le service hébergé d’E2B rapporte environ 150–200ms avec des pools pré-réchauffés. CubeSandbox revendique moins de 60ms via des pools de ressources pré-provisionnés et le clonage par snapshot. Ce chiffre, s’il tient, change quels types de boucles d’agents sont pratiques. Je le vérifierais sur mon propre matériel avant de le citer.

Concurrence. Un sandbox par utilisateur est le cas facile. Un sandbox par étape d’agent, par utilisateur, avec des milliers d’agents en vol est le difficile. La contrainte passe de « à quelle vitesse l’un démarre » à « combien peut-on en faire tourner sur une machine ». Le chiffre de 5MB par instance, couplé à 2 000+ sur une machine à 96 cœurs, est l’argument de densité. Que cela survive à des charges de travail réalistes — des sandboxes qui chargent effectivement des interpréteurs Python, des navigateurs, des dépendances — reste là encore la question ouverte.

Ces trois éléments s’opposent. Une isolation plus forte signifie généralement des VMs plus lourdes, un démarrage plus lent, une densité plus faible. Les systèmes microVM intéressants refusent ce compromis.

Pourquoi cela devient un goulot d’étranglement produit à l’échelle

Pour un prototype mono-utilisateur, rien de tout cela n’a d’importance. Mettez un conteneur Docker derrière votre agent, acceptez la dette de sécurité, déployez. Le coût est invisible jusqu’à ce qu’il ne le soit plus.

Il devient visible en trois points, que j’ai tous observés se dérouler :

Latence par étape. Un agent qui appelle le sandbox 20 fois dans une seule trace de raisonnement hérite du démarrage à froid 20 fois. À 200ms chacun, cela représente 4 secondes de latence d’infrastructure pure ajoutée au temps de réponse perçu par l’utilisateur. Le modèle n’est pas devenu plus lent. L’infrastructure si.

Concurrence multi-locataire. Dès que des utilisateurs payants font tourner des agents simultanément, « une VM par utilisateur » cesse de s’adapter linéairement. La facture d’hébergement croît plus vite que les revenus. Soit vous partagez les noyaux et acceptez le risque d’isolation, soit vous acceptez de moins bonnes marges. Il n’y a pas de troisième option sauf à changer la primitive sous-jacente.

L’écart expérimentation-production. Tout fonctionne localement avec un sandbox à la fois. La production révèle que les pools de préchauffage par snapshot ont une taille finie, qu’en charge les démarrages à froid reviennent, que les politiques réseau eBPF auxquelles vous n’avez pas pensé commencent à compter quand les sandboxes communiquent entre eux ou ne devraient pas. C’est la partie peu glorieuse qui est sous-vendue dans les articles de lancement.

CubeSandbox parie que l’isolation matérielle, la faible surcharge mémoire et les démarrages en moins de 60ms sont simultanément réalisables, et que les équipes en production s’en soucieront une fois qu’elles auront heurté ces trois murs. Que cela porte ses fruits dépend de l’exécution et de l’adoption. Les deux restent ouverts.

Qui devrait évaluer CubeSandbox et qui ne devrait pas

Mérite un vrai regard :

Les équipes déjà sur E2B atteignant des limites de coût ou de concurrence et envisageant de toute façon un auto-hébergement. La migration est véritablement un changement d’une ligne.
Les équipes infra construisant des plateformes d’agents internes avec des exigences de conformité ou de résidence des données excluant les clouds tiers. Apache 2.0 + auto-hébergé est le prérequis.
Quiconque exécute des boucles d’entraînement par renforcement à taux élevé de création de sandboxes, où le coût de démarrage à froid se situe dans la boucle d’entraînement interne. Une amélioration de 100ms multipliée par des millions d’épisodes représente de l’argent réel.
Les équipes dont la configuration actuelle est « conteneur Docker avec des flags de durcissement » et dont le modèle de menace a silencieusement dépassé cela. Le moment honnête pour changer est avant l’incident, pas après.

Probablement à ignorer pour l’instant :

Les prototypes et démos mono-utilisateur. Le coût de mise en place d’un cluster microVM n’est pas justifié à faible volume d’appels.
Les équipes sans accès bare-metal ou VMs compatibles KVM. L’exigence matérielle est réelle — Linux x86_64 avec KVM. Les VMs cloud standard sans virtualisation imbriquée ne sont pas qualifiées d’emblée, bien que la voie PVM élargisse cela.
Quiconque dont la stack est profondément ancrée dans un SDK non-E2B où le coût de migration dépasse les économies d’exécution. La compatibilité aide ; elle n’élimine pas entièrement le coût de migration.

C’est tout ce que je peux confirmer à partir de la lecture du code et de la documentation. Le reste nécessite un temps d’exécution en production, et je n’y suis pas encore.

FAQ

Quel problème CubeSandbox résout-il ?

C’est un runtime pour exécuter du code généré par IA en isolation, à faible latence, avec haute concurrence, sans partager le noyau hôte. Le problème qu’il cible est celui que toute plateforme d’agents finit par rencontrer : les conteneurs sont trop poreux pour le code non fiable, les VMs traditionnelles sont trop lentes et lourdes, les options microVM existantes sont soit propriétaires soit opérationnellement complexes.

En quoi diffère-t-il des approches conteneur uniquement ?

Les approches conteneur uniquement partagent le noyau hôte. Un exploit du noyau invité atteint l’hôte. CubeSandbox donne à chaque sandbox son propre noyau invité via la virtualisation matérielle basée sur KVM — une frontière plus solide contre le type de code qu’un LLM pourrait émettre quand quelque chose tourne mal, ou quand un utilisateur essaie de le faire. La surcharge mémoire rapportée (moins de 5MB par instance) comble également l’écart de densité qui historiquement rendait les VMs non économiques comparées aux conteneurs.

Pourquoi la compatibilité E2B est-elle importante ?

Parce que le coût d’essai d’un nouveau sandbox est généralement un projet de migration, pas l’essai lui-même. Le SDK d’E2B a suffisamment d’adoption que la compatibilité permet aux équipes de tester CubeSandbox en changeant une variable d’environnement. C’est la différence entre « je l’évaluerai le trimestre prochain » et « je vais le mettre en route ce soir ». Le choix de protocole fait le gros du travail sur l’adoption.

Quelles équipes devraient le tester en premier ?

Les équipes déjà sur E2B à un volume non négligeable, les équipes avec des contraintes de conformité nécessitant un auto-hébergement, et les équipes exécutant des boucles d’agents serrées où la latence de démarrage à froid apparaît dans le temps de réponse visible par l’utilisateur. Les utilisateurs à plus petite échelle peuvent attendre — l’adoption précoce coûte plus qu’elle n’économise.

Conclusion

L’infrastructure sous-jacente aux agents devient une vraie catégorie. Pour la majeure partie de 2024 et jusqu’en 2025, le sandboxing était une préoccupation secondaire — géré avec ce qui était pratique. Les équipes qui mettent désormais des agents devant de vrais utilisateurs découvrent que le choix du sandbox façonne tout, de la latence par requête à la marge par utilisateur.

CubeSandbox ne change pas la physique sous-jacente. Les microVMs étaient déjà la bonne réponse architecturale ; les questions ouvertes ont toujours été la qualité d’implémentation et la friction d’adoption. Le dépôt revendique des chiffres compétitifs sur le premier et adresse le second en parlant nativement le protocole d’E2B. Que les chiffres tiennent en production hors du testbed de Tencent, c’est ce que les prochains mois révéleront.

Je prévois de le déployer sur un cluster de test et de vérifier la revendication de démarrage à froid par rapport à ma propre charge de travail. À vérifier. Je reviendrai là-dessus quand j’aurai des données.

Articles précédents :