Cloudflare a publié @cloudflare/computer, un runtime pour agents qui choisit dynamiquement entre des isolats rapides et des conteneurs Linux complets, et a lancé la “Agents Week” : une série d’articles sur la façon dont l’infrastructure cloud doit évoluer quand les clients sont des agents autonomes, pas des navigateurs humains.

Pourquoi cela te concerne. Si tu déploies des agents en production, où et comment ils s’exécutent compte autant que le modèle que tu choisis. Un agent qui doit naviguer sur le web a besoin d’un navigateur dans un conteneur Linux complet. Un agent qui traite du texte rapidement s’adapte mieux à un isolat, un environnement d’exécution léger qui démarre en millisecondes. Aujourd’hui, tu gères ce choix manuellement, en construisant l’infrastructure autour. @cloudflare/computer place un runtime entre les deux : tu déclares ce dont tu as besoin et il achemine vers l’environnement approprié.

Cela s’inscrit dans une continuité que nous suivons. Comme nous l’expliquions en juillet, le protocole MCP est devenu sans état pour mieux escalader. Maintenant Cloudflare fait la même chose au niveau de l’exécution : l’environnement de runtime devient orchestrable, pas figé.

Le deuxième article de la semaine porte sur l’inférence : comment servir Kimi et GLM sur GPU sans épuiser la mémoire, avec quantification du cache KV (la mémoire où le modèle conserve le contexte de la conversation) et compression des poids. Des détails qui impactent le coût pour ceux qui exécutent des agents à grande échelle.

Si tu veux suivre. Les articles de la Agents Week et la documentation de @cloudflare/computer sont sur le blog de Cloudflare.

En détail

Cloudflare Workers existe depuis 2017 comme plateforme pour exécuter du code aux limites du réseau. Le modèle est l’isolat : un environnement d’exécution sandboxé qui démarre en millisecondes et consomme très peu de mémoire, parce qu’il ne lance pas un système d’exploitation complet. C’est parfait pour répondre à une requête HTTP, transformer un JSON, servir une page.

Les agents ont un problème différent. Un agent qui navigue sur le web a besoin d’un navigateur, et un navigateur a besoin d’un système d’exploitation. Un agent qui écrit des fichiers et les traite a besoin d’un vrai système de fichiers. Les isolats ne suffisent pas. Les conteneurs Linux complets résolvent le problème, mais ils démarrent en secondes au lieu de millisecondes et consomment plus de ressources. Jusqu’à aujourd’hui, ceux qui déployaient des agents sur Cloudflare devaient choisir l’une des deux approches et construire tout autour.

@cloudflare/computer place un runtime au milieu qui décide lui-même. L’agent déclare ce dont il a besoin (un navigateur, un système de fichiers, accès au réseau) et le runtime l’achemine vers l’environnement approprié. Si la tâche est légère, elle va en isolat. Si un navigateur est nécessaire, elle va en conteneur. La transition est transparente pour l’agent, qui voit toujours “un ordinateur” comme environnement d’exécution.

La Agents Week élargit la discussion. Cloudflare affirme que l’infrastructure cloud a été conçue pour un monde où les demandes provenaient d’humains avec des navigateurs : limitation de débit calibrée sur le trafic humain, stockage pensé pour les sessions utilisateur, sécurité basée sur les cookies et CORS. Les agents cassent ces hypothèses. Ils font des demandes à haute vitesse, maintiennent l’état pendant des heures, accèdent aux ressources d’une manière que les modèles de sécurité actuels ne couvrent pas. Un nouvel ensemble de primitives est nécessaire.

Le deuxième article de la semaine descend d’un niveau encore plus bas : comment servir des modèles frontier comme Kimi et GLM sur GPU sans épuiser la mémoire. Cloudflare applique la quantification au cache KV (où le modèle conserve le contexte de la conversation) et la compression aux poids du modèle, avec des contrôles d’intégrité pour vérifier que la compression n’a pas corrompu les résultats. Pour ceux qui exécutent des agents qui consomment beaucoup de tokens, le coût de l’inférence se décide aussi ici, pas seulement sur le prix annoncé du modèle.

Les limites de ce que nous savons. Les articles du blog décrivent l’architecture, mais les détails sur la tarification, les SLA et la disponibilité générale de @cloudflare/computer ne sont pas encore clairs à partir du matériel publié. La Agents Week est en cours : d’autres articles pourraient ajouter des informations opérationnelles dans les jours à venir. Pour ceux qui évaluent la plateforme pour des agents en production, le runtime est intéressant conceptuellement mais doit être testé sur ta charge réelle avant de prendre une décision.