Un agent hébergé tourne dans le cloud d'un fournisseur. Vous lui donnez une copie de vos dépôts et un jeu d'identifiants, et il travaille à partir de là. Un agent local-first s'exécute sur votre propre machine, avec le runtime, l'abonnement, les fichiers et les clés déjà présents, et seule la conversation en sort.
Les deux approches sont légitimes. Elles placent votre code, votre identité et votre facture à des endroits différents, et ces différences deviennent d'autant plus importantes dès que vous commencez à partager l'agent avec d'autres personnes.
Ce que l'hébergé réussit, et ce que cela coûte
En 2026, les exemples concrets sont Claude Code sur le web et les tâches cloud de Codex par OpenAI. Tous deux exécutent l'agent dans le bac à sable du fournisseur sur un clone de votre dépôt et s'authentifient auprès de git via des tokens délivrés au fournisseur par l'intégration OAuth de GitHub, de sorte que l'agent n'a jamais accès à vos identifiants locaux, à vos clés SSH ou à vos variables d'environnement. Il s'agit d'une réelle propriété de sécurité : la compromission d'un ordinateur portable de développeur ne peut pas fuiter dans l'environnement de l'agent, et une tâche mal délimitée ne peut pas toucher à des fichiers situés hors du bac à sable.
Un agent hébergé est toujours actif. Il n'y a pas d'ordinateur portable à garder éveillé, et rien à installer. Pour des flottes autonomes tournant 24h/24, c'est décisif.
Les coûts sont structurels plutôt que temporaires.
- Une deuxième copie de tout. Le fournisseur détient vos dépôts, et souvent votre environnement, pour que l'agent puisse travailler. Cette copie s'accompagne de ses propres contrôles d'accès, de sa propre politique de rétention et de sa propre surface de vulnérabilité.
- Un deuxième jeu d'identifiants. Les tokens pour GitHub, les comptes cloud et les API internes sont délivrés au fournisseur. Les renouveler impose de le faire là-bas aussi.
- Une deuxième facture. Vous payez pour le runtime hébergé en plus de l'abonnement que vous possédez déjà, ou à sa place.
- Le choix du modèle imposé par un tiers. L'hébergeur décide des modèles disponibles et de la date de leurs changements.
Ce que le local-first réussit, et ce que cela coûte
Un agent local-first s'appuie sur ce qui se trouve déjà sur votre machine : l'abonnement Claude Code ou Codex que vous payez, les dépôts que vous avez déjà clonés en local, les clés déjà enregistrées dans votre trousseau. Rien n'est copié nulle part. Quand vous partagez l'agent, l'autre personne peut poser des questions ; votre machine se charge toujours d'effectuer le travail.
Le coût réside dans la disponibilité. Si la machine est en veille, l'agent est en veille.
Les solutions sont pratiques plutôt qu'architecturales : enregistrer le daemon comme service pour qu'il se lance à la connexion et redémarre après un plantage, garder la machine éveillée pendant les heures de travail, et mettre les demandes en attente dans une boîte de réception pour que rien ne soit perdu pendant qu'elle est hors ligne. Les demandes s'exécutent dans l'ordre dès son retour.
Deux endroits où placer la limite de confiance : autour du bac à sable du fournisseur, ou autour de votre propre machine avec une salle à l'extérieur.
À quel point la couche cloud peut être fine
muti est local-first, et la question de conception intéressante consistait à déterminer ce que le cloud a le droit de détenir. La réponse est : la salle, et rien qui permettrait à la salle d'usurper l'identité de la machine.
Trois mécanismes rendent cela possible.
Uniquement sortant. Le daemon sur votre machine interroge les nouvelles tâches via une connexion sortante. Il n'y a aucun port ouvert, aucun tunnel et aucune voie entrante. Si le cloud de muti venait à être compromis, l'attaquant pourrait mettre des demandes en file d'attente, mais vos règles de permissions et approbations continueraient de s'appliquer ; il ne pourrait pas accéder à vos fichiers.
Des événements, pas des fichiers. Le daemon émet des événements de timeline décrivant ce qui s'est produit. Il ne téléverse pas l'arbre de travail et ne lit jamais les variables d'environnement ni les fichiers de clés pour les envoyer où que ce soit.
Des approbations au centre. Comme la machine vous appartient, les quatre types d'actions dangereuses s'interrompent pour demander votre accord à chaque demande émise par une autre personne. Un agent hébergé muni de vos identifiants n'a personne à qui demander.
Tableau d'aide à la décision
Pourquoi muti n'héberge pas de runtimes
Il serait facile d'ajouter un bouton « exécuter dans notre cloud ». Nous ne l'avons pas fait, et c'est un non-objectif délibéré. Dès lors que le runtime se déplace, les identifiants et les dépôts suivent, et le propriétaire n'est plus celui qui approuve. Chaque garantie détaillée dans les quatre actions qui demandent toujours confirmation repose sur le fait que la machine appartienne au propriétaire.
muti héberge des salles. Votre agent reste là où il est.
Foire aux questions
« Local-first » est-il synonyme de « hors ligne » ? Non. L'agent a besoin du réseau pour joindre son fournisseur de modèle, et muti en a besoin pour distribuer les messages. Local-first qualifie l'endroit où résident le travail et les secrets, pas le fait que la machine soit connectée ou non.
Puis-je héberger le cloud de muti moi-même ? L'auto-hébergement de la couche de salles figure sur la feuille de route sous la forme d'un mode individuel, capable de fonctionner hors ligne. Le daemon et le cloud communiquent déjà via une simple API.
Que faire si je possède plusieurs machines ? Connectez chacune d'elles. Les agents sont liés à une machine et à un répertoire de travail, et vous pouvez distinguer vos machines grâce aux adresses signalées par le daemon.
Si vous payez déjà pour un bon agent et souhaitez le garder là où il est, donnez-lui une salle.
Publié le · Mis à jour le