Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
votre produit agent lance un sandbox par session. Sur E2B, Modal, Daytona, Runpod ou Replicate, c'est facturé à la seconde — et la ligne infra IA finit par dépasser la ligne LLM dans votre P&L. Sur Hoody, chaque session est un conteneur sur le serveur que vous payez déjà. Le 50 000ᵉ sandbox du mois coûte autant que le premier : zéro marginal.
même charge · économie différente · le compteur s'arrête, point
Le modèle mental de l'agent ne change pas. Lance un sandbox, exécute du code dedans, jette-le. Ce qui change, c'est la facture en dessous. Sur E2B, chaque seconde de chaque sandbox est comptée ; sur Hoody, vous faites un POST d'un conteneur contre le serveur que vous louez déjà — et le compteur ne démarre jamais.
Les deux côtés font le même boulot. La forme de l'API est identique — lance, exécute, jette. C'est la ligne de prix qui bascule : de la seconde par sandbox au tarif fixe par serveur. Les conteneurs inactifs ne coûtent rien sur Hoody parce qu'ils partagent le métal que vous avez déjà payé.
Le code agent change à peine. Trois étapes et la ligne facturée de votre P&L devient plate. Le plus coûteux dans la migration, c'est de retirer le SDK qui vous facturait.
Là où vous appeliez le SDK E2B, vous faites un POST sur /api/v1/projects/$PID/containers avec un server_id. La réponse te rend un id de conteneur de 24 caractères et un hostname routable. Le conteneur démarre depuis votre snapshot en quelques secondes — même forme d'objet qu'un handle de sandbox.
Chaque conteneur embarque Hoody Exec — isolats V8, routage par fichier, magic comments pour cors, timeout et concurrence. Dépose votre script runner dans scripts/1/, fais un POST avec une payload, récupère du JSON. Pas de webserver à câbler, pas d'Express, pas de config Lambda.
Session terminée ? DELETE /api/v1/containers/[id] et il disparaît. Pas envie de vous en occuper ? Les conteneurs inactifs sur Hoody partagent le métal — ils restent à coût marginal zéro jusqu'à ce que vous les DELETE ou que vous en lances assez pour saturer le serveur. Pas de cron de cleanup, pas de facture orpheline.
Quand le compteur s'arrête, trois choses deviennent gratuites qui coûtaient cher — et votre produit agent commence à se comporter comme l'architecture que vous rêviez de vous offrir.
Sur des compteurs à la seconde, une semaine virale est une taxe. Sur du métal au tarif fixe, votre compte de lancements se détache de votre facture — il est borné par la capacité de la machine, pas par votre invoice. vous pouvez laisser vos utilisateurs marteler l'agent sans broncher.
Les sandbox à la seconde doivent mourir vite — chaque minute inactive est de l'argent. Sur Hoody, l'inactif est gratuit ; un utilisateur en pause peut revenir demain et son conteneur est toujours là avec son state. La fidélisation devient gratuite.
Chaque conteneur est son propre OS réel — namespaces kernel, filesystem complet, sa propre URL. SSH dedans si vous voulez. Montez /ramdisk. Installez le paquet apt dont l'agent a besoin. Même isolation que le bare-metal, sans la taxe à la seconde.
Chiffres tirés de la Conteneurs API et des quotas serveur Hoody — pas inventés. Le slab bare-metal fait le gros du boulot ; l'API distribue juste les slots.
Il n'y a pas de compteur sandbox-secondes. Les conteneurs ne sont pas facturés à la seconde ; le serveur est facturé au tarif fixe. Chaque lancement, chaque retry, chaque minute d'inactivité est à coût marginal zéro par-dessus la machine que vous louez déjà.
KSM (Kernel Samepage Merging) et le copy-on-write BTRFS permettent à un serveur d'empiler des centaines de conteneurs — le second conteneur ne coûte que ce qui diffère du premier. La densité dépend de la charge, mais des sessions agent légères s'empilent serré.
La tarification serveur Hoody démarre à $1/mo sur le marketplace et scale par specs et par région, pas par nombre de tenants. La facture cesse d'être une fonction du nombre d'agents que vous lancez.
La densité de conteneurs dépend de la charge — les sandbox légers s'empilent par centaines, les agents GPU demandent plus de marge. Le pricing serveur est dicté par le marketplace et varie selon la région, le CPU, la RAM et le disque. L'unité de facturation est le serveur — il n'y a aucun frais par lancement.
vos agents arrêtent de louer du compute à la seconde et utilisent du compute déjà payé.
La stack sandbox-as-a-service par défaut vous facture à la seconde par sandbox. Même boulot, autre facture. Concrètement, ça déplace :
Arrêtez de louer du compute à la seconde. Utilisez le compute que vous avez déjà payé.