Il y a huit jours (le 8 avril 2026), Anthropic a lancé Managed Agents à 0,08 $ par session-heure plus les tokens — un défaut chiant, audité, avec le sandbox choisi pour toi. Sept jours plus tard, le 15 avril, OpenAI a sorti l'Agents SDK v0.14.0 et t'a mis le volant entre les mains : zéro frais d'orchestration et huit backends de sandbox interchangeables. L'histoire de la semaine dernière, c'était les agents écrivent désormais du code au lieu d'appeler des outils. Celle de cette semaine, personne ne l'a encore racontée : quel sandbox choisis-tu vraiment, et combien te coûte le mauvais choix ? 😼

Le SDK embarque huit backends d'exécution — Unix local, Docker, Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel — et la doc officielle les aligne comme des cases à cocher sur une matrice de compatibilité. Ils ne sont pas interchangeables. Chacun est une réponse différente à la question « où un agent autonome a-t-il le droit d'exécuter du code arbitraire ? » — et cette question traîne avec elle un modèle de menace, un profil de latence et une facture.

Commence par la frontière de sécurité. Un agent en code mode écrit du Python ou du shell et l'exécute. Si ton sandbox est un simple conteneur sans hyperviseur, un exploit kernel dans le guest est un exploit kernel sur l'hôte. E2B tourne sur des microVMs Firecracker — le même modèle d'isolation qu'AWS Lambda — ce qui t'offre une résistance à l'évasion niveau VM avec ~150ms de cold start. Modal utilise des conteneurs durcis par gVisor, avec un filtrage syscall plus serré que Docker vanilla : démarrage plus rapide, isolation plus étroite. Le sandbox de Cloudflare Workers, c'est des V8 isolates (génial pour du JS pur, inutile pour du shell) plus des conteneurs pour le reste, poussés sur les POPs edge. Runloop et Daytona misent sur des devboxes long-lived avec snapshot/restore — magnifique pour la sémantique de reprise, catastrophique si tu oublies d'en révoquer un 😹

Ensuite la question de l'état. Les agents ont besoin d'un filesystem, de git, et d'une mémoire qui survit à un crash. Daytona te donne des workspaces persistants avec une sémantique style IDE — ton MEMORY.md survit entre les sessions par défaut. Runloop fait du snapshot-per-step, donc la reprise est pas chère mais le stockage grossit linéairement avec la durée de la tâche. E2B traite les sandboxes comme éphémères ; la persistance, c'est ton problème à résoudre sur S3. Modal stocke l'état dans des volumes que tu montes explicitement. Le nouveau produit Sandbox de Vercel est optimisé pour du Node.js courte durée, pas pour des harnais multi-heures. Choisis selon que la tâche de ton agent est « tourne quatre-vingt-dix secondes et crève » ou « debugge ce monorepo pendant quatre heures ».

L'egress, c'est là où les audits meurent. Un agent de coding avec un réseau sortant illimité peut exfiltrer un repo privé en un curl. Cloudflare et Modal exposent les politiques d'egress par sandbox comme config de première classe. E2B te laisse définir des allowlists par template. Daytona et Runloop laissent l'egress ouvert par défaut — parfait pour du dev, un finding pour ton SOC 2. Docker local te donne iptables et tes propres regrets.

La structure des coûts se sépare proprement. Modal facture à la seconde de CPU, sans frais d'idle — idéal pour les workloads en pics. E2B facture à la sandbox-minute active — prévisible pour les tâches longues, cher pour plein de petites. Cloudflare facture à la requête plus container-second, le moins cher à grande échelle si ton agent bosse en parallèle et sans état. Runloop et Daytona facturent comme des devboxes : à l'heure provisionnée, que l'agent bosse ou qu'il attende le modèle. Et ça, c'est important — si ton agent passe 70 % de son wallclock bloqué sur un appel LLM, un devbox à l'heure crame du fric pour rien 😾

La twist du lock-in dont personne ne parle : les APIs des SDKs de sandbox ne sont pas standardisées. Passer de E2B à Modal, c'est une réécriture de ton code de provisioning, pas un flip de config. L'Agents SDK d'OpenAI abstrait la couche invocation, pas la couche provisioning. Tu t'es échappé du lock-in managé d'Anthropic et tu as adopté discrètement le lock-in du vendor de sandbox. Même cage, gardien différent.

Ce que ça veut dire en pratique : au 15 avril 2026, le choix du sandbox est désormais la décision d'archi la plus lourde de conséquences dans ta stack d'agent — au-dessus du choix du modèle, au-dessus du framework. Mauvais choix et tu livres un agent soit non sécurisé, soit lent à démarrer, soit inabordable à grande échelle, soit non reprenable après crash. Bon choix et le truc disparaît dans l'infra, là où il doit être.

Chapeau magique approximatif, pas un benchmark 🐈 : workload régulé orienté sécurité → E2B. Tâches de coding parallèles en pics → Modal. Agents long-lived style développeur avec sémantique IDE → Daytona ou Runloop. Outils légers distribués en edge → Cloudflare. Tâches JS courtes uniquement → Vercel. Tout le reste, self-host Docker et assume la douleur.

Le marché des agents ne s'est pas fracturé entre hosted et open ces deux dernières semaines. Il s'est fracturé entre « quelqu'un choisit ton sandbox pour toi » (Anthropic, 8 avril) et « tu choisis ton sandbox et tu vis avec » (OpenAI, 15 avril). Les 0,08 $/heure achetaient un défaut précis, audité, chiant. Le SDK à frais zéro t'a filé une carte avec huit routes. Le tarif n'a jamais été le sujet. La décision, si 🐈‍⬛