Exécutez des agents cloud sur des machines que vous gérez
Les agents cloud de Cursor peuvent s’exécuter sur des pools de machines planifiés dynamiquement au sein de votre réseau. Vous gérez l’infrastructure sous-jacente, tandis que les agents restent démarrés et pilotés depuis Cursor.
Les équipes gardent ainsi la main sur le lieu d’exécution des agents et sur l’infrastructure qu’ils utilisent. Les agents peuvent travailler au plus près de vos services internes et de votre gestion de versions, s’exécuter sur du matériel spécifique, ou utiliser des systèmes d’exploitation et des pipelines de build difficiles à empaqueter dans un build d’Agent Cloud.
Les agents cloud sont aujourd’hui à l’origine de plus de 60 % des pull requests que nous fusionnons en interne, et ils prennent en charge une part croissante du travail logiciel chez bon nombre des plus grandes entreprises avec lesquelles nous collaborons. À mesure que leur rôle s’étend, les machines sur lesquelles ils s’exécutent comptent elles aussi davantage. Ces nouvelles capacités permettent concrètement aux équipes de fournir et de gérer cette infrastructure à grande échelle.
Avec les MicroVM Lambda comme couche de calcul des Agents Cloud de Cursor, les développeurs peuvent exécuter des agents de codage alimentés par l’IA dans leur propre compte AWS. Chaque machine démarre quasi instantanément à partir d’un instantané, se met en veille lorsqu’elle est inactive et reprend avec l’intégralité de son état. Vos agents de codage profitent du démarrage rapide de Lambda, d’une isolation forte et d’une absence totale de gestion de fleet, pendant que Cursor orchestre le travail.
Contrôler où les agents s’exécutent
Les environnements hébergés par Cursor restent l’option par défaut pour les agents cloud. Chaque session s’exécute sur une VM dédiée dans le cloud Cursor, avec ses dépendances installées et ses propres contrôles réseau. L’isolation par agent, le masquage des secrets, le contrôle du trafic sortant et les commits signés répondent aux exigences de sécurité de la plupart des équipes.
Les équipes utilisent généralement les Self-Hosted Machines lorsque :
- L’exécution des outils de l’agent doit se faire à l’intérieur de leur réseau, avec un accès direct à la gestion de versions, aux services internes et aux dépôts de code.
- Les agents nécessitent du matériel spécifique, comme des GPU ou des Mac pour le développement iOS, ou une infrastructure telle que Kubernetes, des sandbox ou des VM managées.
- Leur système d’exploitation ou leur pipeline de build est difficile à empaqueter sous forme de build d’Agent Cloud.
Avec les Self-Hosted Machines, seul l’environnement d’exécution change de place : la boucle de l’agent, l’inférence et la planification restent dans le cloud Cursor. Les sorties des outils sont renvoyées à Cursor pour l’inférence et peuvent contenir du code, et les transcripts d’agent peuvent être traités et stockés par Cursor. Les équipes continuent d’accéder aux agents cloud depuis l’application desktop, cursor.com, le mobile, Slack, GitHub et Linear.
Les workers relient votre infrastructure à la boucle de l’agent Cursor
Avec les Self-Hosted Machines, l’exécution des outils passe d’une VM hébergée par Cursor à une machine de votre environnement. C’est cette machine qui détient la copie de travail du dépôt, modifie les fichiers et exécute les commandes. Un worker la relie au reste du système d’agents.
Pour enregistrer une machine, lancez un worker en installant le CLI de Cursor puis en exécutant agent worker start. Cela ouvre une connexion HTTPS sortante de longue durée vers le cloud Cursor. Au démarrage d’une session, l’infrastructure d’agents de Cursor gère l’inférence et la planification, puis envoie les appels d’outils à un worker dédié pour exécution. Le worker en renvoie les résultats pour le cycle d’inférence suivant. Cursor n’initie jamais de connexion vers votre réseau.
Les workers peuvent être configurés de deux manières.
- My Machines. Cette configuration connecte un seul ordinateur portable ou une seule VM à votre compte : elle convient surtout aux workflows personnels.
- Pools. Un pool est une file d’attente nommée de workers pouvant servir une équipe ou une entreprise. La capacité augmente à mesure que les requêtes arrivent et diminue lorsque des workers se déconnectent, ce qui permet à votre infrastructure cloud existante de passer à l’échelle selon la demande des développeurs.
Les développeurs doivent avoir la liberté d’exécuter des agents de codage sur la plateforme qui convient le mieux à leur workflow, et les entreprises ne devraient pas avoir à faire de compromis sur le contrôle du lieu d’exécution des agents ni de ce à quoi ils accèdent. L’avenir du développement reposera sur des agents puissants, exécutés dans des environnements sécurisés et isolés.
Les agents cloud s'adaptent à votre infrastructure
Les pools de workers peuvent désormais passer à l'échelle en fonction des requêtes en file d'attente et traiter des tâches provenant de n'importe quel dépôt. Nous avons également ajouté le support de plusieurs fournisseurs de sandbox ainsi que du computer use sur Linux, en plus de Mac.
Les pools passent à l'échelle selon la demande et desservent n'importe quel dépôt
La demande d'agents cloud arrive souvent par à-coups, et les pools de Self-Hosted Machines s'y adaptent automatiquement. Cela passe par un controller qui surveille la file d'attente des requêtes et utilise un script de spawn fourni par l'équipe pour démarrer des machines selon les besoins.
Si un pool dispose d'un worker libre, celui-ci prend en charge la requête. Sinon, la requête attend qu'une capacité supplémentaire se libère : les équipes n'ont donc pas à décider combien de machines laisser en fonctionnement.
Les équipes peuvent définir un timeout d'inactivité pour chaque connexion de worker. Une fois celui-ci expiré, la machine peut être réinitialisée et réintégrer le pool. Les équipes peuvent aussi conserver son workspace au cas où l'agent recevrait un suivi.
Self-Hosted Machines donne aux équipes la maîtrise de l'endroit où s'exécutent les agents Cursor, et Vercel Sandbox rend la chose totalement transparente. Chaque tâche obtient un sandbox isolé à la demande, aucune fleet à gérer et rien qui tourne inutilement.
Laisser une machine en fonctionnement alors que son agent est inactif peut coûter cher. Mais si la machine est libérée, l'agent peut avoir besoin de plusieurs minutes pour reconstruire son workspace à l'arrivée d'un suivi. Avec l'hibernation, les équipes peuvent à la place prendre un instantané d'une machine inactive puis l'arrêter. Si un suivi arrive dans la fenêtre de reconnexion, l'instantané est restauré et un worker démarre avec le même ID. Sinon, la requête peut être transférée vers une nouvelle machine.
Les pools ne sont pas liés à des dépôts individuels. Une requête n'a qu'à identifier le pool, et n'importe quel worker disponible peut la prendre en charge. Un même pool peut ainsi desservir de nombreux dépôts.
Les workers s'exécutent sur les fournisseurs de sandbox pris en charge
Self-Hosted Machines ne nécessite pas de créer une couche de sandbox personnalisée de toutes pièces. Nous sommes partenaires d'AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace et Vercel, ce qui permet de démarrer et d'orchestrer les workers là où les sandbox de votre équipe s'exécutent déjà.
Cursor Self-Hosted Machines sur Modal attribue à chaque session d'Agent Cloud un Modal Sandbox : vous pouvez ainsi lui confier une machine taillée sur mesure pour sa tâche.
Les agents contrôlent les navigateurs sur Linux et Mac
Les workers Linux prennent désormais en charge le computer use, au même titre que les Mac. Une fois les dépendances computer use requises installées, dont Chrome ou Chromium, un agent peut cliquer, prendre des captures d'écran et contrôler le navigateur. Vous pouvez observer son bureau ou en prendre le contrôle directement depuis Cursor.
Impossible de créer des applications iOS ou macOS sans Mac. Les Devboxes de Namespace lancent un véritable Mac pour chaque Cloud Agent de Cursor, qui peut désormais effectuer ce travail sur Apple silicon.
Intégrez les agents cloud à votre environnement
Les équipes ont passé des années à façonner leur infrastructure en fonction de leur manière de créer des logiciels. Les Self-Hosted Machines permettent aux agents cloud de s'y intégrer plus naturellement, et nous avons hâte de voir jusqu'où les équipes iront avec elles.
Pour connecter une machine ou configurer un pool, lancez-vous avec la documentation.
