Cloudflare Computer répartit l’ordinateur de l’agent entre isolates et conteneurs

Cloudflare a publié Cloudflare Computer en aperçu open source le 3 août 2026, offrant aux agents un espace de travail persistant unique réparti sur trois backends d’exécution. C’est là que réside la tension du design. Les développeurs peuvent orienter les tâches simples vers des isolates Workers légers et réserver les conteneurs Linux aux traitements plus lourds, mais le projet n’est explicitement pas prêt pour la production.

Cette distinction compte, car l’infrastructure des agents évolue vers des machines complètes et isolées. Cloudflare Computer met à l’épreuve une hypothèse différente : un agent a besoin des capacités d’un ordinateur, mais chaque action ne requiert pas le même runtime informatique. Ses fichiers peuvent persister indépendamment de l’environnement qui exécute chaque commande.

Le résultat met sous pression les fournisseurs qui considèrent un sandbox, un conteneur ou une microVM comme l’unité de base d’une session d’agent. Il pousse également le Sandbox SDK existant de Cloudflare à justifier les cas où les développeurs ont besoin d’un conteneur dédié. Cet aperçu est moins un produit finalisé qu’un argument public sur la façon dont l’informatique agentique devrait être répartie.

Cloudflare Computer sépare les fichiers de l’exécution

Le changement central est architectural : l’espace de travail d’un agent n’appartient plus à un seul conteneur en cours d’exécution.

Selon le dépôt open source du projet, Cloudflare Computer stocke son système de fichiers virtuel de référence dans un Durable Object. Un Durable Object est un composant Cloudflare avec état, doté d’un stockage privé et persistant ainsi que d’un point de coordination unique.

SQLite héberge l’état de ce système de fichiers. L’exécution a lieu ailleurs, via une interface partagée appelée workspace.runtime. L’agent peut lire et modifier les mêmes fichiers même lorsque différents backends exécutent ses commandes.

Trois backends sont proposés dans cet aperçu. Le backend de conteneur fournit un espace utilisateur Linux complet avec de vrais binaires, des gestionnaires de paquets et un accès réseau. Un backend de shell Worker exécute des commandes de type shell via just-bash dans un Dynamic Worker. Le troisième backend évalue des modules JavaScript dans de nouveaux Dynamic Workers.

Les développeurs peuvent enregistrer plusieurs backends pour un espace de travail. Chacun reçoit un identifiant stable, tandis que workspace.runtime.exec() devient le point d’entrée commun. Un appelant peut sélectionner directement un backend, ou un framework d’agent peut choisir en fonction de descriptions fournies par le développeur.

Cette organisation fait du système de fichiers le centre stable de la session. Le calcul devient interchangeable. Une commande légère peut s’exécuter dans un isolate, tandis qu’une installation de paquet ou une compilation native peut basculer vers Linux sans créer d’espace de travail logique distinct.

Cloudflare décrit le paquet comme un système de fichiers virtuel persistant, fondé sur SQLite et doté d’une exécution enfichable. Sa documentation de paquet évoque une limite d’environ 10 Go par espace de travail. Le stockage partage les limites de son Durable Object.

Le paquet fonctionne aussi sans backend d’exécution. Une application peut n’utiliser que le système de fichiers durable, puis ajouter l’exécution lorsque son flux de travail l’exige. Cela fait du modèle de stockage davantage qu’une simple fonctionnalité de support pour un sandbox.

L’API publique ressemble aux opérations familières de système de fichiers de Node.js. Elle comprend des fonctions de lecture, d’écriture, de listage, de suppression et de recherche de fichiers. Les chaînes utilisent UTF-8 par défaut, tandis que les données binaires peuvent passer par des tableaux d’octets ou des flux.

L’accès aux conteneurs nécessite une couche supplémentaire. Un daemon nommé computerd s’exécute dans le sandbox et expose l’espace de travail persistant sous la forme d’un montage FUSE. FUSE permet à un processus en espace utilisateur de présenter des fichiers via une interface de système de fichiers normale.

Le daemon synchronise les modifications avec le Durable Object de référence via un canal RPC. Cela fournit aux outils Linux un répertoire conventionnel tout en conservant SQLite hors du conteneur comme source de vérité.

Les backends d’isolate suivent un chemin plus court. Leurs opérations de système de fichiers appellent le même Durable Object via Workers RPC, ce qui leur évite de maintenir un second stockage. Ils évitent également l’étape de synchronisation requise après le travail en conteneur.

C’est ce qui fait de cette annonce plus qu’un autre service d’exécution de code. Cloudflare Computer décompose l’ordinateur familier en fichiers persistants, exécution sélectionnable, synchronisation et assistants de publication. L’agent voit toujours un seul espace de travail, même si l’infrastructure sous-jacente peut changer d’une commande à l’autre.

Pourquoi les agents ne tiennent plus dans un seul runtime

Les charges de travail des agents combinent de petites opérations sur les fichiers et des travaux occasionnels au niveau système, ce qui fait d’un environnement d’exécution fixe un choix par défaut inefficace.

Un agent de programmation accomplit rarement une tâche uniforme. Il peut examiner un fichier de configuration, rechercher dans un dépôt, modifier quelques lignes, lancer des tests, installer une dépendance, créer une image et publier un artefact. Ces actions ont des exigences d’exécution différentes.

Lire un fichier ne nécessite pas un conteneur Linux complet. Il en va de même pour l’analyse de texte ou l’évaluation d’un module JavaScript contrôlé. La compilation native, l’installation de paquets et les outils du système d’exploitation l’exigent généralement.

Les sandboxes distants traditionnels regroupent ces besoins. Le sandbox fournit un système de fichiers, un shell, des processus et un accès réseau au sein d’un même environnement. Ce modèle est facile à comprendre, mais il lie la persistance et l’exécution au même cycle de vie.

Le précédent Sandbox SDK de Cloudflare suit en grande partie ce modèle. L’entreprise a rendu Sandboxes généralement disponible le 13 avril 2026, après les avoir présentés pour la première fois neuf mois plus tôt comme des environnements de commandes et de système de fichiers.

Lors de sa disponibilité générale, chaque Sandbox était devenu un environnement de développement avec un terminal, des processus en arrière-plan, la surveillance de fichiers, des URL d’aperçu en direct, des contrôles de sortie réseau et des snapshots. Cloudflare a déclaré que les comptes standard pouvaient exécuter 15 000 instances lite simultanées, 6 000 instances basic et plus de 1 000 instances plus grandes.

L’entreprise a également fait évoluer Sandboxes vers une facturation sur le CPU actif, afin que les attentes inactives ne consomment pas de temps CPU facturé. Ce changement répondait à l’un des coûts des sessions d’agent de longue durée. Il n’effaçait pas la différence architecturale entre démarrer un conteneur et exécuter du code dans un isolate léger.

Cloudflare Computer transforme cette différence en décision de routage. Les backends se connectent de manière différée, ce qui signifie qu’ils s’initialisent lorsque le travail les atteint pour la première fois. Un flux de travail peut commencer avec des fichiers et un isolate, puis recourir à Linux uniquement lorsqu’une commande en a réellement besoin.

La stratégie reflète la position plus large de Cloudflare selon laquelle les charges de travail des agents requièrent plusieurs échelles de calcul. Son récapitulatif de l’Agents Week soutenait que certains agents ont besoin de systèmes d’exploitation complets, tandis que la plupart des tâches nécessitent des environnements plus légers qui démarrent en quelques millisecondes.

Cloudflare Computer donne à cette affirmation un modèle de programmation concret. Il ne demande pas aux développeurs de déplacer manuellement des fichiers entre des services sans lien. L’espace de travail assure la continuité tandis que la frontière d’exécution change.

Pour les auteurs de frameworks, cette continuité est importante. Un agent peut recevoir des outils standard nommés read, write, edit, ls et exec. Le paquet propose des adaptateurs pour les applications AI SDK, tandis que le développeur décrit ce que chaque backend peut prendre en charge.

Un modèle peut alors envoyer les opérations textuelles rapides vers un isolate et les commandes plus lourdes vers un conteneur. Cela fait de la sélection du backend une partie de la politique d’outils de l’agent. Cela crée également un nouveau mode d’échec si ces descriptions sont imprécises ou si le modèle choisit mal.

Le design est particulièrement pertinent pour les agents qui s’interrompent souvent. L’inférence de modèle, l’approbation humaine, les requêtes réseau et les appels d’API externes créent des périodes d’inactivité. Maintenir un environnement complet actif pendant chacune de ces périodes peut être pratique, mais ce n’est pas la seule manière de préserver le travail de l’agent.

Un système de fichiers durable permet à la couche d’exécution de disparaître sans effacer l’état de la session. L’action suivante peut rouvrir les mêmes fichiers via un autre backend. Cela ressemble à un ordinateur du point de vue de l’agent, même si aucune machine unique ne possède l’intégralité de la session.

Cette abstraction met sous pression les fournisseurs privilégiant les conteneurs, mais elle n’élimine pas leur argument le plus solide. Un environnement complet et isolé offre des outils prévisibles, un débogage familier et une frontière de sécurité cohérente. Répartir une session entre plusieurs runtimes ajoute des préoccupations de coordination et de synchronisation.

Elle met également sous pression les frontières produits de Cloudflare. Les développeurs doivent comprendre s’ils ont besoin de Sandbox SDK, Cloudflare Computer, Dynamic Workers ou d’une combinaison. Un paquet en aperçu peut explorer les recouvrements, mais une plateforme de production doit à terme offrir une réponse simple.

La réponse probable dépend de la charge de travail. Cloudflare Computer favorise les agents qui effectuent de nombreuses petites opérations et ont occasionnellement besoin de Linux. Un conteneur reste plus clair lorsque presque chaque étape dépend d’outils natifs, de dépendances locales importantes ou d’un accès disque à haut débit.

C’est la véritable question des enjeux. Cet aperçu demande si l’unité que les développeurs devraient provisionner est une machine, ou un espace de travail capable d’emprunter différentes machines.

Comment Cloudflare Computer répartit un espace de travail sur trois backends

Cloudflare Computer gagne en flexibilité en rendant explicite la sélection du runtime, mais chaque backend présente un profil différent de capacités et de synchronisation.

Le backend de shell Worker est le chemin le plus léger pour les commandes familières. Il utilise just-bash, une implémentation TypeScript d’un environnement de type Bash conçue pour fonctionner sans lancer de processus du système d’exploitation.

Ce backend peut gérer du travail shell orienté texte sur l’espace de travail durable. Il n’a besoin ni de Docker ni d’un Cloudflare Container. Les opérations sur les fichiers reviennent vers le Durable Object, conservant l’état de référence en un seul endroit.

Le backend JavaScript Worker traite des modules ECMAScript plutôt que des commandes shell. Chaque exécution s’effectue dans un nouveau Dynamic Worker et peut accepter une entrée structurée ou renvoyer des résultats structurés. Il prend en charge l’accès aux fichiers lié à l’espace de travail et les bibliothèques configurées.

Cloudflare fournit également des modules de confiance pour Git et Cloudflare Artifacts. Les opérations Git peuvent s’exécuter via un client isomorphic-git directement sur le système de fichiers virtuel. Elles ne nécessitent ni conteneur ni binaire Git conventionnel.

Le backend de conteneur couvre les tâches que les isolates ne peuvent pas réaliser. Il fournit Linux, des binaires natifs, Node.js, npm, le réseau et d’autres capacités du système d’exploitation. L’espace de travail y apparaît via le montage FUSE de computerd.

Ce backend crée le problème de données le plus difficile. Cloudflare doit projeter l’état fondé sur SQLite dans un conteneur, permettre à des outils conventionnels de le modifier, puis synchroniser ces modifications ensuite. Le paquet maintient des curseurs de synchronisation indépendants pour chaque backend enregistré.

Si une commande réussit mais que la récupération post-commande échoue, le résultat d’exécution peut signaler un état de synchronisation en attente. Les applications peuvent configurer des tentatives avec un backoff exponentiel plafonné. Cependant, la bibliothèque ne prend pas en charge la planification des alarmes du Durable Object.

Ce détail révèle l’ampleur de la responsabilité qui incombe encore au développeur. L’utilisateur voit un seul espace de travail, mais l’application doit gérer l’enregistrement des backends, la planification des tentatives, le cycle de vie de l’exécution et les synchronisations non résolues.

Le design requiert également une discipline rigoureuse en matière de libération des ressources. La couche RPC ne collecte pas automatiquement les stubs distants. Les sessions de longue durée qui acquièrent à répétition des handles d’espace de travail ou d’exécution peuvent les accumuler, à moins que l’application ne libère chaque handle.

Cloudflare documente la prise en charge du débogage pour détecter ces fuites. Cela reste toutefois une infrastructure en phase de préversion, et non un service de plateforme invisible. Les développeurs qui l’expérimentent doivent comprendre les mécanismes sous-jacents.

La publication de fichiers introduit une autre frontière. Le package peut téléverser un fichier de l’espace de travail vers R2 et renvoyer un lien présigné. Il peut également connecter une session à Cloudflare Artifacts, un service de stockage compatible Git pour le code et les sorties de build.

Un tutoriel inclus illustre la séparation recherchée. Un agent écrit une fiche recette en Markdown dans son espace de travail, puis utilise pandoc dans un conteneur pour créer un PDF. Le stockage reste durable, tandis qu’un outil Linux assure la conversion de format.

Un autre exemple envoie la génération d’images à Workers AI, écrit le résultat dans l’espace de travail et renvoie une ressource partageable. Une interface de comparaison exécute la même tâche côte à côte via les runtimes de conteneur et de Worker.

Ces exemples renvoient à un modèle d’agent plus large. L’espace de travail devient un établi partagé, tandis que les différents runtimes agissent comme des outils spécialisés. L’agent n’a pas besoin de traiter chaque backend comme un ordinateur distinct.

Le mécanisme peut aussi prendre en charge le développement à forte intensité de connaissances. Une équipe d’ingénierie pourrait conserver les fichiers de tâche, les rapports générés et les sorties de test dans l’espace de travail, puis copier les résultats durables dans une base de connaissances interrogeable. Le runtime reste temporaire, tandis que le travail utile devient accessible au-delà de la session de l’agent.

L’abstraction a néanmoins ses limites. Le système de fichiers côté conteneur est conservé en mémoire, et Cloudflare recommande des espaces de travail dimensionnés pour les agents plutôt que des monorepos complets. Un plafond d’environ 10 Go est conséquent pour les documents et les petits projets, mais ne fait pas du service un remplacement général des disques de développement.

Les backends Worker exigent aussi des fonctionnalités expérimentales de Cloudflare et une liaison Worker Loader. Le package lui-même requiert l’indicateur de compatibilité nodejs_compat. Ces exigences confirment son statut de préversion.

Le point le plus important de cette analyse de Cloudflare Computer expliquée n’est pas que les isolates remplacent les conteneurs. Ce n’est pas le cas. Le mécanisme permet à une application de décider quand un conteneur justifie ses coûts de démarrage, de capacités et de synchronisation.

Ce choix peut s’opérer au niveau de l’application ou via un framework d’agents. Le modèle voit les descriptions des backends et peut choisir une destination. Les développeurs ont donc besoin de contrôles de politique, et pas seulement d’indications en langage naturel.

Un système de production limiterait vraisemblablement les commandes, fichiers, réseaux et identifiants auxquels chaque backend peut accéder. Il devrait aussi fournir des enregistrements fiables indiquant pourquoi une commande a atteint un runtime particulier. Le dépôt actuel expose des hooks d’observabilité, mais ne résout pas l’ensemble du problème de gouvernance.

Cloudflare Computer est le plus convaincant lorsque le travail se divise naturellement. Rechercher et modifier dans un isolate, compiler sous Linux, puis publier via un service d’artefacts. Son avantage devient moins clair lorsque chaque action nécessite le conteneur ou lorsqu’une tâche déplace à plusieurs reprises de gros fichiers.

Les avertissements de préversion et les benchmarks compliquent l’argumentaire

Le dépôt fournit des limites inhabituellement directes, notamment un avertissement explicite sur la production et des benchmarks montrant une pénalité importante pour les opérations séquentielles sur de gros fichiers.

Cloudflare indique que le package convient aux expérimentations, à l’exploration et aux prototypes. L’entreprise précise que les API sont instables, que la conception peut évoluer et que le package ne convient pas à un usage en production.

Cet avertissement doit encadrer toute affirmation sur ce qu’est Cloudflare Computer aujourd’hui. Le dépôt contient des packages fonctionnels, des exemples et des centaines de commits, mais certaines parties de sa documentation de conception sont prospectives. Cloudflare demande aux lecteurs de traiter ces spécifications comme une intention plutôt que comme une description du code actuel.

Les performances constituent le compromis le plus clair. L’entreprise a évalué computerd sur un conteneur standard doté d’un processeur virtuel, de 6 Gio de mémoire et de 12 Go de disque. Elle a comparé l’espace de travail FUSE avec un système de fichiers en mémoire et le disque ext4 du conteneur.

Les résultats favorisent le système de fichiers virtuel pour plusieurs opérations à forte charge de métadonnées. La suppression de 1 000 fichiers a pris environ les deux tiers du temps requis par ext4. La création d’une arborescence de répertoires imbriqués a pris environ les trois quarts du temps. La recherche de cette arborescence a également pris environ les trois quarts du temps.

Une initialisation Git suivie d’un commit portant sur 100 fichiers a pris 459,2 millisecondes avec computerd, contre 635,4 millisecondes avec ext4. Un clone superficiel d’un dépôt d’environ 1 Mo a pris 549,1 millisecondes, contre 576,2 millisecondes sur disque.

Les opérations séquentielles de grande taille ont produit le résultat inverse. L’écriture d’un fichier de 64 Mio a pris 230,6 millisecondes avec computerd, contre 16,8 millisecondes avec ext4. La copie de la même quantité a pris 1 037,2 millisecondes, contre 39,8 millisecondes.

Une lecture pure de 64 Mio était environ 30 fois plus lente que la référence sur disque. Une copie pure était plus de 41 fois plus lente. Ces écarts comptent pour les archives, les arborescences de dépendances, les médias, les fichiers de modèles et les charges de traitement de données.

Les benchmarks du système de fichiers de Cloudflare expliquent le mécanisme à l’origine du ralentissement. Le chemin d’écriture hache des blocs de 512 Kio dans un magasin de blobs adressé par le contenu. Cela prend en charge la déduplication et la synchronisation des seuls blocs modifiés, mais ajoute du travail aux opérations de débit brut.

Une installation complète du Sandbox SDK de Cloudflare a rendu ce coût plus concret. Le test portait sur 854 packages et 36 675 fichiers. L’installation a pris 124,7 secondes sur l’espace de travail FUSE, 63,9 secondes sur ext4 et 34,3 secondes en mémoire.

Cloudflare présente ext4 comme la référence plus réaliste pour un usage général. Par rapport à cette référence, l’installation FUSE a pris environ deux fois plus de temps. Les développeurs construisant des projets JavaScript à forte dépendance le remarqueront.

Les benchmarks n’invalident pas la conception. De nombreuses tâches d’agents impliquent des métadonnées, de petites modifications, des recherches et des changements incrémentaux plutôt que des E/S séquentielles soutenues. Les résultats définissent plutôt les cas où le routage entre backends importe.

Un flux de travail raisonnable pourrait conserver les fichiers sources dans l’espace de travail persistant tout en évitant l’extraction répétée de grosses archives. Il pourrait mettre les dépendances en cache ailleurs ou privilégier des tâches dont la valeur justifie les frais de synchronisation. Cloudflare n’a pas encore établi les meilleures pratiques de production.

La sécurité présente une deuxième incertitude. Le dépôt décrit les surfaces d’exécution et le comportement du stockage, mais ne prétend pas que les trois backends fournissent une isolation identique. Un isolate JavaScript, un shell implémenté en TypeScript et un conteneur Linux sont des environnements d’exécution fondamentalement différents.

Le shell Worker gagne en rapidité notamment parce qu’il ne constitue pas un système d’exploitation complet. Cela limite sa compatibilité, mais peut aussi restreindre ce que les commandes peuvent faire. Le conteneur offre des capacités plus larges et exige donc des contrôles plus stricts autour de l’accès réseau, des packages et des identifiants.

Le passage d’un environnement à l’autre peut créer des lacunes de politique. Une commande rejetée dans un backend peut s’exécuter dans un autre. Un agent peut choisir Linux parce que sa description promet davantage de capacités, même lorsque la tâche ne l’exige pas.

Le package comprend des hooks d’observation pour la connexion à l’espace de travail, la synchronisation, l’exécution et les opérations sur le système de fichiers. Ces hooks peuvent alimenter le traçage Cloudflare ou un autre enregistreur. Ils constituent des fondations utiles, mais les utilisateurs en production auront besoin de règles d’autorisation et d’une politique de sélection des backends vérifiable.

La persistance soulève ses propres questions de sécurité. Les fichiers survivent aux redémarrages de Durable Objects, ce dont les agents ont besoin pour les tâches longues. Les espaces de travail persistants peuvent également conserver plus longtemps que prévu des prompts sensibles, du code source, des identifiants générés ou des données téléchargées.

Les applications ont besoin de politiques de suppression et d’une séparation des locataires adaptées à leur niveau de risque. Les montages R2 en lecture seule contribuent à protéger les données de référence, mais ne répondent pas à toutes les questions de conservation des données ou d’accès sortant.

La réponse sur GitHub fournit un signal d’adoption, et non une preuve de maturité pour la production. Le dépôt affichait environ 3 100 étoiles et 141 forks le 6 août. Ces chiffres témoignent de la curiosité des développeurs après l’annonce, notamment compte tenu de sa position dans GitHub Trending.

Ils n’établissent ni la fiabilité, ni la sécurité, ni une utilisation durable. Les étoiles peuvent s’accumuler rapidement autour d’une architecture convaincante. La véritable validation viendra de charges de travail exécutées pendant des semaines, capables de récupérer après des défaillances partielles et de préserver les fichiers de façon cohérente malgré les changements de runtime.

La transparence de Cloudflare aide sur ce point. La publication de chiffres d’E/S défavorables donne aux développeurs une meilleure base pour leurs expérimentations. L’avertissement explicite empêche également de confondre le rang dans les tendances avec un lancement en disponibilité générale.

La conclusion prudente est simple. Cloudflare Computer offre un mécanisme crédible pour séparer l’état des agents de l’exécution, mais la préversion n’a pas démontré que cette coordination supplémentaire surpasse un sandbox dédié en production.

Ce que les développeurs devraient surveiller après l’essor sur GitHub

La prochaine phase dépend de trois signaux : la stabilisation des API, des preuves issues de charges de travail réelles et des politiques applicables de sélection des backends.

Le premier signal serait une version stable et orientée production. Cloudflare Computer présente actuellement des API instables et des exigences expérimentales pour les backends. Une évolution vers une interface stable montrerait que Cloudflare a résolu les frontières de responsabilité entre Computer, Sandbox SDK, Dynamic Workers et Durable Objects.

Cette version devrait clarifier le comportement de reprise. Les développeurs ont besoin de résultats prévisibles lorsqu’une commande de conteneur se termine mais que la synchronisation échoue. Ils ont également besoin de garanties concernant les accès concurrents, le nettoyage, les limites de stockage et les sessions RPC de longue durée.

Si Cloudflare publie une version stable accompagnée de conseils de migration, l’argument architectural gagnera en force. Si les API évoluent sans cesse ou si le package reste une expérimentation, les équipes continueront de considérer le dépôt comme une recherche de conception.

Le deuxième signal sera constitué de preuves issues de charges de travail complètes d’agents. Les microbenchmarks montrent déjà où FUSE fonctionne bien et où il peine. La question plus difficile est de savoir si le routage des commandes entre isolates et conteneurs améliore le temps total des tâches, la fiabilité ou l’utilisation des ressources.

Des évaluations utiles compareraient des agents de programmation, de recherche et d’analyse de données identiques. Elles devraient mesurer le délai de démarrage, la durée d’exécution, les échecs de synchronisation, le volume de stockage transféré et la réussite des tâches. Un benchmark brut du système de fichiers ne peut pas capturer ces effets combinés.

Les exemples du dépôt constituent un début, en particulier l’interface qui compare les runtimes sur une même tâche. Des tests indépendants devraient ajouter des dépôts plus volumineux, des installations répétées de packages, des agents parallèles et des sessions reprenant après des interruptions.

Si les flux de travail à runtimes mixtes se terminent de manière fiable tout en sollicitant moins de conteneurs, le mécanisme de Cloudflare gagnera en crédibilité. Si la synchronisation et le routage effacent ces économies, un sandbox persistant restera le choix le plus simple.

Le troisième signal est la politique de backend. Aujourd’hui, une application peut décrire les backends disponibles et laisser un agent en sélectionner un. Les acheteurs en production voudront des contrôles déterministes régissant le backend qui peut accéder à chaque fichier, réseau, secret et commande.

Cloudflare dispose déjà d’infrastructures connexes. Sa plateforme Sandbox inclut des contrôles sortants programmables, tandis que Durable Objects fournit un état privé et persistant. Cloudflare Computer doit réunir ces éléments dans un modèle de politique que les développeurs peuvent comprendre et raisonner.

Une implémentation mature devrait rendre l’escalade visible. Lorsqu’un agent passe d’un shell Worker à Linux, l’application devrait savoir pourquoi, quelles nouvelles capacités sont devenues disponibles et quelles données ont franchi la frontière.

Cette question dépasse Cloudflare. LangChain, Daytona, Ona, Modal et d’autres plateformes développent des environnements pour agents associant, selon les cas, microVM, conteneurs, persistance et outils de développement. Leur concurrence porte sur la définition même d’un ordinateur pour agent, et pas uniquement sur la vitesse d’exécution.

Certains fournisseurs estiment que le code d’agent non fiable exige une isolation au niveau matériel et une frontière de machine complète. Cloudflare Computer privilégie plutôt la décomposition : un espace de travail peut utiliser une exécution plus légère jusqu’à ce qu’il ait besoin de Linux. Ces approches peuvent coexister, car les besoins d’isolation varient selon les tâches.

Les agents de programmation destinés aux entreprises pourraient continuer à privilégier des environnements dédiés, avec des chaînes d’outils reproductibles et des frontières strictes entre locataires. Les agents traitant un volume élevé de documents pourraient davantage bénéficier de fichiers durables et de commandes légères. Les agents de données traitant de grandes entrées pourraient révéler les limites de débit de la conception FUSE.

Les développeurs devraient donc tester leur combinaison de tâches avant d’adopter ce concept. Comptez le nombre d’étapes qui nécessitent réellement des binaires natifs. Mesurez la quantité de données transitant par l’espace de travail. Provoquez volontairement des échecs de synchronisation et vérifiez la récupération.

Ils devraient également distinguer une expérience d’agent séduisante d’une conception de sécurité adéquate. « Un espace de travail » constitue une interface utile, mais cela ne signifie pas que chaque chemin d’exécution possède la même frontière de confiance. L’escalade d’environnement d’exécution mérite le même examen que l’escalade des autorisations.

Cloudflare Computer est important parce qu’il rend ce choix de conception explicite. Il invite les développeurs à considérer les fichiers comme un état durable, l’exécution comme un service sélectionnable et l’ordinateur apparent comme une abstraction assemblée pour chaque tâche.

Cette approche influencera l’infrastructure des agents même si cette préversion évolue sensiblement. Elle offre une alternative au maintien en vie d’un conteneur ou d’une microVM simplement parce que l’agent aura besoin de ses fichiers plus tard.

La hausse sur GitHub confirme l’intérêt suscité par l’idée. Elle ne tranche pas la question de savoir si les développeurs préfèrent la simplicité opérationnelle d’une seule machine ou l’efficacité promise par plusieurs environnements d’exécution partageant un même espace de travail.

Au cours des prochains mois, surveillez le dépôt plutôt que le nombre d’étoiles. Des API stables, des benchmarks de bout en bout et des politiques backend strictes détermineront si Cloudflare Computer devient une infrastructure de production ou reste une préversion convaincante.

Les équipes qui évaluent la préversion de cloudflare computer devraient commencer par une charge de travail circonscrite, documenter chaque transition d’environnement d’exécution et tester la récupération avant de faire confiance à l’état persistant. Quelles opérations ont réellement besoin de Linux, et lesquelles nécessitent seulement des fichiers et une petite surface d’exécution ? Répondre à cette question à l’aide de traces et de tests de défaillance permettra de déterminer si le modèle hybride convient à vos agents. Cela mettra aussi en évidence les cas où un sandbox conventionnel reste plus facile à sécuriser et à exploiter. La leçon plus large est déjà utile : l’ordinateur d’un agent n’a pas besoin d’être une seule machine fonctionnant en permanence. Toutefois, le diviser en services transfère la complexité vers le routage, la synchronisation et les politiques. Considérez ces mécanismes comme une infrastructure essentielle, et non comme de simples détails d’implémentation.