CubeSandbox vs E2B pour les agents en production

Je m’appelle Dora. Récemment, nous avions un agent effectuant des appels d’outils en production. L’orchestrateur fonctionnait bien. Le LLM fonctionnait bien. Le goulot d’étranglement se situait au niveau de la couche sandbox — chaque fois que l’agent devait exécuter un fragment de code généré, nous payions 200 ms de démarrage à froid, parfois plus, parfois la file d’attente devenait capricieuse. Avec ~40 appels d’outils par session, cela représente une portion significative du temps total.

J’ai donc commencé à examiner les alternatives. La comparaison que tout le monde semble faire en ce moment est CubeSandbox vs E2B. Cet article résume ce que j’ai trouvé après deux semaines à lire les deux projets, en déployant l’un d’eux, et en étant incapable de déployer l’autre (j’y reviendrai).

Avertissement rapide dès le départ : je n’ai aucune relation commerciale avec l’un ou l’autre projet. Les deux sont open source. Le tableau ci-dessous représente un compromis hébergé vs auto-hébergé, et non une opposition « bon / méchant ».

CubeSandbox vs E2B en un coup d’œil

Les deux projets résolvent le même problème de la même façon : démarrer une microVM, exécuter du code non fiable, puis l’arrêter. Les deux publient des chiffres de performance dans la même fourchette. La différence réelle est la forme du produit.

CubeSandbox est une pile sandbox-as-a-service open source de Tencent Cloud, publiée en avril 2026 sous licence Apache 2.0. Construit sur RustVMM et KVM. Chiffres annoncés dans leur dépôt : démarrage à froid inférieur à 60 ms, ~5 Mo de mémoire par sandbox, compatibilité native avec le SDK E2B (changement d’une seule variable d’environnement URL). Il est distribué comme pile complète auto-hébergeable, pas simplement comme bibliothèque.

E2B est également open source (également Apache 2.0), construit sur les microVMs Firecracker. Fondé en 2023. Initialisation de sandbox autour de 150–200 ms avec des pools de snapshots pré-chauffés. L’auto-hébergement existe via des scripts Terraform, mais la distribution principale est le cloud géré — Hobby (gratuit, 100 $ de crédits), Pro (150 $/mois + usage), Enterprise (BYOC, on-prem). Les utilisateurs auto-hébergés sont minoritaires, le mode hébergé est l’offre par défaut.

Le vrai axe n’est donc pas « quel sandbox est le meilleur ». C’est :

Fonctionnalité	CubeSandbox	E2B
Licence	Apache 2.0	Apache 2.0
Mode principal	Auto-hébergé	SaaS hébergé (auto-hébergement possible)
VMM sous-jacent	RustVMM + KVM	Firecracker (KVM)
Démarrage à froid publié	`<60ms`	~150–200ms
Mémoire par sandbox	~5 Mo	~5 Mo
Compatibilité SDK	Remplacement direct du SDK E2B	SDK E2B natif
Support GPU	Nécessite Linux x86_64 avec KVM activé ; pas de passthrough natif en amont	Mêmes contraintes GPU que Firecracker
Charge opérationnelle	Vous gérez le cluster	E2B gère le cluster (managé)

Les chiffres ci-dessus sont tirés du dépôt et des notes de version de chaque projet, et non d’un benchmark que j’ai exécuté. Traitez-les comme des données publiées par les fournisseurs — utiles comme indicateurs, mais non substituables à vos propres tests.

Compromis hébergé vs auto-hébergé

C’est la vraie décision, et elle est principalement non technique.

Choisir l’hébergement avec E2B signifie que vous cessez de penser aux noyaux microVM, aux pools de snapshots, aux hôtes KVM et au basculement d’orchestrateur. Vous cessez également de penser à l’optimisation des coûts, car la tarification est fixée pour vous. L’équipe avec laquelle je travaillais a essayé E2B Pro pendant deux semaines — l’intégration prend réellement environ une heure, le SDK est propre, et les heures d’ingénierie économisées sont bien réelles.

Choisir l’auto-hébergement avec CubeSandbox signifie que vous possédez la machine. Le coût devient « quel est le coût du serveur sous-jacent » au lieu de « quel est le coût de notre courbe d’utilisation ». La conformité devient plus simple car aucune donnée ne quitte votre périmètre. Mais vous êtes aussi responsable de la rotation d’astreinte, des mises à jour du noyau, et du réglage des politiques eBPF. CubeSandbox fournit un déploiement en un clic pour les configurations à nœud unique et en cluster, ce qui aide, mais « déploiement en un clic » et « cluster prêt pour la production » ne sont pas la même chose.

Je me suis arrêté ici pendant quelques jours, car la réponse dépend vraiment de la composition de l’équipe. Une startup de quatre personnes qui déploie des agents le trimestre prochain ne devrait probablement pas gérer sa propre flotte de microVMs. Une équipe avec des ingénieurs infrastructure et des contraintes de conformité le devrait probablement.

Questions de compatibilité et de migration

La compatibilité E2B de CubeSandbox est la revendication technique la plus intéressante de la release CubeSandbox. Selon leur documentation, un agent existant basé sur E2B peut changer une seule variable d’environnement et router le trafic vers un cluster CubeSandbox auto-hébergé — sans modification de code. Je n’ai pas personnellement migré une charge de travail E2B en production, donc je prends cette affirmation sur la foi pour l’instant, mais elle est vérifiable en lisant les appels SDK que chaque côté accepte. La surface est réduite. Les deux parlent le même cycle de vie Sandbox : créer, exécuter une commande, exécuter du code, terminer.

C’est là que les choses deviennent utiles : cela signifie que CubeSandbox est essentiellement un backend bring-your-own-infrastructure pour le SDK E2B. Vous pouvez développer sur le cloud hébergé d’E2B, puis rediriger vers votre propre cluster lorsque l’utilisation le justifie. L’argument du verrouillage s’affaiblit des deux côtés — ce que je considère comme sain pour cette catégorie.

Où CubeSandbox l’emporte

Contrôle, structure des coûts et propriété de l’infrastructure

Pour toute équipe d’agents ayant un volume suffisant pour que la tarification de sandbox géré commence à apparaître dans la facture mensuelle, CubeSandbox est l’option la plus honnête. Vous payez pour du matériel que vous comprenez déjà. Le filtrage des sorties via eBPF (CubeVS) est configurable au niveau du noyau. Si vos règles de résidence des données stipulent « cela ne peut pas quitter notre VPC », c’est une conversation de 30 secondes avec un sandbox auto-hébergé et une conversation beaucoup plus longue avec un sandbox géré.

Ce qui n’est pas assez dit : un runtime d’agent auto-hébergé n’est pas un repas gratuit. Le coût marginal par exécution diminue, le coût fixe augmente. Le point d’équilibre est unique à la courbe d’utilisation de chaque équipe. Faites le calcul avant de décider. Si la réponse est « nous économiserons 300 $/mois et ajouterons deux heures de travail opérationnel hebdomadaire », ce n’est pas une victoire.

Revendications de performance et de densité que les équipes devraient tester

CubeSandbox publie un démarrage à froid inférieur à 60 ms, que les notes de version de Tencent Cloud via HPCwire décrivent comme « un tiers de la moyenne du secteur (150 ms) ». Ils revendiquent également 2 000+ sandboxes sur une seule machine physique. Ces chiffres proviennent de charges de travail en production au sein de Tencent Cloud, et non d’un benchmark synthétique — ce qui est mieux que synthétique, mais c’est toujours leur charge de travail, pas la vôtre.

Ce que je testerais avant de croire aux chiffres annoncés :

Démarrage à froid avec votre taille de snapshot réelle (un template de 5 Go se comporte différemment d’un de 200 Mo)
Comportement de la concurrence au p99, pas seulement en moyenne — CubeSandbox publie un temps de réponse moyen de 67 ms à 50 concurrent, ce qui est encourageant mais différent du p99
Si vos dépendances spécifiques survivent au noyau allégé de RustVMM sans surprise

C’est là que mes données s’arrêtent. J’ai déployé CubeSandbox sur une seule VM avec KVM activé et j’ai réussi à le faire servir des sandboxes en environ une demi-journée. Je ne l’ai pas soumis à des tests de charge aux densités mentionnées dans la release. Quiconque prétend l’avoir fait, après trois semaines d’existence publique du projet, exagère probablement.

Où E2B l’emporte encore

L’autre moitié du tableau CubeSandbox vs E2B : si vous ne voulez pas penser à l’infrastructure, E2B gagne. Cette phrase peut sembler condescendante, mais c’est la vraie conclusion.

Plus précisément :

Le SDK E2B hébergé est plus mature. Plus d’exemples de livres de cuisine, plus d’intégrations LangChain/LlamaIndex, un historique plus long.
Manus, l’analyse de code de Perplexity, Open R1 de Hugging Face — des références de production à grande échelle existent. CubeSandbox a des références de production au sein de Tencent Cloud, ce qui est réel, mais les études de cas externes sont encore en cours de rédaction.
La documentation E2B couvre les sandboxes desktop, les templates à partir de Dockerfiles, la persistance des fichiers et les sessions de 24 heures en standard. CubeSandbox est plus spartiate — le README et les exemples couvrent le cycle de vie principal, pas la longue traîne.
Firecracker lui-même est une quantité connue. AWS Lambda tourne dessus. Le projet Firecracker est en production depuis 2018. La pile basée sur RustVMM de CubeSandbox est plus récente dans l’œil du public, même si elle tourne dans Tencent depuis un moment.

Si vous déployez un produit agent v1 au cours du prochain trimestre et que vous n’avez pas de personne dédiée à l’infrastructure, le plan hébergé d’E2B est la voie la moins complexe. Les heures non passées à se battre avec votre cluster sandbox sont des heures consacrées à l’agent lui-même. Cela vaut 150 $/mois pour beaucoup d’équipes.

Un cadre de décision pour les équipes agent

Après deux semaines d’examen, voici le cadre que j’utiliserais réellement. C’est l’un des raccourcis de comparaison de sandboxes pour agents IA les plus utiles que j’ai trouvés :

Volume inférieur à ~50 000 heures-sandbox/mois, sans contraintes de conformité, sans équipe infrastructure → E2B hébergé. Arrêtez de lire.
Volume supérieur, ou résidence stricte des données, ou vous gérez déjà Kubernetes/microVMs → CubeSandbox auto-hébergé. L’économie s’inverse et vous avez la capacité de l’opérer.
Quelque part entre les deux → Commencez sur E2B hébergé. Construisez avec le SDK. Quand la facture commence à faire mal ou que la conformité pose des questions, la compatibilité du SDK signifie que la migration n’est qu’un changement d’URL. Cette optionnalité est la propriété la plus sous-estimée de toute cette comparaison.
Vous avez besoin du passthrough GPU pour l’inférence agent dans le sandbox → Ni l’un ni l’autre n’est idéal. Upstream Firecracker ne supporte pas nativement le passthrough GPU, et CubeSandbox hérite d’une contrainte similaire. Regardez gVisor ou Daytona pour cette charge de travail.

Le cadrage que j’éviterais : « CubeSandbox est la meilleure technologie, donc il gagne. » Le choix d’un sandbox microVM est un choix de forme produit. La technologie est approximativement équivalente en spécifications publiées. Le coût quotidien est opérationnel.

FAQ

Ce sont les questions que mes coéquipiers n’arrêtaient pas de me poser lors de l’évaluation CubeSandbox vs E2B.

CubeSandbox est-il un remplacement direct d’E2B ?

Pour la surface du SDK E2B, oui — par conception. Le projet se présente comme un runtime compatible E2B où vous changez une variable d’environnement. Pour les fonctionnalités au-delà du cycle de vie principal du sandbox (templates à partir de Dockerfiles, sandboxes desktop, observabilité hébergée), la réponse est « pas encore ».

Qu’est-ce que l’auto-hébergement ajoute réellement à la charge de travail ?

Un hôte (ou une flotte) avec KVM activé, la gestion du noyau/image, la surveillance, le réglage du pool de snapshots, la politique d’egress réseau, et l’astreinte. La release de Tencent Cloud décrit un « déploiement en un clic » pour les configurations à nœud unique et en cluster, mais traiter cela comme identique à un cluster de qualité production est optimiste. Prévoyez 1 à 2 semaines de configuration et une petite part récurrente de l’attention de quelqu’un.

Quelles charges de travail bénéficient le plus des sandboxes microVM ?

Tout ce qui implique l’exécution de code généré par un modèle contre des entrées non fiables à grande échelle. Le risque du noyau partagé des Docker simples est l’argument standard contre les conteneurs pour cela — toutes les grandes plateformes d’agents ont abandonné l’isolation à noyau partagé pour cette raison. Si votre agent n’exécute du code en sandbox qu’à partir d’une liste d’autorisation fixe de scripts de confiance, vous n’avez peut-être pas besoin d’une microVM du tout.

Que devraient tester les équipes en premier ?

Trois choses, dans cet ordre : le démarrage à froid au p99 à votre taille de template réelle ; la densité de sandboxes par dollar de matériel (pour l’auto-hébergé) ou par dollar de facture (pour l’hébergé) ; le mode de défaillance sous charge en rafale. Les chiffres annoncés — moins de 60 ms vs ~150 ms — sont réels, mais ils décrivent des moyennes dans des conditions favorables au fournisseur. Votre charge de travail ne correspondra à aucun des deux fournisseurs, ce qui est la seule raison de faire un benchmark du tout.

Conclusion

Le débat CubeSandbox vs E2B est réel mais légèrement mal cadré. Ce n’est pas « quel sandbox est techniquement supérieur ». Les deux utilisent l’isolation au niveau matériel, les deux publient des chiffres de performance crédibles, les deux sont sous Apache 2.0, les deux parlent le même SDK. La décision est : voulez-vous que quelqu’un d’autre gère l’infrastructure, ou voulez-vous la gérer vous-même.

C’est une question de produit, pas d’ingénierie. Et la réponse honnête pour la plupart des équipes est « commencez hébergé, gardez la migration peu coûteuse ». La compatibilité SDK entre les deux projets est la chose la plus utile dans toute cette release — cela signifie que la taxe de verrouillage vient de diminuer pour tout le monde dans l’infrastructure agent.

Plus à venir une fois que j’aurai soumis CubeSandbox à une vraie charge. Les deux projets évoluent rapidement — cette comparaison ne vieillira pas aussi bien que la technologie sous-jacente.

Articles précédents :