# Murmell > A browser canvas where several AI coding agents (Claude Code, Codex, Kimi, OpenCode) run on a cloud machine and share one project directory. An agent claims a file before it writes to it, so several agents and several people work at once without overwriting each other. Canonical site: https://murmell.com/ Everything below is the full text of every page on murmell.com, in reading order. --- ## What Murmell is Murmell is a browser canvas where several AI coding agents run on a cloud machine and share one project directory. An agent claims a file before it writes to it, so five agents can work in the same repository at the same time, and anyone with the link watches it happen live. ## What it costs Starter is $0.99 per month with Limited Murmell Cloud, equal to 30 minutes per day, and 1 GB shared storage. Go is $9 per month with 10x Murmell Cloud, equal to 5 hours per day, and 5 GB. Pro is $39 per month with Unlimited Murmell Cloud and 20 GB. Storage is shared across all Canvases in the subscription. Every plan includes one active Canvas and 20 agent windows. Annual billing saves 20%. Provider usage is billed separately. Contact us for Teams and Enterprise. ## How a session works 01. Pick your agents. Start Claude Code, Codex, Kimi or OpenCode in the same canvas, on the accounts you already pay for. 02. Hand each one its files. An agent claims the paths it is about to touch. The board keeps the ledger, so nobody overwrites anybody. 03. Watch it run live. Terminals, board and preview stay side by side while everyone on the link watches the same screen. ## Questions and answers ### What is Murmell? Murmell is a browser canvas where several AI coding agents (Claude Code, Codex, Kimi, OpenCode) run on a cloud machine and share one project directory. Each agent opens in its own window with a real terminal, and everyone on the link sees the same canvas as it happens. ### Can several people really use one canvas at the same time? Yes. Everyone on the link sees the same room: who joined, which window they are watching, where their cursor is. Each person drives their own agents, and nothing has to be replayed or refreshed to stay in step. ### Where does my code live? On a machine Murmell runs, in one directory, and in a private GitHub repository created with the project. The workspace is disposable and the repository is not: the work is pushed before a machine is ever torn down. ### How much does Murmell cost? Starter is $0.99 per month with Limited Murmell Cloud, equal to 30 minutes per day, and 1 GB shared storage. Go is $9 per month with 10x Murmell Cloud, equal to 5 hours per day, and 5 GB. Pro is $39 per month with Unlimited Murmell Cloud and 20 GB. Storage is shared across all Canvases in the subscription. Every plan includes one active Canvas and 20 agent windows. Annual billing saves 20%. Provider usage is billed separately. Contact us for Teams and Enterprise. ### What are Murmell Bots? Murmell Bots are autonomous cloud agents for tasks and routines. They will work without an open Canvas and reuse the provider connections already linked to Murmell. Bots and the Canvas + Bots bundle are coming soon. ### Do you resell tokens? No. You connect the agent subscriptions and API keys you already pay for. Murmell charges for the machine and the collaboration, never for the model. ### What stops two agents destroying each other? An agent claims the paths it is about to touch before it writes. A watcher attributes every write back to whoever made it, and a colliding write is snapshotted before it lands, so nothing is lost. The rule is enforced by the machine rather than suggested to the model. ### Is each project isolated? Yes. Every canvas runs on its own machine, separate from every other project Murmell hosts. The machine that executes agent code holds no database and no decryption key. ### Which coding agents does Murmell support? Claude Code, Codex, Kimi and OpenCode today, each in its own terminal on the canvas, signed in with your own account or API key. Adding an agent is adding a tile: nothing about the canvas changes. ### Can I self-host it? No. Murmell runs the machines for you. That is the product. Your code still ends up in a private repository you own. --- ## AI Coding Agents in the Cloud: Supported Agents on Murmell Source: https://murmell.com/agents Available cloud agent runners Murmell provides dedicated cloud sandboxes for leading AI coding agents. Run them individually or orchestrate multiple agents in parallel on the same codebase. Codex in the Cloud: Persistent Cloud Runner for OpenAI Codex Run OpenAI Codex in a persistent cloud runtime with real-time file locking and zero local setup. Claude Code Multi-Agent Cloud: Run Claude Code in the Cloud Run Anthropic Claude Code in a persistent cloud sandbox with multi-agent file locking and zero local setup. --- ## Agents IA de code dans le cloud : agents compatibles Source: https://murmell.com/fr/agents Agents IA cloud disponibles Murmell propose des environnements cloud isolés pour les principaux agents de code. Lancez-les individuellement ou orchestrez plusieurs agents en parallèle sur une même base de code. Codex dans le cloud : exécution persistante d'OpenAI Codex Exécutez OpenAI Codex dans un runtime cloud persistant avec réservation de fichiers en temps réel. Claude Code dans le cloud : exécuter Claude Code en ligne Exécutez Anthropic Claude Code dans un bac à sable cloud persistant avec verrouillage de fichiers multi-agents. --- ## Claude Code Multi-Agent Cloud: Run Claude Code in the Cloud Source: https://murmell.com/agents/claude-code-cloud Zero local installation and setup Getting started with Claude Code typically requires configuring Node.js, CLI permissions, and local dependencies. With Murmell, Claude Code runs out of the box in a dedicated cloud container. Connect your Anthropic key or account, attach your repository, and begin working immediately from any browser. Read our guide to using Claude Code without installing anything for the step-by-step setup. Persistent multi-agent cloud execution Complex coding jobs take time. On Murmell, Claude Code runs uninterrupted in the cloud. You can initiate automated test fixes or documentation refactors and close your browser without killing the process. When you return, the full history and git diff are preserved. See how Claude Code in the browser operates and how sessions persist on dedicated machines. Real-time file locking with The Board When running multiple agents on one project, simultaneous file writes lead to corrupted state. Murmell coordinates all agents through The Board. When Claude Code begins editing a module, it reserves that file path. Other agents wait or move to alternative tasks, ensuring clean commits and zero collision loss. Read more about multiple AI agents on one repo. Running Claude Code alongside Codex and test runners On the multi-agent canvas, you can open Claude Code in one terminal and OpenAI Codex in the cloud in another. Assign backend refactoring to Claude Code while Codex generates corresponding integration tests. Both agents share the same working directory and coordinate via The Board. Compare this setup with standard local execution in our Murmell vs local Claude Code comparison. Collaborative canvas and live terminal Watch Claude Code inspect files, run bash commands, and apply patches in real time. Share your canvas link with team members to collaborate with live cursors, joint agent management, and instant web previews. Learn how to share a live coding session with teammates. --- ## Claude Code dans le cloud : exécuter Claude Code en ligne Source: https://murmell.com/fr/agents/claude-code-cloud Zéro installation locale Lancer Claude Code localement exige d'installer Node.js, de gérer les permissions CLI et d'encombrer sa propre machine. Sur Murmell, Claude Code tourne immédiatement dans un conteneur cloud dédié. Connectez votre clé Anthropic, liez votre dépôt, et commencez à coder depuis n'importe quel navigateur. Consultez notre guide pour utiliser Claude Code sans l'installer. Exécution multi-agents persistante dans le cloud Les refactorisations complexes prennent du temps. Sur Murmell, Claude Code s'exécute sans interruption. Vous pouvez lancer une suite de tests ou une refonte de code et fermer votre ordinateur. À votre retour, l'historique complet et les modifications Git sont préservés. Découvrez Claude Code dans le navigateur. Réservation de fichiers avec Le Tableau Lorsque plusieurs agents travaillent sur un même projet, les écritures simultanées corrompent le code. Murmell arbitre tous les agents via Le Tableau. Dès que Claude Code modifie un fichier, il en prend la réservation. Les autres agents attendent ou traitent d'autres modules. Consultez notre dossier sur plusieurs agents IA sur un même dépôt. Coordination avec Codex et d'autres agents Sur le canvas multi-agents, vous pouvez ouvrir Claude Code dans un terminal et OpenAI Codex dans le cloud dans un autre. Confiez la logique métier à Claude Code pendant que Codex écrit les tests unitaires. Retrouvez également notre comparatif Murmell face à Claude Code en local. Collaboration en direct Suivez les actions de Claude Code en temps réel : lecture de fichiers, exécution de commandes bash et application de patchs. Partagez le lien de votre canvas pour collaborer avec vos collègues en direct. Lisez comment partager une session de code. --- ## Codex dans le cloud : exécution persistante d'OpenAI Codex Source: https://murmell.com/fr/agents/codex-cloud Zéro configuration locale Exécuter OpenAI Codex en local nécessite d'installer des outils CLI, de gérer des versions Node.js et de saturer le processeur de son ordinateur. Sur Murmell, chaque session Codex démarre dans un bac à sable cloud en quelques secondes. Connectez vos identifiants OpenAI et confiez-lui des tâches directement depuis le navigateur. Environnement cloud persistant Les sessions locales s'arrêtent dès que vous fermez votre ordinateur ou perdez la connexion. Murmell maintient Codex actif dans un conteneur indépendant. Vous pouvez lancer une refactorisation lourde, quitter votre bureau et revenir plus tard inspecter les commits et les sorties terminal. Lisez notre guide pour lancer plusieurs agents IA sur un projet. Réservation de fichiers et prévention des conflits avec Le Tableau Faire tourner plusieurs agents IA sur une même base de code provoque d'ordinaire des collisions d'écriture. Murmell intègre Le Tableau, un registre de coordination en direct. Avant que Codex n'écrive dans un fichier, il en réserve l'accès. Les autres agents actifs, comme Claude Code dans le cloud, voient le fichier verrouillé et travaillent sur d'autres modules sans collision. Découvrez comment plusieurs agents partagent un même dépôt. Exécution simultanée sur le canvas multi-agents Sur le canvas multi-agents, vous combinez Codex avec d'autres agents CLI dans des fenêtres distinctes. Codex peut implémenter de nouvelles fonctionnalités pendant qu'un autre agent met à jour la documentation. Comparez cette approche dans notre comparatif Murmell face à Codex en local. Terminal complet et canvas collaboratif Codex s'exécute dans un véritable terminal avec gestion PTY, couleurs ANSI et invites interactives. Vous pouvez inspecter l'historique, visualiser les diffs Git et inviter vos collègues à suivre la session en direct avec curseurs partagés. Découvrez le fonctionnement du code à plusieurs avec des agents IA. --- ## Codex in the Cloud: Persistent Cloud Runner for OpenAI Codex Source: https://murmell.com/agents/codex-cloud Zero local configuration Running OpenAI Codex locally requires installing CLI tools, managing Node.js runtimes, configuring environment variables, and consuming your machine's CPU and memory. On Murmell, every Codex session launches in a pre-configured cloud sandbox in seconds. You sign in with your OpenAI credentials and start issuing tasks directly from your browser. Persistent cloud runtime Local agent sessions die when you close your laptop lid or disconnect your network. Murmell keeps Codex running in an independent cloud container. You can trigger a multi-file refactor or test cycle, leave your workstation, and reconnect from any device to inspect the finished commit and terminal output. Read our guide on running several AI agents on one project. File locking and conflict prevention with The Board Running multiple AI agents on the same codebase usually causes race conditions and broken builds. Murmell introduces The Board, a live coordination ledger. Before Codex writes to any file path, it claims that path. Other agents running concurrently, such as Claude Code in the cloud, see the locked status and work on independent modules without collisions. Read how multiple AI agents share one repo without branches. Concurrent execution on the multi-agent canvas On the multi-agent canvas, you can run Codex alongside other CLI agents in separate windows. Codex can write new feature code while another agent inspects and documents existing endpoints. Compare this approach with running Codex alone in our Murmell vs local Codex comparison. Full terminal fidelity and multiplayer canvas Codex runs in a genuine terminal with complete PTY support, ANSI colors, and interactive prompts. You can inspect command history, view file diffs, and invite teammates to watch the session live with shared cursors. Learn how multiplayer coding with AI agents keeps teams synchronized. --- ## Murmell Features: Multi-Agent Canvas, File Locking, Cloud Sandboxes Source: https://murmell.com/features Platform capabilities Murmell provides the infrastructure and interface for running parallel AI coding agents safely on real-world projects. Multi-Agent Canvas: AI Agent File Lock Canvas for Parallel Coding A real-time visual canvas with file reservation locks for parallel AI coding agents. --- ## Fonctionnalités de Murmell : canvas multi-agents et réservation de fichiers Source: https://murmell.com/fr/features Fonctionnalités de la plateforme Murmell fournit l'infrastructure et l'interface nécessaires pour exécuter des agents IA de code en parallèle en toute sécurité. Canvas multi-agents : espace visuel et verrouillage de fichiers Un canvas visuel temps réel avec verrouillage de fichiers pour exécuter des agents IA en parallèle. --- ## Canvas multi-agents : espace visuel et verrouillage de fichiers Source: https://murmell.com/fr/features/multi-agent-canvas Élimination des conflits de fusion et des écrasements Faire tourner des agents en parallèle sur un même dépôt entraîne habituellement des écrasements involontaires. Murmell résout ce problème au niveau du système de fichiers. Le Tableau fait office d'autorité de réservation : chaque agent réserve ses chemins actifs avant d'écrire. Les autres agents attendent ou s'orientent vers d'autres modules. Consultez notre explication sur plusieurs agents IA sur un même dépôt. Environnement cloud persistant et bacs à sable Chaque canvas fonctionne sur un bac à sable cloud dédié avec de vrais outils Linux, Git et des gestionnaires de paquets. Les agents travaillent indépendamment de votre poste de travail, préservant l'état lors des fermetures d'onglets. Coordination de plusieurs agents CLI simultanément Lancez Anthropic Claude Code, OpenAI Codex, Kimi ou OpenCode dans des fenêtres distinctes. Répartissez les tâches complexes entre plusieurs agents pour accélérer vos développements. Suivez notre guide pour lancer plusieurs agents IA. Zéro installation locale Aucun besoin d'installer des CLI ou de configurer des conteneurs en local. Ouvrez votre projet sur Murmell, connectez vos accès d'API et commencez à orchestrer vos agents directement depuis le navigateur. Espace collaboratif multijoueur Le canvas offre un espace de travail visuel partagé pour l'équipe. Observez où travaillent vos collègues et les agents grâce aux curseurs en temps réel, aux sorties de terminal partagées et aux aperçus web instantanés. Découvrez comment fonctionne le code à plusieurs avec des agents IA ou lisez comment partager une session de code. --- ## Multi-Agent Canvas: AI Agent File Lock Canvas for Parallel Coding Source: https://murmell.com/features/multi-agent-canvas Eliminating merge conflicts and file overwrites Running parallel coding agents on a single repository typically results in overwritten changes and merge disputes. Murmell solves this at the filesystem level. The Board acts as a live reservation authority: each agent claims its active paths before making edits. Other agents dynamically queue or re-route their work to independent modules. Read our detailed explanation of how multiple AI agents share one repo. Persistent cloud runtime and sandboxes Every canvas runs on a dedicated cloud sandbox equipped with real Linux tools, Git, and package managers. Agents execute tasks in the cloud independently of your workstation, persisting state across sessions and network drops without consuming local resources. Coordinating multiple CLI agents simultaneously Launch Anthropic Claude Code, OpenAI Codex, Kimi, or OpenCode in separate windows on the same screen. Divide complex features across multiple agents to accelerate implementation. Follow our step-by-step guide on how to run several AI agents on one project. Zero local setup and instant onboarding No need to install multiple agent CLI tools or configure container runtimes locally. Launch your project on Murmell, connect your API credentials, and start orchestrating parallel tasks directly from your browser. Multiplayer workspace with live presence The canvas provides a shared visual workspace for engineering teams. See where team members and AI agents are focused with real-time cursors, shared terminal outputs, and live application previews. Learn how multiplayer coding with AI agents works, or see how to share a coding session with a colleague. --- ## Murmell explained, one page per idea Source: https://murmell.com/what What is Murmell? Several coding agents in one repository The short answer: what Murmell is, what you see, and what happens to the code. Cloud AI for developers: models, APIs and remote coding agents The three senses of cloud AI, and the one that matters if you want a machine to write code. Cloud AI coding agents: how remote agents work on a repository What a coding agent running on a remote machine actually does, and what it needs to start. AI coding agents, sorted by what separates them The field of AI coding agents, sorted by where each tool sends a second agent. Claude Code in the browser Claude Code in a browser tab, with nothing installed and the session outliving the tab. Run Claude Code in the cloud How Claude Code runs on a machine we operate instead of on your laptop. Multiple AI agents on one repo The file reservation board, and what two agents did with it when we watched. Multiplayer coding with AI agents The two halves of multiplayer on Murmell: many agents, and many people watching them. A cloud sandbox for AI agents What the machine running agent code holds, and which secrets never reach it. Figma for developers: a multiplayer canvas for code What the Figma analogy gets right about Murmell, and where it overreaches. The words Murmell uses, defined Every term the product uses, defined in a sentence each. Set against other tools Most tools that run coding agents in parallel give each one its own copy of your files. Murmell does not, and the comparison pages go through them one at a time, naming what each does and where the two shapes part. --- ## Cloud-KI-Coding verstehen Source: https://murmell.com/de/what Was ist Murmell? Mehrere Programmier-Agenten in einem Repository Die kurze Antwort: Was Murmell ist, was Sie sehen und was mit dem Code geschieht. Cloud-KI für Entwickler: Gehostete Modelle, APIs und Remote-Coding-Agenten Die drei Bedeutungen von „Cloud-KI", und welche für jemanden zählt, der Code von einer entfernten Maschine schreiben lassen will. Cloud-KI-Coding-Agenten: Autonome Code-Entwicklung und Tests auf Remote-Repositories Was ein Coding-Agent, der auf einer entfernten Maschine ausgeführt wird, konkret tut, und was er zum Starten braucht. KI-Coding-Agenten im Vergleich: Claude Code, Cursor, Devin und 10 weitere Tools Der Überblick über die KI-Coding-Agenten, geordnet danach, wohin jedes Werkzeug einen zusätzlichen Agenten schickt. Claude Code im Browser, ohne etwas zu installieren Wie das Claude-Code-CLI auf einer entfernten Maschine läuft und sich in einem Tab anzeigt, ohne lokale Installation. Claude Code in der Cloud ausführen: Ohne lokale Installation mit mehreren Agenten Der konkrete Ablauf einer KI-gestützten Coding-Sitzung auf einer entfernten Maschine, vom leeren Repository bis zum Commit. Mehrere KI-Agenten in einem Repository Der Dateireservierungsmechanismus, der mehrere Agenten in ein einziges geteiltes Verzeichnis schreiben lässt. Multiplayer-Coding mit KI-Agenten Die zwei Seiten von Multiplayer bei Murmell: viele Agenten und viele beobachtende Menschen. Die Cloud-Maschine, auf der die Agenten laufen Was die Maschine enthält, die den Code der Agenten ausführt, und warum sie sonst nichts enthält. Figma für Entwickler: Ein Multiplayer-Canvas für Code Was die Figma-Analogie über Murmell richtig beschreibt und wo sie aufhört. Glossar zum Cloud-KI-Coding Die Begriffe des Fachgebiets, kurz erklärt: Agent, Canvas, Dateireservierung, Sandbox, Kontext, Token. Im Vergleich zu anderen Werkzeugen Die meisten Werkzeuge, die Agenten parallel laufen lassen, geben jedem seine eigene Kopie Ihrer Dateien. Murmell nicht, und die Vergleiche gehen sie einzeln durch, benennen, was jedes tut, und den Punkt, an dem sich die beiden Formen unterscheiden. --- ## Entender la IA de código en la nube Source: https://murmell.com/es/what ¿Qué es Murmell? Varios agentes de código en un repositorio La respuesta corta: qué es Murmell, qué ves y qué pasa con el código. IA en la nube para desarrolladores: modelos, APIs y agentes de código remotos Los tres sentidos de "IA en la nube", y el que le importa a quien quiere que una máquina remota le escriba código. Agentes de IA en la nube: cómo programan y ejecutan pruebas en un repositorio remoto Qué hace en concreto un agente de código que se ejecuta en una máquina remota, y qué necesita para arrancar. Comparativa de agentes de IA para programar: Claude Code, Cursor, Devin y más El panorama de los agentes de IA de código, ordenado por a dónde envía cada herramienta un agente adicional. Claude Code en el navegador, sin instalar nada Cómo el CLI de Claude Code corre en una máquina remota y se muestra en una pestaña, sin instalación local. Ejecutar Claude Code en la nube: sin instalación local y con múltiples agentes El desarrollo concreto de una sesión de código asistida por IA en una máquina remota, del repositorio vacío al commit. Varios agentes de IA en un mismo repositorio El mecanismo de reserva de archivos que deja a varios agentes escribir en un solo directorio compartido. Programación multijugador con agentes de IA Las dos mitades del multijugador en Murmell: muchos agentes y muchas personas observándolos. La máquina en la nube donde corren los agentes Qué contiene la máquina que ejecuta el código de los agentes, y por qué no contiene nada más. Figma para desarrolladores: un lienzo multijugador para código En qué acierta la analogía de Figma con Murmell y dónde se queda corta. Glosario de la IA de código en la nube Los términos del área, definidos brevemente: agente, canvas, reserva de archivo, caja de arena, contexto, token. Frente a otras herramientas La mayoría de las herramientas que hacen correr agentes en paralelo le dan a cada uno su propia copia de tus archivos. Murmell no, y las comparativas las recorren una por una, nombrando lo que hace cada una y el punto donde las dos formas divergen. --- ## Comprendre l'IA de code dans le cloud Source: https://murmell.com/fr/quoi Qu’est-ce que Murmell ? Plusieurs agents de code sur un même dépôt La réponse courte : ce qu’est Murmell, ce que vous voyez et ce qu’il advient du code. L’IA cloud pour développeurs : modèles, API et agents de code Les trois sens de « IA cloud », et celui qui concerne quelqu'un qui veut faire écrire du code par une machine distante. Agent IA cloud pour coder : fonctionnement sur un dépôt distant Ce qu'un agent de code exécuté sur une machine distante fait concrètement, et ce qu'il lui faut pour démarrer. Les agents IA de code, rangés par ce qui les sépare Le panorama des agents IA de code, rangé par l'endroit où chaque outil envoie un agent supplémentaire. Claude Code dans le navigateur, sans rien installer Comment le CLI Claude Code tourne sur une machine distante et s'affiche dans un onglet, sans installation locale. Coder avec l'IA dans le cloud, en pratique Le déroulé concret d'une session de code assistée par IA sur une machine distante, du dépôt vide au commit. Plusieurs agents IA sur un même dépôt Le mécanisme de réservation de fichiers qui laisse plusieurs agents écrire dans un seul dossier partagé. Coder à plusieurs avec des agents IA Les deux volets du multijoueur sur Murmell : plusieurs agents et plusieurs personnes pour les observer. La machine cloud où tournent les agents Ce que contient la machine qui exécute le code des agents, et pourquoi elle ne contient rien d'autre. Figma pour les développeurs : un canvas multijoueur pour le code Ce que l’analogie avec Figma dit de vrai sur Murmell, et où elle s’arrête. Glossaire de l'IA de code dans le cloud Les termes du domaine, définis court : agent, canvas, réservation de fichier, bac à sable, contexte, jeton. Face aux autres outils La plupart des outils qui font tourner des agents en parallèle donnent à chacun sa propre copie de vos fichiers. Murmell non, et les comparatifs les prennent un par un, en nommant ce que chacun fait et l'endroit où les deux formes divergent. --- ## Entender a IA de código na nuvem Source: https://murmell.com/pt/what O que é o Murmell? Vários agentes de código num repositório A resposta curta: o que é o Murmell, o que você vê e o que acontece com o código. IA na nuvem para desenvolvedores: Modelos hospedados, APIs e agentes remotos de código Os três sentidos de "IA na nuvem", e o que interessa a quem quer que uma máquina remota escreva código. Agentes de IA na nuvem: Desenvolvimento e testes autônomos em repositórios remotos O que um agente de código executado em uma máquina remota faz na prática, e o que ele precisa para começar. Comparativo de agentes de IA para programar: Claude Code, Cursor, Devin e mais 10 O panorama dos agentes de IA de código, organizado pelo lugar para onde cada ferramenta manda um agente adicional. Claude Code no navegador, sem instalar nada Como o CLI do Claude Code roda em uma máquina remota e aparece em uma aba, sem instalação local. Rodar Claude Code na nuvem: Sem instalação local e com múltiplos agentes O passo a passo concreto de uma sessão de código assistida por IA em uma máquina remota, do repositório vazio ao commit. Vários agentes de IA em um mesmo repositório O mecanismo de reserva de arquivos que permite que vários agentes escrevam em um único diretório compartilhado. Programação multiplayer com agentes de IA As duas metades do multiplayer no Murmell: muitos agentes e muitas pessoas observando. A máquina na nuvem onde os agentes rodam O que contém a máquina que executa o código dos agentes, e por que ela não contém mais nada. Figma para desenvolvedores: um canvas multiplayer para código O que a analogia com o Figma acerta sobre o Murmell e onde ela exagera. Glossário da IA de código na nuvem Os termos da área, definidos de forma curta: agente, canvas, reserva de arquivo, sandbox, contexto, token. Em relação a outras ferramentas A maioria das ferramentas que rodam agentes em paralelo dá a cada um sua própria cópia dos seus arquivos. Murmell não, e as comparações passam por elas uma a uma, nomeando o que cada uma faz e o ponto onde as duas formas divergem. --- ## Capire l'IA di coding nel cloud Source: https://murmell.com/it/what Cos’è Murmell? Più agenti di codice in un unico repository La risposta breve: cos’è Murmell, cosa visualizzi e cosa succede al codice. IA cloud per sviluppatori: Modelli ospitati, API e agenti di codice remoti I tre significati di "IA cloud", e quale conta per chi vuole far scrivere codice a una macchina remota. Agenti IA di codice nel cloud: Sviluppo autonomo e test su repository remoti Cosa fa concretamente un agente di coding eseguito su una macchina remota, e cosa gli serve per partire. Confronto agenti IA di codice: Claude Code, Cursor, Devin e altri 10 strumenti Il panorama degli agenti IA di coding, ordinato secondo il posto dove ogni strumento manda un agente in più. Claude Code nel browser, senza installare nulla Come il CLI Claude Code gira su una macchina remota e appare in una scheda del browser, senza installazione locale. Eseguire Claude Code nel cloud: Senza installazione locale e con più agenti Lo svolgimento concreto di una sessione di coding assistita da IA su una macchina remota, dal repository vuoto al commit. Più agenti IA su uno stesso repository Il meccanismo di prenotazione dei file che permette a più agenti di scrivere in un'unica cartella condivisa. Programmazione multiplayer con agenti IA Le due metà del multiplayer su Murmell: molti agenti e molte persone che li osservano. La macchina cloud dove girano gli agenti Cosa contiene la macchina che esegue il codice degli agenti, e perché non contiene nient'altro. Figma per sviluppatori: un canvas multiplayer per il codice Cosa coglie di vero l’analogia con Figma su Murmell e dove si ferma. Glossario dell'IA di coding nel cloud I termini del settore, definiti in breve: agente, canvas, prenotazione di file, sandbox, contesto, token. Rispetto agli altri strumenti La maggior parte degli strumenti che fanno girare agenti in parallelo dà a ciascuno la propria copia dei tuoi file. Murmell no, e i confronti li prendono uno per uno, nominando cosa fa ciascuno e il punto dove le due forme divergono. --- ## Понять ИИ-код в облаке Source: https://murmell.com/ru/what Что такое Murmell? Несколько кодинг-агентов в одном репозитории Кратко: что такое Murmell, что вы видите на экране и как сохраняется код. Облачный ИИ для разработчиков: Разница между моделями, API и автономными кодинг-агентами Три значения «облачного ИИ», и то, которое касается человека, желающего заставить удалённую машину писать код. Облачные ИИ-агенты для написания кода: Автономная разработка и тесты в удаленном репозитории Что на самом деле делает агент для кода, выполняемый на удалённой машине, и что ему нужно для запуска. Сравнение ИИ-агентов для кодинга: Claude Code, Cursor, Devin и еще 10 инструментов Панорама ИИ-агентов для кода, рассортированных по тому, куда каждый инструмент отправляет дополнительного агента. Claude Code в браузере, без установки Как CLI Claude Code работает на удалённой машине и отображается во вкладке, без локальной установки. Запуск Claude Code в облаке: Без локальной установки и с поддержкой нескольких агентов Как на практике проходит сессия кодирования с помощью ИИ на удалённой машине, от пустого репозитория до коммита. Несколько ИИ-агентов в одном репозитории Механизм резервирования файлов, который позволяет нескольким агентам писать в один общий каталог. Мультиплеерное программирование с ИИ-агентами Две стороны мультиплеера в Murmell: множество агентов и наблюдающие за ними люди. Облачная машина, на которой работают агенты Что содержит машина, выполняющая код агентов, и почему в ней нет ничего другого. Figma для разработчиков: мультиплеерный холст для кода В чем аналогия с Figma верна для Murmell и где она заканчивается. Глоссарий ИИ-кода в облаке Термины этой области, определённые кратко: агент, канвас, резервирование файла, песочница, контекст, токен. В сравнении с другими инструментами Большинство инструментов, запускающих агентов параллельно, дают каждому собственную копию ваших файлов. Murmell нет, и сравнения разбирают их по одному, называя, что делает каждый, и где эти два подхода расходятся. --- ## क्लाउड में AI कोड को समझना Source: https://murmell.com/hi/what Murmell क्या है? एक रिपॉजिटरी में कई कोडिंग एजेंट संक्षिप्त उत्तर: Murmell क्या है, आप क्या देखते हैं, और कोड का क्या होता है। डेवलपर्स के लिए Cloud AI: Hosted Models, APIs और Remote Coding Agents में अंतर "क्लाउड AI" के तीन मतलब, और वह जो किसी दूरस्थ मशीन से कोड लिखवाने वाले व्यक्ति से जुड़ा है। Cloud AI Coding Agents: रिमोट रिपॉजिटरी में ऑटोनॉमस कोडिंग और टेस्टिंग दूरस्थ मशीन पर चलने वाला कोड एजेंट असल में क्या करता है, और शुरू करने के लिए उसे क्या चाहिए। Top AI Coding Agents तुलना: Multi-Agent आर्किटेक्चर और पैरेलल कोडिंग टूल्स कोड लिखने वाले AI एजेंट का पैनोरमा, हर टूल दूसरे एजेंट को कहां भेजता है इसके हिसाब से बंटा हुआ। बिना कुछ इंस्टॉल किए ब्राउज़र में Claude Code बिना लोकल इंस्टॉल के, Claude Code CLI दूरस्थ मशीन पर कैसे चलता है और टैब में कैसे दिखता है। Cloud में Claude Code चलाना: बिना लोकल सेटअप, मल्टी-एजेंट और ब्राउज़र टर्मिनल दूरस्थ मशीन पर AI-सहायता से कोडिंग सेशन का पूरा क्रम, खाली रिपॉज़िटरी से लेकर कमिट तक। एक ही रिपॉज़िटरी पर कई AI एजेंट फ़ाइल आरक्षण का वह तरीका जो कई एजेंट को एक साझा फ़ोल्डर में लिखने देता है। AI एजेंटों के साथ मल्टीप्लेयर कोडिंग Murmell मल्टीप्लेयर के दो पहलू: कई एजेंट और उन्हें देखने वाले कई लोग। वह क्लाउड मशीन जहां एजेंट चलते हैं एजेंट का कोड चलाने वाली मशीन में क्या होता है, और उसमें और कुछ क्यों नहीं होता। डेवलपर्स के लिए Figma: कोड के लिए मल्टीप्लेयर कैनवस Figma की उपमा Murmell के बारे में क्या सही बताती है और कहाँ अलग है। क्लाउड में AI कोड की शब्दावली इस क्षेत्र के शब्द, छोटे में समझाए गए: एजेंट, कैनवस, फ़ाइल आरक्षण, sandbox, context, टोकन। बाकी टूल्स के मुकाबले ज़्यादातर टूल जो एजेंट को साथ-साथ चलाते हैं, हर एक को आपकी फ़ाइलों की अपनी कॉपी देते हैं। Murmell नहीं देता, और तुलनाएं इन्हें एक-एक करके लेती हैं, हर एक क्या करता है यह बताते हुए, और जहां दोनों तरीके अलग होते हैं। --- ## 클라우드 AI 코딩 이해하기 Source: https://murmell.com/ko/what Murmell이란 무엇인가요? 하나의 리포지토리에서 작업하는 여러 코딩 에이전트 요약: Murmell의 정의, 화면 구성, 코드 관리 방식. 개발자를 위한 클라우드 AI: 호스팅 모델, API, 원격 자율 코딩 에이전트의 차이 "클라우드 AI"의 세 가지 의미, 그리고 원격 머신에 코드를 쓰게 하려는 사람에게 중요한 것은 어느 쪽인지. 클라우드 AI 코딩 에이전트: 원격 리포지토리 자율 개발 및 테스트 구동 방식 원격 머신에서 실행되는 코딩 에이전트가 실제로 하는 일과, 시작하는 데 필요한 것. 주요 AI 코딩 에이전트 비교: 병렬 실행 및 멀티 에이전트 아키텍처 13종 분석 AI 코딩 에이전트 파노라마. 각 도구가 추가 에이전트를 어디로 보내는지에 따라 정렬합니다. 설치 없는 브라우저 속 Claude Code Claude Code CLI가 원격 머신에서 실행되어 로컬 설치 없이 탭에 표시되는 방식. 클라우드에서 Claude Code 실행하기: 로컬 설치 없는 다중 에이전트 개발 원격 머신에서 AI가 돕는 코딩 세션이 빈 저장소부터 커밋까지 실제로 어떻게 진행되는지. 하나의 저장소 위 여러 AI 에이전트 여러 에이전트가 하나의 공유 디렉터리에 쓸 수 있게 하는 파일 점유 메커니즘. AI 에이전트와의 멀티플레이어 코딩 Murmell 멀티플레이어의 두 축: 여러 에이전트와 이들을 지켜보는 팀원들. 에이전트가 실행되는 클라우드 머신 에이전트의 코드를 실행하는 머신에 무엇이 들어 있고, 왜 그 외에는 아무것도 없는지. 개발자를 위한 Figma: 코드를 위한 멀티플레이어 캔버스 Figma 비유가 Murmell에 대해 설명하는 점과 한계. 클라우드 AI 코딩 용어집 이 분야의 용어를 짧게 정의합니다. 에이전트, 캔버스, 파일 점유, 샌드박스, 컨텍스트, 토큰. 다른 도구와의 차이 에이전트를 병렬로 실행하는 대부분의 도구는 각 에이전트에 파일의 자체 복사본을 줍니다. Murmell은 그렇지 않습니다. 비교 페이지에서는 각 도구가 무엇을 하는지, 그리고 두 방식이 어디서 갈라지는지 하나씩 짚어봅니다. --- ## クラウドのAIコーディングを理解する Source: https://murmell.com/ja/what Murmell とは？1つのリポジトリで動く複数のコーディングエージェント 要約：Murmell とは何か、何が見えるのか、コードはどう管理されるのか。 エンジニアのためのクラウドAI：ホスト型モデル、API、リモート自律エージェントの違い 「クラウドAI」の3つの意味と、リモートマシンにコードを書かせたい人にとって重要なのはどれか。 クラウドAIコーディングエージェント：リモートリポジトリでの自律開発とテスト リモートマシン上で動くコーディングエージェントが実際に何をするか、始めるために何が必要か。 主要AIコーディングエージェント徹底比較：並行処理とマルチエージェント構造で選ぶ13選 AIコーディングエージェントのパノラマ。各ツールが追加のエージェントをどこに送るかで並べています。 何もインストールせずにブラウザで動くClaude Code Claude CodeのCLIがリモートマシン上で動き、ローカルインストールなしでタブに表示される仕組み。 Claude Code をクラウドで実行する：環境構築不要・複数エージェント並行開発 リモートマシン上でAI支援のコーディングセッションが実際にどう進むか、空のリポジトリからコミットまで。 1つのリポジトリで複数のAIエージェント 複数のエージェントが1つの共有ディレクトリに書き込めるようにするファイル確保の仕組み。 AI エージェントとのマルチプレイヤーコーディング Murmell におけるマルチプレイヤーの2つの側面：多数のエージェントと、それを見守る人々。 エージェントが動くクラウドマシン エージェントのコードを実行するマシンに何が入っているか、そしてなぜそれ以外何も入っていないのか。 開発者のための Figma：コードのためのマルチプレイヤーキャンバス Figma の類推が Murmell について正しく捉えている点と、当てはまらない点。 クラウドAIコーディングの用語集 この分野の用語を短く定義: エージェント、キャンバス、ファイル確保、サンドボックス、コンテキスト、トークン。 他のツールとの違い 並行してエージェントを動かすほとんどのツールは、各エージェントに独自のファイルコピーを与えます。 Murmellはそうしません。比較ページでは、それぞれのツールが何をするか、そして 両者の形がどこで分かれるかを一つずつ挙げています。 --- ## 理解云端 AI 编程 Source: https://murmell.com/zh/what 什么是 Murmell？一个仓库里的多个编程代理 简短回答：Murmell 是什么、你看到什么，以及代码会怎样。 面向开发者的云端 AI：托管模型、API 与远程编程代理的区别 "云端 AI"这个说法的三种含义,以及哪一种和想让远程机器帮忙写代码的人相关。 云端 AI 编程代理：如何在远程代码仓库自主运行与测试 一个运行在远程机器上的编程代理具体做什么,以及它启动需要什么。 主流 AI 编程代理选型横评：按并发架构与多任务机制深度对比 AI 编程代理全景图,按每款工具把额外的代理送到哪里来分类。 在浏览器里用 Claude Code,不装任何东西 Claude Code 这个 CLI 如何运行在远程机器上、又如何显示在浏览器标签页里,不需要本地安装。 在云端运行 Claude Code：免安装、多代理与远程终端开发 一次在远程机器上、由 AI 辅助的编程会话具体是怎么进行的,从空仓库到提交代码。 多个 AI 代理共用同一个仓库 让多个代理写入同一个共享目录的文件占用机制。 与 AI 代理多人协作编程 Murmell 多人协作的两半：多个代理，以及观看它们的很多人。 代理运行所在的那台云端机器 执行代理代码的机器里到底装了什么,以及为什么它不装别的东西。 开发者专属的 Figma：面向代码的多人协作画布 Figma 类比在 Murmell 身上说对了什么，又在哪里言过其实。 云端 AI 编程术语表 这个领域的常用词,简短定义:代理、画布、文件占用、沙箱、上下文、token。 和其他工具比起来 大多数能并行运行多个代理的工具,都是给每个代理一份你文件的拷贝。Murmell 不这样做,对比页面 会逐个说清楚每个工具做了什么、又在哪里和 Murmell 分道扬镳。 --- ## A máquina na nuvem onde os agentes rodam Source: https://murmell.com/pt/what/cloud-sandbox-for-ai-agents Por que uma caixa de areia Também se diz sandbox, e essa é a palavra usada na maior parte da documentação. Um agente útil executa comandos que ele mesmo escreveu. Instalar um pacote, rodar um script, abrir uma porta. Nenhuma revisão humana passa na frente de cada um desses comandos, o que significa que a única proteção séria é o lugar onde eles rodam. Daí a regra: a máquina que executa o código não tem nada de interessante nela. Nem banco de dados, nem chave de descriptografia, nem credenciais de outro cliente. Um incidente nessa máquina custa a máquina. O que ela contém O diretório do projeto, os CLIs dos agentes, e o que os agentes instalam para trabalhar. As credenciais que você conecta servem aos agentes durante a sessão e não saem desse perímetro. O canvas, a sala e o painel de reservas vivem em outro lugar. Um agente que escrevesse qualquer coisa no seu disco não poderia decidir quem detém um arquivo: a arbitragem não está na máquina que ele controla. Uma máquina por projeto O isolamento entre projetos não é uma configuração, é a forma do produto. Cada canvas inicia sua máquina, e dois projetos nunca compartilham um sistema de arquivos. É também isso que torna o ambiente reproduzível: o projeto parte de uma imagem conhecida a cada vez. E o código, no final Um repositório privado é criado junto com o projeto, e o trabalho é enviado para lá ao longo da sessão, com um último envio antes de destruir a máquina. O que você mantém é um repositório normal, na sua casa, legível sem o Murmell. O andamento de uma sessão. --- ## Qu’est-ce que Murmell ? Plusieurs agents de code sur un même dépôt Source: https://murmell.com/fr/quoi/murmell Envoyez le lien à quelqu’un et cette personne rejoint le canvas avec vous, observant les mêmes terminaux défiler, avec son nom sur son curseur. Ce que vous regardez Un canvas pointillé clair avec des fenêtres dessus, dessinées comme macOS dessine une fenêtre. Chaque fenêtre est le terminal d’un agent, affichant la sortie du vrai CLI sur notre machine avec les caractères exacts qu’il a produits. Les fenêtres sont côte à côte, donc cinq agents sont cinq fenêtres sur un seul écran et vous pouvez tous les lire à la fois. Le canvas sur la page d’accueil est le même objet, dessiné. Un dossier, et un tableau qui indique qui détient quoi Donnez à trois agents la même copie de travail sans règles et ils s’écrasent mutuellement en moins d’une minute. La dernière écriture gagne silencieusement, et personne ne s’en rend compte jusqu’à ce qu’un test casse sans raison apparente. Un agent réserve donc les chemins qu’il s’apprête à toucher avant d’y toucher. Le tableau enregistre un seul détenteur par chemin et refuse tous les autres jusqu’à ce que le détenteur le libère. Ce refus vient de notre serveur, ce n’est donc pas une consigne dans un prompt qu’un modèle pourrait ignorer. Une écriture qui entre en collision malgré tout est sauvegardée en instantané avant d’atterrir. Personne n’écrit sans demander d’abord. Plusieurs agents IA sur un dépôt détaille le tableau, y compris les mesures effectuées lors de nos tests avec deux agents. Les personnes dans la pièce Un lien de lecture est gratuit et sans limite de distribution. Les liens d’édition sont plafonnés par votre forfait. La personne qui ouvre un lien voit les fenêtres là où elles sont et la sortie du terminal au fil de l’eau, et voit les autres curseurs bouger avec un nom sur chacun. Fermer votre onglet ne tue pas les agents. Ils appartiennent au canvas, le travail continue donc sans vous et tourne encore quand vous revenez. Coder à plusieurs avec des agents IA couvre ce que deux personnes peuvent faire sur un même canvas. Où va le code Chaque projet dispose d’un dépôt privé, et le travail y est poussé au fur et à mesure. Une machine sur le point d’être arrêtée pousse une dernière fois avant de s’éteindre, de sorte que la partie jetable est la machine et jamais le code. La machine qui exécute le code des agents ne contient aucune base de données et aucune clé de déchiffrement. Un agent qui s’échappe trouve un dossier de projet et rien à dérober. Une machine cloud pour les agents IA indique où vivent les secrets. D’où vient le nom Murmell vient de murmuration, la forme que prend une nuée lorsque des milliers d’oiseaux bougent comme un seul. Le même mot désigne un son doux, un murmure, et c’est le logo : une simple onde. --- ## What is Murmell? Several coding agents in one repository Source: https://murmell.com/what/murmell Send the link to somebody and they are in the canvas with you, watching the same terminals scroll, with their name on their cursor. What you look at A light dotted canvas with windows on it, drawn the way macOS draws a window. Each window is one agent’s terminal, showing the output of the actual CLI on our machine in the characters it printed. Windows sit next to each other, so five agents are five windows on one screen and you read all of them at once. The canvas on the home page is the same object, drawn. One directory, and a board that says who holds what Give three agents the same checkout with no rules and they overwrite each other inside a minute. Last write wins, silently, and nobody finds out until a test breaks for no reason anybody can see. So an agent claims the paths it is about to touch before it touches them. The board records one holder per path and refuses everyone else until the holder releases it. That refusal comes from our server, so it is not an instruction in a prompt that a model can decide to skip. A write that collides anyway is snapshotted before it lands. Nobody writes without asking first. Multiple AI agents on one repo goes through the board properly, including what we measured when we watched two agents use it. The people in the room A read link is free and there is no limit on how many you hand out. Edit links are capped by your plan. Whoever opens a link sees the windows where they are and the terminal output as it arrives, and sees the other cursors move with a name on each one. Closing your tab does not kill the agents. They belong to the canvas, so the work carries on without you and is still running when you come back. Multiplayer coding with AI agents covers what two people on one canvas can each do. Where the code goes Every project gets a private repository, and the work is pushed to it as the project goes. A machine about to be torn down pushes one last time before it goes, so the disposable part is the machine and never the code. The machine that executes agent code holds no database and no decryption key. An agent that escapes finds a project directory and nothing to steal. A cloud sandbox for AI agents says which secrets live where. Where the name comes from Murmell is from murmuration, the shape a flock makes when thousands of birds move as one. The same word means a low sound, a murmur, and that is the logo: a single wave. --- ## ¿Qué es Murmell? Varios agentes de código en un repositorio Source: https://murmell.com/es/what/murmell Envías el enlace a alguien y entra en el lienzo contigo, viendo las mismas terminales avanzar con su nombre en el cursor. Qué es lo que ves Un lienzo claro con ventanas dibujadas al estilo de macOS. Cada ventana es la terminal de un agente, mostrando la salida real de la CLI en nuestras máquinas. Las ventanas están una al lado de la otra, por lo que cinco agentes son cinco ventanas en una sola pantalla. El lienzo en la página principal es el mismo objeto dibujado. Un directorio y un tablero que indica quién tiene qué Si das a tres agentes el mismo directorio sin reglas, se sobrescriben en menos de un minuto. La última escritura gana en silencio y nadie se entera hasta que un test falla. Por eso un agente reserva las rutas antes de tocarlas. El tablero registra un titular por ruta y rechaza a todos los demás hasta que se libere. Ese rechazo viene de nuestro servidor. Si ocurre una colisión, se guarda una copia de seguridad al instante. Nadie escribe sin pedir permiso antes. Múltiples agentes de IA en un repositorio explica el tablero en detalle con datos de nuestras pruebas. Las personas en la sala Un enlace de lectura es gratuito y sin límite. Los enlaces de edición dependen de tu plan. Quien abre el enlace ve las terminales en vivo y los cursores de los demás con sus nombres. Cerrar la pestaña no detiene a los agentes. Pertenecen al lienzo, así que el trabajo continúa sin ti y sigue ejecutándose cuando regresas. Programación multijugador con agentes de IA explica lo que dos personas pueden hacer. Adónde va el código Cada proyecto tiene un repositorio privado y el trabajo se sincroniza al instante. Una máquina que se va a apagar hace un último push, así que lo desechable es la máquina y nunca el código. La máquina que ejecuta el código no guarda bases de datos ni claves de descifrado. Un agente que escape solo encontrará un directorio de proyecto sin nada valioso que robar. Un sandbox en la nube para agentes de IA explica dónde residen los secretos. De dónde viene el nombre Murmell viene de murmuration, la forma que crea una bandada cuando miles de aves se mueven como una sola. La misma palabra evoca un susurro suave, y ese es el logotipo: una sola onda. --- ## Agent IA cloud pour coder : fonctionnement sur un dépôt distant Source: https://murmell.com/fr/quoi/agent-ia-cloud La boucle, en trois gestes Un agent lit le dépôt pour se repérer, écrit une modification, puis exécute quelque chose qui lui dit s'il a eu raison : une suite de tests, une compilation, une commande. Il lit le résultat, corrige, recommence. Cette boucle est ce qui sépare un agent d'un générateur de texte : il obtient un retour du monde entre deux tentatives. Une machine distante entre en jeu parce que cette boucle demande des choses qu'on ne veut pas sur son portable : installer des paquets, remplir un disque, garder un serveur allumé pendant quarante minutes. Ce qui change quand la machine n'est pas la vôtre Le travail survit à l'onglet. Vous lancez une tâche, vous partez déjeuner, le processus continue. Sur un portable, fermer le capot arrête tout, et c'est la vraie raison pour laquelle les gens n'osent pas lancer une tâche longue. Le nombre cesse d'être un problème. Un agent occupe une machine, pas votre écran. Cinq agents ne demandent pas cinq fois plus d'attention, ils demandent une manière de les regarder. Et l'environnement est reproductible. La machine part d'une image connue à chaque projet, donc « ça marche chez moi » cesse d'être une phrase. Le problème qui arrive au deuxième agent Deux agents dans le même dossier écrivent le même fichier à trente secondes d'écart, et le second efface le premier sans que rien ne signale l'incident. L'échappatoire habituelle est de leur donner chacun une copie du dépôt, ce qui déplace le problème sur la fusion. Murmell prend l'autre chemin. Un dossier partagé, et une réservation avant écriture : un agent annonce les chemins qu'il va toucher, le tableau les lui donne, et les refuse à tout le monde jusqu'à ce qu'il les rende. Le mécanisme en détail. Les agents que Murmell lance Claude Code, Codex, Kimi et OpenCode, chacun dans une fenêtre du canvas avec un vrai terminal, signés avec votre compte ou votre clé. Aucun jeton n'est revendu : la facture couvre la machine et la salle où les gens regardent. Claude Code dans le navigateur décrit ce que ça donne à l'écran. --- ## A cloud sandbox for AI agents Source: https://murmell.com/what/cloud-sandbox-for-ai-agents That is the whole design goal. Not a promise that agents behave, which nobody can make, but an arrangement where the worst afternoon costs you one project directory. What is on the executing machine The agent’s process and the project checkout. That is the interesting part of it. What is not there: the database, and the key that would decrypt anything held in it. A token you connect to a code host is encrypted before it is stored, and it never reaches the machines your agents run on. Reading a secret out of the environment of a Murmell sandbox does not get anybody into an account. Read our article on why the executing machine holds no secrets. The sandbox sits apart The agents on one canvas share a sandbox, and that is deliberate: they are working in one directory, so they need one filesystem. The sandbox runs on infrastructure separate from everything else we operate, so the reach of an agent doing something stupid is the project it was working on. You can run Claude Code, Codex, or multiple agents together in this container. Multiple AI agents on one repo covers how the agents inside that shared directory stay out of each other’s way, and our cloud sandbox findings detail the isolation boundary. Git is readable, never rewritable Agents can read the history of the repository, which they need in order to understand what they are changing. They cannot rewrite it. A history an agent cannot rewrite is a floor under every other mistake it can make. The machine is meant to be thrown away Every project has a private repository from its first day, and the work is pushed there as it happens. A machine about to be destroyed pushes one final time before it goes, so nothing of value is ever stored only in the sandbox. Which is why tearing a machine down is routine here rather than an incident. Run Claude Code in the cloud is what that looks like from the outside, and what Murmell is is the short version of the product. --- ## Agentes de IA en la nube: cómo programan y ejecutan pruebas en un repositorio remoto Source: https://murmell.com/es/what/cloud-ai-agent El bucle, en tres gestos Un agente lee el repositorio para orientarse, escribe un cambio, y luego ejecuta algo que le dice si acertó: una suite de pruebas, una compilación, un comando. Lee el resultado, corrige, vuelve a intentar. Ese bucle es lo que separa a un agente de un generador de texto: obtiene una respuesta del mundo entre dos intentos. Una máquina remota entra en juego porque ese bucle pide cosas que no quieres en tu portátil: instalar paquetes, llenar un disco, mantener un servidor encendido durante cuarenta minutos. Lo que cambia cuando la máquina no es la tuya El trabajo sobrevive a la pestaña. Lanzas una tarea, te vas a comer, el proceso continúa. En un portátil, cerrar la tapa lo detiene todo, y esa es la verdadera razón por la que la gente no se atreve a lanzar una tarea larga. El número deja de ser un problema. Un agente ocupa una máquina, no tu pantalla. Cinco agentes no piden cinco veces más atención, piden una manera de mirarlos. Y el entorno es reproducible. La máquina parte de una imagen conocida en cada proyecto, así que "en mi máquina funciona" deja de ser una frase. El problema que le llega al segundo agente Dos agentes en el mismo directorio escriben el mismo archivo con treinta segundos de diferencia, y el segundo borra al primero sin que nada señale el incidente. La salida habitual es darles a cada uno una copia del repositorio, lo que traslada el problema a la fusión. Murmell toma el otro camino. Un directorio compartido, y una reserva antes de escribir: un agente anuncia las rutas que va a tocar, el tablero se las da, y se las niega a todos los demás hasta que las libera. El mecanismo en detalle. Los agentes que lanza Murmell Claude Code, Codex, Kimi y OpenCode, cada uno en una ventana del canvas con una terminal real, conectados con tu cuenta o tu clave. Ningún token se revende: la factura cubre la máquina y la sala donde la gente mira. Claude Code en el navegador describe qué se ve en pantalla. --- ## Agentes de IA na nuvem: Desenvolvimento e testes autônomos em repositórios remotos Source: https://murmell.com/pt/what/cloud-ai-agent O ciclo, em três movimentos Um agente lê o repositório para se orientar, escreve uma modificação, e então executa algo que diz se ele acertou: uma suíte de testes, uma compilação, um comando. Ele lê o resultado, corrige, tenta de novo. Esse ciclo é o que separa um agente de um gerador de texto: ele recebe uma resposta do mundo real entre duas tentativas. Uma máquina remota entra em cena porque esse ciclo exige coisas que ninguém quer no próprio notebook: instalar pacotes, encher um disco, manter um servidor ligado por quarenta minutos. O que muda quando a máquina não é a sua O trabalho sobrevive à aba. Você inicia uma tarefa, sai para almoçar, o processo continua. Em um notebook, fechar a tampa para tudo, e essa é a verdadeira razão pela qual as pessoas não se arriscam a rodar uma tarefa longa. A quantidade deixa de ser um problema. Um agente ocupa uma máquina, não a sua tela. Cinco agentes não exigem cinco vezes mais atenção, exigem uma forma de observá-los. E o ambiente é reproduzível. A máquina parte de uma imagem conhecida a cada projeto, então "funciona na minha máquina" deixa de ser uma frase. O problema que acontece com o segundo agente Dois agentes no mesmo diretório escrevem o mesmo arquivo com trinta segundos de diferença, e o segundo apaga o primeiro sem que nada sinalize o incidente. A saída habitual é dar a cada um uma cópia do repositório, o que desloca o problema para a fusão. Murmell segue o outro caminho. Um diretório compartilhado, e uma reserva antes da escrita: um agente anuncia os caminhos que vai tocar, o painel os concede a ele, e os nega a todos os outros até que ele os libere. O mecanismo em detalhe. Os agentes que o Murmell inicia Claude Code, Codex, Kimi e OpenCode, cada um em uma janela do canvas com um terminal de verdade, autenticados com sua conta ou sua chave. Nenhum token é revendido: a fatura cobre a máquina e a sala onde as pessoas assistem. Claude Code no navegador descreve como isso aparece na tela. --- ## Agenti IA di codice nel cloud: Sviluppo autonomo e test su repository remoti Source: https://murmell.com/it/what/cloud-ai-agent Il ciclo, in tre mosse Un agente legge il repository per orientarsi, scrive una modifica, poi esegue qualcosa che gli dice se ha avuto ragione: una suite di test, una compilazione, un comando. Legge il risultato, corregge, ricomincia. Questo ciclo è ciò che separa un agente da un generatore di testo: ottiene un riscontro dal mondo tra un tentativo e l'altro. Una macchina remota entra in gioco perché questo ciclo richiede cose che non vuoi sul tuo portatile: installare pacchetti, riempire un disco, tenere un server acceso per quaranta minuti. Cosa cambia quando la macchina non è la tua Il lavoro sopravvive alla scheda. Lanci un compito, esci per pranzo, il processo continua. Su un portatile, chiudere il coperchio ferma tutto, ed è la vera ragione per cui la gente non osa lanciare un compito lungo. Il numero smette di essere un problema. Un agente occupa una macchina, non il tuo schermo. Cinque agenti non chiedono cinque volte più attenzione, chiedono un modo per guardarli. E l'ambiente è riproducibile. La macchina parte da un'immagine nota a ogni progetto, quindi "funziona sul mio computer" smette di essere una frase. Il problema che arriva al secondo agente Due agenti nella stessa cartella scrivono lo stesso file a trenta secondi di distanza, e il secondo cancella il primo senza che nulla segnali l'incidente. La scappatoia abituale è dare a ciascuno una copia del repository, il che sposta il problema sulla fusione. Murmell prende l'altra strada. Una cartella condivisa, e una prenotazione prima della scrittura: un agente annuncia i percorsi che toccherà, la bacheca glieli assegna, e li nega a tutti gli altri finché non li rilascia. Il meccanismo nel dettaglio. Gli agenti che Murmell lancia Claude Code, Codex, Kimi e OpenCode, ciascuno in una finestra del canvas con un vero terminale, collegati con il tuo account o la tua chiave. Nessun token viene rivenduto: la fattura copre la macchina e la stanza dove le persone guardano. Claude Code nel browser descrive cosa dà a schermo. --- ## Multiple AI agents on one repo Source: https://murmell.com/what/multiple-ai-agents-one-repo The agents run on a cloud machine in one project directory, not in a worktree each, so an agent reads what its peers wrote a minute ago rather than at merge time. What goes wrong without a board Give three agents the same checkout and they overwrite each other inside a minute. Last write wins, silently. It surfaces later as a test that broke for no visible reason, or as a function that came back from the dead after somebody deleted it. Nobody fixes this by asking the models to be careful. Two agents can both be careful and still collide, because neither of them can see what the other is holding. Claim, write, release An agent asks for the paths it needs. If nobody holds them, it gets them and writes. When it is done it releases them and the next agent waiting gets its turn. The rule lives on the server. It is not a line in a system prompt, so an agent that ignores it is refused rather than trusted. A write that collides anyway is snapshotted before it lands, and a watcher attributes every write back to whoever made it. The write that collides is caught at the board, not on disk. What two agents did with it We watched two agents work on our own runs, without telling them the board existed as anything other than a tool they could call. They called it 1.8 times per turn. Two writes out of two were covered by a claim. Twice, an agent refused to overwrite a file a peer was holding, and we had to insist before it would. Measured on our own two-agent runs. A small sample and our own observation, not a benchmark. The usual alternative The common answer is one worktree per agent and a merge at the end. It works, and no agent sees another’s work until the merge, so two of them can spend an hour writing the same helper twice and a third can build against an interface that changed underneath it. One directory removes that. The cost is that somebody has to arbitrate the writes, which is what the board is for. Who watches the agents Every window on the multi-agent canvas is a real terminal running Claude Code, Codex, or another CLI agent. Everyone on the link sees all of them live. Reservations show up as they are taken, so a person can see which agent is holding the file they were about to ask about. Read our step-by-step guide to running several agents, explore the technical mechanics of file reservations, or check multiplayer coding with AI agents for the collaboration model. --- ## AI agent file locking: Preventing multi-agent race conditions Source: https://murmell.com/what/ai-agent-file-locking The multi-agent collision problem When developers run multiple AI coding agents locally, each agent operates under the assumption that it is the sole author of the codebase. When two agents inspect the same source file, each generates changes based on that initial snapshot. Whichever agent writes last overwrites the other without generating a warning or Git conflict. This silent corruption breaks test suites and undoes hours of development work. Asking models to coordinate through prompts fails because models cannot observe real-time filesystem events. How server-enforced reservations work Murmell solves file contention through The Board, an authoritative reservation ledger built into the cloud workspace. Claim: An agent requests write permission for specific file paths before modifying them. Enforce: The server grants the claim if available, or signals the agent to wait or choose an alternative task. Release: Once changes are committed to disk, the lock is released for subsequent agents. Because enforcement lives on the server rather than in prompt text, rogue writes are blocked unconditionally. Read our technical breakdown of multiple AI agents on one repo. Collision snapshots as a safety net If an unexpected write bypasses the reservation layer, Murmell takes an instant filesystem snapshot before applying the change. Both versions are stored, allowing developers to inspect diffs rather than losing source code. Orchestrating agents on the canvas File locking makes parallel AI development practical. You can run Anthropic Claude Code and OpenAI Codex in the cloud simultaneously on the multi-agent canvas. Follow our guide on how to coordinate Claude Code and Codex to see the workflow in action. --- ## Cloud में Claude Code चलाना: बिना लोकल सेटअप, मल्टी-एजेंट और ब्राउज़र टर्मिनल Source: https://murmell.com/hi/what/run-claude-code-in-the-cloud शुरू करने से पहले क्या चाहिए एक रिपॉज़िटरी, भले ही खाली हो। किसी मॉडल प्रोवाइडर का अकाउंट, या एक API कुंजी। और एक दूरस्थ मशीन जो फ़ोल्डर होस्ट करे और कमांड चलाए। Murmell प्रोजेक्ट बनाते ही मशीन और एक निजी रिपॉज़िटरी बना देता है, इसलिए व्यवहार में बस मॉडल का अकाउंट जोड़ना बाकी रहता है। रिपॉज़िटरी की जड़ में एक इंस्ट्रक्शन फ़ाइल बहुत कुछ बदल देती है: प्रोजेक्ट कैसे चलाया जाता है, क्या नहीं तोड़ना चाहिए, टीम कैसे लिखती है। एजेंट इसे शुरू में पढ़ते हैं, और यह लगाए गए समय और मिलने वाली गुणवत्ता का सबसे अच्छा अनुपात है। एक घंटा कैसा दिखता है आप एक वाक्य में काम बताते हैं। एजेंट संबंधित फ़ाइलें पढ़ता है, लिखता है, टेस्ट चलाता है, गलती पढ़ता है, सुधारता है। आप हर कदम नहीं देखते: जब यह रुके तब टर्मिनल देखते हैं, और diff पढ़ते हैं। दूसरे एजेंट पर सवाल बंटवारे का बनता है। प्रोजेक्ट के दो कोनों पर काम करने वाले दो एजेंट साथ आगे बढ़ते हैं; एक ही फ़ाइल पर काम करने वाले दो एजेंट एक-दूसरे से टकराते हैं। Murmell पर, हर कोई लिखने से पहले अपने रास्ते आरक्षित करता है, इसलिए टकराव बाद में पता चलने की बजाय शुरू में ही मना कर दिया जाता है। इसकी कीमत, दो पंक्तियों में दो बिल मौजूद हैं और उन्हें अलग रखना बेहतर है। मॉडल के टोकन का भुगतान आपके प्रोवाइडर को, आपके अकाउंट से होता है। मशीन और कमरे का भुगतान होस्ट को होता है। Murmell टोकन नहीं बेचता, यानी आपकी Claude सब्सक्रिप्शन या OpenAI कुंजी वही रहती है जो आप इस्तेमाल करते हैं। आम गड़बड़ी रिपॉज़िटरी की तीन कॉपियों पर तीन एजेंट चलाना सबसे आसान रास्ता लगता है और उसी शाम भारी पड़ता है: तीन ब्रांच, तीन मर्ज, और ऐसे टकराव जो किसी ने नहीं देखे थे। लिखने के नियम के साथ एक फ़ोल्डर साझा करने में सिलाई का काम कम होता है। नियम कैसे काम करता है, और मशीन में क्या है। --- ## 클라우드에서 Claude Code 실행하기: 로컬 설치 없는 다중 에이전트 개발 Source: https://murmell.com/ko/what/run-claude-code-in-the-cloud 시작하기 전에 필요한 것 비어 있어도 되는 저장소 하나. 모델 제공자 계정이나 API 키. 그리고 디렉터리를 담고 명령을 실행할 원격 머신. Murmell은 프로젝트를 만들 때 머신과 비공개 저장소를 함께 만들어주므로, 실제로는 모델 계정만 연결하면 됩니다. 저장소 루트의 지침 파일은 많은 것을 바꿉니다. 프로젝트를 어떻게 실행하는지, 무엇을 망가뜨리면 안 되는지, 팀이 어떤 방식으로 쓰는지. 에이전트는 시작할 때 이를 읽으며, 투입 시간 대비 얻는 품질이 가장 높은 방법입니다. 한 시간이 어떤 모습인지 여러분은 작업을 한 문장으로 설명합니다. 에이전트는 관련 파일을 읽고, 쓰고, 테스트를 실행하고, 오류를 읽고, 고칩니다. 매 단계를 지켜보는 것이 아니라, 멈췄을 때 터미널을 보고 diff를 다시 읽습니다. 두 번째 에이전트부터는 질문이 분배 문제로 바뀝니다. 두 에이전트가 프로젝트의 두 구석에 있으면 나란히 진행되고, 같은 파일에 있으면 서로 부딪힙니다. Murmell에서는 각자 쓰기 전에 경로를 점유하므로, 충돌은 나중에 발견되는 대신 그 자리에서 거부됩니다. 비용, 두 줄로 두 개의 청구서가 존재하며 나누어 생각하는 편이 좋습니다. 모델 토큰은 여러분의 제공자에게, 여러분의 계정으로 지불됩니다. 머신과 방은 호스팅 업체에 지불됩니다. Murmell은 토큰을 되팔지 않으므로, 여러분의 Claude 구독이나 OpenAI 키는 계속 여러분이 쓰던 그대로입니다. 흔한 함정 저장소 복사본 세 개에 에이전트 세 개를 돌리는 것이 당연해 보이지만 그날 저녁 대가를 치릅니다. 브랜치 셋, 병합 셋, 그리고 아무도 예상하지 못한 충돌들. 쓰기 규칙이 있는 디렉터리를 공유하면 이어 붙이는 작업이 훨씬 줄어듭니다. 규칙이 작동하는 방식과 머신에 들어 있는 것. --- ## Claude Code dans le navigateur, sans rien installer Source: https://murmell.com/fr/quoi/claude-code-dans-le-navigateur Ce que vous voyez Une fenêtre sur un canvas, avec un terminal dedans. Le curseur clignote, les commandes s'écrivent, la sortie défile. Ce n'est pas une reconstitution de terminal : c'est un vrai pseudo-terminal sur la machine, transporté jusqu'à l'onglet. Les touches que vous connaissez fonctionnent. Interrompre, remonter dans l'historique, coller un bloc, tout se comporte comme sur votre portable, parce que c'est le même programme. Ce qui change par rapport à votre machine Le disque n'est pas le vôtre. Les dépendances s'installent sur la machine du projet, ce qui laisse votre portable propre et rend l'environnement identique pour tous ceux qui ouvrent le canvas. Et vous pouvez en ouvrir un deuxième. Une deuxième fenêtre, un deuxième agent, sur le même dossier. Le tableau de réservations se charge d'éviter qu'ils s'écrasent : un seul détenteur par fichier. Qui peut regarder Un lien suffit pour qu'un collègue voie le même terminal défiler, avec son curseur nommé sur le canvas. Regarder ne demande pas de compte et ne coûte rien. C'est la différence entre montrer un diff après coup et laisser quelqu'un assister au travail. Les autres agents Codex, Kimi et OpenCode s'ouvrent de la même façon, dans leur propre fenêtre, sur leurs propres identifiants. Rien dans le canvas ne change selon l'agent : une fenêtre est une fenêtre. Murmell face à Claude Code seul compare les deux situations directement. --- ## Claude Code en el navegador, sin instalar nada Source: https://murmell.com/es/what/claude-code-in-the-browser Lo que ves Una ventana en un canvas, con una terminal dentro. El cursor parpadea, los comandos se escriben, la salida corre. No es una reconstrucción de terminal: es un pseudo terminal real en la máquina, transportado hasta la pestaña. Las teclas que conoces funcionan. Interrumpir, subir por el historial, pegar un bloque, todo se comporta como en tu portátil, porque es el mismo programa. Lo que cambia respecto a tu máquina El disco no es el tuyo. Las dependencias se instalan en la máquina del proyecto, lo que deja tu portátil limpio y hace el entorno idéntico para todos los que abren el canvas. Y puedes abrir una segunda. Una segunda ventana, un segundo agente, en el mismo directorio. El tablero de reservas se encarga de que no se pisen: un único titular por archivo. Quién puede mirar Un enlace basta para que un compañero vea la misma terminal correr, con su cursor con nombre en el canvas. Mirar no pide cuenta y no cuesta nada. Esa es la diferencia entre mostrar un diff después y dejar que alguien presencie el trabajo. Los otros agentes Codex, Kimi y OpenCode se abren de la misma forma, en su propia ventana, con sus propias credenciales. Nada en el canvas cambia según el agente: una ventana es una ventana. Murmell frente a Claude Code solo compara las dos situaciones directamente. --- ## Claude Code im Browser, ohne etwas zu installieren Source: https://murmell.com/de/what/claude-code-in-the-browser Was Sie sehen Ein Fenster auf einer Canvas, mit einem Terminal darin. Der Cursor blinkt, die Befehle schreiben sich, die Ausgabe läuft durch. Das ist keine Nachbildung eines Terminals: Es ist ein echtes Pseudoterminal auf der Maschine, bis in den Tab transportiert. Die Tasten, die Sie kennen, funktionieren. Unterbrechen, im Verlauf zurückgehen, einen Block einfügen, alles verhält sich wie auf Ihrem Laptop, weil es dasselbe Programm ist. Was sich gegenüber Ihrer Maschine ändert Die Festplatte ist nicht Ihre. Die Abhängigkeiten werden auf der Maschine des Projekts installiert, was Ihren Laptop sauber lässt und die Umgebung für alle identisch macht, die die Canvas öffnen. Und Sie können ein zweites öffnen. Ein zweites Fenster, ein zweiter Agent, im selben Verzeichnis. Das Reservierungsboard sorgt dafür, dass sie sich nicht überschreiben: ein einziger Inhaber pro Datei. Wer zusehen kann Ein Link reicht, damit ein Kollege dasselbe Terminal durchlaufen sieht, mit seinem benannten Cursor auf der Canvas. Zusehen erfordert kein Konto und kostet nichts. Das ist der Unterschied zwischen einem Diff im Nachhinein zeigen und jemanden bei der Arbeit dabei sein lassen. Die anderen Agenten Codex, Kimi und OpenCode öffnen sich auf dieselbe Weise, in ihrem eigenen Fenster, mit ihren eigenen Zugangsdaten. Nichts an der Canvas ändert sich je nach Agent: Ein Fenster ist ein Fenster. Murmell gegenüber Claude Code allein vergleicht die beiden Situationen direkt. --- ## Claude Code nel browser, senza installare nulla Source: https://murmell.com/it/what/claude-code-in-the-browser Cosa vedi Una finestra su un canvas, con un terminale dentro. Il cursore lampeggia, i comandi si scrivono, l'output scorre. Non è una ricostruzione di terminale: è un vero pseudo-terminale sulla macchina, trasportato fino alla scheda. I tasti che conosci funzionano. Interrompere, risalire nella cronologia, incollare un blocco, tutto si comporta come sul tuo portatile, perché è lo stesso programma. Cosa cambia rispetto alla tua macchina Il disco non è il tuo. Le dipendenze si installano sulla macchina del progetto, il che lascia il tuo portatile pulito e rende l'ambiente identico per chiunque apra il canvas. E puoi aprirne un secondo. Una seconda finestra, un secondo agente, sulla stessa cartella. La bacheca di prenotazione si occupa di evitare che si sovrascrivano: un solo titolare per file. Chi può guardare Un link basta perché un collega veda lo stesso terminale scorrere, con il suo cursore con nome sul canvas. Guardare non richiede un account e non costa nulla. È la differenza tra mostrare un diff dopo e lasciare che qualcuno assista al lavoro. Gli altri agenti Codex, Kimi e OpenCode si aprono allo stesso modo, nella propria finestra, con le proprie credenziali. Nulla nel canvas cambia in base all'agente: una finestra è una finestra. Murmell contro Claude Code da solo confronta le due situazioni direttamente. --- ## Claude Code no navegador, sem instalar nada Source: https://murmell.com/pt/what/claude-code-in-the-browser O que você vê Uma janela no canvas, com um terminal dentro. O cursor pisca, os comandos são digitados, a saída rola. Não é uma reconstituição de terminal: é um pseudo-terminal de verdade na máquina, transportado até a aba. As teclas que você conhece funcionam. Interromper, navegar pelo histórico, colar um bloco, tudo se comporta como no seu notebook, porque é o mesmo programa. O que muda em relação à sua máquina O disco não é o seu. As dependências se instalam na máquina do projeto, o que mantém seu notebook limpo e deixa o ambiente idêntico para todos que abrem o canvas. E você pode abrir um segundo. Uma segunda janela, um segundo agente, no mesmo diretório. O painel de reservas cuida de evitar que eles se sobrescrevam: um único titular por arquivo. Quem pode assistir Um link é suficiente para que um colega veja o mesmo terminal rolando, com o cursor dele nomeado no canvas. Assistir não exige conta e não custa nada. Essa é a diferença entre mostrar um diff depois e deixar alguém acompanhar o trabalho. Os outros agentes Codex, Kimi e OpenCode abrem da mesma forma, em sua própria janela, com suas próprias credenciais. Nada no canvas muda de acordo com o agente: uma janela é uma janela. Murmell frente ao Claude Code sozinho compara as duas situações diretamente. --- ## Claude Code в браузере, без установки Source: https://murmell.com/ru/what/claude-code-in-the-browser Что вы видите Окно на канвасе, а в нём терминал. Курсор мигает, команды печатаются, вывод идёт. Это не имитация терминала: это настоящий псевдотерминал на машине, перенесённый во вкладку. Знакомые сочетания клавиш работают. Прерывание, прокрутка истории, вставка блока текста, всё ведёт себя так же, как на вашем ноутбуке, потому что это та же самая программа. Что меняется по сравнению с вашей машиной Диск не ваш. Зависимости устанавливаются на машине проекта, поэтому ваш ноутбук остаётся чистым, а окружение одинаковое для всех, кто открывает канвас. И вы можете открыть второй. Второе окно, второй агент, в том же каталоге. Доска резервирований следит, чтобы они не перезаписывали друг друга: у файла только один владелец. Кто может смотреть Одной ссылки достаточно, чтобы коллега увидел тот же терминал в реальном времени, со своим именованным курсором на канвасе. Смотреть не требует аккаунта и ничего не стоит. Это разница между показом diff после и наблюдением за работой во время. Другие агенты Codex, Kimi и OpenCode открываются так же, каждый в своём окне, со своими учётными данными. В канвасе ничего не меняется в зависимости от агента: окно есть окно. Murmell против одиночного Claude Code сравнивает эти две ситуации напрямую. --- ## बिना कुछ इंस्टॉल किए ब्राउज़र में Claude Code Source: https://murmell.com/hi/what/claude-code-in-the-browser आप क्या देखते हैं कैनवस पर एक विंडो, उसके अंदर एक टर्मिनल। कर्सर झपकता है, कमांड लिखे जाते हैं, आउटपुट चलता रहता है। यह किसी टर्मिनल की नकल नहीं है: यह मशीन का असली pseudo-terminal है, जो टैब तक पहुंचाया गया है। आपकी जानी-पहचानी keys काम करती हैं। रुकावट डालना, history में जाना, कोई ब्लॉक पेस्ट करना, सब आपके लैपटॉप जैसा ही व्यवहार करता है, क्योंकि यह वही प्रोग्राम है। आपकी मशीन के मुकाबले क्या बदलता है डिस्क आपकी नहीं है। डिपेंडेंसी प्रोजेक्ट की मशीन पर इंस्टॉल होती हैं, जिससे आपका लैपटॉप साफ़ रहता है और कैनवस खोलने वाले हर किसी के लिए वातावरण एक जैसा रहता है। और आप दूसरा भी खोल सकते हैं। दूसरी विंडो, दूसरा एजेंट, उसी फ़ोल्डर में। आरक्षण का बोर्ड उन्हें एक-दूसरे को मिटाने से बचाता है: एक फ़ाइल का एक ही मालिक। कौन देख सकता है एक लिंक काफ़ी है ताकि कोई साथी वही टर्मिनल लाइव चलता देखे, कैनवस पर उसका नाम वाला कर्सर भी। देखने के लिए अकाउंट नहीं चाहिए और यह मुफ़्त है। बाद में diff दिखाने और किसी को काम होते हुए देखने देने में यही असली फ़र्क़ है। बाकी एजेंट Codex, Kimi और OpenCode भी इसी तरह खुलते हैं, अपनी विंडो में, अपनी पहचान के साथ। कैनवस में एजेंट के हिसाब से कुछ नहीं बदलता: एक विंडो बस एक विंडो है। अकेले Claude Code के सामने Murmell दोनों स्थितियों की सीधी तुलना करता है। --- ## Cloud AI for developers: models, APIs and remote coding agents Source: https://murmell.com/what/cloud-ai Three things under one phrase The oldest sense is a hosted model. You download nothing, you send a question, an answer comes back. That is what an assistant in a tab does. The second is the one engineering teams mean: an API. The model becomes a part in software you write, billed per token. The machine stays at the provider, the logic stays with you. The third is newer, and it is the one that changes the day of somebody writing code. An agent runs on a remote machine with a file system, a terminal and network access. It installs dependencies, runs the tests, reads the errors and tries again. You do not talk to it at every step. You give it a goal. What actually separates the third one An AI that answers stops when you close the tab, because it had nothing to do between two questions. An agent on a remote machine carries on: the process lives on the machine, not in the browser. It is the only one of the three where shutting the laptop costs nothing. The consequence is arithmetic. If one agent fits on one machine, two fit on two, and five on five. Work stops being capped by the number of terminals in front of you. Where it breaks when there is more than one Most tools answer by isolating: one agent, one machine, one branch, one merge at the end. That holds until two agents have changed the same file, and nobody knew until both had finished. The other road is sharing with a rule. Agents live in one directory, and an agent claims a path before it writes to it. One holder per file, enforced by the server rather than politely asked of the model. That is the shape Murmell chose. What to ask before you pick one Who owns the machine, and what else is on it. How long it lives, and what survives it. What you pay for: the machine, the model tokens, or both. And whether the agent subscription you already have is reusable or has to be bought again. On that last one the answer here is short: you connect the accounts you already pay for, and the bill covers the machine and the room. See what the canvas is. --- ## Cloud AI coding agents: how remote agents work on a repository Source: https://murmell.com/what/cloud-ai-agent The loop, in three moves An agent reads the repository to find its bearings, writes a change, then runs something that tells it whether it was right: a test suite, a build, a command. It reads the result, fixes, tries again. That loop is what separates an agent from a text generator: it gets an answer from the world between two attempts. A remote machine enters the picture because that loop wants things you do not want on your laptop: installing packages, filling a disk, keeping a server up for forty minutes. What changes when the machine is not yours The work outlives the tab. You start a task, you go to lunch, the process carries on. On a laptop, closing the lid ends it, which is the real reason people do not start long tasks. Number stops being a problem. An agent occupies a machine, not your screen. Five agents do not want five times the attention, they want a way of watching them. And the environment repeats. The machine starts from a known image on every project, so "works on my machine" stops being a sentence anybody says. The problem that arrives with the second agent Two agents in one directory write the same file thirty seconds apart, and the second erases the first with nothing to show for it. The usual escape is to give each one a copy of the repository, which moves the problem to the merge. Murmell takes the other road. One shared directory, and a claim before the write: an agent announces the paths it is about to touch, the board hands them over, and refuses everybody else until it lets go. The mechanism in full. The agents Murmell launches Claude Code, Codex, Kimi and OpenCode, each in a window on the canvas with a real terminal, signed in with your own account or key. No tokens are resold: the bill covers the machine and the room where people watch. Claude Code in a browser tab shows what that looks like on screen. --- ## Cloud-KI für Entwickler: Gehostete Modelle, APIs und Remote-Coding-Agenten Source: https://murmell.com/de/what/cloud-ai Drei Dinge unter einem Wort Die erste Bedeutung ist die älteste: ein Modell, das anderswo gehostet wird. Sie laden nichts herunter, Sie senden eine Frage und erhalten eine Antwort. Das macht ein Assistent in einem Tab. Die zweite ist die Bedeutung technischer Teams: eine API. Das Modell wird zu einem Baustein in Software, die Sie schreiben, abgerechnet pro Token. Die Maschine bleibt beim Anbieter, die Logik bleibt bei Ihnen. Die dritte ist neuer und diejenige, die den Alltag von jemandem verändert, der Code schreibt. Ein Agent läuft auf einer entfernten Maschine, mit einem Dateisystem, einem Terminal, Netzwerkzugang. Er installiert Abhängigkeiten, führt Tests aus, liest Fehler, beginnt von vorn. Sie sprechen nicht bei jedem Schritt mit ihm, Sie geben ihm ein Ziel. Das Wort daneben: agentisch „Agentische KI" bezeichnet die dritte Bedeutung, betrachtet vom Programm statt von der Maschine aus: eine KI, die ein Ziel verfolgt, ihre Aktionen wählt und allein iteriert, bis die Tests bestehen. Die beiden Begriffe überschneiden sich in der Praxis fast immer, weil ein Programm, das vierzig Minuten lang allein arbeitet, eine Maschine braucht, die eingeschaltet bleibt. Was die dritte Bedeutung wirklich unterscheidet Eine antwortende KI stoppt, wenn Sie den Tab schließen, weil sie zwischen zwei Fragen nichts zu tun hatte. Ein Agent auf einer entfernten Maschine macht weiter: Der Prozess lebt auf der Maschine, nicht im Browser. Es ist die einzige der drei Bedeutungen, bei der den Rechner zu schließen nichts kostet. Die Folge ist arithmetisch. Wenn ein Agent allein auf einer Maschine läuft, laufen zwei Agenten auf zwei Maschinen, und fünf auf fünf. Die Arbeit ist nicht mehr durch die Zahl der vor Ihnen geöffneten Terminals begrenzt. Wo es klemmt, wenn sie mehrere sind Die meisten Werkzeuge lösen die Frage durch Isolierung: ein Agent, eine Maschine, ein Branch, und am Ende eine Zusammenführung. Das funktioniert, bis zwei Agenten dieselbe Datei geändert haben, und niemand hat es gewusst, bevor beide fertig waren. Der andere Weg ist Teilen mit einer Regel. Die Agenten leben im selben Verzeichnis, und ein Agent beansprucht einen Pfad, bevor er hineinschreibt. Ein einziger Inhaber pro Datei, durchgesetzt vom Server statt höflich beim Modell angefragt. Das ist die Form, die Murmell gewählt hat. Die Fragen, die man vor der Wahl stellen sollte Wem gehört die Maschine, und was enthält sie außer Ihrem Code. Wie lange lebt sie, und was bleibt, wenn sie zerstört wird. Was Sie bezahlen: die Maschine, die Tokens des Modells, oder beides. Und ob Ihr bestehendes Abo für einen Agenten wiederverwendbar ist oder ob Sie eines neu kaufen müssen. Zu diesem letzten Punkt ist die Antwort von Murmell kurz: Sie verbinden die Konten, die Sie bereits bezahlen, und die Rechnung deckt die Maschine und den Raum. Sehen, was die Canvas macht. --- ## Cloud-KI-Coding-Agenten: Autonome Code-Entwicklung und Tests auf Remote-Repositories Source: https://murmell.com/de/what/cloud-ai-agent Die Schleife, in drei Schritten Ein Agent liest das Repository, um sich zurechtzufinden, schreibt eine Änderung, und führt dann etwas aus, das ihm sagt, ob er richtiglag: eine Testsuite, eine Kompilierung, ein Befehl. Er liest das Ergebnis, korrigiert, beginnt von vorn. Diese Schleife trennt einen Agenten von einem Textgenerator: Er erhält zwischen zwei Versuchen eine Rückmeldung aus der Welt. Eine entfernte Maschine kommt ins Spiel, weil diese Schleife Dinge braucht, die man nicht auf dem eigenen Laptop will: Pakete installieren, die Festplatte füllen, einen Server vierzig Minuten lang eingeschaltet halten. Was sich ändert, wenn die Maschine nicht Ihre ist Die Arbeit überlebt den Tab. Sie starten eine Aufgabe, gehen Mittagessen, der Prozess läuft weiter. Auf einem Laptop stoppt das Zuklappen alles, und das ist der eigentliche Grund, warum sich die Leute nicht trauen, eine lange Aufgabe zu starten. Die Anzahl hört auf, ein Problem zu sein. Ein Agent belegt eine Maschine, nicht Ihren Bildschirm. Fünf Agenten verlangen nicht fünfmal so viel Aufmerksamkeit, sie verlangen eine Art, sie anzusehen. Und die Umgebung ist reproduzierbar. Die Maschine startet bei jedem Projekt von einem bekannten Image aus, also hört „bei mir läuft es" auf, ein Satz zu sein. Das Problem, das den zweiten Agenten trifft Zwei Agenten im selben Verzeichnis schreiben dieselbe Datei mit dreißig Sekunden Abstand, und der zweite löscht den ersten, ohne dass etwas den Vorfall meldet. Der übliche Ausweg ist, jedem eine Kopie des Repositorys zu geben, was das Problem zur Zusammenführung verschiebt. Murmell geht den anderen Weg. Ein geteiltes Verzeichnis, und eine Reservierung vor dem Schreiben: Ein Agent kündigt die Pfade an, die er anfassen wird, das Board gibt sie ihm, und verweigert sie allen anderen, bis er sie freigibt. Der Mechanismus im Detail. Die Agenten, die Murmell startet Claude Code, Codex, Kimi und OpenCode, jeder in einem Fenster der Canvas mit einem echten Terminal, angemeldet mit Ihrem Konto oder Schlüssel. Kein Token wird weiterverkauft: Die Rechnung deckt die Maschine und den Raum, in dem die Leute zusehen. Claude Code im Browser beschreibt, was das auf dem Bildschirm ergibt. --- ## Coder à plusieurs avec des agents IA Source: https://murmell.com/fr/quoi/coder-a-plusieurs-avec-des-agents-ia C’est une seule URL. Personne n’installe rien, personne ne prend de copie, et personne n’a besoin de partager son écran pour que les autres voient le travail se faire. Ce qu’un invité voit Vous envoyez un lien. La personne qui l’ouvre obtient le canvas tel qu’il est, pas un enregistrement. Elle voit les fenêtres là où elles se trouvent et la sortie du terminal arriver ligne par ligne. Elle voit les autres curseurs bouger avec un nom sur chacun, et quelle fenêtre chaque personne regarde. Les liens de lecture sont gratuits et sans limite de nombre. Les liens qui permettent de piloter un agent sont plafonnés par votre forfait, ce qui est la forme honnête des choses : regarder ne nous coûte presque rien, et une machine coûte ce qu’elle coûte. Ce que chaque personne peut faire Chaque personne pilote ses propres agents, et tout le monde les voit tous. C’est une forme différente de deux mains sur un même objet : la chose partagée est le canvas et le dossier en dessous, pas un clavier unique. C’est suffisant pour ce que les gens font réellement ensemble, à savoir décider de ce que les agents doivent faire. Vous observez une exécution partir dans la mauvaise direction, vous le dites, et la personne qui tient cette fenêtre la réoriente pendant que tout le monde voit la correction s’appliquer. Figma pour les développeurs reprend cet argument face à un outil que vous connaissez déjà. Les agents sont les autres joueurs Plusieurs agents dans une même copie de travail est la partie qui demande de l’ingénierie. Un agent réserve les chemins qu’il s’apprête à modifier, le tableau enregistre un seul détenteur par chemin, et tous les autres sont refusés jusqu’à ce que le détenteur le libère. Le refus vient de notre serveur, ce n’est donc pas quelque chose qu’un modèle peut ignorer. Plusieurs agents IA sur un dépôt détaille le mécanisme et les mesures de nos propres exécutions. Partir n’arrête rien Fermer un onglet ne tue pas les agents. Ils appartiennent au canvas plutôt qu’à votre navigateur, de sorte que le travail continue et que la sortie arrivée pendant votre absence est là quand vous revenez. Le code ne reste pas non plus uniquement sur cette machine. Chaque projet dispose d’un dépôt privé, le travail y est poussé au fur et à mesure, et une machine sur le point d’être éteinte effectue une dernière sauvegarde d’abord. Qu’est-ce que Murmell couvre le reste en une seule page, et la page d’accueil dessine la pièce. --- ## Coder avec l'IA dans le cloud, en pratique Source: https://murmell.com/fr/quoi/coder-avec-lia-dans-le-cloud Ce qu'il faut avant de commencer Un dépôt, même vide. Un compte chez un fournisseur de modèle, ou une clé d'API. Et une machine distante qui héberge le dossier et exécute les commandes. Murmell crée la machine et un dépôt privé quand vous créez le projet, donc en pratique il reste le compte du modèle à brancher. Un fichier d'instructions à la racine du dépôt change beaucoup de choses : comment on lance le projet, ce qu'il ne faut pas casser, la façon dont l'équipe écrit. Les agents le lisent au démarrage, et c'est le meilleur rapport entre le temps passé et la qualité obtenue. À quoi ressemble une heure Vous décrivez une tâche en une phrase. L'agent lit les fichiers concernés, écrit, lance les tests, lit l'erreur, corrige. Vous ne regardez pas chaque étape : vous regardez le terminal quand il s'arrête, et vous relisez le diff. Au deuxième agent, la question devient la répartition. Deux agents sur deux coins du projet avancent en parallèle ; deux agents sur le même fichier se marchent dessus. Sur Murmell, chacun réserve ses chemins avant d'écrire, donc la collision est refusée au lieu d'être découverte plus tard. Ce que ça coûte, en deux lignes Deux factures existent et il vaut mieux les séparer. Les jetons du modèle sont payés à votre fournisseur, sur votre compte. La machine et la salle sont payées à l'hébergeur. Murmell ne revend pas de jetons, ce qui veut dire que votre abonnement Claude ou votre clé OpenAI reste celui que vous utilisez. Le piège habituel Lancer trois agents sur trois copies du dépôt paraît la voie évidente et coûte le soir même : trois branches, trois fusions, et des conflits que personne n'a vus venir. Partager un dossier avec une règle d'écriture donne moins de travail de couture. Comment la règle fonctionne, et ce que contient la machine. --- ## Programmazione multiplayer con agenti IA Source: https://murmell.com/it/what/multiplayer-coding-with-ai-agents È un unico URL. Nessuno installa nulla, nessuno crea copie locali e nessuno deve condividere lo schermo affinché gli altri vedano il lavoro procedere. Cosa vede un ospite Invii un link. Chi lo apre vede il canvas in tempo reale, non una registrazione. Vede le finestre dove si trovano e l’output del terminale riga per riga. Vede gli altri cursori muoversi con i rispettivi nomi e quale finestra ciascuno stia seguendo. I link di sola lettura sono gratuiti e senza limiti. I link che permettono di pilotare un agente dipendono dal piano sottoscritto: osservare non costa quasi nulla, mentre una macchina ha il proprio costo. Cosa può fare ogni persona Ogni persona controlla i propri agenti e tutti vedono tutti. È diverso da due mani su una stessa tastiera: ciò che viene condiviso sono il canvas e la directory sottostante, non una singola tastiera. Questo è sufficiente per ciò che le persone fanno realmente insieme: decidere cosa debbano fare gli agenti. Se noti che un’esecuzione sta deviando, lo segnali e chi gestisce quella finestra la reindirizza mentre tutti vedono la correzione applicarsi. Figma per sviluppatori illustra lo stesso concetto con uno strumento noto. Gli agenti sono gli altri partecipanti Avere più agenti in una stessa directory richiede un’architettura dedicata. Un agente riserva i percorsi che sta per modificare, il tabellone registra un unico titolare per percorso e tutti gli altri vengono rifiutati fino al rilascio. Il rifiuto proviene dal server, non da un suggerimento in un prompt. Più agenti IA su un repository illustra il meccanismo e le misurazioni dei nostri test. Uscire non interrompe l’esecuzione Chiudere una scheda non arresta gli agenti. Appartengono al canvas e non al browser, quindi il lavoro continua e la cronologia generata resta disponibile al rientro. Il codice non rimane confinato a quella macchina. Ogni progetto dispone di un repository privato, il lavoro viene sincronizzato continuamente e una macchina in fase di spegnimento esegue un ultimo push prima di chiudere. Cos’è Murmell sintetizza il resto in un’unica pagina e la home page illustra la sala. --- ## KI-Coding-Agenten im Vergleich: Claude Code, Cursor, Devin und 10 weitere Tools Source: https://murmell.com/de/what/best-ai-coding-agents Die Frage, die alles ordnet All diese Werkzeuge können einen Agenten starten. Der erste ist einfach: Er liest, er schreibt, er führt Tests aus. Beim zweiten weichen die Konzepte auseinander, weil man entscheiden muss, was er sieht und was er anfassen darf. Die Tabelle unten ordnet nichts: Sie sagt, für wen jedes Werkzeug passt, eine Zeile pro Werkzeug, und die Gruppen darunter erklären warum. Welches nehmen, je eine Zeile WerkzeugDie richtige Wahl, wenn CursorSie schreiben den Code selbst und wollen die beste Tastatur. DevinSie übergeben ein ganzes Ticket und kehren zu einem Ergebnis zurück. JulesSie wollen einen Plan freigeben, bevor der Agent irgendetwas anfasst. Copilot und Agent HQIhre Arbeit ist bereits in Tickets geordnet, und die Durchsicht ist der Termin. Codex CloudSie haben ein OpenAI-Konto und klar umrissene Aufgaben zu delegieren. Replit AgentSie starten bei null und wollen noch heute Abend eine Anwendung online. WindsurfSie bearbeiten von Hand und wollen parallele Läufe auf Ihrer Festplatte. ConductorSie arbeiten allein auf einem Mac, und der Code darf nicht raus. OpenHands Agent CanvasDer Code muss auf Hardware bleiben, die Sie kontrollieren, und Sie wollen die Quelle. Vibe KanbanSie haben eine Warteschlange von Aufgaben, die auf Ihrem Rechner nacheinander laufen sollen. CodegDie Agenten laufen bereits bei Ihnen, und es fehlt ein Überblick. Gemini Code AssistSie wollen einen guten Agenten in dem Editor, den Sie bereits haben, ohne zu zahlen. Claude Code im WebSie nutzen das CLI bereits, und die einzige Frage ist, wo es läuft. MurmellMehrere Agenten müssen dieselben Dateien anfassen, und Leute sehen zu. Die Tabelle von der Vergleichsseite stellt die andere Frage, die danach, wohin der zweite Agent geht. Eine Cloud-Maschine pro Aufgabe Der Agent erhält einen Klon Ihres Repositorys auf einer Maschine, die Sie nicht sehen, arbeitet auf einem Branch und liefert eine Pull-Request. Das ist die verbreitetste Form, und die, die am wenigsten Vertrauen verlangt: Nichts, was er tut, berührt Ihre Kopie, bevor Sie den Diff gelesen haben. Cursor. Ein Editor pro Person und eine Maschine pro Agent, gegen eine Canvas und ein Verzeichnis für alle. Devin. Parallelität durch Trennung gegen Parallelität durch Teilen, und wann welche Form die richtige ist. Jules. Ein Plan, den Sie freigeben, und eine Pull-Request, die Sie durchsehen, gegen Terminals, die Sie in einem einzigen Baum ansehen. Copilot und Agent HQ. Wo die Arbeit der Agenten zusammenläuft: bei der Pull-Request, oder in der Arbeitskopie. Codex Cloud. Warum das Codex-CLI auf einer geteilten Canvas zu starten nicht dasselbe ist wie ihm eine Aufgabe zu delegieren. Replit Agent. Eine Anwendung aus dem Nichts bauen, gegen mehrere Agenten an bestehendem Code arbeiten lassen. Ein Arbeitsbereich pro Aufgabe, auf Ihrer Maschine Dieselbe Wahl, bei Ihnen: ein Git-Worktree oder ein Arbeitsverzeichnis pro Agent, und eine Zusammenführung am Ende. Der Code verlässt das Haus nicht, was die Sicherheitsfrage klärt, bevor sie gestellt wird, und niemand sonst sieht die Sitzung. Windsurf. Ein Worktree pro Konversation auf Ihrer Maschine, gegen ein geteiltes Verzeichnis in der Cloud. Conductor. Eine Mac-App mit einem Bereich pro Aufgabe, gegen eine Cloud-Canvas mit einem einzigen Verzeichnis für alle. OpenHands Agent Canvas. Der Vergleich, der der Liste am nächsten kommt: ein Worktree pro Agent gegen einen einzigen Baum mit Dateireservierungen. Vibe Kanban. Ein Kanban-Board über lokalen Läufen, gegen eine geteilte Canvas über einem Cloud-Verzeichnis. Codeg. Lokale Sitzungen sammeln, gegen Agenten auf einem geteilten Cloud-Verzeichnis laufen lassen. Ein Agent nach dem anderen, in Ihrem Editor Keine dokumentierte Parallelität: ein Agent, überwacht, in dem Werkzeug, in dem Sie schreiben. Das ist der beste Kompromiss, wenn Sie selbst die Tastatur halten und der Agent Sie unterstützt. Gemini Code Assist. Ein überwachter Agent in Ihrem Editor, gegen mehrere unüberwachte Agenten in einem Verzeichnis, das Sie ansehen. Derselbe Agent, anderswo Das CLI ist auf beiden Seiten identisch. Was sich ändert, ist die Maschine, auf der es läuft, und die Anzahl der Personen, die zusehen können. Claude Code im Web. Dasselbe CLI an zwei Orten: eine isolierte Maschine pro Sitzung, gegen mehrere Agenten auf einer Canvas und eine einzige Arbeitskopie. Das geteilte Verzeichnis, und warum es fast niemand tut In der Tabelle fehlt eine vierte Antwort, und das ist unsere: mehrere Agenten in einem einzigen Verzeichnis, ohne Kopie. Fast niemand bietet das an, weil es einen Schiedsrichter braucht. Ohne Schiedsrichter lesen zwei Agenten dieselbe Version einer Datei, und der zweite löscht den ersten, ohne dass etwas es meldet. Murmell setzt diesen Schiedsrichter in den Server. Ein Agent kündigt die Pfade an, die er anfassen wird, bevor er schreibt, das Board weist sie ihm zu, und verweigert sie allen anderen, bis er sie freigibt. Eine Schreibaktion, die trotzdem auf eine von jemand anderem gehaltene Datei ankommt, wird fotografiert, bevor sie landet. Der Mechanismus im Detail. Wie man in zwei Minuten wählt Wenn Sie den Code selbst schreiben, nehmen Sie einen Editor: Cursor, Windsurf oder Gemini Code Assist, und die Frage ist geklärt. Wenn Ihre Aufgaben unabhängig sind und Sie sie delegieren wollen, nehmen Sie einen Cloud-Agenten: Devin, Jules oder Codex Cloud. Wenn der Code Ihr Netzwerk nicht verlassen darf, nehmen Sie etwas Lokales und selbst Hostbares, allen voran OpenHands. Es bleibt ein Fall, und es ist der einzige, den Murmell behandelt: mehrere Agenten, die dieselben Dateien innerhalb derselben Stunde anfassen müssen, mit Leuten, die zusehen. Die Vergleiche, einzeln. --- ## Die Cloud-Maschine, auf der die Agenten laufen Source: https://murmell.com/de/what/cloud-sandbox-for-ai-agents Warum eine Sandbox Man sagt auch Sandbox, und das ist das Wort, das die meisten Dokumentationen verwenden. Ein nützlicher Agent führt Befehle aus, die er selbst geschrieben hat. Ein Paket installieren, ein Skript starten, einen Port öffnen. Keine menschliche Prüfung geht jedem dieser Befehle voraus, was heißt, dass der einzige ernsthafte Schutz der Ort ist, an dem sie ausgeführt werden. Daher die Regel: Die Maschine, die den Code ausführt, hat nichts Interessantes darauf. Keine Datenbank, kein Entschlüsselungsschlüssel, keine Zugangsdaten eines anderen Kunden. Ein Vorfall auf dieser Maschine kostet die Maschine. Was sie enthält Das Verzeichnis des Projekts, die CLIs der Agenten, und was die Agenten zum Arbeiten installieren. Die Zugangsdaten, die Sie verbinden, dienen den Agenten während der Sitzung und verlassen diesen Bereich nicht. Die Canvas, der Raum und das Reservierungsboard leben woanders. Ein Agent, der irgendetwas auf seine Festplatte schriebe, könnte nicht entscheiden, wer eine Datei hält: Die Schiedsrichterrolle liegt nicht auf der Maschine, die er kontrolliert. Eine Maschine pro Projekt Die Isolierung zwischen Projekten ist keine Einstellung, sie ist die Form des Produkts. Jede Canvas startet ihre Maschine, und zwei Projekte teilen sich nie ein Dateisystem. Das macht auch die Umgebung reproduzierbar: Das Projekt startet jedes Mal von einem bekannten Image aus. Und der Code, am Ende Ein privates Repository wird mit dem Projekt angelegt, und die Arbeit wird im Laufe der Sitzung dorthin gepusht, mit einer letzten Übertragung vor der Zerstörung der Maschine. Was Sie behalten, ist ein normales Repository, bei Ihnen, lesbar ohne Murmell. Der Ablauf einer Sitzung. --- ## Comparativa de agentes de IA para programar: Claude Code, Cursor, Devin y más Source: https://murmell.com/es/what/best-ai-coding-agents La pregunta que lo ordena todo Todas estas herramientas saben lanzar un agente. El primero es fácil: lee, escribe, lanza las pruebas. Es con el segundo donde los diseños divergen, porque hay que decidir qué ve y qué tiene derecho a tocar. La tabla de abajo no clasifica nada: dice a quién le sirve cada herramienta, una línea por herramienta, y los grupos de debajo explican por qué. Cuál elegir, en una línea cada uno HerramientaLa elección correcta cuando CursorEscribes el código tú mismo y quieres el mejor teclado. DevinConfías un ticket entero y vuelves ante un resultado. JulesQuieres aprobar un plan antes de que el agente toque nada. Copilot y Agent HQTu trabajo ya está ordenado en tickets y la revisión es la cita. Codex cloudTienes una cuenta de OpenAI y tareas acotadas que delegar. Replit AgentPartes de cero y quieres una aplicación en línea esa misma noche. WindsurfEditas a mano y quieres ejecuciones paralelas en tu disco. ConductorTrabajas solo en un Mac y el código no puede salir. OpenHands Agent CanvasEl código debe quedarse en hardware que controlas, y quieres el código fuente. Vibe KanbanTienes una cola de tareas que pasar una a una en tu equipo. CodegLos agentes ya corren en tu casa y falta una vista. Gemini Code AssistQuieres un buen agente en el editor que ya tienes, sin pagar nada. Claude Code en la webYa usas el CLI y la única pregunta es dónde corre. MurmellVarios agentes deben tocar los mismos archivos, y hay gente mirando. La tabla de la página de comparativas plantea la otra pregunta, la de a dónde va el segundo agente. Una máquina en la nube por tarea El agente recibe un clon de tu repositorio en una máquina que no ves, trabaja en una rama y entrega una pull request. Es la forma más extendida, y la que pide menos confianza: nada de lo que hace toca tu copia antes de que hayas leído el diff. Cursor. Un editor por persona y una máquina por agente, contra un canvas y un directorio para todos. Devin. El paralelismo por separación contra el paralelismo por reparto, y cuándo cada forma es la correcta. Jules. Un plan que apruebas y una pull request que revisas, contra terminales que miras en un único árbol. Copilot y Agent HQ. Dónde converge el trabajo de los agentes: en la pull request, o en la copia de trabajo. Codex cloud. Por qué lanzar el CLI de Codex en un canvas compartido no es lo mismo que delegarle una tarea. Replit Agent. Fabricar una aplicación desde cero, contra hacer trabajar varios agentes sobre un código que ya existe. Un espacio de trabajo por tarea, en tu máquina La misma elección, en tu propia casa: un worktree de git o un directorio de trabajo por agente, y una fusión al final. El código no sale, lo que resuelve la cuestión de seguridad antes de que se plantee, y nadie más ve la sesión. Windsurf. Un worktree por conversación en tu máquina, contra un directorio compartido en la nube. Conductor. Una aplicación de Mac con un espacio por tarea, contra un canvas en la nube con un solo directorio para todos. OpenHands Agent Canvas. La comparación más cercana de la lista: un worktree por agente contra un único árbol con reservas de archivos. Vibe Kanban. Un tablero kanban sobre ejecuciones locales, contra un canvas compartido sobre un directorio en la nube. Codeg. Reunir sesiones locales, contra hacer correr los agentes en un directorio compartido en la nube. Un agente a la vez, en tu editor Sin paralelismo documentado: un agente, supervisado, en la herramienta donde ya escribes. Es el mejor equilibrio cuando eres tú quien tiene el teclado y el agente te asiste. Gemini Code Assist. Un agente supervisado en tu editor, contra varios agentes sin supervisión en un directorio que miras. El mismo agente, en otro sitio El CLI es idéntico en los dos lados. Lo que cambia es la máquina donde corre y cuánta gente puede mirarla. Claude Code en la web. El mismo CLI en dos sitios: una máquina aislada por tarea, contra varios agentes en un canvas y una sola copia de trabajo. El directorio compartido, y por qué casi nadie lo hace Falta una cuarta respuesta en la tabla, y es la nuestra: varios agentes en un único directorio, sin copia. Casi nadie la propone porque exige un árbitro. Sin árbitro, dos agentes leen la misma versión de un archivo y el segundo borra al primero sin que nada lo anuncie. Murmell pone ese árbitro en el servidor. Un agente anuncia las rutas que va a tocar antes de escribir, el tablero se las asigna, y se las niega a todos los demás hasta que las libera. Una escritura que llega de todas formas a un archivo que tiene otro se fotografía antes de aterrizar. El mecanismo en detalle. Cómo elegir en dos minutos Si escribes el código tú mismo, elige un editor: Cursor, Windsurf o Gemini Code Assist, y la pregunta queda resuelta. Si tus tareas son independientes y quieres delegarlas, elige un agente en la nube: Devin, Jules o Codex cloud. Si el código no puede salir de tu red, elige algo local y auto-hospedable, OpenHands a la cabeza. Queda un caso, y es el único que trata Murmell: varios agentes que deben tocar los mismos archivos en la misma hora, con gente mirando. Las comparaciones una por una. --- ## Figma for developers: a multiplayer canvas for code Source: https://murmell.com/what/figma-for-developers The analogy is worth something because of what it removes. There is no export, no local copy to reconcile and no screen share where one person drives while the rest guess. What the analogy gets right One URL is the whole surface. Everybody on it sees the same canvas at the same moment, and presence is drawn rather than described: named cursors, and who is looking at which window. Watching is cheap on purpose, the way a Figma viewer seat is cheap. Read links are free and there is no limit on them. Edit links are capped by your plan. And the surface is shared by default. You do not decide to share the work after the fact, because the work was never happening anywhere private. The home page shows what that looks like. What the analogy gets wrong In Figma the thing on the canvas is the artifact. Here it is not. The artifact is a git repository, and the canvas is the room where the work on it happens. History lives in a private repository per project, pushed as the project goes, not in the canvas. In Figma two people can push the same rectangle around. Two people do not type into one terminal here. Each person drives their own agents and everyone watches all of them, which is not the same thing as two hands on one object. And most of the work on a Murmell canvas is not done by the people. Agents do the typing, on cloud machines, several of them in one directory. The people watch and step in when an agent is going the wrong way. Why a shared surface matters for code now One agent in one editor never needed a room. Several agents in one directory produce more output than one person follows comfortably, and the people steering them have to be looking at the same thing to divide the work sensibly. That is also why the agents share a directory rather than a worktree each. An agent claims a path before writing to it and the server refuses everyone else until it is released, so the second agent reads what the first one just wrote instead of finding out at merge time. Multiple AI agents on one repo is the mechanism, and multiplayer coding with AI agents is the people half of it. --- ## Figma für Entwickler: Ein Multiplayer-Canvas für Code Source: https://murmell.com/de/what/figma-for-developers Die Analogie ist nützlich wegen dem, was sie überflüssig macht. Es gibt keinen Export, keine lokalen Kopien abzugleichen und keine Bildschirmübertragung, bei der eine Person steuert und die anderen raten. Was die Analogie richtig trifft Eine einzige URL ist die gesamte Arbeitsfläche. Alle Beteiligten sehen im selben Moment dasselbe Canvas, und Anwesenheit wird visualisiert: Cursor mit Namen und die Anzeige, wer welches Fenster betrachtet. Zuschauen ist bewusst kostenlos, ähnlich wie ein Viewer-Account bei Figma. Lese-Links sind kostenlos und unbegrenzt. Bearbeitungs-Links richten sich nach Ihrem gebuchten Tarif. Und die Arbeitsfläche wird standardmäßig geteilt. Sie müssen nicht erst nachträglich entscheiden, die Arbeit zu teilen, da sie nie an einem privaten Ort stattfand. Die Startseite zeigt, wie das aussieht. Wo die Analogie nicht passt Bei Figma ist das Element auf dem Canvas das Artefakt. Hier ist es das nicht. Das Artefakt ist ein Git-Repository und das Canvas ist der Raum, in dem die Arbeit stattfindet. Der Versionsverlauf liegt in einem privaten Repository pro Projekt, nicht im Canvas. Bei Figma können zwei Personen dasselbe Rechteck bewegen. Hier tippen zwei Personen nicht in dasselbe Terminal. Jede Person steuert ihre eigenen Agenten und alle können alle beobachten. Zudem wird der Großteil der Arbeit auf einem Murmell-Canvas nicht von Menschen erledigt. Agenten tippen auf Cloud-Maschinen, mehrere im selben Verzeichnis. Die Menschen beobachten und greifen ein, wenn ein Agent in die falsche Richtung läuft. Warum eine gemeinsame Fläche für Code jetzt wichtig ist Ein einzelner Agent in einem Editor brauchte nie einen Raum. Mehrere Agenten im selben Verzeichnis erzeugen mehr Ausgabe, als eine Person alleine überblicken kann, und wer sie anleitet, muss dieselbe Ansicht vor sich haben. Deshalb teilen sich die Agenten ein Verzeichnis, statt jeweils einen eigenen Worktree zu nutzen. Ein Agent beansprucht einen Pfad vor dem Schreiben und der Server weist alle anderen ab, bis er freigegeben wird. So sieht der zweite Agent sofort, was der erste geschrieben hat. Mehrere KI-Agenten in einem Repository erläutert diesen Mechanismus und Multiplayer-Coding mit KI-Agenten beschreibt die menschliche Zusammenarbeit. --- ## Figma para desarrolladores: un lienzo multijugador para código Source: https://murmell.com/es/what/figma-for-developers La analogía tiene valor por lo que elimina. No hay exportaciones, ni copias locales que reconciliar, ni pantallas compartidas donde uno conduce y los demás adivinan. En qué acierta la analogía Una sola URL es toda la superficie. Todos ven el mismo lienzo en el mismo instante y la presencia se dibuja: cursores con nombre y quién está mirando qué ventana. Observar es gratuito a propósito, igual que una cuenta de visor en Figma. Los enlaces de lectura son gratuitos e ilimitados. Los enlaces de edición dependen de tu plan. Y la superficie es compartida por defecto. No decides compartir el trabajo después del hecho, porque el trabajo nunca ocurrió en un lugar privado. La página principal muestra cómo se ve. En qué falla la analogía En Figma lo que está en el lienzo es el artefacto. Aquí no. El artefacto es un repositorio Git y el lienzo es la sala donde ocurre el trabajo. El historial vive en un repositorio privado por proyecto, no en el lienzo. En Figma dos personas pueden mover el mismo rectángulo. Aquí dos personas no escriben en la misma terminal. Cada persona maneja sus propios agentes y todos observan a todos. Y la mayor parte del trabajo en un lienzo de Murmell no la hacen personas. Los agentes escriben en máquinas en la nube, varios en un mismo directorio. Las personas observan e intervienen cuando un agente se desvía. Por qué un espacio compartido importa ahora para el código Un solo agente en un editor nunca necesitó una sala. Varios agentes en un directorio producen más de lo que una persona puede seguir con comodidad, y quienes los guían deben mirar lo mismo para repartir el trabajo. Por eso los agentes comparten un directorio en lugar de tener un worktree cada uno. Un agente reserva una ruta antes de escribir y el servidor rechaza a los demás hasta que se libere, para que el segundo agente lea lo que el primero acaba de escribir. Múltiples agentes de IA en un repositorio explica el mecanismo y programación multijugador con agentes de IA aborda la parte humana. --- ## Figma para desenvolvedores: um canvas multiplayer para código Source: https://murmell.com/pt/what/figma-for-developers A analogia tem valor pelo que elimina. Não há exportações, nem cópias locais para conciliar, nem compartilhamento de tela onde uma pessoa pilota e as outras adivinham. O que a analogia acerta Uma única URL é toda a superfície. Todos veem o mesmo canvas no mesmo instante e a presença é desenhada: cursores com nomes e indicação de quem está olhando para qual janela. Observar é gratuito de propósito, da mesma forma que uma conta de visualizador no Figma. Links de leitura são gratuitos e ilimitados. Links de edição dependem do seu plano. E a superfície é compartilhada por padrão. Você não decide compartilhar o trabalho após o fato, porque o trabalho nunca aconteceu em nenhum lugar privado. A página inicial mostra como isso funciona. Onde a analogia não se aplica No Figma o objeto no canvas é o artefato. Aqui não. O artefato é um repositório Git e o canvas é a sala onde o trabalho ocorre. O histórico vive em um repositório privado por projeto, não no canvas. No Figma duas pessoas podem mover o mesmo retângulo. Aqui duas pessoas não digitam no mesmo terminal. Cada pessoa controla seus próprios agentes e todos observam todos. E a maior parte do trabalho em um canvas Murmell não é feita por humanos. Os agentes digitam em máquinas na nuvem, vários no mesmo diretório. Os humanos observam e intervêm quando um agente se perde. Por que um espaço compartilhado importa agora para o código Um único agente num editor nunca precisou de uma sala. Vários agentes num diretório produzem mais do que uma pessoa consegue acompanhar com facilidade, e quem os orienta precisa olhar para a mesma coisa para dividir o trabalho. É por isso também que os agentes compartilham um diretório em vez de ter um worktree cada. Um agente reserva um caminho antes de escrever e o servidor recusa os outros até que seja liberado, para que o segundo agente leia o que o primeiro acabou de escrever. Múltiplos agentes de IA num repositório explica o mecanismo e programação multiplayer com agentes de IA aborda a colaboração humana. --- ## Figma per sviluppatori: un canvas multiplayer per il codice Source: https://murmell.com/it/what/figma-for-developers L’analogia è utile per ciò che elimina. Non ci sono esportazioni, né copie locali da sincronizzare, né condivisioni schermo in cui una persona guida e gli altri tirano a indovinare. Cosa coglie di giusto l’analogia Un singolo URL è l’intera superficie. Tutti vedono lo stesso canvas nello stesso momento e la presenza è visualizzata: cursori con nomi e l’indicazione di quale finestra ciascuno stia guardando. Osservare è gratuito per scelta, esattamente come un account visualizzatore su Figma. I link di sola lettura sono gratuiti e illimitati. I link di modifica dipendono dal piano sottoscritto. E la superficie è condivisa per impostazione predefinita. Non si decide di condividere il lavoro a posteriori, perché il lavoro non è mai avvenuto in un luogo privato. La home page mostra come si presenta. Dove l’analogia non si applica In Figma l’oggetto sul canvas è l’artefatto. Qui non lo è. L’artefatto è un repository Git e il canvas è la stanza in cui si svolge il lavoro. La cronologia risiede in un repository privato per progetto, non nel canvas. In Figma due persone possono spostare lo stesso rettangolo. Qui due persone non digitano nello stesso terminale. Ciascuna persona guida i propri agenti e tutti possono osservare tutti. Inoltre la maggior parte del lavoro su un canvas Murmell non è svolta da esseri umani. Gli agenti digitano su macchine cloud, più di uno nella stessa directory. Le persone osservano e intervengono quando un agente devia. Perché una superficie condivisa è essenziale per il codice oggi Un singolo agente in un editor non ha mai avuto bisogno di una stanza. Diversi agenti nella stessa directory generano più output di quanto una sola persona possa seguire comodamente, e chi li guida deve guardare la stessa visuale per dividere il lavoro. Questo è anche il motivo per cui gli agenti condividono una directory invece di avere un worktree ciascuno. Un agente riserva un percorso prima di scrivere e il server rifiuta tutti gli altri fino al rilascio, consentendo al secondo agente di leggere subito quanto appena scritto dal primo. Più agenti IA su un repository spiega il meccanismo e programmazione multiplayer con agenti IA affronta la parte della collaborazione umana. --- ## Figma pour les développeurs : un canvas multijoueur pour le code Source: https://murmell.com/fr/quoi/figma-pour-developpeurs L’analogie a de la valeur pour ce qu’elle supprime. Il n’y a aucun export, aucune copie locale à réconcilier et aucun partage d’écran où une personne pilote pendant que les autres devinent. Ce que l’analogie dit de vrai Une seule URL constitue toute la surface. Tout le monde y voit le même canvas au même instant, et la présence est dessinée plutôt que décrite : des curseurs avec des noms, et qui regarde quelle fenêtre. Observer est volontairement gratuit, de la même manière qu’un siège observateur Figma ne coûte rien. Les liens de lecture sont gratuits et illimités. Les liens d’édition sont plafonnés par votre forfait. Et la surface est partagée par défaut. Vous ne décidez pas de partager le travail après coup, parce que le travail n’a jamais eu lieu dans un endroit privé. La page d’accueil montre à quoi cela ressemble. Où l’analogie s’arrête Dans Figma, l’objet sur le canvas est l’artéfact. Ici, ce n’est pas le cas. L’artéfact est un dépôt git, et le canvas est la pièce où le travail s’effectue. L’historique vit dans un dépôt privé par projet, poussé au fil de l’eau, pas dans le canvas. Dans Figma, deux personnes peuvent déplacer le même rectangle. Ici, deux personnes ne tapent pas dans le même terminal. Chaque personne pilote ses propres agents et tout le monde les observe tous, ce qui n’est pas la même chose que deux mains sur un seul objet. Et l’essentiel du travail sur un canvas Murmell n’est pas fait par des humains. Les agents tapent au clavier sur des machines cloud, à plusieurs dans un même dossier. Les humains observent et interviennent quand un agent fait fausse route. Pourquoi une surface partagée compte pour le code aujourd’hui Un seul agent dans un éditeur n’a jamais eu besoin d’une pièce. Plusieurs agents dans un même dossier produisent plus de résultats qu’une seule personne ne peut suivre confortablement, et les personnes qui les guident doivent regarder la même chose pour diviser le travail intelligemment. C’est aussi pourquoi les agents partagent un dossier plutôt qu’un worktree chacun. Un agent réserve un chemin avant d’y écrire et le serveur refuse tout le monde jusqu’à ce qu’il soit libéré, de sorte que le deuxième agent lit ce que le premier vient d’écrire au lieu de le découvrir au moment de la fusion. Plusieurs agents IA sur un dépôt explique le mécanisme, et coder à plusieurs avec des agents IA traite du volet humain. --- ## Figma для разработчиков: мультиплеерный холст для кода Source: https://murmell.com/ru/what/figma-for-developers Аналогия полезна тем, что она устраняет. Больше нет экспорта, локальных копий для ручного слияния и демонстраций экрана, где один работает, а остальные угадывают. В чем аналогия точна Единый URL представляет собой всю рабочую поверхность. Все участники видят один и тот же холст в один момент, а присутствие визуализировано: курсоры с именами и индикация того, кто какое окно просматривает. Режим наблюдателя бесплатен по умолчанию, как и учетная запись viewer в Figma. Ссылки для чтения бесплатны и не ограничены. Ссылки для редактирования определяются тарифным планом. Рабочая поверхность открыта по умолчанию. Вам не нужно делиться результатами постфактум, так как работа изначально не велась в изолированном месте. Главная страница показывает, как это выглядит. Где аналогия не работает В Figma объектом работы является сам холст. Здесь это не так. Артефакт — это Git-репозиторий, а холст — пространство для работы. История коммитов хранится в приватном репозитории проекта, а не на холсте. В Figma два человека могут перемещать один объект. Здесь два человека не вводят текст в один терминал. Каждый управляет своими агентами, а результаты видны всем. Кроме того, основную часть работы на холсте Murmell выполняют не люди. Агенты пишут код на облачных машинах в общей директории, а люди наблюдают и вносят корректировки. Почему общий холст необходим для кода сегодня Один агент в редакторе не требовал совместного пространства. Несколько агентов в одной директории создают поток вывода, за которым трудно уследить в одиночку, поэтому кураторам необходимо общее поле зрения для распределения задач. По этой же причине агенты делят одну директорию, а не отдельные worktree. Агент резервирует путь перед записью, и сервер блокирует других до освобождения, позволяя второму агенту сразу видеть написанное первым. В статье Несколько ИИ-агентов в одном репозитории описан механизм, а в материале Мультиплеерное программирование с ИИ-агентами раскрыта сторона совместной работы людей. --- ## Glosario de la IA de código en la nube Source: https://murmell.com/es/what/glossary Agente de IA de código Un programa que recibe un objetivo en una frase y trabaja hasta alcanzarlo: lee archivos, escribe, lanza las pruebas, lee el error y vuelve a intentar. Ejecuta comandos, lo que lo separa de un asistente que solo propone texto. IA en la nube Tres cosas según quién hable: un modelo alojado en un proveedor, una API llamada desde tu software, o un agente que se ejecuta en una máquina remota. El tercer sentido es el único en el que algo sigue funcionando cuando cierras la pestaña. IA agéntica Una IA que persigue un objetivo en lugar de responder a una pregunta: elige sus acciones, las ejecuta y vuelve a intentar mientras el resultado no sirva. La palabra dice qué hace el programa, mientras que "IA en la nube" dice dónde corre. Worktree Una segunda copia de trabajo de un repositorio git, con su propio índice, en otra rama. Es la forma más habitual de hacer correr varios agentes sin que se estorben, y se paga con una fusión por copia. Particionamiento Repartir los archivos entre los agentes para que no se crucen. Funciona mientras el reparto sea correcto, y nadie comprueba que lo sea: es una promesa, no una garantía. Canvas La superficie donde se colocan las ventanas de los agentes, con una terminal en cada una. Se comparte con un enlace, y la gente que la mira tiene ahí un cursor con nombre. Reserva de archivo El hecho de que un agente anuncie las rutas que va a escribir antes de escribirlas. Un único titular por ruta, aplicado por el servidor, lo que permite a varios agentes compartir un directorio sin pisarse. Colisión Una escritura en un archivo que tiene otro. Se fotografía antes de aterrizar, así que la versión anterior sigue existiendo y nada se pierde. Caja de arena (sandbox) La máquina aislada donde se ejecuta el código de los agentes. En Murmell, una por proyecto, sin base de datos ni clave de descifrado: lo que pasa ahí solo cuesta la máquina. Máquina efímera Una máquina creada para una sesión y destruida después. Todo lo que debe sobrevivir se envía a un repositorio antes de la destrucción. Contexto Lo que el modelo tiene delante en el momento de responder: tu petición, los archivos leídos, el historial de la sesión. Su tamaño es limitado, lo que explica por qué un agente olvida el principio de una sesión muy larga. Token La unidad de facturación y medida de los modelos, más o menos un trozo de palabra. El precio de una sesión se cuenta en tokens leídos y escritos, en tu proveedor de modelos. CLI Un programa que se usa con el teclado en una terminal. Claude Code, Codex, Kimi y OpenCode lo son, lo que explica por qué se pueden lanzar en una máquina remota y mostrar en una pestaña. Terminal La ventana de texto donde se escriben los comandos y corre la salida. En Murmell es una terminal real en la máquina remota, transportada hasta el navegador, no una imitación. Repositorio El lugar versionado donde vive el código. Cada proyecto de Murmell recibe uno, privado, y el trabajo se envía ahí a lo largo de la sesión. Enlace de lectura Una dirección que deja mirar un canvas sin cuenta y sin pagar. Se ven las ventanas, las terminales que corren y los cursores, sin poder tocar. Multijugador El hecho de que varias personas estén en el mismo canvas al mismo tiempo, cada una manejando sus agentes, con los cursores de los demás visibles con un nombre y un color. Para la versión larga de tres de estas entradas: IA en la nube, agente de IA en la nube y la reserva de archivos. --- ## Glossaire de l'IA de code dans le cloud Source: https://murmell.com/fr/quoi/glossaire Agent IA de code Un programme qui reçoit un but en une phrase et travaille jusqu'à l'atteindre : il lit les fichiers, écrit, lance les tests, lit l'erreur et recommence. Il exécute des commandes, ce qui le sépare d'un assistant qui propose du texte. IA cloud Trois choses selon qui parle : un modèle hébergé chez un fournisseur, une API appelée depuis votre logiciel, ou un agent qui s'exécute sur une machine distante. Le troisième sens est le seul où quelque chose continue quand vous fermez l'onglet. IA agentique Une IA qui poursuit un but au lieu de répondre à une question : elle choisit ses actions, les exécute et recommence tant que le résultat ne convient pas. Le mot dit ce que le programme fait, là où « IA cloud » dit où il tourne. Worktree Une deuxième copie de travail d'un dépôt git, avec son propre index, sur une autre branche. C'est la façon la plus répandue de faire tourner plusieurs agents sans qu'ils se gênent, et elle se paie par une fusion par copie. Partitionnement Le fait de répartir les fichiers entre les agents pour qu'ils ne se croisent pas. Ça marche tant que la répartition est juste, et personne ne vérifie qu'elle l'est : c'est une promesse, pas une garantie. Canvas La surface où les fenêtres des agents sont posées, avec un terminal dans chacune. Elle se partage par un lien, et les gens qui la regardent y ont un curseur nommé. Réservation de fichier Le fait qu'un agent annonce les chemins qu'il va écrire avant de les écrire. Un seul détenteur par chemin, appliqué par le serveur, ce qui permet à plusieurs agents de partager un dossier sans s'écraser. Collision Une écriture sur un fichier tenu par quelqu'un d'autre. Elle est photographiée avant d'atterrir, donc la version précédente existe encore et rien n'est perdu. Bac à sable (sandbox) La machine isolée où le code des agents s'exécute. Sur Murmell, une par projet, sans base de données ni clé de déchiffrement : ce qui s'y passe ne coûte que la machine. Machine éphémère Une machine créée pour une session et détruite après. Tout ce qui doit survivre est poussé dans un dépôt avant la destruction. Contexte Ce que le modèle a sous les yeux au moment de répondre : votre demande, les fichiers lus, l'historique de la session. Sa taille est limitée, ce qui explique pourquoi un agent oublie le début d'une très longue session. Jeton L'unité de facturation et de mesure des modèles, à peu près un morceau de mot. Le prix d'une session se compte en jetons lus et écrits, chez votre fournisseur de modèle. CLI Un programme qui s'utilise au clavier dans un terminal. Claude Code, Codex, Kimi et OpenCode en sont, ce qui est la raison pour laquelle on peut les lancer sur une machine distante et les afficher dans un onglet. Terminal La fenêtre texte où les commandes s'écrivent et où la sortie défile. Sur Murmell, c'est un vrai terminal sur la machine distante, transporté jusqu'au navigateur, pas une imitation. Dépôt L'endroit versionné où vit le code. Chaque projet Murmell en reçoit un, privé, et le travail y est poussé au fil de la session. Lien de lecture Une adresse qui laisse regarder un canvas sans compte et sans payer. On voit les fenêtres, les terminaux qui défilent et les curseurs, sans pouvoir toucher. Multijoueur Le fait que plusieurs personnes soient sur le même canvas au même moment, chacune pilotant ses agents, les curseurs des autres visibles avec un nom et une couleur. Pour la version longue de trois de ces entrées : IA cloud, agent IA cloud et la réservation de fichiers. --- ## Glossar zum Cloud-KI-Coding Source: https://murmell.com/de/what/glossary KI-Coding-Agent Ein Programm, das ein Ziel in einem Satz erhält und arbeitet, bis es erreicht ist: Es liest Dateien, schreibt, führt Tests aus, liest den Fehler und beginnt von vorn. Es führt Befehle aus, was es von einem Assistenten unterscheidet, der Text vorschlägt. Cloud-KI Drei Dinge, je nachdem, wer spricht: ein bei einem Anbieter gehostetes Modell, eine aus Ihrer Software aufgerufene API, oder ein Agent, der auf einer entfernten Maschine läuft. Die dritte Bedeutung ist die einzige, bei der etwas weiterläuft, wenn Sie den Tab schließen. Agentische KI Eine KI, die ein Ziel verfolgt, statt eine Frage zu beantworten: Sie wählt ihre Aktionen, führt sie aus und beginnt von vorn, solange das Ergebnis nicht passt. Das Wort sagt, was das Programm tut, während „Cloud-KI" sagt, wo es läuft. Worktree Eine zweite Arbeitskopie eines Git-Repositorys, mit eigenem Index, auf einem anderen Branch. Es ist die verbreitetste Art, mehrere Agenten laufen zu lassen, ohne dass sie sich stören, und sie kostet eine Zusammenführung pro Kopie. Aufteilung Die Verteilung der Dateien auf die Agenten, damit sie sich nicht kreuzen. Funktioniert, solange die Verteilung stimmt, und niemand prüft, ob sie es tut: Es ist ein Versprechen, keine Garantie. Canvas Die Fläche, auf der die Fenster der Agenten liegen, mit einem Terminal in jedem. Sie wird über einen Link geteilt, und die Leute, die zusehen, haben darauf einen benannten Cursor. Dateireservierung Die Tatsache, dass ein Agent die Pfade ankündigt, die er schreiben wird, bevor er sie schreibt. Ein einziger Inhaber pro Pfad, vom Server durchgesetzt, was mehreren Agenten erlaubt, sich ein Verzeichnis zu teilen, ohne sich zu überschreiben. Kollision Eine Schreibaktion auf eine Datei, die jemand anderes hält. Sie wird fotografiert, bevor sie ankommt, also existiert die vorherige Version noch und nichts geht verloren. Sandbox Die isolierte Maschine, auf der der Code der Agenten läuft. Auf Murmell eine pro Projekt, ohne Datenbank oder Entschlüsselungsschlüssel: Was dort passiert, kostet nur die Maschine. Flüchtige Maschine Eine Maschine, die für eine Sitzung erstellt und danach zerstört wird. Alles, was überleben muss, wird vor der Zerstörung in ein Repository gepusht. Kontext Was das Modell im Moment der Antwort vor Augen hat: Ihre Anfrage, die gelesenen Dateien, den Verlauf der Sitzung. Seine Größe ist begrenzt, was erklärt, warum ein Agent den Anfang einer sehr langen Sitzung vergisst. Token Die Abrechnungs- und Maßeinheit der Modelle, ungefähr ein Wortstück. Der Preis einer Sitzung wird in gelesenen und geschriebenen Tokens gemessen, bei Ihrem Modellanbieter. CLI Ein Programm, das per Tastatur in einem Terminal bedient wird. Claude Code, Codex, Kimi und OpenCode gehören dazu, was der Grund ist, warum man sie auf einer entfernten Maschine starten und in einem Tab anzeigen kann. Terminal Das Textfenster, in dem Befehle geschrieben werden und die Ausgabe durchläuft. Auf Murmell ist es ein echtes Terminal auf der entfernten Maschine, bis in den Browser transportiert, keine Nachbildung. Repository Der versionierte Ort, an dem der Code lebt. Jedes Murmell-Projekt erhält ein privates, und die Arbeit wird im Laufe der Sitzung dorthin gepusht. Lesezugriffslink Eine Adresse, die eine Canvas ohne Konto und ohne Bezahlung ansehen lässt. Man sieht die Fenster, die durchlaufenden Terminals und die Cursor, ohne etwas anfassen zu können. Mehrspieler Die Tatsache, dass sich mehrere Personen gleichzeitig auf derselben Canvas befinden, jede steuert ihre eigenen Agenten, die Cursor der anderen sichtbar mit Namen und Farbe. Für die ausführliche Version von drei dieser Einträge: Cloud-KI, Cloud-KI-Agent und die Dateireservierung. --- ## Glossario dell'IA di coding nel cloud Source: https://murmell.com/it/what/glossary Agente IA di coding Un programma che riceve un obiettivo in una frase e lavora finché non lo raggiunge: legge i file, scrive, lancia i test, legge l'errore e ricomincia. Esegue comandi, il che lo separa da un assistente che propone testo. IA cloud Tre cose secondo chi parla: un modello ospitato da un fornitore, una API chiamata dal tuo software, o un agente che gira su una macchina remota. Il terzo significato è l'unico in cui qualcosa continua quando chiudi la scheda. IA agentica Un'IA che persegue un obiettivo invece di rispondere a una domanda: sceglie le proprie azioni, le esegue e ricomincia finché il risultato non va bene. La parola dice cosa fa il programma, mentre "IA cloud" dice dove gira. Worktree Una seconda copia di lavoro di un repository git, con il proprio indice, su un altro branch. È il modo più diffuso di far girare più agenti senza che si disturbino, e si paga con una fusione per copia. Partizionamento Il fatto di distribuire i file tra gli agenti perché non si incrocino. Funziona finché la distribuzione è corretta, e nessuno verifica che lo sia: è una promessa, non una garanzia. Canvas La superficie dove sono posate le finestre degli agenti, con un terminale in ciascuna. Si condivide con un link, e le persone che la guardano vi hanno un cursore con nome. Prenotazione di file Il fatto che un agente annunci i percorsi che scriverà prima di scriverli. Un solo titolare per percorso, applicato dal server, il che permette a più agenti di condividere una cartella senza sovrascriversi. Collisione Una scrittura su un file tenuto da qualcun altro. Viene fotografata prima di atterrare, quindi la versione precedente esiste ancora e nulla va perso. Sandbox La macchina isolata dove gira il codice degli agenti. Su Murmell, una per progetto, senza database né chiave di decrittazione: quello che vi succede costa solo la macchina. Macchina effimera Una macchina creata per una sessione e distrutta dopo. Tutto ciò che deve sopravvivere viene inviato in un repository prima della distruzione. Contesto Ciò che il modello ha davanti nel momento in cui risponde: la tua richiesta, i file letti, la cronologia della sessione. La sua dimensione è limitata, il che spiega perché un agente dimentica l'inizio di una sessione molto lunga. Token L'unità di fatturazione e misura dei modelli, all'incirca un pezzo di parola. Il prezzo di una sessione si conta in token letti e scritti, presso il tuo fornitore di modelli. CLI Un programma che si usa da tastiera in un terminale. Claude Code, Codex, Kimi e OpenCode lo sono, il che è la ragione per cui si possono lanciare su una macchina remota e mostrare in una scheda. Terminale La finestra di testo dove si scrivono i comandi e scorre l'output. Su Murmell è un vero terminale sulla macchina remota, trasportato fino al browser, non un'imitazione. Repository Il luogo versionato dove vive il codice. Ogni progetto Murmell ne riceve uno, privato, e il lavoro vi viene inviato man mano che la sessione procede. Link di sola lettura Un indirizzo che permette di guardare un canvas senza account e senza pagare. Si vedono le finestre, i terminali che scorrono e i cursori, senza poter toccare. Multiplayer Il fatto che più persone siano sullo stesso canvas nello stesso momento, ciascuna pilota i propri agenti, i cursori degli altri visibili con nome e colore. Per la versione lunga di tre di queste voci: IA cloud, agente IA cloud e la prenotazione di file. --- ## Glossário da IA de código na nuvem Source: https://murmell.com/pt/what/glossary Agente de IA de código Um programa que recebe um objetivo em uma frase e trabalha até alcançá-lo: lê os arquivos, escreve, roda os testes, lê o erro e tenta de novo. Ele executa comandos, o que o separa de um assistente que propõe texto. IA na nuvem Três coisas dependendo de quem fala: um modelo hospedado em um provedor, uma API chamada a partir do seu software, ou um agente que roda em uma máquina remota. O terceiro sentido é o único em que algo continua quando você fecha a aba. IA agêntica Uma IA que persegue um objetivo em vez de responder a uma pergunta: ela escolhe suas ações, as executa e tenta de novo enquanto o resultado não for satisfatório. A palavra diz o que o programa faz, enquanto "IA na nuvem" diz onde ele roda. Worktree Uma segunda cópia de trabalho de um repositório git, com seu próprio índice, em outra branch. É a forma mais comum de rodar vários agentes sem que atrapalhem uns aos outros, e o preço é uma fusão por cópia. Particionamento O ato de distribuir os arquivos entre os agentes para que não se cruzem. Funciona enquanto a divisão for correta, e ninguém verifica se ela é: é uma promessa, não uma garantia. Canvas A superfície onde as janelas dos agentes ficam, com um terminal em cada uma. Ela se compartilha por um link, e as pessoas que a observam têm um cursor nomeado nela. Reserva de arquivo O ato de um agente anunciar os caminhos que vai escrever antes de escrevê-los. Um único titular por caminho, aplicado pelo servidor, o que permite que vários agentes compartilhem um diretório sem se sobrescreverem. Colisão Uma escrita em um arquivo detido por outro agente. Ela é fotografada antes de ser gravada, então a versão anterior continua existindo e nada se perde. Caixa de areia (sandbox) A máquina isolada onde o código dos agentes roda. No Murmell, uma por projeto, sem banco de dados nem chave de descriptografia: o que acontece nela custa só a máquina. Máquina efêmera Uma máquina criada para uma sessão e destruída depois. Tudo o que precisa sobreviver é enviado para um repositório antes da destruição. Contexto O que o modelo tem diante de si no momento de responder: seu pedido, os arquivos lidos, o histórico da sessão. Seu tamanho é limitado, o que explica por que um agente esquece o início de uma sessão muito longa. Token A unidade de cobrança e medida dos modelos, mais ou menos um pedaço de palavra. O preço de uma sessão se conta em tokens lidos e escritos, no seu provedor de modelo. CLI Um programa que se usa pelo teclado em um terminal. Claude Code, Codex, Kimi e OpenCode são exemplos, e é por isso que é possível executá-los em uma máquina remota e exibi-los em uma aba. Terminal A janela de texto onde os comandos são digitados e a saída rola. No Murmell, é um terminal de verdade na máquina remota, transportado até o navegador, não uma imitação. Repositório O lugar versionado onde o código vive. Cada projeto do Murmell recebe um, privado, e o trabalho é enviado para lá ao longo da sessão. Link de leitura Um endereço que permite assistir a um canvas sem conta e sem pagar. Dá para ver as janelas, os terminais rolando e os cursores, sem poder tocar. Multiusuário O fato de várias pessoas estarem no mesmo canvas ao mesmo tempo, cada uma pilotando seus agentes, com os cursores dos outros visíveis com nome e cor. Para a versão longa de três dessas entradas: IA na nuvem, agente de IA na nuvem e a reserva de arquivos. --- ## The words Murmell uses, defined Source: https://murmell.com/what/glossary Canvas One project, and the room around it. A dotted surface in the browser holding the windows of one project. It is the unit everything else attaches to: the agents belong to the canvas rather than to your tab, the share links point at a canvas, and closing your browser leaves it running. Window A real terminal, on the canvas. Each window holds a terminal attached to a coding agent running on a cloud machine. What you read is what the CLI printed, in the characters it printed, and what you type goes to it. Board The list of who is holding which file. The server side record of every reservation, note and collision on a project. Agents talk to it through tools rather than being asked to behave: it grants a path or refuses it. File reservation One agent holding one path until it lets go. Before an agent writes to a file it claims the path. The board records one holder per path and refuses everybody else until the holder releases it or the claim expires. The rule lives on the server, so an agent that ignores it is refused rather than trusted. Collision A write to a file somebody else is holding. When a write lands on a path held by another agent, the file is snapshotted before the write goes in. Nothing is lost, and the snapshot is on the board for you to look at. Read link See the canvas, change nothing. A link that shows the windows, the terminal output as it arrives and the cursors of everybody else. It is free, there is no limit on how many people hold one, and it can never turn into an edit link. Edit link Drive an agent on somebody else canvas. A link that lets the holder type into the terminals, open windows and move things. Every action that changes anything requires it, and how many can be live at once is set by the plan. Sandbox The machine your agents run on. A cloud machine holding the project directory and the agent processes, and nothing else. It has no database, no decryption key and no stored credential, so an agent that escapes what it was asked to do finds a project directory and nothing to steal. Bring your own key Your agent account, your bill. You sign in with the agent subscriptions and API keys you already pay for. The key is encrypted on your account and opened only at the moment an agent starts, never on the machines your agents run on. Murmell charges for the machine and the collaboration, never for the model. Related concepts in detail To see how these parts interact, read about multiple AI agents on one repo, multiplayer coding with AI agents, and the cloud sandbox architecture. --- ## L’IA cloud pour développeurs : modèles, API et agents de code Source: https://murmell.com/fr/quoi/ia-cloud Trois choses sous un seul mot Le premier sens est le plus ancien : un modèle hébergé ailleurs. Vous ne téléchargez rien, vous envoyez une question et vous recevez une réponse. C'est ce que fait un assistant dans un onglet. Le deuxième est le sens des équipes techniques : une API. Le modèle devient une brique dans un logiciel que vous écrivez, facturée au jeton. La machine reste chez le fournisseur, la logique reste chez vous. Le troisième est plus récent et c'est celui qui change la journée de quelqu'un qui écrit du code. Un agent s'exécute sur une machine distante, avec un système de fichiers, un terminal, un accès réseau. Il installe des dépendances, lance les tests, lit les erreurs, recommence. Vous ne lui parlez pas à chaque étape, vous lui donnez un but. Le mot qu'on croise à côté : agentique « IA agentique » désigne le troisième sens vu depuis le programme plutôt que depuis la machine : une IA qui poursuit un but, choisit ses actions et itère seule jusqu'à ce que les tests passent. Les deux termes se recouvrent presque toujours en pratique, parce qu'un programme qui travaille seul pendant quarante minutes a besoin d'une machine qui reste allumée. Ce qui distingue vraiment le troisième Une IA qui répond s'arrête quand vous fermez l'onglet, parce qu'elle n'avait rien à faire entre deux questions. Un agent sur une machine distante continue : le processus vit sur la machine, pas dans le navigateur. C'est le seul des trois sens où fermer l'ordinateur ne coûte rien. La conséquence est arithmétique. Si un agent tient tout seul sur une machine, deux agents tiennent sur deux machines, et cinq sur cinq. Le travail cesse d'être limité par le nombre de terminaux ouverts devant vous. Où ça coince quand ils sont plusieurs La plupart des outils règlent la question en isolant : un agent, une machine, une branche, et une fusion à la fin. Ça marche jusqu'au moment où deux agents ont modifié le même fichier, et personne ne l'a su avant que les deux aient fini. L'autre voie est le partage avec une règle. Les agents vivent dans le même dossier, et un agent réserve un chemin avant d'y écrire. Un seul détenteur par fichier, appliqué par le serveur plutôt que demandé poliment au modèle. C'est la forme que Murmell a choisie. Les questions à poser avant de choisir Qui possède la machine, et qu'est-ce qu'elle contient à part votre code. Combien de temps elle vit, et ce qui reste quand elle est détruite. Ce que vous payez : la machine, les jetons du modèle, ou les deux. Et si votre abonnement à un agent existant est réutilisable ou s'il faut en racheter un. Sur ce dernier point, la réponse de Murmell est courte : vous branchez les comptes que vous payez déjà, et la facture couvre la machine et la salle. Voir ce que fait le canvas. --- ## IA cloud per sviluppatori: Modelli ospitati, API e agenti di codice remoti Source: https://murmell.com/it/what/cloud-ai Tre cose sotto una sola parola Il primo significato è il più antico: un modello ospitato altrove. Non scarichi nulla, invii una domanda e ricevi una risposta. È quello che fa un assistente in una scheda del browser. Il secondo è il significato dei team tecnici: una API. Il modello diventa un mattoncino in un software che scrivi tu, fatturato a token. La macchina resta presso il fornitore, la logica resta da te. Il terzo è più recente ed è quello che cambia la giornata di chi scrive codice. Un agente gira su una macchina remota, con un file system, un terminale, accesso alla rete. Installa dipendenze, lancia i test, legge gli errori, ricomincia. Non gli parli a ogni passaggio, gli dai un obiettivo. La parola che si incontra accanto: agentica "IA agentica" indica il terzo significato visto dal programma invece che dalla macchina: un'IA che persegue un obiettivo, sceglie le proprie azioni e itera da sola finché i test non passano. I due termini si sovrappongono quasi sempre nella pratica, perché un programma che lavora da solo per quaranta minuti ha bisogno di una macchina che resti accesa. Cosa distingue davvero il terzo Un'IA che risponde si ferma quando chiudi la scheda, perché non aveva nulla da fare tra una domanda e l'altra. Un agente su una macchina remota continua: il processo vive sulla macchina, non nel browser. È l'unico dei tre significati in cui chiudere il computer non costa nulla. La conseguenza è aritmetica. Se un agente sta da solo su una macchina, due agenti stanno su due macchine, e cinque su cinque. Il lavoro smette di essere limitato dal numero di terminali aperti davanti a te. Dove si incastra quando sono in più La maggior parte degli strumenti risolve la questione isolando: un agente, una macchina, un branch, e una fusione alla fine. Funziona finché due agenti non hanno modificato lo stesso file, e nessuno lo sa finché entrambi non hanno finito. L'altra via è la condivisione con una regola. Gli agenti vivono nella stessa cartella, e un agente riserva un percorso prima di scriverci. Un solo titolare per file, applicato dal server invece di chiesto gentilmente al modello. È la forma che Murmell ha scelto. Le domande da porsi prima di scegliere Chi possiede la macchina, e cosa contiene oltre al tuo codice. Quanto vive, e cosa resta quando viene distrutta. Cosa paghi: la macchina, i token del modello, o entrambi. E se il tuo abbonamento a un agente esistente è riutilizzabile o se devi comprarne uno nuovo. Su quest'ultimo punto, la risposta di Murmell è breve: colleghi gli account che paghi già, e la fattura copre la macchina e la stanza. Guarda cosa fa il canvas. --- ## IA en la nube para desarrolladores: modelos, APIs y agentes de código remotos Source: https://murmell.com/es/what/cloud-ai Tres cosas bajo una sola palabra El primer sentido es el más antiguo: un modelo alojado en otro lugar. No descargas nada, envías una pregunta y recibes una respuesta. Eso es lo que hace un asistente en una pestaña. El segundo es el sentido de los equipos técnicos: una API. El modelo se convierte en una pieza dentro de un software que escribes, facturada por token. La máquina se queda en el proveedor, la lógica se queda contigo. El tercero es más reciente y es el que cambia el día de quien escribe código. Un agente se ejecuta en una máquina remota, con un sistema de archivos, una terminal, acceso a la red. Instala dependencias, corre las pruebas, lee los errores, vuelve a intentar. No le hablas en cada paso, le das un objetivo. La palabra que se cruza al lado: agéntica "IA agéntica" nombra el tercer sentido visto desde el programa en vez de desde la máquina: una IA que persigue un objetivo, elige sus acciones e itera sola hasta que las pruebas pasan. Los dos términos coinciden casi siempre en la práctica, porque un programa que trabaja solo durante cuarenta minutos necesita una máquina que se quede encendida. Lo que distingue de verdad al tercero Una IA que responde se detiene cuando cierras la pestaña, porque no tenía nada que hacer entre dos preguntas. Un agente en una máquina remota continúa: el proceso vive en la máquina, no en el navegador. Es el único de los tres sentidos donde cerrar el ordenador no cuesta nada. La consecuencia es aritmética. Si un agente cabe solo en una máquina, dos agentes caben en dos máquinas, y cinco en cinco. El trabajo deja de estar limitado por el número de terminales abiertas frente a ti. Dónde se atasca cuando son varios La mayoría de las herramientas resuelven la cuestión aislando: un agente, una máquina, una rama, y una fusión al final. Funciona hasta el momento en que dos agentes han modificado el mismo archivo, y nadie lo supo hasta que los dos terminaron. La otra vía es compartir con una regla. Los agentes viven en el mismo directorio, y un agente reserva una ruta antes de escribir en ella. Un único titular por archivo, aplicado por el servidor en vez de sugerido educadamente al modelo. Es la forma que eligió Murmell. Las preguntas que hacerse antes de elegir Quién posee la máquina, y qué contiene además de tu código. Cuánto tiempo vive, y qué queda cuando se destruye. Qué pagas: la máquina, los tokens del modelo, o los dos. Y si tu suscripción a un agente existente sirve o hay que comprar otra. Sobre este último punto, la respuesta de Murmell es corta: conectas las cuentas que ya pagas, y la factura cubre la máquina y la sala. Ver qué hace el canvas. --- ## IA na nuvem para desenvolvedores: Modelos hospedados, APIs e agentes remotos de código Source: https://murmell.com/pt/what/cloud-ai Três coisas sob uma única palavra O primeiro sentido é o mais antigo: um modelo hospedado em outro lugar. Você não baixa nada, envia uma pergunta e recebe uma resposta. É o que faz um assistente em uma aba. O segundo é o sentido das equipes técnicas: uma API. O modelo vira uma peça dentro de um software que você escreve, cobrada por token. A máquina fica com o provedor, a lógica fica com você. O terceiro é mais recente e é o que muda o dia de quem escreve código. Um agente roda em uma máquina remota, com um sistema de arquivos, um terminal, acesso à rede. Ele instala dependências, roda os testes, lê os erros, tenta de novo. Você não fala com ele a cada passo, você dá a ele um objetivo. A palavra que cruza o caminho: agêntica "IA agêntica" nomeia o terceiro sentido visto a partir do programa em vez da máquina: uma IA que persegue um objetivo, escolhe suas ações e itera sozinha até os testes passarem. Os dois termos quase sempre se sobrepõem na prática, porque um programa que trabalha sozinho por quarenta minutos precisa de uma máquina que fique ligada. O que realmente distingue o terceiro Uma IA que responde para quando você fecha a aba, porque ela não tinha nada para fazer entre duas perguntas. Um agente em uma máquina remota continua: o processo vive na máquina, não no navegador. É o único dos três sentidos em que fechar o computador não custa nada. A consequência é aritmética. Se um agente cabe sozinho em uma máquina, dois agentes cabem em duas máquinas, e cinco em cinco. O trabalho deixa de ser limitado pelo número de terminais abertos na sua frente. Onde emperra quando são vários A maioria das ferramentas resolve a questão isolando: um agente, uma máquina, uma branch, e uma fusão no final. Funciona até o momento em que dois agentes modificaram o mesmo arquivo, e ninguém soube até os dois terminarem. O outro caminho é compartilhar com uma regra. Os agentes vivem no mesmo diretório, e um agente reserva um caminho antes de escrever nele. Um único titular por arquivo, aplicado pelo servidor em vez de pedido educadamente ao modelo. É a forma que o Murmell escolheu. As perguntas para fazer antes de escolher Quem é dono da máquina, e o que ela contém além do seu código. Quanto tempo ela vive, e o que sobra quando é destruída. O que você paga: a máquina, os tokens do modelo, ou os dois. E se sua assinatura de um agente existente é reutilizável ou se é preciso comprar outra. Sobre esse último ponto, a resposta do Murmell é curta: você conecta as contas que já paga, e a fatura cobre a máquina e a sala. Veja o que o canvas faz. --- ## Confronto agenti IA di codice: Claude Code, Cursor, Devin e altri 10 strumenti Source: https://murmell.com/it/what/best-ai-coding-agents La domanda che ordina tutto Tutti questi strumenti sanno lanciare un agente. Il primo è facile: legge, scrive, lancia i test. È al secondo che le concezioni divergono, perché bisogna decidere cosa vede e cosa ha il diritto di toccare. La tabella qui sotto non classifica nulla: dice a chi conviene ogni strumento, una riga per strumento, e i gruppi sotto spiegano perché. Quale prendere, una riga ciascuno StrumentoLa scelta giusta quando CursorScrivi il codice tu stesso e vuoi la migliore tastiera. DevinAffidi un ticket intero e torni davanti a un risultato. JulesVuoi approvare un piano prima che l'agente tocchi qualcosa. Copilot e Agent HQIl tuo lavoro è già ordinato in ticket e la revisione è l'appuntamento. Codex CloudHai un account OpenAI e compiti ben definiti da delegare. Replit AgentParti da zero e vuoi un'applicazione online la sera stessa. WindsurfModifichi a mano e vuoi esecuzioni parallele sul tuo disco. ConductorLavori da solo su un Mac e il codice non deve uscire. OpenHands Agent CanvasIl codice deve restare su hardware che controlli, e vuoi il sorgente. Vibe KanbanHai una fila di compiti da far passare uno per uno sul tuo computer. CodegGli agenti girano già da te e manca una vista. Gemini Code AssistVuoi un buon agente nell'editor che hai già, senza pagare nulla. Claude Code sul webUsi già il CLI e l'unica domanda è dove gira. MurmellPiù agenti devono toccare gli stessi file, e ci sono persone che guardano. La tabella della pagina dei confronti pone l'altra domanda, quella del posto dove va il secondo agente. Una macchina cloud per compito L'agente riceve un clone del tuo repository su una macchina che non vedi, lavora su un branch e restituisce una pull request. È la forma più diffusa, e quella che chiede meno fiducia: niente di ciò che fa tocca la tua copia prima che tu abbia letto il diff. Cursor. Un editor a persona e una macchina per agente, contro un canvas e una cartella per tutti. Devin. Il parallelismo per separazione contro il parallelismo per condivisione, e quando ogni forma è quella giusta. Jules. Un piano che approvi e una pull request che rileggi, contro terminali che guardi in un solo albero. Copilot e Agent HQ. Dove converge il lavoro degli agenti: alla pull request, o nella copia di lavoro. Codex Cloud. Perché lanciare il CLI Codex su un canvas condiviso non è la stessa cosa di delegargli un compito. Replit Agent. Costruire un'applicazione dal nulla, contro far lavorare più agenti su codice che esiste già. Uno spazio di lavoro per compito, sulla tua macchina Stessa scelta, da te: un worktree git o una cartella di lavoro per agente, e un'unione alla fine. Il codice non esce, il che risolve la questione della sicurezza prima che si ponga, e nessun altro vede la sessione. Windsurf. Un worktree per conversazione sulla tua macchina, contro una cartella condivisa nel cloud. Conductor. Un'app Mac con uno spazio per compito, contro un canvas cloud con un'unica cartella per tutti. OpenHands Agent Canvas. Il confronto più vicino della lista: un worktree per agente contro un solo albero con prenotazioni di file. Vibe Kanban. Una bacheca kanban sopra esecuzioni locali, contro un canvas condiviso sopra una cartella cloud. Codeg. Raccogliere sessioni locali, contro far girare gli agenti su una cartella cloud condivisa. Un agente alla volta, nel tuo editor Nessun parallelismo documentato: un agente, supervisionato, nello strumento dove scrivi. È il miglior compromesso quando sei tu a tenere la tastiera e l'agente ti assiste. Gemini Code Assist. Un agente supervisionato nel tuo editor, contro più agenti non supervisionati in una cartella che guardi. Lo stesso agente, altrove Il CLI è identico da entrambe le parti. Quello che cambia è la macchina dove gira e il numero di persone che possono guardarla. Claude Code sul web. Lo stesso CLI in due posti: una macchina isolata per compito, contro più agenti su un canvas e un'unica copia di lavoro. La cartella condivisa, e perché quasi nessuno la fa Manca una quarta risposta nella tabella, ed è la nostra: più agenti in un'unica cartella, senza copia. Quasi nessuno la propone perché richiede un arbitro. Senza arbitro, due agenti leggono la stessa versione di un file e il secondo cancella il primo senza che nulla lo annunci. Murmell mette questo arbitro nel server. Un agente annuncia i percorsi che toccherà prima di scrivere, la bacheca glieli assegna, e li nega a tutti gli altri finché non li rilascia. Una scrittura che arriva comunque su un file tenuto da qualcun altro viene fotografata prima di atterrare. Il meccanismo nel dettaglio. Come scegliere in due minuti Se scrivi il codice tu stesso, prendi un editor: Cursor, Windsurf o Gemini Code Assist, e la domanda è risolta. Se i tuoi compiti sono indipendenti e vuoi affidarli, prendi un agente cloud: Devin, Jules o Codex cloud. Se il codice non ha il diritto di lasciare la tua rete, prendi qualcosa di locale e auto-ospitabile, OpenHands in testa. Resta un caso, ed è l'unico che Murmell tratta: più agenti che devono toccare gli stessi file nella stessa ora, con persone che guardano. I confronti uno per uno. --- ## Claude Code in the browser Source: https://murmell.com/what/claude-code-in-the-browser So there is nothing to install, and closing the tab does not end the run. Nothing to install No CLI to keep current on your machine, and no shell to be in before you can start. You open the canvas, open a window, and the agent is there. Any computer with a browser reaches the same canvas. The tab is not the session Close it and the agents keep going. Come back later and the same windows are where you left them, with the output that arrived while you were away. That falls out of running the agents on our machines instead of in your tab. Run Claude Code in the cloud is the machine side of it. Real terminal output, not a transcript of it The window shows what the CLI printed, in the characters it printed. You are reading the tool rather than a summary of the tool, which matters the first time an agent asks you something and you need to see exactly what it saw. More than one window Because the agents are not on your computer, five of them side by side cost you nothing local. They also share one project directory, which is the part that needs a rule: an agent claims the paths it is about to touch, and the board refuses everyone else until it releases them. Multiple AI agents on one repo explains the board. The canvas on the home page shows the windows. Somebody else can open the same tab A canvas has a link, and whoever opens it sees the windows and the terminals live, with named cursors on the ones who are looking. Read links are free and there is no limit on them, so showing a colleague what an agent is doing costs a paste. Multiplayer coding with AI agents is that part, and Figma for developers is the same idea against a surface you already know. --- ## Cos’è Murmell? Più agenti di codice in un unico repository Source: https://murmell.com/it/what/murmell Invia il link a un collaboratore ed entrerà nel canvas con te, visualizzando i terminali in tempo reale con il suo nome associato al cursore. Cosa visualizzi Un canvas a matrice di punti chiara con finestre nello stile di macOS. Ogni finestra è il terminale di un agente e mostra l’output effettivo della CLI sulle nostre macchine. Le finestre sono affiancate, permettendo di seguire cinque agenti contemporaneamente su un unico schermo. Il canvas nella home page illustra esattamente questo oggetto. Una directory e un tabellone per assegnare i file Assegnare a tre agenti la stessa directory senza regole porta a sovrascritture reciproche in meno di un minuto. L’ultima scrittura prevale silenziosamente fino al fallimento dei test. Per questo un agente riserva i percorsi prima di modificarli. Il tabellone registra un unico titolare per percorso e respinge chiunque altro fino al rilascio. Tale rifiuto è garantito dal server. In caso di conflitto, viene salvato uno snapshot istantaneo prima della scrittura. Nessuno scrive senza aver prima richiesto l’accesso. Più agenti IA su un repository illustra il tabellone con i dati raccolti durante i nostri test. Le persone nella stanza I link di sola lettura sono gratuiti e senza limiti numerici. I link di modifica dipendono dal piano. Chi apre un link visualizza i terminali in tempo reale e i cursori degli altri partecipanti con i rispettivi nomi. Chiudere la scheda non interrompe gli agenti. Appartengono al canvas, quindi il lavoro prosegue autonomamente. Programmazione multiplayer con agenti IA descrive le modalità di collaborazione a due su un canvas. Dove risiede il codice Ogni progetto dispone di un repository privato su cui il codice viene sincronizzato costantemente. Una macchina prima della dismissione esegue un push finale, rendendo usa e getta solo la macchina e mai il codice. La macchina che esegue il codice degli agenti non contiene database né chiavi di decifratura. Un eventuale agente compromesso troverà solo la directory di progetto senza credenziali da sottrarre. Una sandbox cloud per agenti IA illustra la gestione dei segreti. Origine del nome Murmell deriva da murmuration, la figura creata da migliaia di uccelli che volano all’unisono. Il termine richiama anche un mormorio leggero, rappresentato nel logo da una singola onda. --- ## La macchina cloud dove girano gli agenti Source: https://murmell.com/it/what/cloud-sandbox-for-ai-agents Perché una sandbox Si dice anche sandbox, ed è la parola che usa la maggior parte della documentazione. Un agente utile esegue comandi che ha scritto lui stesso. Installare un pacchetto, lanciare uno script, aprire una porta. Nessuna revisione umana passa davanti a ognuno di questi comandi, il che significa che l'unica protezione seria è il luogo in cui vengono eseguiti. Da qui la regola: la macchina che esegue il codice non ha niente di interessante sopra. Nessun database, nessuna chiave di decrittazione, nessuna credenziale di un altro cliente. Un incidente su questa macchina costa la macchina. Cosa contiene La cartella del progetto, i CLI degli agenti, e ciò che gli agenti installano per lavorare. Le credenziali che colleghi servono agli agenti durante la sessione e non escono da questo perimetro. Il canvas, la stanza e la bacheca di prenotazione vivono altrove. Un agente che scrivesse qualsiasi cosa sul proprio disco non potrebbe decidere chi detiene un file: l'arbitraggio non è sulla macchina che controlla. Una macchina per progetto L'isolamento tra progetti non è un'impostazione, è la forma del prodotto. Ogni canvas avvia la propria macchina, e due progetti non condividono mai un file system. È anche ciò che rende l'ambiente riproducibile: il progetto parte da un'immagine nota ogni volta. E il codice, alla fine Un repository privato viene creato con il progetto, e il lavoro vi viene inviato man mano che la sessione procede, con un ultimo invio prima della distruzione della macchina. Ciò che ti resta è un repository normale, presso di te, leggibile senza Murmell. Lo svolgimento di una sessione. --- ## La machine cloud où tournent les agents Source: https://murmell.com/fr/quoi/machine-cloud-pour-agents-ia Pourquoi un bac à sable On dit aussi sandbox, et c'est le mot qu'emploient la plupart des documentations. Un agent utile exécute des commandes qu'il a écrites lui-même. Installer un paquet, lancer un script, ouvrir un port. Aucune revue humaine ne passe devant chacune de ces commandes, ce qui veut dire que la seule protection sérieuse est l'endroit où elles s'exécutent. D'où la règle : la machine qui exécute le code n'a rien d'intéressant dessus. Pas de base de données, pas de clé de déchiffrement, pas d'identifiants d'un autre client. Un incident sur cette machine coûte la machine. Ce qu'elle contient Le dossier du projet, les CLI des agents, et ce que les agents installent pour travailler. Les identifiants que vous branchez servent aux agents pendant la session et ne quittent pas ce périmètre. Le canvas, la salle et le tableau de réservations vivent ailleurs. Un agent qui écrirait n'importe quoi sur son disque ne pourrait pas décider qui détient un fichier : l'arbitrage n'est pas sur la machine qu'il contrôle. Une machine par projet L'isolation entre projets n'est pas un réglage, c'est la forme du produit. Chaque canvas démarre sa machine, et deux projets ne partagent jamais un système de fichiers. C'est aussi ce qui rend l'environnement reproductible : le projet part d'une image connue à chaque fois. Et le code, à la fin Un dépôt privé est créé avec le projet, et le travail y est poussé au fil de la session, avec une dernière poussée avant la destruction de la machine. Ce que vous gardez est un dépôt normal, chez vous, lisible sans Murmell. Le déroulé d'une session. --- ## La máquina en la nube donde corren los agentes Source: https://murmell.com/es/what/cloud-sandbox-for-ai-agents Por qué una caja de arena También se dice sandbox, y es la palabra que usa la mayoría de la documentación. Un agente útil ejecuta comandos que él mismo ha escrito. Instalar un paquete, lanzar un script, abrir un puerto. Ninguna revisión humana pasa delante de cada uno de esos comandos, lo que significa que la única protección seria es el lugar donde se ejecutan. De ahí la regla: la máquina que ejecuta el código no tiene nada interesante encima. Ni base de datos, ni clave de descifrado, ni credenciales de otro cliente. Un incidente en esa máquina cuesta la máquina. Lo que contiene El directorio del proyecto, los CLI de los agentes, y lo que los agentes instalan para trabajar. Las credenciales que conectas sirven a los agentes durante la sesión y no salen de ese perímetro. El canvas, la sala y el tablero de reservas viven en otro lugar. Un agente que escribiera cualquier cosa en su disco no podría decidir quién tiene un archivo: el arbitraje no está en la máquina que controla. Una máquina por proyecto El aislamiento entre proyectos no es un ajuste, es la forma del producto. Cada canvas arranca su máquina, y dos proyectos nunca comparten un sistema de archivos. Es también lo que hace el entorno reproducible: el proyecto parte de una imagen conocida cada vez. Y el código, al final Se crea un repositorio privado junto con el proyecto, y el trabajo se envía ahí a lo largo de la sesión, con un último envío antes de destruir la máquina. Lo que conservas es un repositorio normal, en tu casa, legible sin Murmell. El desarrollo de una sesión. --- ## Les agents IA de code, rangés par ce qui les sépare Source: https://murmell.com/fr/quoi/meilleurs-agents-ia-de-code La question qui range tout Tous ces outils savent lancer un agent. Le premier est facile : il lit, il écrit, il lance les tests. C'est au deuxième que les conceptions divergent, parce qu'il faut décider ce qu'il voit et ce qu'il a le droit de toucher. Le tableau ci-dessous ne classe rien : il dit à qui chaque outil convient, une ligne par outil, et les groupes en dessous expliquent pourquoi. Lequel prendre, en une ligne chacun OutilLe bon choix quand CursorVous écrivez le code vous-même et voulez le meilleur clavier. DevinVous confiez un ticket entier et revenez devant un résultat. JulesVous voulez approuver un plan avant que l'agent touche quoi que ce soit. Copilot et Agent HQVotre travail est déjà rangé en tickets et la relecture est le rendez-vous. Codex cloudVous avez un compte OpenAI et des tâches cadrées à déléguer. Replit AgentVous partez de rien et voulez une application en ligne le soir même. WindsurfVous éditez à la main et voulez des exécutions parallèles sur votre disque. ConductorVous travaillez seul sur un Mac et le code ne doit pas sortir. OpenHands Agent CanvasLe code doit rester sur du matériel que vous contrôlez, et vous voulez le source. Vibe KanbanVous avez une file de tâches à faire passer une par une sur votre poste. CodegLes agents tournent déjà chez vous et il manque une vue. Gemini Code AssistVous voulez un bon agent dans l'éditeur que vous avez déjà, sans rien payer. Claude Code sur le webVous utilisez déjà le CLI et la seule question est où il tourne. MurmellPlusieurs agents doivent toucher les mêmes fichiers, et des gens regardent. Le tableau de la page des comparatifs pose l'autre question, celle de l'endroit où part le deuxième agent. Une machine cloud par tâche L'agent reçoit un clone de votre dépôt sur une machine que vous ne voyez pas, travaille sur une branche et rend une pull request. C'est la forme la plus répandue, et celle qui demande le moins de confiance : rien de ce qu'il fait ne touche votre copie avant que vous ayez lu le diff. Cursor. Un éditeur par personne et une machine par agent, contre un canvas et un dossier pour tout le monde. Devin. Le parallélisme par séparation contre le parallélisme par partage, et quand chaque forme est la bonne. Jules. Un plan que vous approuvez et une pull request que vous relisez, contre des terminaux que vous regardez dans un seul arbre. Copilot et Agent HQ. Où le travail des agents converge : à la pull request, ou dans la copie de travail. Codex cloud. Pourquoi lancer le CLI Codex sur un canvas partagé n'est pas la même chose que lui déléguer une tâche. Replit Agent. Fabriquer une application à partir de rien, contre faire travailler plusieurs agents sur un code qui existe. Un espace de travail par tâche, sur votre machine Le même choix, chez vous : un worktree git ou un dossier de travail par agent, et une fusion à la fin. Le code ne sort pas, ce qui règle la question de sécurité avant qu'elle se pose, et personne d'autre ne voit la séance. Windsurf. Un worktree par conversation sur votre machine, contre un dossier partagé dans le cloud. Conductor. Une application Mac avec un espace par tâche, contre un canvas cloud avec un seul dossier pour tous. OpenHands Agent Canvas. La comparaison la plus proche de la liste : un worktree par agent contre un seul arbre avec des réservations de fichiers. Vibe Kanban. Un tableau kanban au-dessus d'exécutions locales, contre un canvas partagé au-dessus d'un dossier cloud. Codeg. Rassembler des sessions locales, contre faire tourner les agents sur un dossier cloud partagé. Un agent à la fois, dans votre éditeur Pas de parallélisme documenté : un agent, supervisé, dans l'outil où vous écrivez. C'est le meilleur compromis quand c'est vous qui tenez le clavier et que l'agent vous assiste. Gemini Code Assist. Un agent supervisé dans votre éditeur, contre plusieurs agents non supervisés dans un dossier que vous regardez. Le même agent, ailleurs Le CLI est identique des deux côtés. Ce qui change est la machine où il tourne et le nombre de personnes qui peuvent la regarder. Claude Code sur le web. Le même CLI à deux endroits : une machine isolée par tâche, contre plusieurs agents sur un canvas et une seule copie de travail. Le dossier partagé, et pourquoi presque personne ne le fait Il manque une quatrième réponse dans le tableau, et c'est la nôtre : plusieurs agents dans un seul dossier, sans copie. Presque personne ne la propose parce qu'elle demande un arbitre. Sans arbitre, deux agents lisent la même version d'un fichier et le second efface le premier sans que rien ne l'annonce. Murmell met cet arbitre dans le serveur. Un agent annonce les chemins qu'il va toucher avant d'écrire, le tableau les lui attribue, et les refuse à tous les autres jusqu'à ce qu'il les rende. Une écriture qui arrive quand même sur un fichier tenu par quelqu'un d'autre est photographiée avant d'atterrir. Le mécanisme en détail. Comment choisir en deux minutes Si vous écrivez le code vous-même, prenez un éditeur : Cursor, Windsurf ou Gemini Code Assist, et la question est réglée. Si vos tâches sont indépendantes et que vous voulez les confier, prenez un agent cloud : Devin, Jules ou Codex cloud. Si le code n'a pas le droit de quitter votre réseau, prenez du local et auto-hébergeable, OpenHands en tête. Il reste un cas, et c'est le seul que Murmell traite : plusieurs agents qui doivent toucher les mêmes fichiers dans la même heure, avec des gens qui regardent. Les comparaisons une par une. --- ## Mehrere KI-Agenten in einem Repository Source: https://murmell.com/de/what/multiple-ai-agents-one-repo Der Fall, der alles zerstört Zwei Agenten erhalten zwei Aufgaben, die dieselbe Datei betreffen. Der erste liest die Datei, überlegt zwanzig Sekunden, schreibt. Der zweite hat dieselbe Version gelesen, bevor der erste geschrieben hat, und schreibt darüber. Nichts ist abgestürzt, nichts hat gewarnt, und die Arbeit des ersten ist verschwunden. Dieser Fall ist nicht selten, sobald es mehr als einen Agenten gibt, weil Agenten breit lesen und schnell schreiben. Deshalb isolieren fast alle Werkzeuge: eine Maschine pro Agent, ein Branch pro Agent. Was der Rest der Welt tut: ein Worktree pro Agent Die übliche Antwort auf dieses Problem ist die Aufteilung: Man gibt jedem Agenten seinen eigenen Git-Worktree, eine vollständige Kopie der Dateien mit eigenem Index, und sorgt dafür, dass sich die Bereiche nicht überschneiden. Das machen Windsurf, Conductor und OpenHands, und das empfehlen die meisten Anleitungen. Es funktioniert, und es hat genau einen Nachteil: Die Aufteilung ist ein Versprechen, keine Garantie. Niemand prüft, dass sich die Bereiche nicht überschneiden, und wenn sie es tun, erfährt man es beim Zusammenführen, wenn beide Agenten fertig sind und sich niemand mehr an die Überlegung erinnert. Die Reservierung, in drei Schritten Bevor ein Agent schreibt, kündigt er die Pfade an, die er anfassen wird. Das Board weist sie ihm zu, wenn sie frei sind, und verweigert sie, wenn sie belegt sind. Ein einziger Inhaber pro Datei, zu jedem Zeitpunkt. Während der Arbeit beobachtet ein Wächter die tatsächlichen Schreibaktionen auf der Festplatte und ordnet jede ihrem Urheber zu. Eine Schreibaktion auf einen von jemand anderem gehaltenen Pfad wird fotografiert, bevor sie ankommt: Die vorherige Version bleibt erhalten, also geht nichts verloren, auch wenn die Regel umgangen wird. Am Ende gibt der Agent seine Pfade frei. Die Datei wird für den nächsten wieder verfügbar, ohne Zusammenführung, weil es nie zwei lebende Versionen zur gleichen Zeit gab. Was das auf dem Bildschirm ergibt Jedes Fenster zeigt seinen Agenten bei der Arbeit, und das Board zeigt, wer was hält. Man sieht, dass ein Agent wartet, und warum. Ein blockierter Agent ist sichtbar, bevor er Schaden anrichtet, was den echten Unterschied zu einer unsichtbaren Warteschlange ausmacht. Menschen zählen auch. Mehrere Personen auf derselben Canvas steuern ihre eigenen Agenten und sehen die Cursor der anderen, jeder mit einem Namen. Wenn es nicht die richtige Form ist Wenn Ihre Aufgaben wirklich unabhängig und lang sind, bleibt die Isolierung per Maschine sinnvoll: nichts zu schlichten, nichts zu warten. Das Teilen gewinnt, wenn sich die Aufgaben berühren, was der Fall ist, sobald man an derselben Funktion arbeitet. Die Vergleiche gehen die Wahl Werkzeug für Werkzeug durch. --- ## Claude Code in der Cloud ausführen: Ohne lokale Installation mit mehreren Agenten Source: https://murmell.com/de/what/run-claude-code-in-the-cloud Was Sie vor dem Start brauchen Ein Repository, auch ein leeres. Ein Konto bei einem Modellanbieter, oder einen API-Schlüssel. Und eine entfernte Maschine, die das Verzeichnis beherbergt und die Befehle ausführt. Murmell erstellt die Maschine und ein privates Repository, wenn Sie das Projekt anlegen, also bleibt in der Praxis nur das Modellkonto zu verbinden. Eine Anweisungsdatei im Wurzelverzeichnis des Repositorys ändert viel: wie man das Projekt startet, was nicht kaputtgehen darf, wie das Team schreibt. Die Agenten lesen sie beim Start, und es ist das beste Verhältnis zwischen aufgewendeter Zeit und erreichter Qualität. Wie eine Stunde aussieht Sie beschreiben eine Aufgabe in einem Satz. Der Agent liest die betroffenen Dateien, schreibt, führt Tests aus, liest den Fehler, korrigiert. Sie verfolgen nicht jeden Schritt: Sie schauen auf das Terminal, wenn es anhält, und lesen den Diff durch. Beim zweiten Agenten wird die Frage zur Aufteilung. Zwei Agenten auf zwei Ecken des Projekts kommen parallel voran; zwei Agenten auf derselben Datei stehen sich im Weg. Auf Murmell reserviert jeder seine Pfade, bevor er schreibt, also wird die Kollision verweigert, statt später entdeckt zu werden. Was es kostet, in zwei Zeilen Es gibt zwei Rechnungen, und man trennt sie besser. Die Tokens des Modells werden an Ihren Anbieter bezahlt, auf Ihrem Konto. Die Maschine und der Raum werden an den Hoster bezahlt. Murmell verkauft keine Tokens weiter, was heißt: Ihr Claude-Abo oder Ihr OpenAI-Schlüssel bleibt der, den Sie nutzen. Die übliche Falle Drei Agenten auf drei Kopien des Repositorys zu starten wirkt naheliegend und kostet noch am selben Abend: drei Branches, drei Zusammenführungen, und Konflikte, die niemand kommen sah. Ein Verzeichnis mit einer Schreibregel zu teilen gibt weniger Näharbeit. Wie die Regel funktioniert, und was die Maschine enthält. --- ## Multiplayer coding with AI agents Source: https://murmell.com/what/multiplayer-coding-with-ai-agents It is one URL. Nobody installs anything, nobody takes a copy, and nobody has to be screen sharing for the others to see the work happen. What a guest sees You send a link. Whoever opens it gets the canvas as it stands, not a recording. They see the windows where they are and the terminal output arriving line by line. They see the other cursors move, with a name on each, and which window each person is watching. Read links are free and there is no limit on how many you give out. Links that let somebody drive an agent are capped by your plan, which is the honest shape of it: looking costs us almost nothing, and a machine costs what a machine costs. What each person can do Each person drives their own agents, and everyone sees all of them. That is a different shape from two hands on one object: the shared thing is the canvas and the directory under it, not a single keyboard. It is enough for the thing people actually do together, which is deciding what the agents should be doing. You watch a run go the wrong way, you say so, and the person holding that window redirects it while everyone watches the correction land. Figma for developers is the same argument, made against a tool you already know. The agents are the other players Several agents in one checkout is the part that needs engineering. An agent claims the paths it is about to touch, the board records one holder per path, and everyone else is refused until the holder releases it. The refusal comes from our server, so it is not something a model can talk itself out of. Multiple AI agents on one repo has the mechanism and the numbers from our own runs. Leaving does not stop it Closing a tab does not kill the agents. They belong to the canvas rather than to your browser, so the work carries on and the output that arrived while you were away is there when you come back. The code is not sitting only on that machine either. Every project gets a private repository, the work is pushed as it goes, and a machine about to be torn down pushes one last time first. What Murmell is covers the rest of it in one page, and the home page draws the room. --- ## Multiplayer-Coding mit KI-Agenten Source: https://murmell.com/de/what/multiplayer-coding-with-ai-agents Es ist eine einzige URL. Niemand muss etwas installieren, niemand zieht eine Kopie und niemand muss seinen Bildschirm teilen, damit andere die Arbeit sehen. Was Gäste sehen Sie senden einen Link. Wer ihn öffnet, sieht das Canvas in Echtzeit, keine Aufzeichnung. Man sieht die Fenster an ihren Plätzen und die Terminalausgabe Zeile für Zeile. Man sieht die Cursor anderer Personen mit Namen und welches Fenster jeweils aktiv ist. Lese-Links sind kostenlos und in beliebiger Zahl erstellbar. Links zur Steuerung von Agenten richten sich nach Ihrem Tarif: Zuschauen verursacht kaum Kosten, während eine Cloud-Maschine ihren festen Preis hat. Was jede Person tun kann Jede Person steuert ihre eigenen Agenten und alle sehen alle. Das ist etwas anderes als zwei Hände an einer Tastatur: Geteilt werden das Canvas und das Verzeichnis darunter, nicht eine einzelne Tastatur. Das genügt für das, was Menschen tatsächlich gemeinsam tun: entscheiden, was die Agenten als Nächstes tun sollen. Sie sehen einen Durchlauf in die falsche Richtung gehen, merken es an, und wer dieses Fenster hält, korrigiert die Richtung. Figma für Entwickler zieht denselben Vergleich anhand eines bekannten Werkzeugs. Die Agenten sind die weiteren Mitspieler Mehrere Agenten in einem Verzeichnis erfordern echte Ingenieursarbeit. Ein Agent reserviert die Pfade, die er bearbeiten möchte, das Board vergibt genau einen Inhaber pro Pfad und alle anderen werden abgewiesen, bis der Pfad freigegeben wird. Die Abweisung kommt von unserem Server, nicht aus einem Prompt. Mehrere KI-Agenten in einem Repository erklärt den Mechanismus und die Messwerte aus unseren eigenen Testläufen. Schließen beendet die Ausführung nicht Einen Tab zu schließen stoppt die Agenten nicht. Sie gehören zum Canvas und nicht zum Browser. Die Arbeit läuft weiter und alle Ausgaben sind bei Ihrer Rückkehr vorhanden. Der Code verbleibt auch nicht nur auf dieser Maschine. Jedes Projekt erhält ein privates Git-Repository, Änderungen werden fortlaufend übertragen und eine Maschine vor dem Herunterfahren führt einen letzten Push durch. Was Murmell ist fasst den Rest auf einer Seite zusammen und die Startseite zeigt die Raumansicht. --- ## Murmell क्या है? एक रिपॉजिटरी में कई कोडिंग एजेंट Source: https://murmell.com/hi/what/murmell किसी को लिंक भेजें और वे आपके साथ कैनवस में आ जाएंगे, कर्सर पर अपने नाम के साथ वही टर्मिनल आउटपुट देखते हुए। आप क्या देखते हैं macOS जैसी विंडो वाला एक हल्का डॉटेड कैनवस। हर विंडो एक एजेंट का टर्मिनल है, जो हमारी मशीन पर चलने वाले CLI का वास्तविक आउटपुट दिखाती है। विंडो अगल-बगल होती हैं, इसलिए पाँच एजेंट एक ही स्क्रीन पर पाँच विंडो में दिखते हैं। होमपेज पर मौजूद कैनवस भी यही ऑब्जेक्ट दिखाता है। एक डायरेक्टरी और फ़ाइल स्वामित्व वाला बोर्ड बिना नियमों के तीन एजेंटों को एक ही कोड दें तो वे एक मिनट में एक-दूसरे का काम मिटा देंगे। अंतिम बदलाव बिना सूचना के लागू हो जाएगा और टेस्ट टूटने तक पता नहीं चलेगा। इसलिए एजेंट बदलाव करने से पहले फ़ाइल पाथ रिज़र्व करता है। बोर्ड प्रति पाथ एक होल्डर दर्ज करता है और बाकियों को मना करता है। यह रोक हमारे सर्वर द्वारा लगाई जाती है। यदि टकराव होता भी है, तो तुरंत स्नैपशॉट ले लिया जाता है। बिना पूर्व अनुमति के कोई नहीं लिख सकता। एक रिपॉजिटरी में कई AI एजेंट में बोर्ड का विस्तृत विवरण और परीक्षण डेटा उपलब्ध है। कमरे में मौजूद लोग रीड लिंक मुफ़्त और असीमित हैं। एडिट लिंक प्लान के अनुसार होते हैं। जो भी लिंक खोलता है उसे लाइव टर्मिनल और नाम के साथ घूमते कर्सर दिखाई देते हैं। टैब बंद करने से एजेंट रुकते नहीं हैं। वे कैनवस से जुड़े हैं, इसलिए काम जारी रहता है। AI एजेंटों के साथ मल्टीप्लेयर कोडिंग में दो लोगों के सहयोग का विवरण है। कोड कहाँ जाता है हर प्रोजेक्ट को एक निजी रिपॉजिटरी मिलती है और काम लगातार पुश होता है। मशीन बंद होने से पहले अंतिम बार पुश करती है, इसलिए नष्ट होने वाली चीज़ मशीन है, कोड कभी नहीं। एजेंट कोड चलाने वाली मशीन में कोई डेटाबेस या डिक्रिप्शन की नहीं होती। यदि कोई एजेंट बाहर निकलता भी है, तो उसे प्रोजेक्ट डायरेक्टरी के अलावा कुछ नहीं मिलेगा। AI एजेंटों के लिए क्लाउड सैंडबॉक्स में सुरक्षा की जानकारी दी गई है। नाम की उत्पत्ति Murmell नाम murmuration से आया है, जो हज़ारों पक्षियों के एक साथ उड़ने पर बनने वाली आकृति को दर्शाता है। इसका अर्थ धीमी सुखद आवाज़ (murmur) भी है, और लोगो एक लहर को दर्शाता है। --- ## Murmell이란 무엇인가요? 하나의 리포지토리에서 작업하는 여러 코딩 에이전트 Source: https://murmell.com/ko/what/murmell 링크를 팀원에게 전달하면 즉시 같은 캔버스에 들어와 커서에 이름을 표시하며 동일한 터미널 출력을 실시간으로 함께 볼 수 있습니다. 화면에 표시되는 구성 macOS 창 스타일의 밝은 도트 캔버스입니다. 각 창은 에이전트의 실제 터미널로 클라우드 인스턴스 CLI의 출력 문자를 그대로 표시합니다. 창이 나란히 배치되어 5개의 에이전트 창을 한 화면에서 동시에 모니터링할 수 있습니다. 홈페이지의 캔버스도 동일한 구조로 렌더링됩니다. 단일 디렉터리와 점유 현황을 관리하는 보드 규칙 없이 세 에이전트에게 같은 디렉터리를 맡기면 1분 안에 서로의 코드를 덮어쓰게 됩니다. 마지막 쓰기가 조용히 덮어쓰며 테스트가 실패할 때까지 문제를 알아채기 어렵습니다. 따라서 에이전트는 수정 전 파일 경로를 먼저 선점합니다. 보드는 경로당 단일 점유자만 승인하고 해제 전까지 다른 쓰기를 차단합니다. 이 제어는 서버가 직접 수행합니다. 만약 충돌이 발생하더라도 쓰기 직전에 스냅샷이 자동 생성됩니다. 사전 점유 없는 임의 쓰기는 허용되지 않습니다. 하나의 리포지토리에서 실행되는 여러 AI 에이전트에서 보드의 상세 동작과 실제 측정 결과를 확인하실 수 있습니다. 함께 작업하는 동료들 읽기 전용 링크는 무료이며 무제한 발급됩니다. 편집 링크는 요금제 한도를 따릅니다. 링크를 연 사용자는 터미널 출력과 팀원들의 이름이 달린 커서를 실시간으로 확인할 수 있습니다. 탭을 닫아도 에이전트는 멈추지 않습니다. 작업은 캔버스 상에서 지속 실행됩니다. AI 에이전트와의 멀티플레이어 코딩에서 두 사람이 협업하는 구체적인 방식을 다룹니다. 작성된 코드의 저장 위치 모든 프로젝트에는 전용 비공개 Git 리포지토리가 연결되어 작업물이 지속적으로 푸시됩니다. 머신이 종료되기 전에도 최종 저장을 수행하므로 휘발되는 것은 머신일 뿐 코드가 아닙니다. 에이전트 코드를 실행하는 머신에는 데이터베이스도 복호화 키도 보관되지 않습니다. 비정상 접근이 발생하더라도 프로젝트 파일 외에 탈취할 수 있는 기밀 정보가 없습니다. AI 에이전트를 위한 클라우드 샌드박스에서 보안 관리 방침을 안내합니다. 이름의 유래 Murmell은 수천 마리의 새들이 하나의 형태처럼 군무를 이루는 murmuration에서 따왔습니다. 부드러운 속삭임(murmur)을 뜻하기도 하며, 단일 파동 형태의 로고에 그 의미가 담겨 있습니다. --- ## Murmell とは？1つのリポジトリで動く複数のコーディングエージェント Source: https://murmell.com/ja/what/murmell リンクを共有するだけで相手と同じキャンバスに入り、名前付きカーソルとともに同一ターミナルのログ出力をリアルタイムで確認できます。 画面に見えるもの macOS のようなウィンドウが並ぶ明るいドット柄のキャンバスです。各ウィンドウはエージェントの本物のターミナルであり、クラウドマシン上の CLI 出力がそのまま表示されます。並列配置により、5つのエージェントを1画面で同時に確認できます。 ホームページ上のキャンバスもまったく同一の描画オブジェクトです。 1つのディレクトリとファイルの保有を管理するボード ルールなしに3つのエージェントを同一ディレクトリで動かすと、1分以内にコードが上書きされます。警告なしに最後の書き込みが優先され、テストが壊れるまで気づけません。 そのため、エージェントは変更前にパスを予約します。ボードが1つのパスにつき1つの保持者を記録し、解放されるまで他からの書き込みを拒否します。この制御はサーバーによって行われます。万一衝突が起きた場合も書き込み直前にスナップショットが保存されます。 事前の予約なしに書き込みは行われません。 1つのリポジトリに複数の AI エージェントでボードの詳細な仕様と計測結果を公開しています。 空間にいる人々 閲覧リンクは無料で無制限に発行できます。編集リンクはプラン上限に準じます。リンクを開いた人はターミナルの進行状況と他の参加者の名前付きカーソルをリアルタイムに確認できます。 タブを閉じてもエージェントは停止しません。作業は継続し、戻った際もそのまま稼働しています。AI エージェントとのマルチプレイヤーコーディングで複数人での協調作業について解説しています。 コードの保存先 各プロジェクトには専用のプライベート Git リポジトリが割り当てられ、作業は継続的にプッシュされます。マシン停止時にも最終保存が行われるため、使い捨てなのはマシンでありコードではありません。 エージェントを実行するマシンにはデータベースも復号キーも保持されません。万一エージェントが制御を離れても、そこにあるのはプロジェクトファイルだけであり盗まれる機密情報はありません。AI エージェント用クラウドサンドボックスで機密情報の管理方針を記載しています。 名前の由来 Murmell は数千羽の鳥が一つの生命体のように舞う群舞（murmuration）に由来しています。静かなささやき（murmur）の意味も持ち、ロゴの一筋の波のモチーフとなっています。 --- ## Comparativo de agentes de IA para programar: Claude Code, Cursor, Devin e mais 10 Source: https://murmell.com/pt/what/best-ai-coding-agents A pergunta que organiza tudo Todas essas ferramentas sabem iniciar um agente. O primeiro é fácil: ele lê, escreve, roda os testes. É no segundo que as concepções divergem, porque é preciso decidir o que ele vê e o que tem permissão para tocar. A tabela abaixo não classifica nada: ela diz para quem cada ferramenta serve, uma linha por ferramenta, e os grupos abaixo explicam o porquê. Qual escolher, em uma linha cada FerramentaA escolha certa quando CursorVocê escreve o código você mesmo e quer o melhor teclado. DevinVocê delega um ticket inteiro e volta para ver um resultado. JulesVocê quer aprovar um plano antes que o agente toque em qualquer coisa. Copilot e Agent HQSeu trabalho já está organizado em tickets e a revisão é o ponto de encontro. Codex cloudVocê tem uma conta OpenAI e tarefas bem definidas para delegar. Replit AgentVocê parte do zero e quer um aplicativo no ar ainda hoje à noite. WindsurfVocê edita à mão e quer execuções paralelas no seu disco. ConductorVocê trabalha sozinho em um Mac e o código não pode sair de lá. OpenHands Agent CanvasO código precisa ficar em hardware que você controla, e você quer o código-fonte. Vibe KanbanVocê tem uma fila de tarefas para passar uma a uma no seu computador. CodegOs agentes já rodam na sua máquina e falta uma visão geral. Gemini Code AssistVocê quer um bom agente no editor que já tem, sem pagar nada. Claude Code na webVocê já usa o CLI e a única pergunta é onde ele roda. MurmellVários agentes precisam tocar nos mesmos arquivos, e tem gente assistindo. A tabela de a página de comparações faz a outra pergunta, a de para onde vai o segundo agente. Uma máquina na nuvem por tarefa O agente recebe um clone do seu repositório em uma máquina que você não vê, trabalha em uma branch e entrega uma pull request. É a forma mais comum, e a que exige menos confiança: nada do que ele faz toca sua cópia antes de você ler o diff. Cursor. Um editor por pessoa e uma máquina por agente, contra um canvas e um diretório para todo mundo. Devin. O paralelismo por separação contra o paralelismo por compartilhamento, e quando cada forma é a certa. Jules. Um plano que você aprova e uma pull request que você revisa, contra terminais que você observa em uma única árvore. Copilot e Agent HQ. Onde o trabalho dos agentes converge: na pull request, ou na cópia de trabalho. Codex cloud. Por que executar o CLI Codex em um canvas compartilhado não é a mesma coisa que delegar uma tarefa a ele. Replit Agent. Fabricar um aplicativo do zero, contra fazer vários agentes trabalharem em um código que já existe. Um espaço de trabalho por tarefa, na sua máquina A mesma escolha, na sua casa: um worktree git ou um diretório de trabalho por agente, e uma fusão no final. O código não sai, o que resolve a questão de segurança antes mesmo dela surgir, e mais ninguém vê a sessão. Windsurf. Um worktree por conversa na sua máquina, contra um diretório compartilhado na nuvem. Conductor. Um aplicativo para Mac com um espaço por tarefa, contra um canvas na nuvem com um único diretório para todos. OpenHands Agent Canvas. A comparação mais próxima da lista: um worktree por agente contra uma única árvore com reservas de arquivos. Vibe Kanban. Um quadro kanban sobre execuções locais, contra um canvas compartilhado sobre um diretório na nuvem. Codeg. Reunir sessões locais, contra rodar os agentes em um diretório na nuvem compartilhado. Um agente por vez, no seu editor Sem paralelismo documentado: um agente, supervisionado, na ferramenta onde você já escreve. É o melhor compromisso quando é você quem segura o teclado e o agente te assiste. Gemini Code Assist. Um agente supervisionado no seu editor, contra vários agentes não supervisionados em um diretório que você observa. O mesmo agente, em outro lugar O CLI é idêntico dos dois lados. O que muda é a máquina onde ele roda e o número de pessoas que podem observá-lo. Claude Code na web. O mesmo CLI em dois lugares: uma máquina isolada por tarefa, contra vários agentes em um canvas e uma única cópia de trabalho. O diretório compartilhado, e por que quase ninguém faz isso Falta uma quarta resposta na tabela, e é a nossa: vários agentes em um único diretório, sem cópia. Quase ninguém propõe isso porque exige um árbitro. Sem árbitro, dois agentes leem a mesma versão de um arquivo e o segundo apaga o primeiro sem que nada avise. Murmell coloca esse árbitro no servidor. Um agente anuncia os caminhos que vai tocar antes de escrever, o painel os atribui a ele, e os nega a todos os outros até que ele os libere. Uma escrita que mesmo assim chega em um arquivo detido por outro agente é fotografada antes de ser gravada. O mecanismo em detalhe. Como escolher em dois minutos Se você escreve o código você mesmo, escolha um editor: Cursor, Windsurf ou Gemini Code Assist, e a questão está resolvida. Se suas tarefas são independentes e você quer delegá-las, escolha um agente na nuvem: Devin, Jules ou Codex cloud. Se o código não pode sair da sua rede, escolha algo local e auto-hospedável, com OpenHands à frente. Resta um caso, e é o único que o Murmell trata: vários agentes que precisam tocar nos mesmos arquivos na mesma hora, com gente assistindo. As comparações uma a uma. --- ## Più agenti IA su uno stesso repository Source: https://murmell.com/it/what/multiple-ai-agents-one-repo Il caso che rompe tutto Due agenti ricevono due compiti che toccano lo stesso file. Il primo legge il file, riflette venti secondi, scrive. Il secondo ha letto la stessa versione prima che il primo scrivesse, e scrive sopra. Niente si è bloccato, niente ha avvisato, e il lavoro del primo è sparito. Questo caso non è raro non appena c'è più di un agente, perché gli agenti leggono ampio e scrivono in fretta. È la ragione per cui quasi tutti gli strumenti isolano: una macchina per agente, un branch per agente. Cosa fa il resto del mondo: un worktree per agente La risposta comune a questo problema è il partizionamento: si dà a ogni agente il proprio worktree git, una copia completa dei file con il proprio indice, e ci si assicura che i perimetri non si sovrappongano. È quello che fanno Windsurf, Conductor e OpenHands, ed è quello che raccomandano la maggior parte delle guide. Funziona, e ha esattamente un difetto: il partizionamento è una promessa, non una garanzia. Nessuno verifica che i perimetri non si sovrappongano, e quando si sovrappongono lo si scopre alla fusione, quando entrambi gli agenti hanno finito e nessuno ricorda più il ragionamento. La prenotazione, in tre tempi Prima di scrivere, un agente annuncia i percorsi che toccherà. La bacheca glieli assegna se sono liberi, e li nega se sono occupati. Un solo titolare per file, in ogni istante. Durante il lavoro, un osservatore guarda le scritture reali sul disco e attribuisce ciascuna al proprio autore. Una scrittura su un percorso tenuto da qualcun altro viene fotografata prima di atterrare: la versione precedente viene conservata, quindi nulla va perso anche quando la regola viene aggirata. Alla fine, l'agente rilascia i propri percorsi. Il file torna disponibile per il successivo, senza fusione, perché non sono mai esistite due versioni vive contemporaneamente. Cosa dà a schermo Ogni finestra mostra il proprio agente al lavoro, e la bacheca mostra chi tiene cosa. Si vede che un agente aspetta, e perché. Un agente bloccato è visibile prima che faccia danni, il che è la vera differenza rispetto a una coda invisibile. Anche le persone contano. Più persone sullo stesso canvas pilotano i propri agenti e vedono i cursori degli altri, con un nome su ciascuno. Quando non è la forma giusta Se i tuoi compiti sono davvero indipendenti e lunghi, l'isolamento per macchina resta ragionevole: niente da arbitrare, niente da aspettare. La condivisione vince quando i compiti si toccano, il che è il caso non appena si lavora sulla stessa funzionalità. I confronti dettagliano la scelta strumento per strumento. --- ## Plusieurs agents IA sur un même dépôt Source: https://murmell.com/fr/quoi/plusieurs-agents-ia-un-depot Le cas qui casse tout Deux agents reçoivent deux tâches qui touchent le même fichier. Le premier lit le fichier, réfléchit vingt secondes, écrit. Le second a lu la même version avant que le premier écrive, et il écrit par-dessus. Rien n'a planté, rien n'a averti, et le travail du premier a disparu. Ce cas n'est pas rare dès qu'il y a plus d'un agent, parce que les agents lisent large et écrivent vite. C'est la raison pour laquelle presque tous les outils isolent : une machine par agent, une branche par agent. Ce que fait le reste du monde : un worktree par agent La réponse courante à ce problème est le partitionnement : on donne à chaque agent son propre worktree git, une copie complète des fichiers avec son propre index, et on s'arrange pour que les périmètres ne se chevauchent pas. C'est ce que font Windsurf, Conductor et OpenHands, et c'est ce que recommandent la plupart des guides. Ça marche, et ça a exactement un défaut : le partitionnement est une promesse, pas une garantie. Personne ne vérifie que les périmètres ne se chevauchent pas, et quand ils se chevauchent on l'apprend à la fusion, quand les deux agents ont fini et que plus personne ne se souvient du raisonnement. La réservation, en trois temps Avant d'écrire, un agent annonce les chemins qu'il va toucher. Le tableau les lui attribue s'ils sont libres, et les refuse s'ils sont tenus. Un seul détenteur par fichier, à tout instant. Pendant le travail, un observateur regarde les écritures réelles sur le disque et attribue chacune à son auteur. Une écriture sur un chemin tenu par quelqu'un d'autre est photographiée avant d'atterrir : la version précédente est conservée, donc rien n'est perdu même quand la règle est contournée. À la fin, l'agent rend ses chemins. Le fichier redevient disponible pour le suivant, sans fusion, parce qu'il n'y a jamais eu deux versions vivantes en même temps. Ce que ça donne à l'écran Sur le canvas multi-agents, chaque fenêtre montre son agent (Claude Code, Codex, Kimi) au travail, et le tableau montre qui tient quoi. On voit qu'un agent attend, et pourquoi. Un agent bloqué est visible avant qu'il fasse des dégâts, ce qui est la vraie différence avec une file d'attente invisible. Consultez notre guide pratique pour lancer plusieurs agents. Les gens comptent aussi. Plusieurs personnes sur le même canvas pilotent leurs propres agents et voient les curseurs des autres, avec un nom sur chacun. Quand ce n'est pas la bonne forme Si vos tâches sont vraiment indépendantes et longues, l'isolation par machine reste raisonnable : rien à arbitrer, rien à attendre. Le partage gagne quand les tâches se touchent, ce qui est le cas dès qu'on travaille sur une même fonctionnalité. Les comparatifs détaillent le choix outil par outil. --- ## Programação multiplayer com agentes de IA Source: https://murmell.com/pt/what/multiplayer-coding-with-ai-agents É uma única URL. Ninguém instala nada, ninguém faz cópias locais e ninguém precisa compartilhar a tela para que os outros vejam o trabalho acontecer. O que um convidado vê Você envia um link. Quem o abre vê o canvas ao vivo, não uma gravação. Vê as janelas onde estão e a saída do terminal linha por linha. Vê os outros cursores se moverem com nomes e qual janela cada pessoa está acompanhando. Links de leitura são gratuitos e ilimitados. Links que permitem controlar agentes dependem do seu plano: observar quase não nos custa nada e uma máquina custa o que custa uma máquina. O que cada pessoa pode fazer Cada pessoa controla seus próprios agentes e todos veem todos. É diferente de duas mãos num mesmo teclado: o que é compartilhado é o canvas e o diretório, não um teclado único. Isso é suficiente para o que as pessoas realmente fazem juntas: decidir o que os agentes devem fazer. Você vê uma execução ir para o caminho errado, avisa, e quem tem essa janela a redireciona enquanto todos veem a correção acontecer. Figma para desenvolvedores apresenta o mesmo argumento com uma ferramenta conhecida. Os agentes são os outros participantes Ter vários agentes num mesmo diretório exige engenharia. Um agente reserva os caminhos que vai alterar, o quadro registra um único titular por caminho e os demais são recusados até a liberação. A recusa vem do servidor, não é uma instrução em um prompt. Múltiplos agentes de IA num repositório detalha o mecanismo com medições de testes reais. Sair não interrompe o trabalho Fechar a aba não desliga os agentes. Eles pertencem ao canvas e não ao seu navegador, então o trabalho continua e os resultados gerados continuam lá quando você retorna. O código também não fica apenas naquela máquina. Cada projeto tem um repositório privado, o trabalho é sincronizado continuamente e uma máquina prestes a ser desativada faz um último salvamento. O que é o Murmell cobre o restante em uma página e a página inicial mostra a sala. --- ## Programación multijugador con agentes de IA Source: https://murmell.com/es/what/multiplayer-coding-with-ai-agents Es una sola URL. Nadie instala nada, nadie hace copias y nadie tiene que compartir pantalla para que los demás vean el trabajo. Qué ve un invitado Envías un enlace. Quien lo abre ve el lienzo en vivo, no una grabación. Ve las ventanas en su lugar y la salida de la terminal línea a línea. Ve a los demás cursores moverse con un nombre y qué ventana está mirando cada persona. Los enlaces de lectura son gratuitos y sin límite. Los enlaces para controlar agentes dependen de tu plan: mirar casi no nos cuesta nada y una máquina cuesta lo que cuesta una máquina. Qué puede hacer cada persona Cada persona controla sus propios agentes y todos ven a todos. Es diferente a dos manos en un mismo teclado: lo compartido es el lienzo y el directorio, no un teclado único. Es suficiente para lo que la gente realmente hace junta: decidir qué deben hacer los agentes. Ves que una ejecución va mal, lo dices, y quien tiene esa ventana la redirige mientras todos ven la corrección aplicarse. Figma para desarrolladores plantea el mismo argumento. Los agentes son los otros participantes Tener varios agentes en un mismo directorio requiere ingeniería. Un agente reserva las rutas que va a tocar, el tablero registra un único titular por ruta y los demás son rechazados hasta que se libere. El rechazo viene del servidor, no es una sugerencia en un prompt. Múltiples agentes de IA en un repositorio contiene el mecanismo y las métricas de nuestras pruebas. Cerrar la sesión no lo detiene Cerrar una pestaña no detiene a los agentes. Pertenecen al lienzo y no al navegador, por lo que el trabajo sigue y los resultados siguen ahí al volver. El código tampoco queda únicamente en esa máquina. Cada proyecto tiene un repositorio privado, el trabajo se sincroniza continuamente y una máquina por apagarse hace un último guardado. Qué es Murmell cubre el resto en una sola página y la página principal muestra la sala. --- ## Rodar Claude Code na nuvem: Sem instalação local e com múltiplos agentes Source: https://murmell.com/pt/what/run-claude-code-in-the-cloud O que é preciso antes de começar Um repositório, mesmo vazio. Uma conta em um provedor de modelo, ou uma chave de API. E uma máquina remota que hospeda o diretório e executa os comandos. Murmell cria a máquina e um repositório privado quando você cria o projeto, então na prática só falta conectar a conta do modelo. Um arquivo de instruções na raiz do repositório muda muita coisa: como o projeto é iniciado, o que não pode quebrar, o jeito como a equipe escreve. Os agentes o leem ao iniciar, e é a melhor relação entre o tempo gasto e a qualidade obtida. Como é uma hora Você descreve uma tarefa em uma frase. O agente lê os arquivos envolvidos, escreve, roda os testes, lê o erro, corrige. Você não acompanha cada passo: olha o terminal quando ele para, e revisa o diff. Com o segundo agente, a questão vira a divisão. Dois agentes em dois cantos do projeto avançam em paralelo; dois agentes no mesmo arquivo pisam um no outro. No Murmell, cada um reserva seus caminhos antes de escrever, então a colisão é recusada em vez de descoberta depois. Quanto custa, em duas linhas Existem duas faturas e é melhor separá-las. Os tokens do modelo são pagos ao seu provedor, na sua conta. A máquina e a sala são pagas ao operador. Murmell não revende tokens, o que significa que sua assinatura Claude ou sua chave OpenAI continua sendo a que você usa. A armadilha comum Lançar três agentes em três cópias do repositório parece o caminho óbvio e cobra o preço na mesma noite: três branches, três fusões, e conflitos que ninguém viu chegar. Compartilhar um diretório com uma regra de escrita dá menos trabalho de costura. Como a regra funciona, e o que contém a máquina. --- ## Ejecutar Claude Code en la nube: sin instalación local y con múltiples agentes Source: https://murmell.com/es/what/run-claude-code-in-the-cloud Lo que hace falta antes de empezar Un repositorio, aunque esté vacío. Una cuenta en un proveedor de modelos, o una clave de API. Y una máquina remota que aloje el directorio y ejecute los comandos. Murmell crea la máquina y un repositorio privado cuando creas el proyecto, así que en la práctica solo queda conectar la cuenta del modelo. Un archivo de instrucciones en la raíz del repositorio cambia muchas cosas: cómo se lanza el proyecto, qué no hay que romper, cómo escribe el equipo. Los agentes lo leen al arrancar, y es la mejor relación entre tiempo invertido y calidad obtenida. Cómo es una hora Describes una tarea en una frase. El agente lee los archivos afectados, escribe, lanza las pruebas, lee el error, corrige. No miras cada paso: miras la terminal cuando se detiene, y revisas el diff. Con el segundo agente, la pregunta pasa a ser el reparto. Dos agentes en dos rincones del proyecto avanzan en paralelo; dos agentes en el mismo archivo se pisan. En Murmell, cada uno reserva sus rutas antes de escribir, así que la colisión se rechaza en vez de descubrirse más tarde. Lo que cuesta, en dos líneas Existen dos facturas y conviene separarlas. Los tokens del modelo se pagan a tu proveedor, en tu cuenta. La máquina y la sala se pagan al operador. Murmell no revende tokens, lo que significa que tu suscripción a Claude o tu clave de OpenAI sigue siendo la que ya usas. La trampa habitual Lanzar tres agentes en tres copias del repositorio parece el camino evidente y cuesta esa misma noche: tres ramas, tres fusiones, y conflictos que nadie vio venir. Compartir un directorio con una regla de escritura da menos trabajo de costura. Cómo funciona la regla, y qué contiene la máquina. --- ## Eseguire Claude Code nel cloud: Senza installazione locale e con più agenti Source: https://murmell.com/it/what/run-claude-code-in-the-cloud Cosa serve prima di iniziare Un repository, anche vuoto. Un account presso un fornitore di modelli, o una chiave API. E una macchina remota che ospita la cartella ed esegue i comandi. Murmell crea la macchina e un repository privato quando crei il progetto, quindi in pratica resta da collegare l'account del modello. Un file di istruzioni nella radice del repository cambia molte cose: come si lancia il progetto, cosa non va rotto, il modo in cui il team scrive. Gli agenti lo leggono all'avvio, ed è il miglior rapporto tra tempo speso e qualità ottenuta. A cosa somiglia un'ora Descrivi un compito in una frase. L'agente legge i file coinvolti, scrive, lancia i test, legge l'errore, corregge. Non guardi ogni passaggio: guardi il terminale quando si ferma, e rileggi il diff. Al secondo agente, la domanda diventa la ripartizione. Due agenti su due angoli del progetto avanzano in parallelo; due agenti sullo stesso file si pestano i piedi. Su Murmell, ognuno riserva i propri percorsi prima di scrivere, quindi la collisione viene rifiutata invece di essere scoperta più tardi. Quanto costa, in due righe Esistono due fatture ed è meglio tenerle separate. I token del modello si pagano al tuo fornitore, sul tuo account. La macchina e la stanza si pagano al gestore. Murmell non rivende token, il che significa che il tuo abbonamento Claude o la tua chiave OpenAI restano quelli che usi già. La trappola abituale Lanciare tre agenti su tre copie del repository sembra la via ovvia e costa la sera stessa: tre branch, tre fusioni, e conflitti che nessuno ha visto arrivare. Condividere una cartella con una regola di scrittura dà meno lavoro di ricucitura. Come funziona la regola, e cosa contiene la macchina. --- ## Run Claude Code in the cloud Source: https://murmell.com/what/run-claude-code-in-the-cloud Codex runs the same way, in a window of its own on the same canvas and in the same project directory. Your laptop stops being the runtime There is nothing to install. The agent’s process and its checkout live on the cloud machine. Your browser sends keystrokes and draws what comes back, so a closed lid has no effect on a run in progress and a long build does not heat up the machine you are sitting at. It also means the computer in front of you stops mattering. Any machine with a browser reaches the same canvas and the same session. Claude Code in the browser is that half of it. The credentials do not travel with the agent Connecting a code host takes a token with repo scope. It is encrypted before it is stored, and it never reaches the machines your agents run on. The machine that executes agent code holds no database and no decryption key. Agents can read the repository history. They cannot rewrite it. A cloud sandbox for AI agents lists what is on that machine and what is deliberately not. The reason to move it off your machine Running one agent on somebody else’s computer would be a convenience. The reason it is worth doing is that several agents can then share one directory. An agent claims the paths it is about to touch, and the board records one holder per path and refuses everyone else until the holder releases it. That rule is enforced by our server rather than requested in a prompt, which is what makes three agents in one checkout survive the afternoon. Multiple AI agents on one repo has the mechanism, and the home page draws it. The machine is disposable, the repository is not Every project gets a private repository. Work is pushed to it as the project goes, and a machine about to be torn down pushes once more before it goes. The code outlives the machine that wrote it, which is what lets us throw machines away freely. --- ## O que é o Murmell? Vários agentes de código num repositório Source: https://murmell.com/pt/what/murmell Envie o link para alguém e essa pessoa entra no canvas com você, vendo os mesmos terminais avançarem com o nome dela no cursor. O que você vê Um canvas claro com janelas desenhadas no estilo do macOS. Cada janela é o terminal de um agente, mostrando a saída real da CLI em nossas máquinas com os caracteres exatos impressos. As janelas ficam lado a lado, então cinco agentes são cinco janelas numa tela única. O canvas na página inicial é o mesmo objeto desenhado. Um diretório e um quadro que registra quem detém o quê Dê a três agentes o mesmo diretório sem regras e eles se sobrescreverão em menos de um minuto. A última gravação vence em silêncio e ninguém percebe até que um teste quebre. Por isso um agente reserva os caminhos antes de alterá-los. O quadro registra um titular por caminho e recusa todos os outros até que seja liberado. Essa recusa vem do nosso servidor. Se houver uma colisão, um snapshot é feito imediatamente antes. Ninguém escreve sem pedir permissão antes. Múltiplos agentes de IA num repositório explica o quadro detalhadamente com dados de nossas medições. As pessoas na sala Um link de leitura é gratuito e sem limite. Links de edição dependem do seu plano. Quem abre o link vê os terminais em tempo real e os cursores das outras pessoas com nomes. Fechar a aba não desliga os agentes. Eles pertencem ao canvas, então o trabalho continua sem você e segue rodando quando você volta. Programação multiplayer com agentes de IA explica o que duas pessoas podem fazer juntas. Para onde vai o código Cada projeto recebe um repositório privado e o trabalho é sincronizado continuamente. Uma máquina prestes a ser desativada faz um último push antes de desligar, então a parte descartável é a máquina, nunca o código. A máquina que executa o código não armazena bancos de dados nem chaves de descriptografia. Um agente que escape encontrará apenas um diretório de projeto sem nada de valor para roubar. Uma sandbox na nuvem para agentes de IA detalha onde residem os segredos. De onde vem o nome Murmell vem de murmuration, a forma que um bando cria quando milhares de pássaros se movem como um só. A mesma palavra evoca um murmúrio suave, e esse é o logotipo: uma única onda. --- ## AI coding agents, sorted by what separates them Source: https://murmell.com/what/best-ai-coding-agents The question that sorts the field All of these tools can start an agent. The first one is easy: it reads, it writes, it runs the tests. The designs diverge at the second, because somebody has to decide what it sees and what it is allowed to touch. The table below ranks nothing: it says who each tool is for, one line per tool, and the groups underneath explain why. Which to take, one line each ToolThe right choice when CursorYou write the code yourself and want the best keyboard. DevinYou hand over a whole ticket and come back to a result. JulesYou want to approve a plan before the agent touches anything. Copilot and Agent HQYour work is already in tickets and review is the meeting point. Codex cloudYou have an OpenAI account and scoped tasks to delegate. Replit AgentYou are starting from nothing and want an app online tonight. WindsurfYou edit by hand and want parallel runs on your own disk. ConductorYou work alone on a Mac and the code must not leave it. OpenHands Agent CanvasThe code has to stay on hardware you control, and you want the source. Vibe KanbanYou have a queue of tasks to push through one at a time on your machine. CodegThe agents already run on your machine and there is no overview. Gemini Code AssistYou want a good agent in the editor you already have, for nothing. Claude Code on the webYou already use the CLI and the only question is where it runs. MurmellSeveral agents have to touch the same files, and people are watching. The table on the comparisons page asks the other question, the one about where a second agent goes. A cloud machine of its own, per task The agent gets a clone of your repository on a machine you never see, works on a branch and hands back a pull request. It is the most common shape and the one that asks for the least trust: nothing it does touches your checkout before you have read the diff. Cursor. One editor per person and one VM per agent, against one canvas and one directory for everybody. Devin. Parallel by separation against parallel by sharing, and when each shape is the right one. Jules. A plan you approve and a pull request you review, against terminals you watch in one shared tree. Copilot and Agent HQ. Where agent work converges: at the pull request, or in the working tree. Codex cloud. Why running the Codex CLI on a shared canvas is a different thing from delegating a task to it. Replit Agent. Building an app from nothing against running several agents on a codebase that already exists. A workspace per task, on your own machine The same choice, at home: a git worktree or a working directory per agent, and a merge at the end. The code never leaves, which settles the security conversation before it starts, and nobody else sees the session. Windsurf. A worktree per conversation on your own machine, against one shared directory in the cloud. Conductor. A Mac app with a workspace per task, against a cloud canvas with one directory for all of them. OpenHands Agent Canvas. The closest comparison on the list: a worktree per agent against one tree with file reservations. Vibe Kanban. A kanban board over local agent runs, against a shared canvas over one cloud directory. Codeg. Aggregating local agent sessions against running the agents on one shared cloud directory. One agent at a time, in your editor No documented parallelism: one supervised agent, in the tool where you write. It is the best trade when you are the one holding the keyboard and the agent is assisting you. Gemini Code Assist. One supervised agent in your editor, against several unsupervised ones in a directory you watch. The same agent, somewhere else The CLI is identical on both sides. What changes is the machine it runs on and how many people can watch it. Claude Code on the web. The same CLI in two places: one isolated VM per task, against several agents on one canvas and one checkout. The shared directory, and why almost nobody offers it There is a fourth answer missing from the table, and it is ours: several agents in one directory, with no copies. Almost nobody offers it because it needs an arbiter. Without one, two agents read the same version of a file and the second erases the first with nothing to announce it. Murmell puts that arbiter in the server. An agent announces the paths it is about to touch before it writes, the board hands them over, and refuses everybody else until it lets go. A write that lands on a file somebody else holds is snapshotted before it lands. The mechanism in full. How to choose in two minutes If you write the code yourself, take an editor: Cursor, Windsurf or Gemini Code Assist, and the question is settled. If your tasks are independent and you want to hand them over, take a cloud agent: Devin, Jules or Codex cloud. If the code is not allowed to leave your network, take something local and open source, OpenHands first. One case is left, and it is the only one Murmell is built for: several agents that have to touch the same files in the same hour, with people watching. The comparisons, one at a time. --- ## Was ist Murmell? Mehrere Programmier-Agenten in einem Repository Source: https://murmell.com/de/what/murmell Senden Sie den Link an eine andere Person und diese betritt mit Ihnen das Canvas, beobachtet die Terminals live und sieht ihren Namen am Cursor. Was Sie vor sich sehen Ein helles Raster-Canvas mit Fenstern im Stil von macOS. Jedes Fenster ist das Terminal eines Agenten und zeigt die tatsächliche CLI-Ausgabe unserer Maschinen. Die Fenster liegen nebeneinander, sodass fünf Agenten fünf Fenster auf einem Bildschirm bilden. Das Canvas auf der Startseite zeigt genau dieses Objekt. Ein Verzeichnis und ein Board zur Zuweisung von Dateien Gibt man drei Agenten dasselbe Verzeichnis ohne Regeln, überschreiben sie sich innerhalb einer Minute gegenseitig. Der letzte Schreibvorgang gewinnt unbemerkt, bis ein Test fehlschlägt. Daher reserviert ein Agent Pfade vor dem Bearbeiten. Das Board registriert einen Inhaber pro Pfad und weist alle anderen ab, bis die Freigabe erfolgt. Diese Abweisung erfolgt durch unseren Server. Bei einer Kollision wird vorab ein Snapshot erstellt. Niemand schreibt ohne vorherige Anfrage. Mehrere KI-Agenten in einem Repository erläutert das Board im Detail mit Messwerten aus Tests mit zwei Agenten. Die Personen im Raum Lese-Links sind kostenlos und unbegrenzt nutzbar. Bearbeitungs-Links richten sich nach Ihrem Tarif. Wer einen Link öffnet, sieht die Fenster live und die Cursor anderer Personen mit Namen. Einen Tab zu schließen stoppt die Agenten nicht. Sie gehören zum Canvas, die Arbeit läuft weiter und steht bei der Rückkehr bereit. Multiplayer-Coding mit KI-Agenten beschreibt, wie zwei Personen auf einem Canvas zusammenarbeiten. Wohin der Code geht Jedes Projekt erhält ein privates Git-Repository und die Arbeit wird fortlaufend synchronisiert. Eine Maschine vor der Abschaltung führt einen letzten Push aus, sodass stets nur die Maschine austauschbar ist, niemals der Code. Die Maschine, auf der der Agenten-Code ausgeführt wird, enthält keine Datenbank und keine Entschlüsselungsschlüssel. Ein ausbrechender Agent findet lediglich ein Projektverzeichnis ohne schützenswerte Geheimnisse. Eine Cloud-Sandbox für KI-Agenten zeigt, wo Geheimnisse verwahrt werden. Woher der Name stammt Murmell leitet sich von Murmuration ab, dem Formationsflug tausender Vögel als geschlossene Einheit. Das Wort bezeichnet auch ein sanftes Murmeln, was sich im Logo widerspiegelt: eine einzelne Welle. --- ## Vários agentes de IA em um mesmo repositório Source: https://murmell.com/pt/what/multiple-ai-agents-one-repo O caso que quebra tudo Dois agentes recebem duas tarefas que tocam o mesmo arquivo. O primeiro lê o arquivo, pensa por vinte segundos, escreve. O segundo leu a mesma versão antes de o primeiro escrever, e escreve por cima. Nada travou, nada avisou, e o trabalho do primeiro desapareceu. Esse caso não é raro assim que há mais de um agente, porque os agentes leem amplo e escrevem rápido. É por isso que quase todas as ferramentas isolam: uma máquina por agente, uma branch por agente. O que o resto do mundo faz: um worktree por agente A resposta comum a esse problema é o particionamento: dá-se a cada agente seu próprio worktree git, uma cópia completa dos arquivos com seu próprio índice, e organiza-se para que os perímetros não se sobreponham. É o que fazem Windsurf, Conductor e OpenHands, e é o que a maioria dos guias recomenda. Funciona, e tem exatamente um defeito: o particionamento é uma promessa, não uma garantia. Ninguém verifica se os perímetros não se sobrepõem, e quando se sobrepõem isso só se descobre na fusão, quando os dois agentes já terminaram e ninguém mais se lembra do raciocínio. A reserva, em três tempos Antes de escrever, um agente anuncia os caminhos que vai tocar. O painel os atribui a ele se estiverem livres, e os nega se estiverem ocupados. Um único titular por arquivo, a qualquer momento. Durante o trabalho, um observador acompanha as escritas reais no disco e atribui cada uma ao seu autor. Uma escrita em um caminho detido por outro agente é fotografada antes de ser gravada: a versão anterior é preservada, então nada se perde mesmo quando a regra é contornada. No final, o agente libera seus caminhos. O arquivo volta a ficar disponível para o próximo, sem fusão, porque nunca existiram duas versões vivas ao mesmo tempo. Como isso aparece na tela Cada janela mostra seu agente trabalhando, e o painel mostra quem detém o quê. Dá para ver que um agente está esperando, e por quê. Um agente bloqueado fica visível antes de causar estrago, que é a real diferença em relação a uma fila de espera invisível. As pessoas também contam. Várias pessoas no mesmo canvas pilotam seus próprios agentes e veem os cursores dos outros, cada um com um nome. Quando essa não é a forma certa Se suas tarefas são realmente independentes e longas, o isolamento por máquina continua sendo razoável: nada para arbitrar, nada para esperar. O compartilhamento ganha quando as tarefas se tocam, o que acontece assim que se trabalha na mesma funcionalidade. As comparações detalham a escolha ferramenta por ferramenta. --- ## Varios agentes de IA en un mismo repositorio Source: https://murmell.com/es/what/multiple-ai-agents-one-repo El caso que lo rompe todo Dos agentes reciben dos tareas que tocan el mismo archivo. El primero lee el archivo, piensa veinte segundos, escribe. El segundo leyó la misma versión antes de que el primero escribiera, y escribe encima. Nada falló, nada avisó, y el trabajo del primero desapareció. Este caso no es raro en cuanto hay más de un agente, porque los agentes leen mucho y escriben rápido. Es la razón por la que casi todas las herramientas aíslan: una máquina por agente, una rama por agente. Lo que hace el resto del mundo: un worktree por agente La respuesta habitual a este problema es el particionamiento: se le da a cada agente su propio worktree de git, una copia completa de los archivos con su propio índice, y se procura que los perímetros no se solapen. Es lo que hacen Windsurf, Conductor y OpenHands, y es lo que recomiendan la mayoría de las guías. Funciona, y tiene exactamente un defecto: el particionamiento es una promesa, no una garantía. Nadie comprueba que los perímetros no se solapen, y cuando se solapan se descubre en la fusión, cuando los dos agentes han terminado y ya nadie recuerda el razonamiento. La reserva, en tres tiempos Antes de escribir, un agente anuncia las rutas que va a tocar. El tablero se las asigna si están libres, y se las niega si están ocupadas. Un único titular por archivo, en todo momento. Durante el trabajo, un observador mira las escrituras reales en el disco y atribuye cada una a su autor. Una escritura en una ruta que tiene otro se fotografía antes de aterrizar: se conserva la versión anterior, así que nada se pierde aunque se salte la regla. Al final, el agente devuelve sus rutas. El archivo vuelve a estar disponible para el siguiente, sin fusión, porque nunca existieron dos versiones vivas al mismo tiempo. Lo que se ve en pantalla Cada ventana muestra a su agente trabajando, y el tablero muestra quién tiene qué. Se ve que un agente espera, y por qué. Un agente atascado se ve antes de causar daño, y esa es la diferencia real con una cola invisible. La gente también cuenta. Varias personas en el mismo canvas manejan sus propios agentes y ven los cursores de los demás, con un nombre en cada uno. Cuándo no es la forma correcta Si tus tareas son de verdad independientes y largas, el aislamiento por máquina sigue siendo razonable: nada que arbitrar, nada que esperar. Compartir gana cuando las tareas se tocan, lo que ocurre en cuanto se trabaja en la misma función. Las comparativas detallan la elección herramienta por herramienta. --- ## Verrouillage de fichiers pour agents IA : éviter les collisions Source: https://murmell.com/fr/quoi/verrouillage-de-fichiers-agents-ia Le problème des collisions multi-agents Lorsque des développeurs font tourner plusieurs agents IA en local, chaque agent suppose qu'il est le seul à modifier le projet. Si deux agents examinent le même fichier, chacun prépare des modifications basées sur cette vue initiale. Le dernier qui écrit écrase le travail du premier sans le moindre avertissement. Cette corruption silencieuse casse les suites de tests et détruit des heures de travail. Demander aux modèles d'être prudents dans leurs instructions ne suffit pas, car ils ne peuvent pas surveiller le système de fichiers en continu. Comment fonctionne la réservation côté serveur Murmell résout cette concurrence avec Le Tableau, un registre de réservation en direct intégré au conteneur cloud. Demande : L'agent signale les chemins qu'il s'apprête à modifier. Attribution : Le serveur lui accorde le verrou s'il est libre, ou fait patienter l'agent. Libération : Une fois les modifications enregistrées, le fichier redevient accessible aux autres. Puisque la règle est appliquée par le serveur et non par une consigne dans un prompt, aucun agent ne peut outrepasser le verrouillage. Lisez notre explication complète sur plusieurs agents IA sur un même dépôt. Les captures de sécurité en cas de conflit Si une écriture imprévue tente de contourner la réservation, Murmell réalise automatiquement une capture instantanée avant d'appliquer le changement. Les deux versions sont conservées, ce qui permet aux développeurs de comparer les diffs sans perte de données. Orchestration des agents sur le canvas Ce verrouillage rend le développement multi-agents pratique et fluide. Vous pouvez combiner Anthropic Claude Code et OpenAI Codex dans le cloud en toute sécurité sur le canvas multi-agents. Suivez notre guide sur comment coordonner Claude Code et Codex. --- ## Глоссарий ИИ-кода в облаке Source: https://murmell.com/ru/what/glossary ИИ-агент для кода Программа, которая получает цель в одну фразу и работает, пока не достигнет её: читает файлы, пишет, запускает тесты, читает ошибку и пробует снова. Она выполняет команды, что и отличает её от ассистента, предлагающего текст. Облачный ИИ Три разные вещи, в зависимости от того, кто говорит: модель, размещённая у поставщика, API, вызываемый из вашего софта, или агент, выполняющийся на удалённой машине. Только третье значение подразумевает, что что-то продолжается, когда вы закрываете вкладку. Агентный ИИ ИИ, который преследует цель вместо того, чтобы отвечать на вопрос: он выбирает действия, выполняет их и повторяет, пока результат не устроит. Слово говорит о том, что делает программа, тогда как «облачный ИИ» говорит о том, где она работает. Worktree Вторая рабочая копия git-репозитория, со своим индексом, на другой ветке. Это самый распространённый способ запускать несколько агентов, не мешая друг другу, и он стоит одного слияния на копию. Разбиение Распределение файлов между агентами так, чтобы они не пересекались. Работает, пока распределение точное, а этого никто не проверяет. Это обещание, а не гарантия. Канвас Поверхность, на которой расположены окна агентов, а в каждом окне терминал. Открывается по ссылке, и у наблюдающих есть именованный курсор. Резервирование файла Объявление агентом путей, которые он собирается записать, перед тем как их записать. У пути только один владелец, и это применяет сервер, что позволяет нескольким агентам делить каталог, не перезаписывая друг друга. Столкновение Запись на файл, которым владеет кто-то другой. Она снимается снимком до того, как попадает на диск, поэтому предыдущая версия по-прежнему существует и ничего не теряется. Песочница (sandbox) Изолированная машина, на которой выполняется код агентов. В Murmell одна на проект, без базы данных и ключа расшифровки: то, что там происходит, стоит только эту машину. Одноразовая машина Машина, созданная для одной сессии и уничтоженная после неё. Всё, что должно выжить, отправляется в репозиторий до уничтожения. Контекст То, что модель видит перед собой в момент ответа: ваш запрос, прочитанные файлы, история сессии. Его размер ограничен, чем и объясняется, почему агент забывает начало очень длинной сессии. Токен Единица учёта и оплаты моделей, примерно равная фрагменту слова. Цена сессии считается в прочитанных и написанных токенах, у вашего поставщика модели. CLI Программа, которой управляют с клавиатуры в терминале. Claude Code, Codex, Kimi и OpenCode относятся к этой категории, поэтому их можно запускать на удалённой машине и отображать во вкладке. Терминал Текстовое окно, в котором печатаются команды и идёт вывод. В Murmell это настоящий терминал на удалённой машине, перенесённый в браузер, а не имитация. Репозиторий Место с версионированием, где живёт код. Каждый проект Murmell получает свой, приватный, и работа отправляется туда по мере сессии. Ссылка для чтения Адрес, который позволяет смотреть на канвас без аккаунта и без оплаты. Видны окна, терминалы в реальном времени и курсоры, но трогать нельзя. Многопользовательский режим Состояние, при котором несколько человек находятся на одном канвасе одновременно, каждый управляет своими агентами, а курсоры остальных видны с именем и цветом. Подробная версия трёх из этих статей: Облачный ИИ, облачный ИИ-агент и резервирование файлов. --- ## Облачная машина, на которой работают агенты Source: https://murmell.com/ru/what/cloud-sandbox-for-ai-agents Почему песочница Также говорят «сэндбокс», и это слово используют в большинстве документаций. Полезный агент выполняет команды, которые сам же написал. Установить пакет, запустить скрипт, открыть порт. Ни одна команда не проходит проверку человеком заранее, а значит единственная серьёзная защита, это место, где она выполняется. Отсюда правило: на машине, выполняющей код, нет ничего интересного. Ни базы данных, ни ключа расшифровки, ни учётных данных другого клиента. Инцидент на этой машине стоит только эту машину. Что она содержит Каталог проекта, CLI агентов и то, что агенты устанавливают для работы. Учётные данные, которые вы подключаете, используются агентами на время сессии и не покидают этот периметр. Канвас, комната и доска резервирований работают в другом месте. Агент, который написал бы что угодно на свой диск, всё равно не смог бы решить, кто владеет файлом: этот арбитраж находится не на машине, которую он контролирует. Одна машина на проект Изоляция между проектами не настройка, а сама форма продукта. Каждый канвас запускает свою машину, и два проекта никогда не делят файловую систему. Это же делает окружение воспроизводимым: проект каждый раз стартует с известного образа. И код, в конце Приватный репозиторий создаётся вместе с проектом, и работа отправляется туда по мере сессии, с последней отправкой перед уничтожением машины. То, что вы получаете, это обычный репозиторий, ваш собственный, читаемый без Murmell. Как проходит сессия. --- ## Мультиплеерное программирование с ИИ-агентами Source: https://murmell.com/ru/what/multiplayer-coding-with-ai-agents Достаточно одной ссылки. Не нужно ничего устанавливать, делать копии или демонстрировать экран. Что видит гость Вы отправляете ссылку. Открывший ее видит живой холст, а не запись: окна на своих местах, посимвольный вывод терминала, перемещение именных курсоров и активные окна участников. Ссылки для чтения бесплатны и не ограничены по количеству. Ссылки с правом управления агентами зависят от тарифа: просмотр почти ничего не стоит, тогда как аренда облачной машины имеет фиксированную стоимость. Что может делать каждый участник Каждый человек управляет своими агентами, и все видят общую картину. Это отличается от двух рук на одной клавиатуре: общими являются холст и директория проекта, а не одно окно ввода. Этого достаточно для главной совместной задачи: определять, что именно должны делать агенты. Если агент сбивается с курса, участники замечают это, и куратор окна вносит исправления на глазах у всех. Статья Figma для разработчиков описывает ту же логику на знакомом примере. Агенты как полноценные участники Работа нескольких агентов в одной рабочей копии требует инженерных решений. Агент резервирует пути перед записью, доска фиксирует единственного владельца, а остальные получают отказ до момента освобождения. Отказ формируется нашим сервером и не может быть проигнорирован моделью. В статье Несколько ИИ-агентов в одном репозитории подробно описан механизм и приведены данные реальных замеров. Закрытие вкладки не прерывает процесс Закрытие вкладки не останавливает агентов. Они принадлежат холсту, а не браузеру, поэтому работа продолжается, а результаты будут доступны при повторном входе. Код не остается запертым на виртуальной машине. Каждый проект подключен к приватному Git-репозиторию, изменения непрерывно пушатся, а перед выключением машины выполняется финальное сохранение. Обзорный материал Что такое Murmell обобщает ключевые концепции, а главная страница демонстрирует рабочее пространство. --- ## Несколько ИИ-агентов в одном репозитории Source: https://murmell.com/ru/what/multiple-ai-agents-one-repo Случай, который всё ломает Два агента получают две задачи, затрагивающие один и тот же файл. Первый читает файл, думает двадцать секунд, пишет. Второй прочитал ту же версию до того, как первый записал, и пишет поверх. Ничего не сломалось, никто не предупредил, а работа первого исчезла. Этот случай не редкость, как только агентов становится больше одного, потому что агенты читают широко и пишут быстро. Именно поэтому почти все инструменты выбирают изоляцию: одна машина на агента, одна ветка на агента. Что делают остальные: worktree на агента Обычный ответ на эту проблему, разбиение: каждому агенту дают собственный git worktree, полную копию файлов со своим индексом, и следят, чтобы зоны не пересекались. Так делают Windsurf, Conductor и OpenHands, и это рекомендует большинство руководств. Это работает, и у этого есть ровно один недостаток: разбиение, это обещание, а не гарантия. Никто не проверяет, что зоны не пересекаются, а когда они пересекаются, об этом узнают при слиянии, когда оба агента закончили и уже никто не помнит рассуждений. Резервирование, в трёх шагах Перед тем как писать, агент объявляет пути, которые собирается затронуть. Доска выделяет их ему, если они свободны, и отказывает, если заняты. У файла всегда только один владелец. Во время работы наблюдатель следит за реальными записями на диске и связывает каждую с её автором. Запись по пути, занятому кем-то другим, снимается снимком до того, как попадает на диск: предыдущая версия сохраняется, поэтому ничего не теряется, даже если правило обошли. В конце агент отпускает свои пути. Файл снова становится доступным для следующего, без слияния, потому что живых версий никогда не было одновременно две. Что видно на экране Каждое окно показывает своего агента за работой, а доска показывает, кто что держит. Видно, что агент ждёт, и почему. Застрявший агент виден до того, как он успевает навредить, и это настоящая разница с невидимой очередью. Люди тоже учитываются. Несколько человек на одном канвасе управляют своими агентами и видят курсоры друг друга, у каждого своё имя. Когда эта форма не подходит Если ваши задачи действительно независимы и продолжительны, изоляция по машинам остаётся разумной: нечего координировать, нечего ждать. Совместное использование побеждает, когда задачи соприкасаются, а это происходит, как только несколько человек работают над одной функцией. Сравнения разбирают этот выбор по каждому инструменту. --- ## Что такое Murmell? Несколько кодинг-агентов в одном репозитории Source: https://murmell.com/ru/what/murmell Отправьте ссылку коллеге, и он окажется на холсте вместе с вами, наблюдая за выводом терминалов с именем на своем курсоре. Что вы видите перед собой Светлый точечный холст с окнами в стиле macOS. Каждое окно — это терминал агента, транслирующий реальный вывод CLI на наших серверах. Окна расположены рядом, поэтому пять агентов — это пять окон на одном экране для одновременного контроля. Холст на главной странице представляет собой этот же интерактивный объект. Одна директория и доска резервирования файлов Если предоставить трем агентам одну рабочую копию без правил, они перезапишут код друг друга в течение минуты. Последняя запись побеждает без предупреждений, пока не упадут тесты. Поэтому агент резервирует пути перед внесением изменений. Доска закрепляет один путь за одним владельцем и отклоняет запросы остальных до момента освобождения. Контроль выполняется сервером. При возникновении конфликта автоматически создается снимок состояния. Никто не пишет в файл без предварительного запроса. В статье Несколько ИИ-агентов в одном репозитории подробно описана работа доски с замерами из наших тестов. Люди в одной комнате Ссылки для чтения бесплатны и не имеют лимитов. Ссылки с правом редактирования регулируются тарифом. Любой открывший ссылку видит работу терминалов в реальном времени и именные курсоры коллег. Закрытие вкладки не останавливает агентов. Процессы продолжаются на холсте независимо от вашего присутствия. Материал Мультиплеерное программирование с ИИ-агентами рассказывает о совместной работе команды. Куда сохраняется код Каждый проект подключается к приватному Git-репозиторию, куда непрерывно отправляются изменения. Перед завершением работы машины выполняется финальный push, поэтому временной является только машина, но не код. Машина, исполняющая код агентов, не содержит баз данных и ключей дешифрования. В случае нештатного поведения агент обнаружит только рабочую директорию проекта. Статья Облачная песочница для ИИ-агентов описывает архитектуру безопасности. Происхождение названия Murmell происходит от слова murmuration — скоординированного полета тысяч птиц как единого целого. Слово также созвучно с мягким шепотом, что отражено в логотипе в виде плавной волны. --- ## Облачный ИИ для разработчиков: Разница между моделями, API и автономными кодинг-агентами Source: https://murmell.com/ru/what/cloud-ai Три вещи под одним словом Первое значение самое старое: модель, размещённая где-то ещё. Вы ничего не скачиваете, отправляете вопрос и получаете ответ. Это то, что делает ассистент во вкладке браузера. Второе, значение технических команд: API. Модель становится кирпичиком в программе, которую вы пишете, и оплачивается за токен. Машина остаётся у поставщика, логика остаётся у вас. Третье более новое, и именно оно меняет день человека, пишущего код. Агент выполняется на удалённой машине, с файловой системой, терминалом, сетевым доступом. Он устанавливает зависимости, запускает тесты, читает ошибки, пробует снова. Вы не разговариваете с ним на каждом шаге, вы даёте ему цель. Слово рядом: агентный «Агентный ИИ» обозначает третье значение, но с точки зрения программы, а не машины: ИИ, который преследует цель, выбирает действия и повторяет попытки самостоятельно, пока тесты не пройдут. На практике эти два термина почти всегда пересекаются, потому что программе, работающей самостоятельно сорок минут, нужна машина, которая остаётся включённой. Что на самом деле отличает третье значение ИИ, который отвечает, останавливается, когда вы закрываете вкладку, потому что ему нечего было делать между вопросами. Агент на удалённой машине продолжает: процесс живёт на машине, а не в браузере. Это единственное из трёх значений, где закрытие компьютера ничего не стоит. Следствие арифметическое. Если один агент помещается на одной машине, два агента помещаются на двух, а пять на пяти. Работа перестаёт ограничиваться числом открытых перед вами терминалов. Где всё заедает, когда их несколько Большинство инструментов решают этот вопрос изоляцией: один агент, одна машина, одна ветка, и слияние в конце. Это работает до момента, когда два агента изменили один и тот же файл, и никто не узнал об этом, пока оба не закончили. Другой путь, совместное использование с правилом. Агенты живут в одном каталоге, и агент занимает путь перед тем, как в него писать. У файла только один владелец, и это применяет сервер, а не просьба к модели. Это форма, которую выбрал Murmell. Вопросы, которые стоит задать перед выбором Кто владеет машиной, и что на ней есть, кроме вашего кода. Сколько она живёт, и что остаётся, когда её уничтожают. За что вы платите: за машину, за токены модели, или за то и другое. И можно ли использовать существующую подписку на агента повторно, или придётся покупать новую. По последнему пункту ответ Murmell короткий: вы подключаете аккаунты, за которые уже платите, а счёт покрывает машину и комнату. Посмотреть, что делает канвас. --- ## Облачные ИИ-агенты для написания кода: Автономная разработка и тесты в удаленном репозитории Source: https://murmell.com/ru/what/cloud-ai-agent Цикл в три действия Агент читает репозиторий, чтобы сориентироваться, пишет изменение, а затем выполняет что-то, что говорит ему, был ли он прав: набор тестов, компиляцию, команду. Он читает результат, исправляет, пробует снова. Этот цикл и отличает агента от генератора текста: он получает обратную связь от мира между попытками. Удалённая машина появляется в игре потому, что этот цикл требует вещей, которые не нужны на вашем ноутбуке: устанавливать пакеты, заполнять диск, держать сервер включённым сорок минут. Что меняется, когда машина не ваша Работа переживает вкладку. Вы запускаете задачу, уходите обедать, процесс продолжается. На ноутбуке закрытая крышка останавливает всё, и это настоящая причина, по которой люди не решаются запускать долгие задачи. Число перестаёт быть проблемой. Один агент занимает машину, а не ваш экран. Пять агентов требуют не в пять раз больше внимания, а способа за ними наблюдать. И окружение воспроизводимо. Машина стартует с известного образа для каждого проекта, поэтому фраза «у меня работает» исчезает. Проблема, которая настигает второго агента Два агента в одном каталоге пишут один и тот же файл с разницей в тридцать секунд, и второй стирает первого, а ничто об этом не сообщает. Обычный обходной путь, дать каждому копию репозитория, что лишь переносит проблему на момент слияния. Murmell идёт другим путём. Общий каталог и резервирование перед записью: агент объявляет пути, которые собирается затронуть, доска отдаёт их ему и отказывает всем остальным, пока он их не отпустит. Механизм подробно. Агенты, которые запускает Murmell Claude Code, Codex, Kimi и OpenCode, каждый в своём окне канваса с настоящим терминалом, подписанные вашим аккаунтом или ключом. Токены не перепродаются: счёт покрывает машину и комнату, где люди наблюдают. Claude Code в браузере описывает, как это выглядит на экране. --- ## Сравнение ИИ-агентов для кодинга: Claude Code, Cursor, Devin и еще 10 инструментов Source: https://murmell.com/ru/what/best-ai-coding-agents Вопрос, который всё сортирует Все эти инструменты умеют запускать агента. Первый, это просто: он читает, пишет, запускает тесты. Расхождение начинается со второго агента, потому что нужно решить, что он видит и что имеет право трогать. Таблица ниже никого не оценивает: она одной строкой показывает, для какой ситуации подходит каждый инструмент, а группы под ней объясняют почему. Что выбрать, по одной строке ИнструментПодходящая ситуация CursorВы пишете код сами и хотите лучшую клавиатурную работу. DevinВы поручаете весь тикет и возвращаетесь к результату. JulesВы хотите утвердить план до того, как агент чего-либо коснётся. Copilot и Agent HQВаша работа уже организована тикетами, а ревью, привычная встреча. Codex cloudУ вас есть аккаунт OpenAI и чётко очерченные задачи для делегирования. Replit AgentВы начинаете с нуля и хотите онлайн-приложение тем же вечером. WindsurfВы редактируете вручную и хотите параллельные запуски на своём диске. ConductorВы работаете один на Mac, и код не должен выходить наружу. OpenHands Agent CanvasКод должен оставаться на оборудовании, которое вы контролируете, и вам нужен исходный код. Vibe KanbanУ вас есть очередь задач для обработки по одной на своей машине. CodegАгенты уже работают в вашем окружении, и не хватает общего обзора. Gemini Code AssistВы хотите хорошего агента в редакторе, который уже есть, и не платить ничего. Claude Code в вебеВы уже пользуетесь CLI, и единственный вопрос, где он выполняется. MurmellНескольким агентам нужно затронуть одни и те же файлы, и есть люди, которые наблюдают. Таблица страницы сравнений отвечает на другой вопрос, о том, куда идёт второй агент. Одна облачная машина на задачу Агент получает клон репозитория на машине, которую вы не видите, работает на ветке и возвращает pull request. Это самая распространённая форма, и она требует наименьшего доверия: ничего из того, что он делает, не касается вашей копии, пока вы не прочитаете diff. Cursor. Редактор на человека и машина на агента, против канваса и каталога для всех. Devin. Параллелизм через разделение против параллелизма через совместное использование, и когда каждая форма верна. Jules. План, который вы утверждаете, и pull request, который вы проверяете, против терминалов, за которыми вы наблюдаете в одном дереве. Copilot и Agent HQ. Где сходится работа агентов: в pull request, или в рабочей копии. Codex cloud. Почему запуск CLI Codex на общем канвасе — это не то же самое, что делегировать ему задачу. Replit Agent. Создание приложения с нуля против работы нескольких агентов над существующим кодом. Одно рабочее пространство на задачу, на вашей машине Тот же выбор с вашей стороны: git worktree или рабочий каталог на агента, и одно слияние в конце. Код не выходит наружу, что снимает вопрос безопасности ещё до его возникновения, и никто другой не видит сессию. Windsurf. Worktree на диалог на вашей машине против общего каталога в облаке. Conductor. Mac-приложение с пространством на задачу против облачного канваса с одним каталогом для всех. OpenHands Agent Canvas. Самое близкое сравнение в списке: worktree на агента против одного дерева с резервированием файлов. Vibe Kanban. Канбан-доска над локальными запусками против общего канваса над облачным каталогом. Codeg. Собирать уже существующие локальные сессии против запуска агентов в общем облачном каталоге. Один агент за раз, в вашем редакторе Никакого документированного параллелизма: один агент, под наблюдением, в инструменте, где вы пишете. Это лучший компромисс, когда клавиатуру держите вы, а агент помогает. Gemini Code Assist. Один агент под наблюдением в вашем редакторе против нескольких агентов без наблюдения в каталоге, за которым вы следите. Тот же агент, в другом месте CLI полностью идентичен с обеих сторон. Меняется машина, на которой он выполняется, и число людей, которые могут за ним наблюдать. Claude Code в вебе. Один и тот же CLI в двух местах. Изолированная машина на задачу против нескольких агентов на канвасе и одной рабочей копии. Общий каталог, и почему его почти никто не делает В таблице не хватает четвёртого ответа, и это наш. Несколько агентов в одном каталоге, без копий. Почти никто его не предлагает, потому что он требует координатора. Без координатора два агента читают одну и ту же версию файла, и второй стирает первого без единого предупреждения. Murmell помещает этого координатора на сервер. Агент объявляет пути, которые собирается затронуть, перед тем как писать, доска выделяет их ему и отказывает всем остальным, пока он их не отпустит. Запись, всё же попавшая на файл, занятый кем-то другим, снимается снимком до того, как попадает на диск. Механизм подробно. Как выбрать за две минуты Если вы пишете код сами, берите редактор: Cursor, Windsurf или Gemini Code Assist, и вопрос решён. Если ваши задачи независимы и вы хотите их поручить, берите облачного агента: Devin, Jules или Codex cloud. Если код не имеет права покидать вашу сеть, берите локальное и самостоятельно размещаемое решение, в первую очередь OpenHands. Остаётся один случай, и это единственный, который решает Murmell: несколько агентов должны затронуть одни и те же файлы в течение одного часа, а люди наблюдают. Сравнения одно за другим. --- ## Запуск Claude Code в облаке: Без локальной установки и с поддержкой нескольких агентов Source: https://murmell.com/ru/what/run-claude-code-in-the-cloud Что нужно перед началом Репозиторий, пусть даже пустой. Аккаунт у поставщика модели или API-ключ. И удалённая машина, которая размещает каталог и выполняет команды. Murmell создаёт машину и приватный репозиторий, когда вы создаёте проект, поэтому на практике остаётся только подключить аккаунт модели. Файл с инструкциями в корне репозитория сильно меняет ситуацию: как запускать проект, что нельзя ломать, в каком стиле пишет команда. Агенты читают его при запуске, и это лучшее соотношение затраченного времени и полученного качества. Как выглядит час работы Вы описываете задачу одной фразой. Агент читает нужные файлы, пишет, запускает тесты, читает ошибку, исправляет. Вы не следите за каждым шагом: вы смотрите терминал, когда он останавливается, и перечитываете diff. Со второго агента вопрос превращается в распределение. Два агента в двух углах проекта продвигаются параллельно; два агента на одном файле мешают друг другу. В Murmell каждый резервирует свои пути перед записью, поэтому столкновение отклоняется, а не обнаруживается позже. Сколько это стоит, в двух строках Существуют два счёта, и их лучше разделять. Токены модели оплачиваются вашему поставщику, с вашего аккаунта. Машина и комната оплачиваются хостингу. Murmell не перепродаёт токены, а значит ваша подписка Claude или ключ OpenAI остаются теми же, что вы уже используете. Обычная ловушка Запустить трёх агентов на трёх копиях репозитория кажется очевидным путём и обходится дорого в тот же вечер: три ветки, три слияния и конфликты, которых никто не предвидел. Общий каталог с правилом записи требует меньше работы по сшиванию. Как работает правило, и что содержит машина. --- ## एक ही रिपॉज़िटरी पर कई AI एजेंट Source: https://murmell.com/hi/what/multiple-ai-agents-one-repo वह मामला जो सब बिगाड़ देता है दो एजेंट को दो ऐसे काम मिलते हैं जो एक ही फ़ाइल को छूते हैं। पहला फ़ाइल पढ़ता है, बीस सेकंड सोचता है, लिखता है। दूसरे ने पहले के लिखने से पहले वही वर्ज़न पढ़ा था, और वह उसके ऊपर लिख देता है। कुछ भी क्रैश नहीं हुआ, किसी को कोई चेतावनी नहीं मिली, और पहले का काम गायब हो गया। जैसे ही एक से ज़्यादा एजेंट हों, यह मामला दुर्लभ नहीं रहता, क्योंकि एजेंट व्यापक पढ़ते हैं और तेज़ी से लिखते हैं। यही वजह है कि लगभग हर टूल अलगाव अपनाता है: हर एजेंट के लिए एक मशीन, हर एजेंट के लिए एक ब्रांच। बाकी दुनिया क्या करती है: हर एजेंट के लिए एक worktree इस समस्या का आम जवाब बंटवारा है: हर एजेंट को अपना git worktree दिया जाता है, फ़ाइलों की पूरी कॉपी अपने इंडेक्स के साथ, और यह देखा जाता है कि दायरे एक-दूसरे से न टकराएं। यही Windsurf, Conductor और OpenHands करते हैं, और यही ज़्यादातर गाइड सुझाते हैं। यह काम करता है, और इसमें ठीक एक कमी है: बंटवारा एक वादा है, गारंटी नहीं। कोई यह जांच नहीं करता कि दायरे टकरा नहीं रहे, और जब वे टकराते हैं तो पता मर्ज के समय चलता है, जब दोनों एजेंट काम खत्म कर चुके होते हैं और किसी को वजह याद नहीं रहती। आरक्षण, तीन चरणों में लिखने से पहले, एजेंट उन रास्तों की घोषणा करता है जिन्हें वह छूने वाला है। बोर्ड, अगर वे खाली हों तो उसे दे देता है, और अगर किसी के पास हों तो मना कर देता है। हर पल, एक फ़ाइल का एक ही मालिक। काम के दौरान, एक ऑब्ज़र्वर डिस्क पर असली लेखन देखता है और हर एक को उसके लेखक से जोड़ता है। किसी और के पास मौजूद रास्ते पर आया लेखन डिस्क पर उतरने से पहले स्नैपशॉट किया जाता है: पिछला वर्ज़न सुरक्षित रहता है, इसलिए नियम टूटने पर भी कुछ नहीं खोता। आख़िर में, एजेंट अपने रास्ते छोड़ देता है। फ़ाइल अगले के लिए फिर से उपलब्ध हो जाती है, बिना किसी मर्ज के, क्योंकि एक साथ दो ज़िंदा वर्ज़न कभी हुए ही नहीं। स्क्रीन पर यह कैसा दिखता है हर विंडो अपने एजेंट को काम करते दिखाती है, और बोर्ड दिखाता है कि किसके पास क्या है। दिखता है कि कोई एजेंट इंतज़ार कर रहा है, और क्यों। अटका हुआ एजेंट नुकसान करने से पहले दिख जाता है, और अदृश्य कतार से यही असली फ़र्क़ है। लोग भी गिनती में आते हैं। एक ही कैनवस पर मौजूद कई लोग अपने-अपने एजेंट चलाते हैं और बाकी सबके नाम वाले कर्सर देखते हैं। जब यह सही तरीका नहीं अगर आपके काम सच में स्वतंत्र और लंबे हैं, तो मशीन के हिसाब से अलगाव अब भी ठीक-ठाक है: कुछ तय करने को नहीं, कुछ इंतज़ार करने को नहीं। साझा करना तब जीतता है जब काम एक-दूसरे को छूते हैं, जो एक ही फ़ीचर पर काम करते समय हमेशा होता है। तुलनाएं टूल के हिसाब से यह चुनाव विस्तार से बताती हैं। --- ## डेवलपर्स के लिए Cloud AI: Hosted Models, APIs और Remote Coding Agents में अंतर Source: https://murmell.com/hi/what/cloud-ai एक शब्द के नीचे तीन चीज़ें पहला मतलब सबसे पुराना है: कहीं और होस्ट किया गया मॉडल। आप कुछ डाउनलोड नहीं करते, सवाल भेजते हैं और जवाब पाते हैं। यही टैब में बैठा असिस्टेंट करता है। दूसरा तकनीकी टीमों का मतलब है: API। मॉडल उस सॉफ़्टवेयर की एक ईंट बन जाता है जिसे आप लिखते हैं, टोकन के हिसाब से बिल आता है। मशीन प्रोवाइडर के पास रहती है, तर्क आपके पास रहता है। तीसरा हाल का है और यही कोड लिखने वाले किसी व्यक्ति का दिन बदल देता है। एजेंट दूरस्थ मशीन पर चलता है, फ़ाइल सिस्टम, टर्मिनल और नेटवर्क एक्सेस के साथ। यह डिपेंडेंसी इंस्टॉल करता है, टेस्ट चलाता है, गलतियां पढ़ता है, फिर कोशिश करता है। आप हर कदम पर उससे बात नहीं करते, आप उसे एक लक्ष्य देते हैं। साथ मिलने वाला शब्द: एजेंटिक "एजेंटिक AI" तीसरे मतलब को मशीन की बजाय प्रोग्राम की नज़र से देखता है: एक AI जो किसी लक्ष्य का पीछा करता है, अपने कदम चुनता है, और जब तक टेस्ट पास न हों, अकेले बार-बार कोशिश करता है। व्यवहार में दोनों शब्द लगभग हमेशा मिल जाते हैं, क्योंकि चालीस मिनट अकेले काम करने वाले प्रोग्राम को एक मशीन चाहिए जो चालू रहे। तीसरे को असल में क्या अलग करता है जवाब देने वाला AI तब रुक जाता है जब आप टैब बंद करते हैं, क्योंकि दो सवालों के बीच उसके पास करने को कुछ नहीं था। दूरस्थ मशीन पर एजेंट चलता रहता है: प्रोसेस मशीन पर रहता है, ब्राउज़र में नहीं। तीनों में से यही अकेला मतलब है जहां कंप्यूटर बंद करने की कोई कीमत नहीं। नतीजा गणितीय है। अगर एक एजेंट एक मशीन पर समाता है, तो दो एजेंट दो मशीनों पर समाते हैं, और पांच पांच पर। काम अब आपके सामने खुले टर्मिनलों की संख्या तक सीमित नहीं रहता। जब वे कई हों तो कहां अटकता है ज़्यादातर टूल इस सवाल को अलगाव से सुलझाते हैं: एक एजेंट, एक मशीन, एक ब्रांच, और आख़िर में एक मर्ज। यह तब तक काम करता है जब तक दो एजेंटों ने एक ही फ़ाइल नहीं बदली, और जब तक दोनों काम खत्म न कर लें किसी को पता नहीं चलता। दूसरा रास्ता नियम के साथ साझा करना है। एजेंट एक ही फ़ोल्डर में रहते हैं, और कोई एजेंट लिखने से पहले रास्ता आरक्षित करता है। एक फ़ाइल का एक ही मालिक, जिसे मॉडल से विनम्रता से मांगने की बजाय सर्वर लागू करता है। यही तरीका Murmell ने चुना है। चुनने से पहले पूछने लायक सवाल मशीन का मालिक कौन है, और आपके कोड के अलावा उसमें क्या है। यह कितनी देर चलती है, और नष्ट होने पर क्या बचता है। आप किसके लिए भुगतान करते हैं: मशीन के लिए, मॉडल के टोकन के लिए, या दोनों के लिए। और क्या आपकी मौजूदा एजेंट सब्सक्रिप्शन दोबारा इस्तेमाल हो सकती है या नई खरीदनी पड़ेगी। आख़िरी सवाल पर Murmell का जवाब छोटा है: आप वही अकाउंट जोड़ते हैं जिनके लिए पहले से भुगतान करते हैं, और बिल मशीन और कमरे को कवर करता है। देखें कैनवस क्या करता है। --- ## Cloud AI Coding Agents: रिमोट रिपॉजिटरी में ऑटोनॉमस कोडिंग और टेस्टिंग Source: https://murmell.com/hi/what/cloud-ai-agent तीन कदम का लूप एजेंट अपनी दिशा जानने के लिए रिपॉज़िटरी पढ़ता है, एक बदलाव लिखता है, फिर कुछ ऐसा चलाता है जो उसे बताता है कि वह सही था या नहीं: टेस्ट सूट, कंपाइल, कोई कमांड। यह नतीजा पढ़ता है, सुधारता है, फिर कोशिश करता है। यही लूप एजेंट को टेक्स्ट जनरेटर से अलग करता है: दो कोशिशों के बीच उसे असली दुनिया से जवाब मिलता है। दूरस्थ मशीन इसलिए ज़रूरी होती है क्योंकि इस लूप को वो चीज़ें चाहिए जो आप अपने लैपटॉप पर नहीं चाहते: पैकेज इंस्टॉल करना, डिस्क भरना, चालीस मिनट तक सर्वर चालू रखना। जब मशीन आपकी न हो तो क्या बदलता है काम टैब से आगे जीता है। आप कोई काम शुरू करते हैं, लंच पर जाते हैं, प्रोसेस चलता रहता है। लैपटॉप पर, ढक्कन बंद करने से सब कुछ रुक जाता है, और यही असली वजह है कि लोग लंबा काम शुरू करने से हिचकते हैं। संख्या समस्या नहीं रहती। एक एजेंट एक मशीन घेरता है, आपकी स्क्रीन नहीं। पांच एजेंट पांच गुना ध्यान नहीं मांगते, बल्कि उन्हें देखने का एक तरीका मांगते हैं। और वातावरण दोहराया जा सकता है। मशीन हर प्रोजेक्ट के लिए एक जाने-पहचाने image से शुरू होती है, इसलिए "मेरे यहां तो चलता है" जैसा वाक्य बेमानी हो जाता है। दूसरे एजेंट तक पहुंचने वाली समस्या एक ही फ़ोल्डर में दो एजेंट तीस सेकंड के अंतर पर एक ही फ़ाइल लिखते हैं, और दूसरा बिना किसी सूचना के पहले को मिटा देता है। आम तरीका हर एक को रिपॉज़िटरी की अपनी कॉपी देना है, जो समस्या को सिर्फ़ मर्ज तक टाल देता है। Murmell दूसरा रास्ता चुनता है। साझा फ़ोल्डर, और लिखने से पहले आरक्षण: एजेंट उन रास्तों की घोषणा करता है जिन्हें वह छूने वाला है, बोर्ड उसे ये दे देता है, और जब तक वह इन्हें छोड़ न दे, बाकी सबको मना कर देता है। यह तरीका विस्तार से। Murmell जो एजेंट चलाता है Claude Code, Codex, Kimi और OpenCode, कैनवस की अपनी-अपनी विंडो में असली टर्मिनल के साथ, आपके अकाउंट या कुंजी से साइन किए हुए। कोई टोकन नहीं बेचा जाता: बिल मशीन और उस कमरे को कवर करता है जहां लोग देखते हैं। ब्राउज़र में Claude Code बताता है कि स्क्रीन पर यह कैसा दिखता है। --- ## डेवलपर्स के लिए Figma: कोड के लिए मल्टीप्लेयर कैनवस Source: https://murmell.com/hi/what/figma-for-developers यह उपमा इसलिए उपयोगी है क्योंकि यह अनावश्यक झंझटों को समाप्त करती है। कोई एक्सपोर्ट नहीं, कोई स्थानीय कॉपी मिलाने की ज़रूरत नहीं, और कोई स्क्रीन शेयरिंग नहीं जहाँ एक व्यक्ति काम करे और बाकी अनुमान लगाएं। उपमा क्या सही बताती है एक ही URL पूरा कार्यक्षेत्र है। सभी लोग एक ही पल में एक ही कैनवस देखते हैं, और उपस्थिति स्पष्ट दिखती है: नाम वाले कर्सर और कौन किस विंडो को देख रहा है। देखना जानबूझकर मुफ़्त रखा गया है, जैसे Figma में व्यूअर सीट होती है। पढ़ने के लिंक मुफ़्त और असीमित हैं। संपादन लिंक आपके प्लान की सीमा के अनुसार होते हैं। और कार्यक्षेत्र डिफ़ॉल्ट रूप से साझा होता है। आपको बाद में काम शेयर करने का फ़ैसला नहीं करना पड़ता, क्योंकि काम कभी किसी निजी जगह पर हुआ ही नहीं था। होमपेज पर देखें यह कैसा दिखता है। उपमा कहाँ लागू नहीं होती Figma में कैनवस पर दिखने वाली चीज़ ही अंतिम उत्पाद होती है। यहाँ ऐसा नहीं है। उत्पाद एक Git रिपॉजिटरी है, और कैनवस वह कमरा है जहाँ काम होता है। इतिहास हर प्रोजेक्ट की निजी रिपॉजिटरी में सुरक्षित रहता है। Figma में दो लोग एक ही आयत को हिला सकते हैं। यहाँ दो लोग एक ही टर्मिनल में टाइप नहीं करते। हर व्यक्ति अपने एजेंट चलाता है और सब मिलकर सभी को देखते हैं। और Murmell कैनवस पर अधिकांश काम इंसानों द्वारा नहीं किया जाता। एजेंट क्लाउड मशीनों पर एक ही डायरेक्टरी में टाइप करते हैं। इंसान केवल देखते हैं और ज़रूरत पड़ने पर मार्गदर्शन करते हैं। कोड के लिए साझा कार्यक्षेत्र क्यों ज़रूरी है एडिटर में अकेले एजेंट को कभी कमरे की ज़रूरत नहीं पड़ी। एक डायरेक्टरी में कई एजेंट इतना आउटपुट देते हैं जिसे एक व्यक्ति आसानी से ट्रैक नहीं कर सकता, इसलिए काम बाँटने के लिए सभी को एक ही दृश्य देखना होता है। यही कारण है कि एजेंट अलग-अलग वर्क-ट्री के बजाय एक ही डायरेक्टरी साझा करते हैं। लिखने से पहले एजेंट फ़ाइल रिज़र्व करता है और सर्वर दूसरों को रोकता है, जिससे दूसरा एजेंट पहले द्वारा लिखे गए कोड को तुरंत देख सके। एक रिपॉजिटरी में कई AI एजेंट में इस प्रणाली को समझें, और AI एजेंटों के साथ मल्टीप्लेयर कोडिंग में इंसानी सहयोग के बारे में पढ़ें। --- ## Top AI Coding Agents तुलना: Multi-Agent आर्किटेक्चर और पैरेलल कोडिंग टूल्स Source: https://murmell.com/hi/what/best-ai-coding-agents वह सवाल जो सब कुछ छांट देता है ये सारे टूल एजेंट चला सकते हैं। पहला आसान है: यह पढ़ता है, लिखता है, टेस्ट चलाता है। असली फ़र्क़ दूसरे एजेंट से शुरू होता है, क्योंकि तय करना पड़ता है कि वह क्या देखता है और क्या छूने का हक़ रखता है। नीचे दी गई टेबल कुछ भी रैंक नहीं करती: यह एक लाइन में बताती है कि हर टूल किस हालत के लिए सही है, और नीचे के समूह बताते हैं क्यों। कौन सा लें, हर एक लाइन में टूलसही चुनाव कब है Cursorआप खुद कोड लिखते हैं और सबसे अच्छी कीबोर्ड सुविधा चाहते हैं। Devinआप पूरा टिकट सौंपते हैं और नतीजे के सामने वापस आते हैं। Julesआप चाहते हैं कि एजेंट कुछ भी छूने से पहले प्लान मंज़ूर करें। Copilot और Agent HQआपका काम पहले से टिकट में बंटा है, और रिव्यू ही सही मौका है। Codex cloudआपके पास OpenAI अकाउंट है और सौंपने लायक साफ़-सुथरे काम हैं। Replit Agentआप शून्य से शुरू करते हैं और उसी शाम एक लाइव ऐप चाहते हैं। Windsurfआप हाथ से एडिट करते हैं और अपनी डिस्क पर समांतर रन चाहते हैं। Conductorआप Mac पर अकेले काम करते हैं, और कोड बाहर नहीं जाना चाहिए। OpenHands Agent Canvasकोड आपके नियंत्रण वाले हार्डवेयर पर रहना चाहिए, और आपको सोर्स कोड चाहिए। Vibe Kanbanआपके पास एक-एक करके निपटाने के लिए कामों की कतार है, अपनी मशीन पर। Codegएजेंट पहले से आपके यहां चल रहे हैं और बस एक साझा नज़र की कमी है। Gemini Code Assistआप पहले से मौजूद एडिटर में एक अच्छा एजेंट चाहते हैं, बिना कुछ भुगतान किए। वेब पर Claude Codeआप पहले से CLI इस्तेमाल करते हैं, और सवाल बस इतना है कि यह कहां चलता है। Murmellकई एजेंट को एक ही फ़ाइलों को छूना है, और लोग देख रहे हैं। तुलना पेज की टेबल एक अलग सवाल का जवाब देती है, इस बारे में कि दूसरा एजेंट कहां जाता है। हर काम के लिए एक क्लाउड मशीन एजेंट को ऐसी मशीन पर आपकी रिपॉज़िटरी का क्लोन मिलता है जो आप नहीं देख सकते, यह किसी ब्रांच पर काम करता है और pull request लौटाता है। यह सबसे आम तरीका है, और सबसे कम भरोसे की मांग करता है: जब तक आप diff न पढ़ें, इसका कोई भी काम आपकी कॉपी को नहीं छूता। Cursor. हर व्यक्ति के लिए एक एडिटर और हर एजेंट के लिए एक मशीन, बनाम सबके लिए एक कैनवस और एक फ़ोल्डर। Devin. अलगाव से मिलने वाली समांतरता बनाम साझा करने से मिलने वाली समांतरता, और हर एक सही कब है। Jules. एक प्लान जिसे आप मंज़ूर करते हैं और एक pull request जिसे आप रिव्यू करते हैं, बनाम एक ही पेड़ में टर्मिनल जिन्हें आप देखते हैं। Copilot और Agent HQ. एजेंट का काम कहां मिलता है: pull request पर, या वर्किंग कॉपी में। Codex cloud. साझा कैनवस पर Codex CLI चलाना किसी काम को सौंपने जैसा क्यों नहीं है। Replit Agent. शून्य से ऐप बनाना, बनाम मौजूद कोड पर कई एजेंट से काम करवाना। हर काम के लिए एक वर्कस्पेस, आपकी मशीन पर आपके यहां भी वही चुनाव: हर एजेंट के लिए एक git worktree या वर्किंग फ़ोल्डर, और आख़िर में एक मर्ज। कोड बाहर नहीं जाता, जिससे सुरक्षा का सवाल शुरू होने से पहले ही सुलझ जाता है, और सेशन कोई और नहीं देखता। Windsurf. हर बातचीत के लिए आपकी मशीन पर एक worktree, बनाम क्लाउड में एक साझा फ़ोल्डर। Conductor. हर काम के लिए एक जगह वाला Mac ऐप, बनाम सबके लिए एक ही फ़ोल्डर वाला क्लाउड कैनवस। OpenHands Agent Canvas. इस लिस्ट की सबसे करीबी तुलना: हर एजेंट के लिए एक worktree, बनाम एक ही पेड़ फ़ाइल आरक्षण के साथ। Vibe Kanban. लोकल रन के ऊपर एक कानबान बोर्ड, बनाम क्लाउड फ़ोल्डर के ऊपर एक साझा कैनवस। Codeg. लोकल सेशन इकट्ठा करना, बनाम एक साझा क्लाउड फ़ोल्डर पर एजेंट चलाना। एक बार में एक एजेंट, आपके एडिटर में कोई दस्तावेज़ीकृत समांतरता नहीं: एक एजेंट, निगरानी में, उसी टूल में जहां आप लिखते हैं। जब कीबोर्ड आपके हाथ में हो और एजेंट सिर्फ़ मदद करे, तो यह सबसे अच्छा समझौता है। Gemini Code Assist. आपके एडिटर में एक निगरानी वाला एजेंट, बनाम एक फ़ोल्डर में कई बिना-निगरानी वाले एजेंट जिन्हें आप देखते हैं। वही एजेंट, कहीं और CLI दोनों तरफ़ पूरी तरह एक जैसा है। जो बदलता है वह है जिस मशीन पर यह चलता है, और कितने लोग इसे देख सकते हैं। वेब पर Claude Code. एक ही CLI दो जगह: हर काम के लिए एक अलग मशीन, बनाम कैनवस पर कई एजेंट और एक ही वर्किंग कॉपी। साझा फ़ोल्डर, और लगभग कोई इसे क्यों नहीं करता टेबल में एक चौथा जवाब नहीं है, और वह हमारा है। एक ही फ़ोल्डर में कई एजेंट, बिना कॉपी के। लगभग कोई इसे नहीं सुझाता क्योंकि इसके लिए एक arbiter चाहिए। बिना arbiter के, दो एजेंट एक ही फ़ाइल का एक ही वर्ज़न पढ़ते हैं, और दूसरा बिना किसी चेतावनी के पहले को मिटा देता है। Murmell इस arbiter को सर्वर में रखता है। लिखने से पहले एजेंट उन रास्तों की घोषणा करता है जिन्हें वह छूने वाला है, बोर्ड उसे ये दे देता है, और जब तक वह इन्हें छोड़ न दे, बाकी सबको मना कर देता है। किसी और के पास मौजूद फ़ाइल पर फिर भी आया लेखन डिस्क पर उतरने से पहले स्नैपशॉट कर लिया जाता है। यह तरीका विस्तार से। दो मिनट में कैसे चुनें अगर आप खुद कोड लिखते हैं, तो एडिटर लें: Cursor, Windsurf या Gemini Code Assist, और सवाल सुलझ गया। अगर आपके काम स्वतंत्र हैं और उन्हें सौंपना चाहते हैं, तो क्लाउड एजेंट लें: Devin, Jules या Codex cloud। अगर कोड को आपके नेटवर्क से बाहर जाने का हक़ नहीं है, तो लोकल और सेल्फ़-होस्टेड लें, सबसे पहले OpenHands। एक मामला बचता है, और यही अकेला मामला है जिसे Murmell सुलझाता है: कई एजेंट को एक ही घंटे में एक ही फ़ाइलों को छूना है, और लोग देख रहे हैं। तुलनाएं एक-एक करके। --- ## AI एजेंटों के साथ मल्टीप्लेयर कोडिंग Source: https://murmell.com/hi/what/multiplayer-coding-with-ai-agents यह एक अकेला URL है। किसी को कुछ इंस्टॉल नहीं करना पड़ता, न ही कोड की कॉपी लेनी पड़ती है, और न ही स्क्रीन शेयर करनी पड़ती है। अतिथि को क्या दिखाई देता है आप लिंक भेजते हैं। जो भी इसे खोलता है उसे लाइव कैनवस दिखता है, कोई रिकॉर्डिंग नहीं। उन्हें अपनी जगह पर विंडो और लाइन दर लाइन टर्मिनल आउटपुट दिखता है। वे नाम के साथ कर्सर घूमते देखते हैं और जान पाते हैं कि कौन क्या देख रहा है। रीड लिंक मुफ़्त और असीमित हैं। एजेंट चलाने की अनुमति देने वाले लिंक आपके प्लान के अनुसार सीमित होते हैं: केवल देखने में हमारा कोई ख़र्च नहीं होता, और मशीन की अपनी तय लागत होती है। हर व्यक्ति क्या कर सकता है हर व्यक्ति अपने एजेंट संचालित करता है, और सभी लोग सबको देख सकते हैं। यह एक ही कीबोर्ड पर दो हाथों जैसा नहीं है: साझा की जाने वाली चीज़ कैनवस और डायरेक्टरी है, कीबोर्ड नहीं। यह साथ मिलकर निर्णय लेने के लिए पर्याप्त है कि एजेंटों को क्या करना चाहिए। यदि कोई रन गलत दिशा में जा रहा है, तो आप टोक सकते हैं और संबंधित व्यक्ति उसे ठीक कर सकता है। डेवलपर्स के लिए Figma परिचित टूल के संदर्भ में यही बात समझाता है। एजेंट भी सहयोगी हैं एक ही डायरेक्टरी में कई एजेंटों को चलाना तकनीकी इंजीनियरिंग की माँग करता है। एजेंट जिन पाथ में बदलाव करना चाहता है उन्हें रिज़र्व करता है, बोर्ड एक होल्डर दर्ज करता है, और बाकी सभी को मना कर दिया जाता है। यह पाबंदी हमारे सर्वर से आती है, इसलिए मॉडल इसे अनदेखा नहीं कर सकता। एक रिपॉजिटरी में कई AI एजेंट में प्रणाली और वास्तविक परीक्षणों के आँकड़े दिए गए हैं। हटने से काम नहीं रुकता टैब बंद करने से एजेंट बंद नहीं होते। वे आपके ब्राउज़र के बजाय कैनवस से जुड़े होते हैं, इसलिए काम जारी रहता है और आपके लौटने पर सारा आउटपुट मौजूद रहता है। कोड केवल उस मशीन पर भी नहीं रहता। हर प्रोजेक्ट को निजी रिपॉजिटरी मिलती है, काम लगातार पुश होता है, और मशीन बंद होने से पहले अंतिम बार कोड सुरक्षित करती है। Murmell क्या है में बाकी विवरण देखें, और होमपेज पर रूम दृश्य देखें। --- ## वह क्लाउड मशीन जहां एजेंट चलते हैं Source: https://murmell.com/hi/what/cloud-sandbox-for-ai-agents sandbox क्यों इसे sandbox भी कहते हैं, और ज़्यादातर डॉक्यूमेंटेशन यही शब्द इस्तेमाल करती हैं। काम का एजेंट वे कमांड चलाता है जो उसने खुद लिखे हैं। कोई पैकेज इंस्टॉल करना, कोई स्क्रिप्ट चलाना, कोई पोर्ट खोलना। हर कमांड के आगे कोई इंसानी रिव्यू नहीं होता, यानी इकलौती असली सुरक्षा यही है कि ये कहां चलते हैं। इसीलिए यह नियम है: कोड चलाने वाली मशीन पर कुछ भी दिलचस्प नहीं होता। न डेटाबेस, न डिक्रिप्शन कुंजी, न किसी और क्लाइंट के credentials। इस मशीन पर कोई घटना सिर्फ़ मशीन की कीमत पर पड़ती है। इसमें क्या है प्रोजेक्ट का फ़ोल्डर, एजेंट के CLI, और जो कुछ एजेंट काम के लिए इंस्टॉल करते हैं। जो credentials आप जोड़ते हैं वे सेशन के दौरान एजेंट के काम आते हैं और इस दायरे से बाहर नहीं जाते। कैनवस, कमरा और आरक्षण का बोर्ड कहीं और रहते हैं। अपनी डिस्क पर कुछ भी लिख देने वाला एजेंट यह तय नहीं कर सकता कि किसी फ़ाइल का मालिक कौन है: यह फ़ैसला उस मशीन पर नहीं होता जिसे वह कंट्रोल करता है। हर प्रोजेक्ट के लिए एक मशीन प्रोजेक्ट के बीच अलगाव कोई सेटिंग नहीं, यह उत्पाद का ढांचा है। हर कैनवस अपनी मशीन शुरू करता है, और दो प्रोजेक्ट कभी एक फ़ाइल सिस्टम साझा नहीं करते। यही चीज़ वातावरण को दोहराए जाने लायक भी बनाती है: प्रोजेक्ट हर बार एक जाने-पहचाने image से शुरू होता है। और आख़िर में, कोड प्रोजेक्ट के साथ एक निजी रिपॉज़िटरी बनती है, और सेशन के दौरान काम वहां पहुंचता रहता है, मशीन नष्ट होने से पहले आख़िरी बार भेजा जाता है। जो आपके पास बचता है वह एक आम रिपॉज़िटरी है, आपके पास, जिसे Murmell के बिना भी पढ़ा जा सकता है। एक सेशन का पूरा क्रम। --- ## क्लाउड में AI कोड की शब्दावली Source: https://murmell.com/hi/what/glossary कोड लिखने वाला AI एजेंट एक प्रोग्राम जिसे एक वाक्य में लक्ष्य मिलता है और वह उसे पाने तक काम करता है: फ़ाइलें पढ़ता है, लिखता है, टेस्ट चलाता है, गलती पढ़ता है और फिर कोशिश करता है। यह कमांड चलाता है, जो इसे टेक्स्ट सुझाने वाले असिस्टेंट से अलग करता है। क्लाउड AI बोलने वाले के हिसाब से तीन चीज़ें: किसी प्रोवाइडर के पास होस्ट किया मॉडल, आपके सॉफ़्टवेयर से बुलाई गई API, या दूरस्थ मशीन पर चलने वाला एजेंट। तीसरा मतलब ही अकेला है जहां टैब बंद करने पर भी कुछ चलता रहता है। एजेंटिक AI एक AI जो सवाल का जवाब देने की बजाय किसी लक्ष्य का पीछा करता है: यह अपने कदम चुनता है, उन्हें चलाता है, और जब तक नतीजा ठीक न हो, फिर कोशिश करता है। यह शब्द बताता है कि प्रोग्राम क्या करता है, जबकि "क्लाउड AI" बताता है कि यह कहां चलता है। Worktree किसी git रिपॉज़िटरी की एक दूसरी वर्किंग कॉपी, अपने इंडेक्स के साथ, किसी और ब्रांच पर। बिना एक-दूसरे को परेशान किए कई एजेंट चलाने का सबसे आम तरीका यही है, और इसकी कीमत हर कॉपी के लिए एक मर्ज है। बंटवारा (Partitioning) एजेंट के बीच फ़ाइलें इस तरह बांटना कि वे एक-दूसरे को न छुएं। यह तब तक काम करता है जब तक बंटवारा सही है, और कोई यह जांच नहीं करता कि यह सही है: यह एक वादा है, गारंटी नहीं। कैनवस वह सतह जहां एजेंट की विंडो रखी होती हैं, हर एक में एक टर्मिनल। यह एक लिंक से साझा होता है, और इसे देखने वाले लोगों का अपना नाम वाला कर्सर होता है। फ़ाइल आरक्षण यह तथ्य कि एजेंट किसी रास्ते को लिखने से पहले उसकी घोषणा करता है। एक रास्ते का एक ही मालिक, जिसे सर्वर लागू करता है, जिससे कई एजेंट बिना एक-दूसरे को मिटाए एक फ़ोल्डर साझा कर पाते हैं। टकराव (Collision) किसी और के पास मौजूद फ़ाइल पर आया लेखन। यह डिस्क पर उतरने से पहले स्नैपशॉट कर लिया जाता है, इसलिए पिछला वर्ज़न अभी भी मौजूद रहता है और कुछ नहीं खोता। Sandbox (बाड़ेदार मशीन) वह अलग मशीन जहां एजेंट का कोड चलता है। Murmell पर, हर प्रोजेक्ट की अपनी, बिना डेटाबेस या डिक्रिप्शन कुंजी के: यहां जो होता है उसकी कीमत बस मशीन जितनी है। अस्थायी मशीन (Ephemeral machine) एक सेशन के लिए बनी और बाद में नष्ट कर दी गई मशीन। जो कुछ बचना चाहिए वह नष्ट होने से पहले किसी रिपॉज़िटरी में भेज दिया जाता है। Context जवाब देते समय मॉडल के सामने जो कुछ होता है: आपका अनुरोध, पढ़ी गई फ़ाइलें, सेशन का इतिहास। इसका आकार सीमित होता है, यही वजह है कि बहुत लंबे सेशन में एजेंट शुरुआत भूल जाता है। टोकन मॉडल की बिलिंग और मापने की इकाई, लगभग एक शब्द का टुकड़ा। किसी सेशन की कीमत पढ़े और लिखे गए टोकन में गिनी जाती है, आपके मॉडल प्रोवाइडर के यहां। CLI कीबोर्ड से टर्मिनल में इस्तेमाल होने वाला प्रोग्राम। Claude Code, Codex, Kimi और OpenCode इसी तरह के हैं, यही वजह है कि इन्हें दूरस्थ मशीन पर चलाकर टैब में दिखाया जा सकता है। टर्मिनल वह टेक्स्ट विंडो जहां कमांड लिखी जाती हैं और आउटपुट चलता रहता है। Murmell पर, यह दूरस्थ मशीन का असली टर्मिनल है, जो ब्राउज़र तक पहुंचाया गया है, कोई नकल नहीं। रिपॉज़िटरी वह वर्ज़न वाली जगह जहां कोड रहता है। हर Murmell प्रोजेक्ट को एक निजी रिपॉज़िटरी मिलती है, और सेशन के दौरान काम वहां पहुंचता रहता है। रीड लिंक एक पता जिससे बिना अकाउंट और बिना भुगतान किसी कैनवस को देखा जा सकता है। विंडो, चलते टर्मिनल और कर्सर दिखते हैं, बिना छूए। मल्टीप्लेयर यह तथ्य कि एक ही कैनवस पर एक ही समय में कई लोग होते हैं, हर एक अपने एजेंट चलाता है, बाकियों के कर्सर नाम और रंग के साथ दिखते हैं। इनमें से तीन एंट्री के विस्तृत वर्ज़न के लिए: क्लाउड AI, क्लाउड AI एजेंट और फ़ाइल आरक्षण। --- ## 개발자를 위한 Figma: 코드를 위한 멀티플레이어 캔버스 Source: https://murmell.com/ko/what/figma-for-developers 이 비유가 유용한 이유는 불필요한 단계를 없애주기 때문입니다. 내보내기도, 수동 병합할 로컬 복사본도, 한 명이 조작하고 나머지는 지켜봐야 하는 화면 공유도 없습니다. 비유가 설명하는 핵심 단 하나의 URL이 전체 작업 공간입니다. 누구나 같은 순간에 같은 캔버스를 보며, 이름이 표시된 커서와 각자가 보고 있는 창이 화면에 그대로 렌더링됩니다. Figma의 뷰어 계정처럼 관람은 무료로 제공됩니다. 읽기 전용 링크는 무료이며 제한 없이 생성할 수 있습니다. 편집 권한 링크는 요금제 한도를 따릅니다. 작업 공간은 기본적으로 공유됩니다. 사적인 공간에서 작업이 진행된 것이 아니므로 나중에 별도로 공유할 필요가 없습니다. 홈페이지에서 실제 동작 모습을 확인할 수 있습니다. 비유가 적용되지 않는 부분 Figma에서는 캔버스 위 객체가 결과물이지만 여기서는 아닙니다. 결과물은 Git 리포지토리이며 캔버스는 작업이 이뤄지는 방입니다. 변경 내역은 프로젝트별 비공개 리포지토리에 지속적으로 푸시됩니다. Figma에서는 두 사람이 같은 도형을 동시에 움직일 수 있습니다. 하지만 여기서는 두 사람이 하나의 터미널에 동시에 타이핑하지 않습니다. 각자 에이전트를 운용하고 서로의 진행 상황을 함께 지켜봅니다. 또한 Murmell 캔버스 작업의 대부분은 사람이 아닌 에이전트가 수행합니다. 에이전트가 클라우드 머신의 공유 디렉터리에서 작업하며 사람은 이를 감독하고 방향을 교정합니다. 코드에 공유 작업 공간이 필요한 이유 에디터 안의 단일 에이전트는 별도의 방이 필요하지 않았습니다. 하지만 한 디렉터리에서 여러 에이전트가 일하면 혼자서 감당하기 어려운 양의 출력이 발생하므로, 지시하는 사람들이 같은 화면을 보고 역할을 분담해야 합니다. 에이전트가 개별 워크트리 대신 단일 디렉터리를 공유하는 이유도 여기에 있습니다. 에이전트가 쓰기 전 파일 경로를 선점하고 해제 전까지 다른 접근을 차단하므로, 두 번째 에이전트는 병합 시점이 아니라 작성 즉시 결과를 읽을 수 있습니다. 하나의 리포지토리에서 실행되는 여러 AI 에이전트에서 상세 메커니즘을 다루며, AI 에이전트와의 멀티플레이어 코딩에서 사람 간의 협업 방식을 설명합니다. --- ## 에이전트가 실행되는 클라우드 머신 Source: https://murmell.com/ko/what/cloud-sandbox-for-ai-agents 왜 샌드박스인가 대부분의 문서에서 쓰는 말도 샌드박스입니다. 쓸모 있는 에이전트는 자신이 직접 작성한 명령을 실행합니다. 패키지 설치, 스크립트 실행, 포트 열기. 이 명령 하나하나를 사람이 미리 검토하지 않으므로, 유일하게 확실한 보호책은 그 명령이 실행되는 장소입니다. 그래서 규칙은 이렇습니다. 코드를 실행하는 머신에는 흥미로운 것이 아무것도 없습니다. 데이터베이스도, 복호화 키도, 다른 고객의 자격 증명도 없습니다. 이 머신에서 생긴 사고는 그 머신만 잃는 것으로 끝납니다. 거기 들어 있는 것 프로젝트 디렉터리, 에이전트의 CLI, 그리고 에이전트가 작업을 위해 설치하는 것들입니다. 여러분이 연결하는 자격 증명은 세션 동안 에이전트가 쓰고, 이 경계를 벗어나지 않습니다. 캔버스, 방, 점유 보드는 다른 곳에서 실행됩니다. 자기 디스크에 무엇이든 쓸 수 있는 에이전트라도 누가 파일을 소유하는지는 결정할 수 없습니다. 그 판단은 에이전트가 통제하는 머신 위에 있지 않습니다. 프로젝트마다 머신 하나 프로젝트 간 격리는 설정값이 아니라 제품의 형태 자체입니다. 각 캔버스는 자체 머신을 시작하며, 두 프로젝트가 파일시스템을 공유하는 일은 결코 없습니다. 이는 또한 환경을 재현 가능하게 만드는 요인입니다. 프로젝트는 매번 알려진 이미지에서 시작합니다. 그리고 마지막에 남는 코드 비공개 저장소가 프로젝트와 함께 만들어지고, 작업은 세션이 진행되는 동안 그리로 푸시되며, 머신이 폐기되기 전에 마지막 푸시가 이루어집니다. 여러분이 얻는 것은 Murmell 없이도 읽을 수 있는, 여러분 소유의 평범한 저장소입니다. 세션이 진행되는 방식. --- ## AI 에이전트와의 멀티플레이어 코딩 Source: https://murmell.com/ko/what/multiplayer-coding-with-ai-agents 단 하나의 URL이면 충분합니다. 별도의 프로그램 설치도, 코드 복사도, 화면 공유도 필요하지 않습니다. 참여자가 보게 되는 화면 링크를 전달하면 접속자는 녹화본이 아닌 현재 상태의 캔버스를 보게 됩니다. 배치된 창과 터미널 출력이 실시간으로 표시되며, 이름이 달린 팀원들의 커서 움직임을 볼 수 있습니다. 읽기 전용 링크는 무료이며 무제한으로 공유할 수 있습니다. 에이전트 조작 권한 링크는 플랜 한도에 따릅니다. 관람은 리소스를 거의 쓰지 않지만 클라우드 인스턴스는 명확한 비용이 들기 때문입니다. 각자가 할 수 있는 역할 각자가 자신의 에이전트를 실행하고 모두가 전체 에이전트를 관찰합니다. 하나의 키보드를 두고 다투는 것이 아니라 캔버스와 작업 디렉터리를 공유하는 구조입니다. 이를 통해 에이전트의 작업 방향을 함께 논의하고 결정할 수 있습니다. 에이전트가 엉뚱한 방향으로 진행할 때 지적하고 담당자가 즉시 경로를 수정할 수 있습니다. 개발자를 위한 Figma에서 익숙한 도구를 바탕으로 같은 개념을 설명합니다. 동료로서 참여하는 에이전트 단일 디렉터리에서 여러 에이전트를 실행하려면 기술적 제어가 필요합니다. 에이전트가 수정할 파일 경로를 선점하면 보드가 단일 점유자를 등록하고 해제 전까지 다른 접근을 차단합니다. 이 차단은 서버에서 강제되므로 모델이 임의로 건너뛸 수 없습니다. 하나의 리포지토리에서 실행되는 여러 AI 에이전트에서 상세 동작 방식과 측정 데이터를 확인하실 수 있습니다. 접속을 종료해도 유지되는 작업 브라우저 탭을 닫아도 에이전트 프로세스는 종료되지 않습니다. 캔버스 인스턴스에 유지되므로 자리를 비운 동안 생성된 작업 결과도 재접속 시 온전히 확인할 수 있습니다. 작성된 코드는 클라우드 인스턴스에만 머무르지 않습니다. 프로젝트별 비공개 Git 리포지토리에 지속적으로 동기화되며 머신 종료 전에도 최종 저장을 수행합니다. Murmell이란 무엇인가에서 전체 개요를 다루며, 홈페이지에서 룸 화면을 확인할 수 있습니다. --- ## 설치 없는 브라우저 속 Claude Code Source: https://murmell.com/ko/what/claude-code-in-the-browser 여러분이 보게 되는 것 캔버스 위의 창 하나에 터미널이 들어 있습니다. 커서가 깜빡이고, 명령어가 입력되고, 출력이 흘러갑니다. 이것은 터미널을 흉내 낸 것이 아니라, 머신 위의 진짜 의사 터미널이 탭까지 옮겨진 것입니다. 여러분이 아는 키가 그대로 작동합니다. 중단, 히스토리 위로 이동, 블록 붙여넣기, 모두 노트북에서처럼 동작합니다. 같은 프로그램이기 때문입니다. 여러분의 머신과 달라지는 점 디스크가 여러분 것이 아닙니다. 의존성은 프로젝트의 머신에 설치되므로 노트북은 깨끗하게 남고, 캔버스를 여는 모든 사람에게 환경이 동일합니다. 그리고 두 번째 창을 열 수 있습니다. 두 번째 에이전트를, 같은 디렉터리에서요. 점유 보드가 서로 덮어쓰지 않도록 처리합니다. 파일 하나에 소유자는 한 명. 누가 볼 수 있는가 링크 하나면 동료가 같은 터미널이 흘러가는 것을 보고, 캔버스 위에 이름이 붙은 자신의 커서를 볼 수 있습니다. 보는 것은 계정을 요구하지 않고 비용도 들지 않습니다. 나중에 diff를 보여주는 것과 작업을 지켜보게 하는 것의 차이입니다. 다른 에이전트들 Codex, Kimi, OpenCode도 같은 방식으로, 각자의 창에서 각자의 자격 증명으로 열립니다. 캔버스 안에서 에이전트에 따라 달라지는 것은 없습니다. 창은 창입니다. Murmell과 단독 Claude Code 비교는 두 상황을 직접 비교합니다. --- ## 하나의 저장소 위 여러 AI 에이전트 Source: https://murmell.com/ko/what/multiple-ai-agents-one-repo 모든 것을 망가뜨리는 경우 두 에이전트가 같은 파일을 건드리는 두 작업을 받습니다. 첫 번째가 파일을 읽고, 20초 동안 생각한 뒤 씁니다. 두 번째는 첫 번째가 쓰기 전의 같은 버전을 읽었고, 그 위에 덮어씁니다. 아무것도 멈추지 않았고, 아무 경고도 없었고, 첫 번째의 작업은 사라졌습니다. 에이전트가 하나 이상이 되는 순간부터 이 경우는 드물지 않습니다. 에이전트는 넓게 읽고 빠르게 쓰기 때문입니다. 거의 모든 도구가 격리를 택하는 이유가 여기 있습니다. 에이전트마다 머신 하나, 브랜치 하나. 다른 곳에서 하는 방식: 에이전트마다 worktree 이 문제에 대한 흔한 답은 분할입니다. 각 에이전트에게 자체 git worktree, 자체 인덱스를 가진 파일 전체 복사본을 주고, 영역이 겹치지 않도록 조정합니다. Windsurf, Conductor, OpenHands가 하는 방식이고, 대부분의 가이드가 권장하는 방식입니다. 작동하고, 결함이 정확히 하나 있습니다. 분할은 보장이 아니라 약속입니다. 아무도 영역이 겹치지 않는지 확인하지 않고, 겹칠 때는 병합 시점, 즉 두 에이전트가 모두 끝나고 아무도 이유를 기억하지 못할 때 알게 됩니다. 세 단계로 본 점유 쓰기 전에 에이전트는 건드릴 경로를 알립니다. 보드는 비어 있으면 부여하고, 점유되어 있으면 거부합니다. 어느 순간이든 파일 하나에 소유자는 한 명뿐입니다. 작업하는 동안 감시자는 디스크의 실제 쓰기를 지켜보며 각각을 작성자에게 연결합니다. 다른 사람이 점유한 경로에 쓰기가 발생하면 반영되기 전에 스냅샷됩니다. 이전 버전이 보존되므로 규칙을 우회하더라도 아무것도 잃지 않습니다. 끝나면 에이전트는 경로를 놓아줍니다. 파일은 다음 에이전트를 위해 다시 사용 가능해지며, 병합이 필요 없습니다. 살아 있는 버전이 동시에 둘이었던 적이 없기 때문입니다. 화면에 보이는 것 각 창은 자신의 에이전트가 작업하는 모습을 보여주고, 보드는 누가 무엇을 쥐고 있는지 보여줍니다. 어떤 에이전트가 기다리고 있는지, 왜 기다리는지 보입니다. 막힌 에이전트는 피해를 내기 전에 보이며, 이것이 보이지 않는 대기열과의 진짜 차이입니다. 사람도 셈에 들어갑니다. 같은 캔버스의 여러 사람이 각자 자신의 에이전트를 조작하고, 이름이 붙은 다른 사람들의 커서를 봅니다. 이 형태가 맞지 않을 때 작업이 정말로 독립적이고 오래 걸린다면 머신 단위 격리로도 충분합니다. 조정할 것도 기다릴 것도 없습니다. 공유는 작업들이 서로 맞닿을 때 이깁니다. 같은 기능을 함께 작업하는 순간 바로 그런 경우입니다. 비교 페이지가 도구별로 이 선택을 자세히 다룹니다. --- ## 클라우드 AI 코딩 용어집 Source: https://murmell.com/ko/what/glossary AI 코딩 에이전트 한 문장짜리 목표를 받아 그것을 달성할 때까지 작업하는 프로그램입니다. 파일을 읽고, 쓰고, 테스트를 실행하고, 오류를 읽고 다시 시도합니다. 명령을 실행한다는 점이 텍스트를 제안하는 어시스턴트와 구분되는 지점입니다. 클라우드 AI 말하는 사람에 따라 세 가지입니다. 제공자가 호스팅하는 모델, 여러분의 소프트웨어에서 호출하는 API, 또는 원격 머신에서 실행되는 에이전트. 세 번째 의미만이 탭을 닫아도 무언가가 계속되는 경우입니다. 에이전틱 AI 질문에 답하는 대신 목표를 추구하는 AI입니다. 스스로 행동을 선택하고, 실행하고, 결과가 만족스럽지 않으면 다시 시도합니다. "클라우드 AI"가 어디서 실행되는지 말하는 반면, 이 말은 프로그램이 무엇을 하는지 말합니다. Worktree git 저장소의 두 번째 작업 복사본으로, 자체 인덱스를 가지고 다른 브랜치에 있습니다. 여러 에이전트를 서로 방해하지 않고 실행하는 가장 흔한 방법이며, 복사본마다 한 번의 병합이라는 대가를 치릅니다. 분할 에이전트들끼리 겹치지 않도록 파일을 나누어 배분하는 것입니다. 분배가 정확한 동안에는 작동하지만, 아무도 정확한지 확인하지 않습니다. 보장이 아니라 약속입니다. 캔버스 에이전트의 창들이 놓이는 표면이며, 각 창 안에 터미널이 있습니다. 링크로 공유되고, 지켜보는 사람들은 이름이 붙은 커서를 갖습니다. 파일 점유 에이전트가 쓸 경로를 쓰기 전에 알리는 것입니다. 경로 하나에 소유자는 한 명뿐이며 서버가 강제하므로, 여러 에이전트가 덮어쓰지 않고 하나의 디렉터리를 공유할 수 있습니다. 충돌 다른 누군가가 점유한 파일에 발생하는 쓰기입니다. 반영되기 전에 스냅샷되므로 이전 버전이 여전히 존재하고 아무것도 사라지지 않습니다. 샌드박스 에이전트의 코드가 실행되는 격리된 머신입니다. Murmell에서는 프로젝트마다 하나씩이며, 데이터베이스도 복호화 키도 없습니다. 그곳에서 일어나는 일은 머신 하나만 잃는 것으로 끝납니다. 일회용 머신 한 세션을 위해 만들어지고 그 후 폐기되는 머신입니다. 살아남아야 할 것은 폐기 전에 저장소로 푸시됩니다. 컨텍스트 답할 순간에 모델이 보고 있는 것입니다. 여러분의 요청, 읽은 파일들, 세션 기록입니다. 크기가 제한되어 있어서, 아주 긴 세션에서 에이전트가 처음 부분을 잊는 이유가 여기 있습니다. 토큰 모델의 과금과 측정 단위이며, 대략 단어 조각 하나에 해당합니다. 세션 하나의 가격은 읽고 쓴 토큰 수로, 여러분의 모델 제공자에게 계산됩니다. CLI 터미널에서 키보드로 조작하는 프로그램입니다. Claude Code, Codex, Kimi, OpenCode가 여기 속하며, 그래서 원격 머신에서 실행해 탭에 표시할 수 있습니다. 터미널 명령을 입력하고 출력이 흘러가는 텍스트 창입니다. Murmell에서는 원격 머신의 진짜 터미널이 브라우저까지 옮겨진 것이지, 흉내 낸 것이 아닙니다. 저장소 코드가 사는 버전 관리된 장소입니다. Murmell의 프로젝트마다 비공개 저장소 하나가 생기고, 작업은 세션이 진행되는 동안 그리로 푸시됩니다. 읽기 전용 링크 계정도 결제도 없이 캔버스를 볼 수 있게 하는 주소입니다. 창, 흘러가는 터미널, 커서가 보이지만 건드릴 수는 없습니다. 멀티플레이어 여러 사람이 같은 캔버스에 동시에 있으면서 각자 자신의 에이전트를 조작하고, 다른 사람들의 커서를 이름과 색이 붙은 채로 보는 상태입니다. 이 중 세 항목의 자세한 설명은 여기서 볼 수 있습니다. 클라우드 AI, 클라우드 AI 에이전트, 파일 점유. --- ## 개발자를 위한 클라우드 AI: 호스팅 모델, API, 원격 자율 코딩 에이전트의 차이 Source: https://murmell.com/ko/what/cloud-ai 한 단어 아래 세 가지 첫 번째 의미가 가장 오래되었습니다. 다른 곳에서 호스팅되는 모델입니다. 아무것도 다운로드하지 않고 질문을 보내고 답을 받습니다. 탭 안의 어시스턴트가 하는 일입니다. 두 번째는 기술 팀들이 쓰는 의미, API입니다. 모델은 여러분이 작성하는 소프트웨어의 부품이 되고, 토큰 단위로 요금이 매겨집니다. 머신은 제공자 쪽에 남고, 로직은 여러분 쪽에 남습니다. 세 번째는 더 최근의 것이며, 코드를 쓰는 사람의 하루를 바꾸는 것입니다. 에이전트는 파일시스템, 터미널, 네트워크 접근을 가진 원격 머신에서 실행됩니다. 의존성을 설치하고, 테스트를 실행하고, 오류를 읽고, 다시 시도합니다. 매 단계마다 말을 걸 필요 없이 목표 하나만 주면 됩니다. 옆에서 마주치는 말: 에이전틱 "에이전틱 AI"는 머신이 아니라 프로그램 쪽에서 본 세 번째 의미를 가리킵니다. 목표를 추구하고, 스스로 행동을 선택하고, 테스트가 통과할 때까지 혼자 반복하는 AI입니다. 실제로는 두 용어가 거의 항상 겹칩니다. 40분 동안 혼자 작업하는 프로그램에는 계속 켜져 있는 머신이 필요하기 때문입니다. 세 번째를 진짜로 구분 짓는 것 답하는 AI는 탭을 닫으면 멈춥니다. 질문 사이에 할 일이 없었기 때문입니다. 원격 머신 위의 에이전트는 계속됩니다. 프로세스는 브라우저가 아니라 머신 위에서 살아 있습니다. 세 가지 의미 중 컴퓨터를 닫아도 아무것도 잃지 않는 것은 이것뿐입니다. 결과는 단순한 산수입니다. 에이전트 하나가 머신 하나로 충분하다면, 에이전트 둘은 머신 둘로, 다섯은 다섯으로 충분합니다. 작업은 눈앞에 열린 터미널 개수에 더 이상 제한받지 않습니다. 여럿이 될 때 막히는 지점 대부분의 도구는 격리로 이 문제를 해결합니다. 에이전트 하나, 머신 하나, 브랜치 하나, 그리고 마지막에 병합. 이는 두 에이전트가 같은 파일을 수정할 때까지는 잘 작동하며, 둘 다 끝날 때까지는 아무도 그 사실을 모릅니다. 다른 길은 규칙이 있는 공유입니다. 에이전트는 같은 디렉터리에 살고, 쓰기 전에 경로를 점유합니다. 파일 하나에 소유자는 한 명뿐이며, 모델에 부탁하는 것이 아니라 서버가 강제합니다. 이것이 Murmell이 선택한 방식입니다. 선택하기 전에 물어야 할 질문 머신을 소유한 사람은 누구이고, 여러분의 코드 말고 무엇이 들어 있는지. 얼마나 오래 살아 있고, 폐기되면 무엇이 남는지. 무엇을 지불하는지, 머신인지, 모델 토큰인지, 아니면 둘 다인지. 그리고 기존 에이전트 구독을 재사용할 수 있는지, 아니면 다시 사야 하는지. 마지막 질문에 대한 Murmell의 답은 짧습니다. 이미 결제하고 있는 계정을 연결하면, 청구서는 머신과 방을 포함합니다. 캔버스가 무엇을 하는지 보기. --- ## 클라우드 AI 코딩 에이전트: 원격 리포지토리 자율 개발 및 테스트 구동 방식 Source: https://murmell.com/ko/what/cloud-ai-agent 세 가지 동작으로 이루어진 루프 에이전트는 방향을 잡기 위해 저장소를 읽고, 수정 사항을 쓴 다음, 자신이 옳았는지 말해주는 무언가를 실행합니다. 테스트 스위트, 컴파일, 명령 하나. 결과를 읽고, 고치고, 다시 시도합니다. 이 루프가 에이전트를 텍스트 생성기와 구분 짓습니다. 시도 사이에 세상으로부터 피드백을 받습니다. 원격 머신이 등장하는 이유는 이 루프가 여러분의 노트북에서는 원하지 않는 일들을 요구하기 때문입니다. 패키지 설치, 디스크 채우기, 서버를 40분 동안 켜두기. 머신이 여러분 것이 아닐 때 달라지는 것 작업이 탭보다 오래 삽니다. 작업을 시작하고 점심을 먹으러 가도 프로세스는 계속됩니다. 노트북에서는 뚜껑을 닫으면 모든 것이 멈추고, 이것이 사람들이 긴 작업을 감히 시작하지 못하는 진짜 이유입니다. 숫자는 더 이상 문제가 되지 않습니다. 에이전트 하나는 머신 하나를 차지하지, 여러분의 화면을 차지하지 않습니다. 에이전트 다섯은 다섯 배의 주의가 아니라, 그것들을 지켜보는 방법 하나만 요구합니다. 그리고 환경은 재현 가능합니다. 머신은 프로젝트마다 알려진 이미지에서 시작하므로 "제 컴퓨터에서는 되는데요"라는 말이 사라집니다. 두 번째 에이전트에게 생기는 문제 같은 디렉터리의 두 에이전트가 30초 간격으로 같은 파일에 쓰면, 두 번째가 아무 알림 없이 첫 번째를 지워버립니다. 흔한 회피책은 각자에게 저장소 복사본을 주는 것인데, 그러면 문제가 병합 시점으로 옮겨갈 뿐입니다. Murmell은 다른 길을 택합니다. 공유 디렉터리와, 쓰기 전 점유입니다. 에이전트가 건드릴 경로를 알리면 보드가 그것을 부여하고, 놓아줄 때까지 다른 모든 에이전트에게 거부합니다. 메커니즘 자세히 보기. Murmell이 실행하는 에이전트 Claude Code, Codex, Kimi, OpenCode는 각각 캔버스의 창 안에서 진짜 터미널과 함께 실행되며, 여러분의 계정이나 키로 서명됩니다. 토큰은 되팔리지 않습니다. 청구서는 머신과 사람들이 지켜보는 방을 포함합니다. 브라우저 속 Claude Code는 화면에서 어떻게 보이는지 설명합니다. --- ## 주요 AI 코딩 에이전트 비교: 병렬 실행 및 멀티 에이전트 아키텍처 13종 분석 Source: https://murmell.com/ko/what/best-ai-coding-agents 모든 것을 정렬하는 질문 이 도구들은 모두 에이전트를 실행할 수 있습니다. 첫 번째는 쉽습니다. 읽고, 쓰고, 테스트를 실행합니다. 생각이 갈리는 지점은 두 번째 에이전트부터인데, 그것이 무엇을 보고 무엇을 건드릴 권리를 가지는지 결정해야 하기 때문입니다. 아래 표는 아무것도 등급을 매기지 않습니다. 각 도구가 어떤 상황에 맞는지 한 줄로 보여주고, 그 아래 그룹이 이유를 설명합니다. 어느 것을 고를지, 한 줄씩 도구정답이 되는 상황 Cursor직접 코드를 쓰면서 최고의 키보드 경험을 원한다. Devin티켓 전체를 맡기고 결과 앞으로 돌아오고 싶다. Jules에이전트가 무언가를 건드리기 전에 계획을 승인하고 싶다. Copilot과 Agent HQ작업이 이미 티켓으로 정리되어 있고, 리뷰가 정해진 약속이다. Codex cloudOpenAI 계정이 있고, 범위가 명확한 작업을 위임하고 싶다. Replit Agent아무것도 없는 상태에서 시작해 그날 밤 온라인 앱을 원한다. Windsurf직접 편집하면서 자신의 디스크에서 병렬 실행을 원한다. ConductorMac에서 혼자 작업하며 코드를 밖으로 내보내고 싶지 않다. OpenHands Agent Canvas코드는 자신이 관리하는 하드웨어에 남아야 하고, 소스가 필요하다. Vibe Kanban자신의 머신에서 하나씩 처리할 작업 목록이 있다. Codeg에이전트가 이미 자신의 환경에서 실행 중이고, 전체를 보는 뷰가 부족하다. Gemini Code Assist이미 있는 에디터 안에서 좋은 에이전트를 원하고, 아무것도 지불하고 싶지 않다. 웹의 Claude Code이미 CLI를 쓰고 있고, 유일한 질문은 그것이 어디서 실행되는가뿐이다. Murmell여러 에이전트가 같은 파일을 건드려야 하고, 지켜보는 사람이 있다. 비교 페이지의 표는 다른 질문, 즉 두 번째 에이전트가 어디로 가는지를 다룹니다. 작업마다 클라우드 머신 하나 에이전트는 여러분이 보지 못하는 머신에서 저장소 클론을 받아 브랜치에서 작업하고 풀 리퀘스트를 돌려줍니다. 가장 널리 쓰이는 형태이고, 가장 적은 신뢰를 요구하는 형태입니다. 에이전트가 하는 어떤 일도 여러분이 diff를 읽기 전까지는 여러분의 복사본을 건드리지 않습니다. Cursor. 한 사람에 하나의 에디터, 에이전트마다 하나의 머신인 세계와, 모두를 위한 캔버스와 하나의 디렉터리인 세계. Devin. 분리를 통한 병렬 처리 대 공유를 통한 병렬 처리, 그리고 각 형태가 옳은 경우. Jules. 여러분이 승인하는 계획과 리뷰하는 풀 리퀘스트 대, 하나의 트리 안에서 지켜보는 터미널들. Copilot과 Agent HQ. 에이전트의 작업이 어디서 모이는가. 풀 리퀘스트에서, 아니면 작업 복사본 안에서. Codex cloud. Codex CLI를 공유 캔버스에서 실행하는 것이 작업을 위임하는 것과 왜 다른지. Replit Agent. 아무것도 없는 상태에서 애플리케이션을 만드는 것 대, 존재하는 코드에서 여러 에이전트를 작업시키는 것. 작업마다 작업 공간 하나, 여러분의 머신 위에서 여러분 쪽에서의 같은 선택입니다. 에이전트마다 git worktree나 작업 디렉터리 하나, 그리고 마지막에 병합 한 번. 코드가 밖으로 나가지 않으므로 보안 문제는 생기기 전에 해결되고, 다른 누구도 그 세션을 보지 못합니다. Windsurf. 여러분 머신 위 대화마다 worktree 하나 대, 클라우드 안의 공유 디렉터리. Conductor. 작업마다 공간 하나를 가진 Mac 애플리케이션 대, 모두를 위한 디렉터리 하나를 가진 클라우드 캔버스. OpenHands Agent Canvas. 목록에서 가장 가까운 비교입니다. 에이전트마다 worktree 하나 대, 파일 점유가 있는 하나의 트리. Vibe Kanban. 로컬 실행 위의 칸반 보드 대, 클라우드 디렉터리 위의 공유 캔버스. Codeg. 이미 있는 로컬 세션을 모으는 것 대, 공유 클라우드 디렉터리에서 에이전트를 실행하는 것. 한 번에 에이전트 하나, 여러분의 에디터 안에서 기록된 병렬 처리는 없습니다. 에이전트 하나가, 여러분이 이미 쓰고 있는 도구 안에서 감독받습니다. 여러분이 키보드를 쥐고 에이전트가 돕는 경우 가장 좋은 타협점입니다. Gemini Code Assist. 여러분의 에디터 안에서 감독받는 에이전트 하나 대, 지켜보는 디렉터리 안의 감독받지 않는 여러 에이전트. 같은 에이전트, 다른 장소에서 CLI는 양쪽에서 완전히 같습니다. 달라지는 것은 그것이 실행되는 머신과, 그것을 볼 수 있는 사람의 수입니다. 웹의 Claude Code. 같은 CLI가 두 장소에서. 작업마다 격리된 머신 대 캔버스 위 여러 에이전트와 하나의 작업 복사본. 공유 디렉터리, 그리고 거의 아무도 하지 않는 이유 표에는 네 번째 답이 빠져 있습니다. 그것이 저희 것입니다. 복사본 없이, 하나의 디렉터리에 여러 에이전트가 있는 형태입니다. 거의 아무도 이를 제안하지 않는 이유는 조정자가 필요하기 때문입니다. 조정자가 없으면 두 에이전트는 같은 버전의 파일을 읽고, 두 번째가 아무 알림 없이 첫 번째를 지워버립니다. Murmell은 이 조정자를 서버에 둡니다. 에이전트는 쓰기 전에 건드릴 경로를 알리고, 보드가 그것을 부여하며, 놓아줄 때까지 다른 모든 에이전트에게 거부합니다. 그래도 다른 누군가가 점유한 파일에 쓰기가 발생하면, 반영되기 전에 스냅샷됩니다. 메커니즘 자세히 보기. 2분 안에 고르는 법 직접 코드를 쓴다면 에디터를 고르세요. Cursor, Windsurf, Gemini Code Assist로 질문이 해결됩니다. 작업이 독립적이고 맡기고 싶다면 클라우드 에이전트를 고르세요. Devin, Jules, Codex cloud입니다. 코드가 네트워크를 벗어날 권리가 없다면 OpenHands를 필두로 로컬에서 자체 호스팅 가능한 것을 고르세요. 남은 경우는 하나뿐이며, 그것이 Murmell이 다루는 유일한 경우입니다. 여러 에이전트가 같은 한 시간 안에 같은 파일을 건드려야 하고, 지켜보는 사람이 있는 경우입니다. 비교를 하나씩 살펴보기. --- ## エンジニアのためのクラウドAI：ホスト型モデル、API、リモート自律エージェントの違い Source: https://murmell.com/ja/what/cloud-ai 1つの言葉に隠れた3つのもの 最初の意味は最も古く、どこか別の場所でホストされたモデルです。何もダウンロードせず、質問を送って 答えを受け取ります。タブの中のアシスタントがやっていることです。 2つ目は技術チームにとっての意味、APIです。モデルはあなたが書くソフトウェアの中の部品になり、 トークンごとに課金されます。マシンはプロバイダー側に留まり、ロジックはあなたの側に留まります。 3つ目はより新しく、コードを書く人の1日を変えるものです。エージェントはファイルシステム、ターミナル、 ネットワークアクセスを持つリモートマシン上で動作します。依存関係をインストールし、テストを実行し、 エラーを読み、やり直します。毎ステップ話しかけるのではなく、目標を1つ与えるだけです。 隣にある言葉: エージェンティック 「エージェンティックAI」はマシンではなくプログラムの側から見た3つ目の意味を指します。目標を追い、 自分の行動を選び、テストが通るまで1人で繰り返すAIです。実際にはほぼ常に2つの言葉は重なります。 40分間1人で作業するプログラムには、動き続けるマシンが必要だからです。 3つ目を本当に分けているもの 質問に答えるAIはタブを閉じると止まります。質問の合間にすることが何もなかったからです。リモート マシン上のエージェントは続きます。プロセスはブラウザではなくマシンの上で生きています。3つの意味 の中で、コンピューターを閉じても何も失わないのはこれだけです。 結果は単純な算数です。1つのエージェントが1台のマシンで成り立つなら、2つのエージェントは2台の マシンで、5つは5台で成り立ちます。作業は目の前に開いたターミナルの数に制限されなくなります。 複数になったときにつまずく場所 ほとんどのツールは隔離することでこの問題を解決します。1エージェント、1マシン、1ブランチ、そして 最後にマージです。これは2つのエージェントが同じファイルを変更するまでうまくいき、そのことは両方が 終わるまで誰も知りません。 もう1つの道はルール付きの共有です。エージェントは同じディレクトリに住み、書き込む前にパスを確保 します。1つのファイルにつき所有者は1人だけで、モデルにお願いするのではなくサーバーが強制します。 これがMurmellが選んだ形です。 選ぶ前に聞くべき質問 マシンを所有しているのは誰か、あなたのコード以外に何が入っているか。どれくらいの間生きていて、 破棄されたとき何が残るか。あなたが支払うもの: マシンか、モデルのトークンか、その両方か。そして すでにある既存のエージェントのサブスクリプションが再利用できるのか、新しく買い直す必要があるのか。 最後の点について、Murmellの答えは短いです。すでに支払っているアカウントを接続すれば、請求は マシンと部屋をカバーします。キャンバスの機能を見る。 --- ## クラウドAIコーディングエージェント：リモートリポジトリでの自律開発とテスト Source: https://murmell.com/ja/what/cloud-ai-agent 3つの動作からなるループ エージェントはリポジトリを読んで状況を把握し、変更を書き込み、その判断が正しかったかを教えてくれる 何か、テストスイート、コンパイル、コマンドを実行します。結果を読み、修正し、やり直します。この ループがエージェントをテキスト生成器と分けるものです。2回の試みの間に世界からフィードバックを 得ているのです。 リモートマシンが登場するのは、このループがノートパソコンでやりたくないことを求めるからです。 パッケージのインストール、ディスクを埋めること、40分間サーバーを起動したままにすることです。 マシンが自分のものでないと何が変わるか 作業がタブより長生きします。タスクを起動して、ランチに出かけても、プロセスは続きます。ノート パソコンではふたを閉じるとすべてが止まります。これが人々が長いタスクを起動する勇気を持てない 本当の理由です。 数はもはや問題ではなくなります。エージェントはあなたの画面ではなく、マシンを占有します。5つの エージェントは5倍の注意を要求するのではなく、それらを見る方法を要求します。 そして環境は再現可能になります。マシンはプロジェクトごとに既知のイメージから起動するので、 「自分の環境では動く」というフレーズは意味を失います。 2番目のエージェントに起きる問題 同じディレクトリにいる2つのエージェントが30秒差で同じファイルに書き込み、2番目が何の予告もなく 最初を消してしまいます。よくある逃げ道は、それぞれにリポジトリのコピーを与えることですが、それは 問題をマージに先送りするだけです。 Murmellは別の道を取ります。共有ディレクトリと、書き込み前の確保です。エージェントは触れるパスを 宣言し、ボードがそれを与え、解放されるまで全員に対して拒否します。 仕組みの詳細。 Murmellが起動するエージェント Claude Code、Codex、Kimi、OpenCode。それぞれ本物のターミナルを持つキャンバスのウィンドウで、 あなたのアカウントやキーで署名されます。トークンは一切転売されません。請求はマシンと、人々が 見ている部屋をカバーします。ブラウザのClaude Codeは画面に何が表示されるかを説明しています。 --- ## Claude Code をクラウドで実行する：環境構築不要・複数エージェント並行開発 Source: https://murmell.com/ja/what/run-claude-code-in-the-cloud 始める前に必要なもの 空でも構わないリポジトリ。モデルプロバイダーのアカウント、またはAPIキー。そしてディレクトリを ホストしコマンドを実行するリモートマシンです。Murmellはプロジェクト作成時にマシンと非公開リポジトリ を作るので、実際には接続すべきモデルのアカウントが残るだけです。 リポジトリのルートにある指示ファイルは多くを変えます。プロジェクトの起動方法、壊してはいけない もの、チームの書き方。エージェントは起動時にそれを読み、費やす時間に対して得られる品質の比率が 最も良い方法です。 1時間はどんな感じか タスクを一文で説明します。エージェントは関係するファイルを読み、書き、テストを実行し、エラーを 読み、修正します。すべてのステップを見ているわけではありません。止まったときにターミナルを見て、 diffを読み返します。 2番目のエージェントになると、問題は分担になります。プロジェクトの2つの角にいる2つのエージェント は並行して進み、同じファイルにいる2つのエージェントはぶつかります。Murmellでは、それぞれが書き 込む前にパスを確保するので、衝突は後で発見されるのではなく、その場で拒否されます。 費用について、2行で 2つの請求書があり、分けて考えたほうがいいです。モデルのトークンはあなたのアカウントで、あなたの プロバイダーに支払います。マシンと部屋はホスティング側に支払います。Murmellはトークンを転売しない ため、あなたのClaudeサブスクリプションやOpenAIのキーは、いつも使っているものそのままです。 よくある落とし穴 リポジトリの3つのコピーで3つのエージェントを起動するのは一見自然な道に見えますが、その晩のうちに 代償を払うことになります。3つのブランチ、3回のマージ、そして誰も予期しなかった競合です。書き込み ルール付きの1つの共有ディレクトリなら、縫い合わせる作業ははるかに少なくなります。 ルールの仕組み、そして マシンに含まれるもの。 --- ## 主要AIコーディングエージェント徹底比較：並行処理とマルチエージェント構造で選ぶ13選 Source: https://murmell.com/ja/what/best-ai-coding-agents すべてを並べる問い これらのツールはすべてエージェントを起動できます。最初の1つは簡単です。読み、書き、テストを実行 します。考え方が分かれるのは2番目のエージェントからで、それが何を見て、何に触れる権利を持つかを 決めなければならないからです。 以下の表は何も格付けしていません。各ツールがどんな場面に向いているかを、ツールごとに1行で示し、 その下のグループが理由を説明します。 どれを選ぶか、1行ずつ ツール正解になる場面 Cursor自分でコードを書き、最高のキーボード体験が欲しい。 Devinチケット全体を任せて、結果の前に戻ってきたい。 Julesエージェントが何かに触れる前に計画を承認したい。 Copilot と Agent HQ作業がすでにチケットで整理されていて、レビューが約束の場である。 Codex cloudOpenAIのアカウントを持っていて、範囲の明確なタスクを委任したい。 Replit Agent何もない状態から始めて、その晩のうちにオンラインのアプリが欲しい。 Windsurf手で編集していて、自分のディスク上で並行実行がしたい。 ConductorMacで一人で作業していて、コードを外に出したくない。 OpenHands Agent Canvasコードは自分が管理するハードウェアに留まる必要があり、ソースが欲しい。 Vibe Kanban自分のマシンで1つずつこなすタスクの列がある。 Codegエージェントはすでに自分の環境で動いていて、全体を見渡すビューが足りない。 Gemini Code Assistすでに持っているエディタの中で良いエージェントが欲しく、何も払いたくない。 ウェブ版Claude CodeすでにCLIを使っていて、唯一の問いはどこで動くかだけ。 Murmell複数のエージェントが同じファイルに触れる必要があり、見ている人がいる。 比較ページの表はもう1つの問い、2番目のエージェントがどこへ行くかを扱っています。 タスクごとに1台のクラウドマシン エージェントはあなたが見ることのないマシン上であなたのリポジトリのクローンを受け取り、ブランチ上で作業し、プルリクエストを返します。最も普及した形であり、最も信頼を必要としない形です。エージェントが行うことは、あなたがdiffを読むまであなたのコピーに一切触れません。 Cursor. 1人1エディタ、1エージェント1マシンの世界と、全員のためのキャンバスと1つのディレクトリの世界。 Devin. 分離による並行性と共有による並行性、そしてそれぞれの形が正しいのはどんなときか。 Jules. 承認する計画とレビューするプルリクエストと、1本の木の中で見るターミナルの違い。 Copilot と Agent HQ. エージェントの作業がどこで収束するか。プルリクエストか、作業コピーか。 Codex cloud. 共有キャンバスでCodex CLIを起動することは、タスクを委任することと同じではない理由。 Replit Agent. 何もない状態からアプリケーションを作ることと、既存のコードで複数のエージェントを働かせることの違い。 タスクごとに1つの作業スペース、あなたのマシン上 あなたの側での同じ選択です。エージェントごとにgit worktreeか作業ディレクトリ、そして最後に1回のマージです。コードは外に出ないため、セキュリティの問題は起きる前に解決され、他の誰もそのセッションを見ません。 Windsurf. あなたのマシン上の会話ごとのworktreeと、クラウド上の共有ディレクトリ。 Conductor. タスクごとにスペースを持つMacアプリと、全員のための1つのディレクトリを持つクラウドキャンバス。 OpenHands Agent Canvas. リストの中で最も近い比較。エージェントごとのworktreeと、ファイル確保付きの1本の木。 Vibe Kanban. ローカル実行の上に乗るカンバンボードと、クラウドディレクトリの上に乗る共有キャンバス。 Codeg. ローカルのセッションを集めることと、共有クラウドディレクトリでエージェントを動かすことの違い。 一度に1つのエージェント、あなたのエディタの中で 記録されている並行処理はありません。1つのエージェントが、あなたがすでに書いているツールの中で監督されます。あなたがキーボードを握り、エージェントが補助する場合の最良の妥協点です。 Gemini Code Assist. あなたのエディタの中の監督付きエージェントと、あなたが見るディレクトリの中の監督なしの複数エージェント。 同じエージェント、別の場所で CLIは両側でまったく同じです。変わるのはそれが動くマシンと、それを見られる人数です。 ウェブ版Claude Code. 同じCLIが2つの場所に。タスクごとの隔離マシンと、キャンバス上の複数エージェントかつ単一の作業コピー。 共有ディレクトリ、そしてなぜほとんど誰もやらないか 表には4つ目の答えが欠けています。それが私たちのものです。複数のエージェントが1つのディレクトリに、 コピーなしでいる形です。ほとんど誰もこれを提案しないのは、調停者が必要だからです。調停者がいなければ、 2つのエージェントは同じバージョンのファイルを読み、2番目が何の告知もなく最初を消してしまいます。 Murmellはこの調停者をサーバーに置きます。エージェントは書き込む前に触れるパスを宣言し、ボードが それを割り当て、解放されるまで他の全員に対して拒否します。それでも他の誰かが保持しているファイル への書き込みが発生した場合、それは反映される前にスナップショットされます。 仕組みの詳細。 2分で選ぶ方法 自分でコードを書くなら、エディタを選びましょう。Cursor、Windsurf、Gemini Code Assistで問いは解決 します。タスクが独立していて任せたいなら、クラウドエージェントを選びましょう。Devin、Jules、 Codex cloudです。コードがネットワークを出る権利がないなら、OpenHandsを筆頭にローカルで自己ホスト 可能なものを選びましょう。 残るケースは1つだけで、それがMurmellが扱う唯一のものです。複数のエージェントが同じ1時間の中で 同じファイルに触れる必要があり、見ている人がいる場合です。比較を1つずつ見る。 --- ## 何もインストールせずにブラウザで動くClaude Code Source: https://murmell.com/ja/what/claude-code-in-the-browser 表示されるもの キャンバス上のウィンドウに、中にターミナルがあります。カーソルが点滅し、コマンドが書かれ、出力が 流れます。これはターミナルの再現ではなく、マシン上の本物の擬似端末がタブまで運ばれたものです。 あなたが知っているキー操作がそのまま動きます。中断、履歴をさかのぼる、ブロックを貼り付ける。 すべて同じプログラムなので、ノートパソコンと同じように振る舞います。 自分のマシンとの違い ディスクはあなたのものではありません。依存関係はプロジェクトのマシンにインストールされるため、 ノートパソコンはきれいなままで、キャンバスを開く全員にとって環境が同一になります。 そして2つ目を開けます。2つ目のウィンドウ、2つ目のエージェント、同じディレクトリで。確保のボード が互いを上書きしないよう管理します。 1つのファイルにつき所有者は1人。 誰が見られるか リンク1つで、同僚は同じターミナルが流れるのを見られ、キャンバス上に名前付きのカーソルが現れます。 見るだけならアカウントは不要で、費用もかかりません。作業後にdiffを見せるのと、作業そのものに 立ち会わせるのとの違いです。 他のエージェント Codex、Kimi、OpenCodeも同じように、それぞれ独自のウィンドウで、独自の認証情報で開きます。キャンバス の中では、エージェントによって何も変わりません。ウィンドウはウィンドウです。 単体のClaude CodeとMurmellの比較は両者の状況を直接比べています。 --- ## エージェントが動くクラウドマシン Source: https://murmell.com/ja/what/cloud-sandbox-for-ai-agents なぜサンドボックスが必要か ほとんどのドキュメントが使う言葉もサンドボックスです。 役に立つエージェントは、自分自身が書いたコマンドを実行します。パッケージのインストール、スクリプト の起動、ポートを開くこと。これらのコマンド一つひとつの前に人間のレビューが入るわけではないため、 唯一まともな防御は、それらが実行される場所です。 そこから導かれるルールはこうです。コードを実行するマシンには興味を引くものが何もありません。 データベースなし、復号鍵なし、他の顧客の認証情報なし。このマシン上のインシデントは、そのマシンだけ を失う代償で済みます。 何が入っているか プロジェクトのディレクトリ、エージェントのCLI、そしてエージェントが作業のためにインストールする ものです。あなたが接続する認証情報はセッション中エージェントに使われ、この範囲の外には出ません。 キャンバス、部屋、確保のボードは別の場所に住んでいます。ディスクに何を書き込んでも、エージェント は誰がファイルを保持しているかを決めることはできません。調停はエージェントが制御するマシンの上 にはないからです。 プロジェクトごとに1台のマシン プロジェクト間の隔離は設定ではなく、製品の形そのものです。各キャンバスは自分のマシンを起動し、 2つのプロジェクトが同じファイルシステムを共有することは決してありません。これは環境を再現可能 にするものでもあります。プロジェクトは毎回既知のイメージから始まります。 そして最後にコードは 非公開リポジトリはプロジェクトと同時に作成され、作業はセッションの間中プッシュされ、マシンが 破棄される前に最後のプッシュが行われます。あなたが手元に残すのは、Murmellなしでも読める、あなた の側にある普通のリポジトリです。セッションの流れ。 --- ## AI エージェントとのマルチプレイヤーコーディング Source: https://murmell.com/ja/what/multiplayer-coding-with-ai-agents 必要なのは1つの URL だけです。インストールの必要も、コードのローカルコピーも、作業を見るための画面共有も不要です。 参加者に見えるもの リンクを送信すると、開いた人には録画ではなく現在のキャンバスが表示されます。ウィンドウの位置、リアルタイムで出力されるターミナルの文字、他の人の名前付きカーソル、誰がどの画面を見ているかが表示されます。 閲覧リンクは無料で無制限に発行できます。エージェントを操作できるリンクはプランの上限に基づきます。閲覧コストはほぼゼロですが、マシンの稼働には相応のコストがかかるためです。 各自ができること 各自が自分のエージェントを操作し、全員がすべてのエージェントを視認できます。1つのキーボードを奪い合うのではなく、共有されるのはキャンバスとディレクトリです。 これにより、人間同士の本来の役割である「エージェントに何をさせるか」の意思決定に集中できます。誤った処理を見つけたら指摘し、担当者が軌道修正する様子を全員で見守ることができます。開発者向け Figmaでも同様の構造を解説しています。 エージェントも参加者の一員 同一環境で複数エージェントを走らせるには工学的配慮が必要です。エージェントが変更対象のパスを予約し、ボードが1つの保持者を記録して解放まで他を拒否します。拒否はサーバー側で強制されるため、モデルが無視することはできません。 1つのリポジトリに複数の AI エージェントで詳細な仕組みと計測データを紹介しています。 ブラウザを閉じても停止しない タブを閉じてもエージェントは終了しません。エージェントはキャンバス上で稼働し続けるため、離脱中に進んだ処理結果も再接続時にそのまま確認できます。 コードもマシン内だけに留まりません。プロジェクトごとにプライベートリポジトリが用意され、変更は随時プッシュされ、マシン破棄時にも最終保存が行われます。 Murmell とはで全体像を解説し、ホームページで実際のルームを描画しています。 --- ## 面向开发者的云端 AI：托管模型、API 与远程编程代理的区别 Source: https://murmell.com/zh/what/cloud-ai 一个词底下的三件事 第一种含义最古老:一个托管在别处的模型。你什么都不用下载,通过网页或者 App 访问一个界面,计算发生在厂商的服务器上。ChatGPT 或 Claude.ai 的网页版就是这个意思。 第二种含义面向开发者:一个可以从自己代码里调用的 API。你发一个请求,拿到一个回答,把它接进自己的产品里。这仍然是"云端",但没有代理会自己动手写代码。 第三种含义是本页真正关心的:一个云端 AI 代理。它不只是回答问题,它在一台远程机器上执行命令:读文件、写代码、跑测试、装依赖。它运行在服务器上,不是你的笔记本上,所以关掉标签页它不会停。 为什么第三种含义不一样 前两种含义下,关掉浏览器就等于停止。第三种含义下,进程继续跑在远程机器上:你启动一个任务,离开,回来发现它已经完成或者卡在了某个地方等你处理。 这也是为什么数量不再是问题。一个代理占用一台机器,不占用你的注意力。多个代理需要的是一种旁观的方式,而不是成倍的精力。 代理具体做什么 一个云端 AI 代理收到一句话描述的目标,读相关文件,写修改,跑测试或编译,读结果,再修正,如此循环直到达成目标。这个循环的详细说明。 多个代理共用一个项目时 代理数量一旦超过一个,谁能写哪个文件就成了问题。大多数工具给每个代理一份仓库拷贝来回避这个问题,把冲突挪到合并的那一刻。多个 AI 代理共用一个仓库 说明了另一种做法:共用一个目录,写入前先占用,对比页面 把 Murmell 和 Cursor、Devin、Copilot 以及 Codex 的云端代理放在一起比较。 --- ## 云端 AI 编程代理：如何在远程代码仓库自主运行与测试 Source: https://murmell.com/zh/what/cloud-ai-agent 循环,分三步 代理先读仓库摸清情况,写一处修改,然后跑一个能告诉它对不对的东西:一套测试、一次编译、一条命令。它读结果,修正,再来一轮。正是这个循环把代理和一个文本生成器区分开来:它在两次尝试之间从真实世界拿到反馈。 远程机器登场,是因为这个循环需要一些你不想在自己笔记本上做的事:装依赖包、占满硬盘、让一台服务器连续开四十分钟。 机器不是你自己的之后,变了什么 工作能扛过关标签页这件事。你启动一个任务,出去吃饭,进程继续跑。在笔记本上,合上盖子就意味着一切停止,这也是大多数人不敢启动长任务的真正原因。 数量不再是问题。一个代理占用一台机器,而不是占用你的屏幕。五个代理不需要五倍的注意力,它们需要的是一种旁观的方式。 环境也变得可复现。每个项目的机器都从同一份已知镜像启动,"我这边能跑"这句话不再成立。 第二个代理会撞上的问题 同一个目录里的两个代理,前后相差三十秒写同一个文件,后者会抹掉前者,而且没有任何提示。惯常的解法是各给一份仓库拷贝,这只是把问题挪到了合并阶段。 Murmell 走另一条路:共用一个目录,写入前先占用。代理声明自己要动的路径,看板把这些路径给它,并拒绝所有其他人,直到它释放为止。这套机制 的详细说明。 Murmell 启动的代理 Claude Code、Codex、Kimi 和 OpenCode,各自在画布的一个窗口里运行,背后是真正的终端,用你自己的账号或密钥登录。没有 token 被转售:账单只覆盖机器和旁观的房间。Claude Code 在浏览器里 描述了它在屏幕上到底长什么样。 --- ## 主流 AI 编程代理选型横评：按并发架构与多任务机制深度对比 Source: https://murmell.com/zh/what/best-ai-coding-agents 把一切归类的那个问题 这些工具都会启动一个代理。第一个很简单:它读,它写,它跑测试。设计的分歧出现在第二个代理身上,因为这时必须决定它能看到什么、有权碰什么。 下面的表格不做排名:它说清楚每款工具适合谁,一行一款,下面的分组解释原因。 该选哪个,一行说清楚 工具适合的场景 Cursor你自己动手写代码,想要最好的编辑体验。 Devin你想交出一整个工单,回来看结果。 Jules你想在代理动手之前先批准一份计划。 Copilot 与 Agent HQ你的工作已经按工单管理,审阅是既定的交接点。 Codex Cloud你有一个 OpenAI 账号和边界清晰的任务要委托。 Replit Agent你从零开始,想当晚就把应用做上线。 Windsurf你手动编辑代码,想在自己硬盘上并行执行。 Conductor你独自在 Mac 上工作,代码不能外传。 OpenHands Agent Canvas代码必须留在你能控制的硬件上,你还想要源码。 Vibe Kanban你有一串任务,要在自己的机器上一个个过。 Codeg代理已经在你那边运行,缺的是一个总览视图。 Gemini Code Assist你想要一个好用的代理,就在你已经在用的编辑器里,不用额外付费。 网页版 Claude Code你已经在用这个 CLI,唯一的问题是它跑在哪里。 Murmell多个代理需要碰同样的文件,而且有人在旁观。 对比页面 的表格回答的是另一个问题:第二个代理去了哪里。 每个任务一台云端机器 代理拿到你仓库在一台你看不见的机器上的克隆,在一个分支上工作,交出一个 pull request。这是最常见的形式,也是需要信任最少的一种:在你读到 diff 之前,它做的任何事都碰不到你自己的拷贝。 Cursor。一人一个编辑器、一个代理一台机器,对比一块画布、一个目录给所有人共用。 Devin。靠隔离实现并行,对比靠共享实现并行,以及各自适合的场景。 Jules。一份你批准的计划和一个你审阅的 pull request,对比在同一棵代码树里你能实时看到的终端。 Copilot 与 Agent HQ。代理的工作在哪里汇合:是在 pull request,还是在工作副本里。 Codex Cloud。在共享画布上运行 Codex CLI,和把一个任务委托出去,是两件不同的事,原因在这里。 Replit Agent。从零造一个应用,对比让多个代理在已经存在的代码上工作。 每个任务一个工作空间,在你自己的机器上 同样的选择,只是在本地:一个代理一个 git worktree 或工作目录,最后合并。代码不外传,这提前解决了安全问题,也没有别人看到这场会话。 Windsurf。你机器上每段对话一个 worktree,对比云端的一个共享目录。 Conductor。一款一个任务一个空间的 Mac 应用,对比一块所有人共用一个目录的云端画布。 OpenHands Agent Canvas。这份对比列表里最接近的一组:一个代理一个 worktree,对比一整棵树加文件占用机制。 Vibe Kanban。本地执行之上的一块看板,对比云端目录之上的一块共享画布。 Codeg。汇总本地会话,对比在共享云端目录上直接启动代理。 同一时间一个代理,在你的编辑器里 没有文档说明的并行能力:一个受监督的代理,在你已经在写代码的工具里。当键盘在你手里、代理只是辅助时,这是最好的折中方案。 Gemini Code Assist。编辑器里一个受监督的代理,对比一个你旁观的目录里多个不受监督的代理。 同一个代理,换个地方 CLI 在两边完全一样。变化的是它运行的机器,以及能旁观它的人数。 网页版 Claude Code。同一个 CLI,两种运行方式:每个任务一台隔离机器,还是画布上多个代理共用一份工作副本。 共享目录,以及为什么几乎没人这么做 表格里缺了第四种答案,那正是我们的答案:多个代理在一个目录里,不做拷贝。几乎没人这样做,因为它需要一个仲裁者。没有仲裁者,两个代理会读到同一个版本的文件,第二个覆盖第一个,而且没有任何提示。 Murmell 把这个仲裁者放进了服务器。代理写入前先声明要动的路径,看板把这些路径分配给它,拒绝所有其他人,直到它释放。如果一次写入还是落在了别人占用的文件上,它会在落地前被拍下快照。机制详细说明。 两分钟做出选择 如果你自己写代码,选一个编辑器:Cursor、Windsurf 或 Gemini Code Assist,问题就解决了。如果任务互相独立、你想委托出去,选一个云端代理:Devin、Jules 或 Codex Cloud。如果代码不能离开你的网络,选本地、可自托管的方案,首选 OpenHands。 还剩一种情况,也是唯一 Murmell 处理的情况:多个代理需要在同一个小时里碰同样的文件,还有人在旁观。逐个对比。 --- ## 什么是 Murmell？一个仓库里的多个编程代理 Source: https://murmell.com/zh/what/murmell 将链接发送给他人，他们就能和你一起进入画布，看着同一个终端滚动，光标上标有他们的名字。 你看到的是什么 一个浅色点状画布，上面排列着窗口，样式类似于 macOS。每个窗口是一个代理的终端，原样显示我们机器上实际 CLI 输出的字符。窗口并排摆放，五个代理就是同一屏幕上的五个窗口，你可以同时阅读所有内容。 主页上的画布绘制的就是完全相同的对象。 一个目录，以及一个记录谁持有哪个文件的看板 如果给三个代理同一个工作目录且没有任何规则，它们在一分钟之内就会互相覆盖。最后写入者悄无声息地覆盖，直到测试莫名其妙地失败才会被发现。 因此代理在修改路径之前必须先声明占用。看板为每个路径记录唯一的持有者，并拒绝其他所有人直到持有者释放。这种拒绝是由我们的服务器执行的，而不是模型可以跳过的提示词指令。即使发生冲突，写入在落地前也会被快照保存。 没有事先声明，谁也不能写入。 一个仓库上的多个 AI 代理详细介绍了看板，包括两个代理使用它时的测量数据。 房间里的人 只读链接完全免费，发放数量不限。编辑链接受套餐限制。打开链接的人可以看到窗口所在位置和实时的终端输出，并看到其他光标移动且每个光标带有姓名。 关闭标签页不会终止代理。它们属于画布，因此工作在没有你的情况下继续进行，返回时依然在运行。与 AI 代理多人协作编程介绍了两个人在同一画布上各自能做什么。 代码存放在哪里 每个项目都会获得一个私有 Git 仓库，工作成果在进行中实时推送。即将销毁的机器在关闭前会进行最后一次推送，因此一次性的是机器，绝不是代码。 执行代理代码的机器不存放数据库，也不存放解密密钥。逃逸的代理只会发现一个项目目录，没有任何有价值的东西可窃取。面向 AI 代理的云沙箱说明了各类机密的存放位置。 名字从何而来 Murmell 源自 murmuration（鸟群），即成千上万只鸟协同移动时形成的奇观。同一个词也表示低语、轻柔的声音，这也是 Logo 的寓意：一缕波浪。 --- ## 在云端运行 Claude Code：免安装、多代理与远程终端开发 Source: https://murmell.com/zh/what/run-claude-code-in-the-cloud 开始之前需要什么 一个仓库,哪怕是空的。一个模型厂商的账号,或者一个 API 密钥。再加一台承载目录、执行命令的远程机器。创建项目时 Murmell 会一并建好机器和一个私有仓库,所以实际上只剩下接入模型账号这一步。 在仓库根目录放一份指令文件能改变很多东西:怎么启动项目、什么不能碰、团队的写法习惯。代理启动时会读取它,这是投入时间和产出质量之间性价比最高的一步。 一个小时大概是什么样 你用一句话描述一个任务。代理读相关文件,写代码,跑测试,读错误信息,修正。你不会盯着每一步:你在它停下来的时候看一眼终端,读一下 diff。 到第二个代理时,问题变成了怎么分工。两个代理各管项目的一角,会并行推进;两个代理盯着同一个文件,就会互相踩脚。在 Murmell 上,每个代理写入前都会先占用自己要动的路径,所以冲突会被直接拒绝,而不是事后才被发现。 花费,两句话说清 实际存在两笔账,分开看更清楚。模型的 token 费用付给你自己的模型厂商,记在你自己的账号上。机器和房间的费用付给托管方。Murmell 不转售 token,也就是说你的 Claude 订阅或 OpenAI 密钥,用的还是你原来那一个。 常见的坑 让三个代理各拿一份仓库拷贝去跑,看起来是显而易见的做法,但当晚就会露馅:三个分支、三次合并,还有一堆没人提前看到的冲突。共用一个目录、配上写入规则,收尾的缝合工作会少得多。这条规则如何运作,以及 这台机器里到底有什么。 --- ## 与 AI 代理多人协作编程 Source: https://murmell.com/zh/what/multiplayer-coding-with-ai-agents 这是一个单独的 URL。没有人需要安装任何东西，没有人需要拷贝代码，也没有人需要共享屏幕别人才能看到工作进展。 访客能看到什么 你发送一个链接。打开它的人看到的是实时的画布，而不是录屏。他们看到窗口所在的位置，终端输出一行一行实时到达。他们看到其他光标带着名字移动，以及每个人正在看哪个窗口。 只读链接完全免费，发放数量没有限制。允许他人控制代理的链接受套餐额度限制，这是符合常理的设定：旁观几乎不消耗我们的成本，而机器有其固定的成本。 每个人能做什么 每个人控制自己的代理，所有人都能看到所有代理。这与两个人抢一个键盘不同：共享的是画布和它下面的目录，而不是单个键盘。 这足以满足人们真正一起做的事：决定代理应该做什么。当你看到某个任务走偏时指出问题，持有该窗口的人进行调整，所有人实时看到修正生效。开发者专属的 Figma用你熟悉的工具做了同样的论述。 代理是其他参与者 同一个工作区里的多个代理是需要工程设计的部分。代理声明即将修改的路径，看板为每个路径记录唯一的持有者，其他人都会被拒绝直到持有者释放。拒绝来自我们的服务器，因此这不是模型可以选择忽略的提示词。 一个仓库上的多个 AI 代理详细介绍了该机制及我们实际运行的测量数据。 离开并不会终止运行 关闭标签页不会终止代理。它们属于画布而不是你的浏览器，因此工作会继续进行，离开期间产生的输出在重新打开时依然存在。 代码也不会仅仅停留在该机器上。每个项目都有私有 Git 仓库，代码实时推送，即将销毁的机器在关闭前会进行最后一次推送。 什么是 Murmell用一页涵盖了其余内容，主页展示了房间视图。 --- ## 多个 AI 代理共用同一个仓库 Source: https://murmell.com/zh/what/multiple-ai-agents-one-repo 会搞砸一切的那种情况 两个代理拿到两个都会碰同一个文件的任务。第一个读文件,想了二十秒,写入。第二个在第一个写入之前读到的是同一个版本,于是它直接写了上去。什么都没崩溃,什么提示都没有,第一个代理的工作凭空消失了。 只要代理数量超过一个,这种情况就不算少见,因为代理读得广、写得快。这也是几乎所有工具都选择隔离的原因:一个代理一台机器,一个代理一个分支。 其他产品的做法:每个代理一个 worktree 对这个问题最常见的回答是分区:给每个代理自己的 git worktree,一份完整的文件拷贝和独立索引,再想办法让各自的范围不重叠。Windsurf、Conductor 和 OpenHands 都是这么做的,大多数教程也这么推荐。 这样做有效,而且只有一个缺点:分区是一个承诺,不是一个保证。没有人真的核实范围是否重叠,一旦重叠了,要到合并的时候才会发现,那时两个代理都已经做完,已经没人记得当初的思路了。 占用机制,分三步 写入之前,代理先声明自己要动的路径。如果这些路径是空闲的,看板就分配给它;如果被占着,就拒绝。任何时刻,每个文件只有一个持有者。 工作过程中,一个观察者盯着磁盘上真正发生的写入,把每一次都归属到它的作者。落在别人占用路径上的写入会在落地前被拍下快照:之前的版本被保留下来,所以即使规则被绕开,也不会丢失任何东西。 结束时,代理释放自己的路径。文件立刻对下一个代理可用,不需要合并,因为从来就没有两个版本同时存活过。 屏幕上看到的是什么 每个窗口显示自己代理的工作过程,看板显示谁占着什么。你能看到一个代理在等,也能看到为什么。一个卡住的代理在造成损失之前就能被看见,这正是它和一条看不见的等待队列的真正区别。 人也一样能被看到。同一块画布上的多个人各自操作自己的代理,还能看到彼此带名字的光标。 什么时候这不是对的做法 如果你的任务真的互不相关,而且耗时很长,按机器隔离仍然合理:没什么需要仲裁,也没什么需要等待。当任务开始互相触碰(只要是在同一个功能上工作,几乎立刻就会发生),共享就更划算。对比页面 会逐个工具讲清楚这个选择。 --- ## 开发者专属的 Figma：面向代码的多人协作画布 Source: https://murmell.com/zh/what/figma-for-developers 这个类比很有价值，因为它去掉了多余的环节。没有导出，没有需要调和的本地副本，也没有一个人操作其他人只能干猜的屏幕共享。 这个类比说对了什么 一个 URL 就是整个操作面。上面的每个人在同一时刻看到完全相同的画布，存在感是通过画出来的光标和谁正在看哪个窗口来体现的，而不是文字描述。 旁观是特意设计为免费的，就像 Figma 的查看者席位一样。只读链接完全免费且没有数量限制。编辑链接受你的套餐限制。 而且这个工作面默认就是共享的。你不需要在事后才决定分享工作，因为工作从一开始就不是在任何私密角落进行的。主页展示了它的具体样貌。 这个类比哪里不适用 在 Figma 里，画布上的东西就是产物。在这里不是。产物是一个 Git 仓库，画布是发生工作的房间。历史记录保存在每个项目的私有仓库里，随着项目推进实时推送，而不是存放在画布里。 在 Figma 里两个人可以挪动同一个矩形。在这里两个人不会在同一个终端里打字。每个人控制自己的代理，所有人都可以看到所有代理，这和两个人抢一个键盘不是一回事。 而且 Murmell 画布上的大部分工作不是由人类完成的。代理在云端机器上打字，多个代理位于同一个目录中。人类负责旁观，并在代理走偏时介入。 为什么现在代码需要共享工作面 编辑器里的单个代理从来不需要房间。同一个目录里的多个代理产生的输出比一个人能轻松跟踪的要多得多，引导它们的人必须看着同一个界面才能合理分配工作。 这也是为什么代理共享一个目录而不是各自拥有一个 worktree。代理在写入路径前先声明占用，服务器在释放前拒绝其他所有人，因此第二个代理能直接读取第一个代理刚写完的内容，而不是到合并时才发现冲突。 一个仓库上的多个 AI 代理介绍了这套机制，而与 AI 代理多人协作编程则介绍了人类协作的部分。 --- ## 云端 AI 编程术语表 Source: https://murmell.com/zh/what/glossary AI 编程代理 一个程序,收到一句话描述的目标就一直工作到达成为止:读文件、写代码、跑测试、读错误信息、再来一轮。它执行命令,这一点把它和只会提出文字的助手区分开来。 云端 AI 根据说话的人不同指三件事:一个厂商托管的模型、一个从你自己程序里调用的 API,或者一个运行在远程机器上的代理。第三种含义是唯一"关掉标签页之后还在继续"的情况。 智能体式 AI(Agentic AI) 一种追求目标而不是回答问题的 AI:它自己选择行动,执行,结果不满意就重来。这个词说的是程序在做什么,而"云端 AI"说的是它在哪里运行。 Worktree git 仓库的第二份工作副本,有自己的索引,在另一个分支上。这是让多个代理互不打扰地工作的最常见做法,代价是每份副本都要合并一次。 分区(Partitioning) 把文件分给不同代理,让他们互不交叉。只要划分得当就有效,但没人真的去核实划分是否正确:这是一个承诺,不是一个保证。 画布(Canvas) 摆放代理窗口的平面,每个窗口里是一个终端。它通过一个链接分享出去,旁观的人在上面有一个带名字的光标。 文件占用 代理在写入路径之前先声明要写的路径。每个路径只有一个持有者,由服务器强制执行,这让多个代理能共用一个目录而不会互相覆盖。 碰撞(Collision) 一次写入落在了别人持有的文件上。它会在落地前被拍下快照,所以之前的版本仍然存在,不会丢失任何东西。 沙箱(Sandbox) 代理代码执行所在的隔离机器。在 Murmell 上,每个项目一台,不含数据库也不含解密密钥:出了事,代价只是这台机器。 一次性机器 为一次会话创建、会话结束后销毁的机器。任何需要保留的东西都会在销毁前推送进一个仓库。 上下文(Context) 模型作答那一刻眼前拥有的东西:你的请求、读过的文件、会话历史。它的容量有限,这也是为什么一次很长的会话里代理会忘记开头发生了什么。 Token 模型计费和计量的单位,大致相当于一个词的一小部分。一次会话的价格按读写的 token 数量计算,付给你自己的模型厂商。 CLI 一种在终端里用键盘操作的程序。Claude Code、Codex、Kimi 和 OpenCode 都是,这也是为什么它们能被启动在远程机器上、又显示在一个标签页里的原因。 终端(Terminal) 命令输入、输出滚动的那个文字窗口。在 Murmell 上,它是远程机器上一个真正的终端,被搬运到浏览器里,不是仿制品。 仓库(Repository) 存放版本化代码的地方。每个 Murmell 项目都会得到一个私有仓库,工作在会话过程中不断被推送进去。 只读链接 一个不需要账号、不需要付款就能旁观画布的地址。能看到窗口、滚动的终端和光标,但碰不了任何东西。 多人协作 多个人同时在同一块画布上,各自操作自己的代理,能看到彼此带名字、带颜色的光标。 其中三个词的详细版本:云端 AI、云端 AI 代理 和 文件占用机制。 --- ## 在浏览器里用 Claude Code,不装任何东西 Source: https://murmell.com/zh/what/claude-code-in-the-browser 你看到的是什么 画布上的一个窗口,里面是一个终端。光标在闪烁,命令在输入,输出在滚动。这不是重新拼出来的终端画面:它是机器上真正的伪终端,被原样搬到了标签页里。 你熟悉的按键都能用。中断、翻历史、粘贴一大段文字,表现和在你自己电脑上一样,因为运行的就是同一个程序。 相比自己的机器,变了什么 硬盘不是你的了。依赖包装在项目的机器上,你的笔记本保持干净,打开这块画布的每个人用的环境也完全一样。 而且你可以再开一个。第二个窗口,第二个代理,在同一个目录里。占用看板负责防止他们互相覆盖:一个文件只有一个持有者。 谁能旁观 一个链接就够了,同事能看到同一个终端实时滚动,自己的光标带着名字出现在画布上。旁观不需要账号,也不花钱。这就是事后展示一份 diff 和让人当场看着你工作之间的区别。 其他代理 Codex、Kimi 和 OpenCode 用同样的方式打开,各自在自己的窗口里,用各自的账号登录。画布里不会因为换了代理而有什么不同:窗口就是窗口。Murmell 对比单独的 Claude Code 把两种情况直接放在一起比较。 --- ## クラウドAIコーディングの用語集 Source: https://murmell.com/ja/what/glossary AIコーディングエージェント プログラムが一文で目標を受け取り、それを達成するまで作業します。ファイルを読み、書き込み、テストを実行し、エラーを読み、やり直します。コマンドを実行する点が、テキストを提案するアシスタントとの違いです。 クラウドAI 話す人によって3つの意味があります。プロバイダーがホストするモデル、あなたのソフトウェアから呼び出すAPI、そしてリモートマシン上で動作するエージェントです。タブを閉じても何かが続くのは3つ目の意味だけです。 エージェンティックAI 質問に答える代わりに目標を追うAIです。自分の行動を選び、実行し、結果が満足いくものになるまでやり直します。この言葉はプログラムが何をするかを言い、「クラウドAI」はどこで動くかを言います。 worktree gitリポジトリの2つ目の作業コピーで、独自のインデックスを持ち、別のブランチにあります。複数のエージェントを互いに邪魔せずに動かす最も一般的な方法で、コピーごとに1回のマージという代償を払います。 分割 (パーティショニング) エージェント同士が交差しないようにファイルを割り振ることです。割り振りが正しい限りうまくいきますが、それが正しいことを誰も検証しません。約束であって保証ではありません。 キャンバス エージェントのウィンドウが配置される面で、それぞれの中にターミナルがあります。リンクで共有され、見ている人には名前付きのカーソルがあります。 ファイル確保 エージェントが書き込むパスを、書き込む前に宣言することです。パスごとに所有者は1人だけで、サーバーが強制します。これにより複数のエージェントが互いを上書きせずにディレクトリを共有できます。 衝突 他の誰かが保持しているファイルへの書き込みです。反映される前にスナップショットされるため、前のバージョンはまだ存在し、何も失われません。 サンドボックス エージェントのコードが実行される隔離されたマシンです。Murmellではプロジェクトごとに1台、データベースも復号鍵もありません。そこで起きることのコストはそのマシンだけです。 使い捨てマシン セッションのために作成され、その後破棄されるマシンです。生き残るべきものはすべて破棄前にリポジトリにプッシュされます。 コンテキスト モデルが答える瞬間に目にしているものです。あなたの依頼、読んだファイル、セッションの履歴。サイズには限りがあるため、非常に長いセッションではエージェントが最初の部分を忘れる理由がここにあります。 トークン モデルの課金と計測の単位で、おおよそ単語の一部に相当します。セッションの価格は、あなたのモデルプロバイダーのもとで読み書きされたトークン数で数えられます。 CLI ターミナルでキーボードから操作するプログラムです。Claude Code、Codex、Kimi、OpenCodeはすべてCLIであり、だからこそリモートマシン上で起動してタブに表示できます。 ターミナル コマンドが書かれ、出力が流れるテキストウィンドウです。Murmellでは、これはリモートマシン上の本物のターミナルがブラウザまで運ばれたもので、模造品ではありません。 リポジトリ コードが住むバージョン管理された場所です。各Murmellプロジェクトは非公開のリポジトリを1つ受け取り、作業はセッションの間中そこにプッシュされます。 閲覧リンク アカウントなし、支払いなしでキャンバスを見られるアドレスです。ウィンドウ、流れるターミナル、カーソルが見えますが、操作はできません。 マルチプレイヤー 複数の人が同時に同じキャンバスにいて、それぞれが自分のエージェントを操作し、他の人のカーソルが名前と色付きで見える状態です。 これらのうち3つの長いバージョンは、クラウドAI、 クラウドAIエージェント、 ファイル確保の仕組みで読めます。 --- ## 1つのリポジトリで複数のAIエージェント Source: https://murmell.com/ja/what/multiple-ai-agents-one-repo すべてを壊すケース 2つのエージェントが同じファイルに触れる2つのタスクを受け取ります。最初のエージェントがファイル を読み、20秒考え、書き込みます。2番目のエージェントは最初が書き込む前に同じバージョンを読んで おり、それを上書きしてしまいます。何もクラッシュせず、何も警告せず、最初の作業は消えました。 この状況は1つ以上のエージェントがいれば珍しくありません。エージェントは広く読み、速く書くから です。ほとんどのツールが隔離している理由がここにあります。エージェントごとに1台のマシン、エージェ ントごとに1つのブランチです。 他の世界がやっていること: エージェントごとにworktree この問題への一般的な答えは分割です。各エージェントに独自のgit worktree、独自のインデックスを 持つファイルの完全なコピーを与え、範囲が重ならないように調整します。Windsurf、Conductor、 OpenHandsがやっていることで、ほとんどのガイドが推奨する方法です。 これは機能し、欠点はちょうど1つです。分割は約束であって保証ではありません。範囲が重ならない ことを誰も検証しておらず、重なったときにそれがわかるのはマージのとき、つまり両方のエージェント が終わり、もう誰も理由を覚えていないときです。 確保、3つの段階で 書き込む前に、エージェントは触れるパスを宣言します。ボードは空いていればそれを割り当て、保持 されていれば拒否します。常に1つのファイルにつき所有者は1人だけです。 作業中、監視役はディスクへの実際の書き込みを見張り、それぞれをその作成者に紐づけます。他の 誰かが保持しているパスへの書き込みは反映される前にスナップショットされます。前のバージョンは 保持されるため、ルールが回避されても何も失われません。 最後に、エージェントはパスを解放します。ファイルは次のエージェントのために利用可能になり、 マージは不要です。生きているバージョンが2つ同時に存在したことは一度もないからです。 画面に映るもの 各ウィンドウは作業中のエージェントを映し、ボードは誰が何を持っているかを示します。エージェント が待っていること、そしてその理由が見えます。行き詰まったエージェントは被害が出る前に見えます。 これが見えないキューとの本当の違いです。 人も数に入ります。同じキャンバス上の複数の人が、それぞれ自分のエージェントを操作し、名前付き の他人のカーソルを見ます。 この形が適さないとき タスクが本当に独立していて長時間かかるなら、マシンごとの隔離は依然として合理的です。調停する ものも待つものもありません。共有が勝るのはタスクが触れ合うときで、同じ機能に取り組んでいれば 必ずそうなります。比較ページではツールごとの選択を詳しく説明しています。 --- ## 代理运行所在的那台云端机器 Source: https://murmell.com/zh/what/cloud-sandbox-for-ai-agents 为什么需要沙箱 大多数文档里也叫它 sandbox。 一个有用的代理会执行它自己写的命令:装一个包,跑一个脚本,打开一个端口。没有人会在这些命令执行前逐条审核,这意味着唯一靠得住的防护就是它们运行的地方。 由此得到这条规则:执行代码的机器上不放任何有价值的东西。没有数据库,没有解密密钥,没有别的客户的凭证。这台机器出了事,代价就只是这台机器。 它里面有什么 项目的目录,代理的各种 CLI,以及代理为了工作装进去的东西。你接入的凭证只在会话期间供代理使用,不会离开这个范围。 画布、房间和占用看板都活在别处。一个在自己磁盘上乱写的代理,没办法决定谁持有某个文件:仲裁权不在它能控制的这台机器上。 一个项目一台机器 项目之间的隔离不是一个开关,而是产品本身的形状。每块画布启动自己的机器,两个项目永远不会共用一个文件系统。这也是环境可复现的原因:每次都从同一份已知镜像启动。 最后,代码去了哪里 项目创建的同时会生成一个私有仓库,工作在会话过程中不断被推送进去,机器销毁前还会有最后一次推送。你最终留下的是一个普通仓库,在你自己手里,离开 Murmell 也能读。一次会话的完整过程。 --- ## 開発者のための Figma：コードのためのマルチプレイヤーキャンバス Source: https://murmell.com/ja/what/figma-for-developers この類推は、不要な工程を取り除いてくれるという点で価値があります。エクスポートも、突き合わせるローカルコピーも、1人が操作して他が推測する画面共有もありません。 類推が正しく捉えていること 1つの URL が作業領域全体です。そこにいる全員がまったく同じ瞬間に同じキャンバスを見渡し、存在は言葉ではなく描画されます。名前付きカーソルと、誰がどのウィンドウを見ているかが表示されます。 閲覧は Figma の閲覧用シートと同様に意図的に無料となっています。読み取りリンクは無料で無制限です。編集リンクはプランの上限に基づきます。 そして作業領域はデフォルトで共有されます。作業が非公開な場所で行われていたわけではないため、後から共有を決める必要はありません。ホームページでその実際の様子をご覧いただけます。 類推が当てはまらないこと Figma ではキャンバス上のものが成果物です。Murmell では違います。成果物は Git リポジトリであり、キャンバスは作業が行われる部屋です。履歴はキャンバスではなくプロジェクトごとのプライベートリポジトリに保存されます。 Figma では2人が同じ四角形を動かせます。Murmell では2人が1つのターミナルに同時に文字を打ち込むことはありません。各自が自分のエージェントを動かし、全員がすべてを観察します。 そして Murmell キャンバス上の作業の大部分は人間ではなくエージェントが行います。エージェントがクラウドマシン上の同一ディレクトリで入力し、人間はそれを見守り、軌道修正を行います。 なぜ今コードに共有作業領域が必要なのか エディタ内の単一エージェントに部屋は不要でした。同一ディレクトリにいる複数のエージェントは1人が追いきれない量の出力を生成するため、指示を出す人間が同じ画面を見て分担を決める必要があります。 エージェントが個別のワークツリーではなく1つのディレクトリを共有するのもそのためです。エージェントは書き込み前にパスを予約し、解放されるまで他のアクセスを拒否するため、2番目のエージェントはマージ時ではなく直後に最新内容を読み取れます。 1つのリポジトリに複数の AI エージェントで仕組みを解説し、AI エージェントとのマルチプレイヤーコーディングで人間の協調作業を説明しています。 --- ## Guides: putting coding agents to work Source: https://murmell.com/how How to use Claude Code without installing anything The steps for opening a real Claude Code terminal from a browser, with no local installation. How to run several AI agents on one project The steps for running several coding agents on one shared directory, from empty project to splitting the files. How to show a coding session live The steps for letting a colleague or a client watch an agent session live, with nothing but a link. Before the guides If the vocabulary is not settled yet, what cloud AI means and what an agent does take two minutes each. --- ## Anleitungen: KI-Agenten zum Arbeiten bringen Source: https://murmell.com/de/how Claude Code im Browser nutzen ohne lokale Installation Die Vorgehensweise, um ein echtes Claude-Code-Terminal aus einem Browser zu öffnen, ohne lokale Installation. Mehrere KI-Agenten in einem Repository gleichzeitig ausführen (ohne Git-Konflikte) Die Vorgehensweise, um mehrere Coding-Agenten in einem gemeinsamen Verzeichnis laufen zu lassen, vom leeren Projekt bis zur Aufteilung der Dateien. Live-Coding-Session mit KI teilen (ohne Screen-Sharing) Die Vorgehensweise, damit ein Kollege oder Kunde eine Live-Sitzung von Agenten mit einem einfachen Link ansieht. Vor den Anleitungen Falls die Begriffe noch nicht klar sind, lesen sich was Cloud-KI bedeutet und was ein Agent macht in je zwei Minuten. --- ## Guías: hacer que los agentes de IA trabajen Source: https://murmell.com/es/how Cómo usar Claude Code en el navegador sin instalar nada en tu equipo La forma de abrir una terminal real de Claude Code desde el navegador, sin instalación local. Cómo ejecutar varios agentes de IA en un mismo repositorio (sin conflictos de Git) La forma de hacer correr varios agentes de código en un mismo directorio, del proyecto vacío al reparto de archivos. Cómo compartir una sesión de código con IA en vivo (sin compartir pantalla) La forma de dejar que un compañero o un cliente vea una sesión de agentes en directo, con un simple enlace. Antes de las guías Si el vocabulario todavía no está claro, qué significa IA en la nube y qué hace un agente se leen en dos minutos cada una. --- ## Guias: fazendo agentes de IA trabalharem Source: https://murmell.com/pt/how Como usar o Claude Code no navegador sem instalar nada no seu computador O passo a passo para abrir um terminal Claude Code de verdade a partir de um navegador, sem instalação local. Como rodar vários agentes de IA no mesmo repositório (sem conflitos de Git) O passo a passo para rodar vários agentes de código no mesmo diretório, do projeto vazio à divisão dos arquivos. Como compartilhar uma sessão de código com IA ao vivo (sem compartilhar tela) O passo a passo para que um colega ou um cliente acompanhe uma sessão de agentes ao vivo, com um simples link. Antes dos guias Se o vocabulário ainda não estiver claro, o que significa IA na nuvem e o que faz um agente se leem em dois minutos cada. --- ## Guides : faire travailler des agents IA Source: https://murmell.com/fr/comment Comment utiliser Claude Code sans rien installer La marche à suivre pour ouvrir un vrai terminal Claude Code depuis un navigateur, sans installation locale. Comment lancer plusieurs agents IA sur un projet La marche à suivre pour faire tourner plusieurs agents de code sur un même dossier, du projet vide à la répartition des fichiers. Comment montrer une session de code en direct La marche à suivre pour qu'un collègue ou un client regarde une session d'agents en direct, avec un simple lien. Avant les guides Si le vocabulaire n'est pas encore posé, ce que veut dire IA cloud et ce que fait un agent se lisent en deux minutes chacun. --- ## Guide: far lavorare gli agenti IA Source: https://murmell.com/it/how Come usare Claude Code nel browser senza installare nulla sul tuo computer La procedura per aprire un vero terminale Claude Code da un browser, senza installazione locale. Come eseguire più agenti IA sullo stesso repository (senza conflitti Git) La procedura per far girare più agenti di coding sulla stessa cartella, dal progetto vuoto alla suddivisione dei file. Come condividere una sessione di codice con IA dal vivo (senza condividere lo schermo) La procedura perché un collega o un cliente guardi una sessione di agenti dal vivo, con un semplice link. Prima delle guide Se il vocabolario non è ancora chiaro, cosa vuol dire IA cloud e cosa fa un agente si leggono in due minuti ciascuna. --- ## Руководства: как поставить ИИ-агентов на работу Source: https://murmell.com/ru/how Как запускать Claude Code в браузере без установки на свой компьютер Порядок действий, чтобы открыть настоящий терминал Claude Code из браузера без локальной установки. Как запускать несколько ИИ-агентов в одном репозитории (без конфликтов Git) Порядок действий, чтобы запустить несколько агентов для кода в одном каталоге, от пустого проекта до распределения файлов. Как делиться сессией написания кода с ИИ в реальном времени (без демонстрации экрана) Порядок действий, чтобы коллега или клиент смотрели сессию агентов в реальном времени по одной простой ссылке. Прежде чем читать руководства Если термины ещё не знакомы, что означает облачный ИИ и что делает агент читаются за две минуты каждая. --- ## गाइड: AI एजेंट से काम कैसे लें Source: https://murmell.com/hi/how बिना लोकल इंस्टॉलेशन के ब्राउज़र में Claude Code CLI कैसे चलाएं बिना लोकल इंस्टॉल के, ब्राउज़र से असली Claude Code टर्मिनल खोलने का तरीका। एक ही Git Repo में एक साथ कई AI Agents कैसे चलाएं (बिना Merge Conflicts) एक ही फ़ोल्डर पर कई कोड एजेंट चलाने का तरीका, खाली प्रोजेक्ट से लेकर फ़ाइलों के बंटवारे तक। Live AI Coding Session कैसे शेयर करें (बिना स्क्रीन शेयर, मल्टीप्लेयर व्यू) किसी साथी या क्लाइंट को सिर्फ़ एक लिंक से एजेंट का लाइव सेशन दिखाने का तरीका। गाइड से पहले अगर शब्दावली अभी साफ़ नहीं है, तो क्लाउड AI का मतलब और एजेंट क्या करता है हर एक दो मिनट में पढ़े जा सकते हैं। --- ## 가이드: AI 에이전트에게 작업시키기 Source: https://murmell.com/ko/how 로컬 설치 없이 브라우저에서 Claude Code CLI를 바로 실행하는 방법 브라우저에서 로컬 설치 없이 진짜 Claude Code 터미널을 여는 방법. 동일한 Git 저장소에서 여러 AI 에이전트를 동시 실행하는 방법 (충돌 방지) 같은 디렉터리에서 여러 코딩 에이전트를 실행하는 방법. 빈 프로젝트부터 파일 분배까지. 실시간 AI 코딩 세션 공유 방법 (화면 공유 없는 멀티플레이어 뷰) 동료나 고객이 링크 하나로 에이전트 세션을 실시간으로 지켜보게 하는 방법. 가이드를 읽기 전에 용어가 아직 낯설다면 클라우드 AI가 무엇을 뜻하는지와 에이전트가 무엇을 하는지를 각각 2분 안에 읽을 수 있습니다. --- ## ガイド: AIエージェントに作業させる Source: https://murmell.com/ja/how ローカルインストール不要でブラウザからClaude Code CLIを実行する方法 ブラウザから本物のClaude Codeターミナルを、ローカルインストールなしで開く手順。 同一リポジトリで複数のAIエージェントを同時実行する方法（Gitコンフリクト防止） 同じディレクトリで複数のコーディングエージェントを動かす手順。空のプロジェクトからファイルの割り振りまで。 AIコーディングセッションをリアルタイム共有する方法（画面共有不要） 同僚や顧客にエージェントのセッションをリンク1つでライブで見てもらう手順。 ガイドの前に 用語がまだわからない場合は、クラウドAIの意味と エージェントが何をするかがそれぞれ2分で読めます。 --- ## 指南:让 AI 代理干活 Source: https://murmell.com/zh/how 如何免本地安装直接在浏览器中运行 Claude Code 不在本地安装,直接从浏览器打开一个真正的 Claude Code 终端的具体做法。 如何在同一个项目仓库同时运行多个 AI 代理（避免 Git 冲突） 在同一个目录上运行多个编程代理的具体做法,从空项目到文件分工。 如何实时分享 AI 编程会话（多人免安装在线旁观） 让同事或客户实时旁观一次代理会话的具体做法,只需要一个链接。 在读指南之前 如果术语还没搞清楚,云端 AI 到底是什么 和 一个代理具体做什么 各自两分钟就能读完。 --- ## Claude Code im Browser nutzen ohne lokale Installation Source: https://murmell.com/de/how/use-claude-code-without-installing Warum das funktioniert Ein CLI braucht nur ein Terminal und ein Dateisystem. Beide gibt es auf der Maschine des Projekts, und ein Terminal lässt sich verlustfrei bis in einen Tab transportieren. Was sich zeigt, ist ein echtes Pseudoterminal, keine Nachbildung. Was Sie dabei gewinnen Ihre Festplatte bleibt sauber. Die Umgebung ist für alle identisch. Und Sie können ein zweites Fenster mit einem anderen Agenten im selben Verzeichnis öffnen, was eine lokale Installation mühsam macht. Mehrere Agenten laufen lassen. Die ehrliche Grenze Sie hängen von einer Verbindung ab. Ein entferntes Terminal über ein instabiles Netzwerk bleibt ein entferntes Terminal, und es gibt keinen Offline-Modus. --- ## Comment utiliser Claude Code sans rien installer Source: https://murmell.com/fr/comment/utiliser-claude-code-sans-linstaller Pourquoi ça marche Un CLI n'a besoin que d'un terminal et d'un système de fichiers. Les deux existent sur la machine du projet, et un terminal se transporte jusqu'à un onglet sans rien perdre. Ce qui s'affiche est un pseudo-terminal réel, pas une reconstitution. Ce que vous gagnez au passage Votre disque reste propre. L'environnement est identique pour tout le monde. Et vous pouvez ouvrir une deuxième fenêtre avec un autre agent dans le même dossier, ce qu'une installation locale rend pénible. Faire tourner plusieurs agents. La limite honnête Vous dépendez d'une connexion. Un terminal distant sur un réseau instable reste un terminal distant, et il n'y a pas de mode hors ligne. --- ## Como usar o Claude Code no navegador sem instalar nada no seu computador Source: https://murmell.com/pt/how/use-claude-code-without-installing Por que isso funciona Um CLI só precisa de um terminal e de um sistema de arquivos. Os dois existem na máquina do projeto, e um terminal se transporta até uma aba sem perder nada. O que aparece é um pseudo-terminal de verdade, não uma reconstituição. O que você ganha de quebra Seu disco continua limpo. O ambiente é idêntico para todo mundo. E você pode abrir uma segunda janela com outro agente no mesmo diretório, algo que uma instalação local torna incômodo. Rodar vários agentes. O limite honesto Você depende de uma conexão. Um terminal remoto em uma rede instável continua sendo um terminal remoto, e não existe modo offline. --- ## Come usare Claude Code nel browser senza installare nulla sul tuo computer Source: https://murmell.com/it/how/use-claude-code-without-installing Perché funziona Un CLI ha bisogno solo di un terminale e di un file system. Entrambi esistono sulla macchina del progetto, e un terminale si trasporta fino a una scheda senza perdere nulla. Quello che appare è un vero pseudo-terminale, non una ricostruzione. Cosa guadagni nel frattempo Il tuo disco resta pulito. L'ambiente è identico per tutti. E puoi aprire una seconda finestra con un altro agente nella stessa cartella, cosa che un'installazione locale rende scomoda. Far girare più agenti. Il limite onesto Dipendi da una connessione. Un terminale remoto su una rete instabile resta un terminale remoto, e non esiste una modalità offline. --- ## Cómo usar Claude Code en el navegador sin instalar nada en tu equipo Source: https://murmell.com/es/how/use-claude-code-without-installing Por qué funciona Un CLI solo necesita una terminal y un sistema de archivos. Los dos existen en la máquina del proyecto, y una terminal se transporta hasta una pestaña sin perder nada. Lo que ves es un pseudo terminal real, no una reconstrucción. Lo que ganas de paso Tu disco queda limpio. El entorno es idéntico para todos. Y puedes abrir una segunda ventana con otro agente en el mismo directorio, algo que una instalación local hace incómodo. Correr varios agentes a la vez. El límite honesto Dependes de una conexión. Una terminal remota en una red inestable sigue siendo una terminal remota, y no hay modo sin conexión. --- ## Как запускать Claude Code в браузере без установки на свой компьютер Source: https://murmell.com/ru/how/use-claude-code-without-installing Почему это работает CLI нужен только терминал и файловая система. Оба есть на машине проекта, и терминал переносится во вкладку без потерь. То, что вы видите, это настоящий псевдотерминал, а не имитация. Что вы получаете заодно Ваш диск остаётся чистым. Окружение одинаковое для всех. И вы можете открыть второе окно с другим агентом в том же каталоге, что при локальной установке доставляет неудобства. Запуск нескольких агентов. Честное ограничение Вы зависите от соединения. Удалённый терминал на нестабильной сети остаётся удалённым терминалом, и офлайн-режима не существует. --- ## How to use Claude Code without installing anything Source: https://murmell.com/how/use-claude-code-without-installing Why it works A CLI needs a terminal and a file system. Both exist on the project machine, and a terminal travels to a tab without losing anything. What you see is a real pseudo-terminal, not a reconstruction of one. What you get on the way Your disk stays clean. The environment is identical for everybody. And you can open a second window with another agent in the same directory, which a local install makes painful. Running several agents. The honest limit You depend on a connection. A remote terminal on an unreliable network is still a remote terminal, and there is no offline mode. --- ## Como compartilhar uma sessão de código com IA ao vivo (sem compartilhar tela) Source: https://murmell.com/pt/how/share-a-coding-session Para que serve de verdade Mostrar um método para alguém que está começando com agentes, deixar um cliente ver que o trabalho está avançando, ou fazer um colega acompanhar enquanto uma migração roda. Nos três casos, o valor está em estar presente durante, não em revisar depois. O que quem assiste vê As janelas, o conteúdo dos terminais no momento em que muda, o painel de arquivos reservados, e os cursores nomeados das outras pessoas presentes. É a mesma cena que você vê, não uma captura. E se você quiser que ela toque Um canvas compartilhado com permissão de escrita é outro gesto, e é isso que os planos abrem: cada um pilota seus próprios agentes no mesmo projeto. Veja o que o canvas faz. --- ## Cómo compartir una sesión de código con IA en vivo (sin compartir pantalla) Source: https://murmell.com/es/how/share-a-coding-session Para qué sirve de verdad Enseñar un método a alguien que empieza con agentes, dejar que un cliente vea que el trabajo avanza, o hacer que un compañero mire mientras corre una migración. En los tres casos, el valor está en estar presente durante, no en revisar después. Lo que ve quien mira Las ventanas, el contenido de las terminales en el momento en que cambia, el tablero de archivos reservados, y los cursores con nombre de las demás personas presentes. Es la misma escena que tú, no una captura. Y si quieres que toque Compartir un canvas en modo escritura es otro gesto, y es lo que abren los planes: cada uno maneja sus propios agentes en el mismo proyecto. Ver qué hace el canvas. --- ## Come condividere una sessione di codice con IA dal vivo (senza condividere lo schermo) Source: https://murmell.com/it/how/share-a-coding-session A cosa serve davvero Mostrare un metodo a qualcuno che inizia con gli agenti, lasciare che un cliente veda che il lavoro avanza, o far guardare un collega mentre gira una migrazione. Nei tre casi, il valore è essere presenti durante, non rileggere dopo. Cosa vede chi guarda Le finestre, il contenuto dei terminali nel momento in cui cambia, la bacheca dei file riservati, e i cursori con nome delle altre persone presenti. È la stessa scena che vedi tu, non una cattura. E se vuoi che tocchi Un canvas condiviso in scrittura è un altro gesto, ed è quello che aprono i piani: ognuno pilota i propri agenti nello stesso progetto. Guarda cosa fa il canvas. --- ## How to coordinate Claude Code and Codex on one project Source: https://murmell.com/how/coordinate-claude-code-and-codex Why run two different models together Different AI coding agents possess complementary strengths. Developers frequently prefer Anthropic Claude Code for architectural reasoning, complex refactoring, and multi-file logic, while using OpenAI Codex in the cloud for rapid test suite generation and API endpoint scaffolding. Running them on a single workstation requires juggling separate terminals, local environment variables, and multiple Git checkouts. On the multi-agent canvas, both agents run simultaneously in persistent cloud sandboxes. Practical task allocation The most effective workflow assigns distinct subdirectories to each agent. For example: Claude Code operates on src/core/ and database schema migrations. Codex implements unit tests under test/ and documentation in docs/. Because both agents share the same project directory, Codex reads newly created interfaces immediately without waiting for branch merges or remote pushes. Real-time coordination via The Board File collisions are resolved before writes reach the filesystem. When Claude Code opens a source file, it acquires a live reservation. Codex sees the lock status on the canvas and queues its modification. Read our deep dive into multiple AI agents on one repo to explore the reservation ledger. Collaborative visibility You and your team can monitor both agent terminals simultaneously from any browser. Follow our guide on how to share a coding session to invite collaborators to the canvas. --- ## Comment coordonner Claude Code et Codex sur un même projet Source: https://murmell.com/fr/comment/coordonner-claude-code-et-codex Pourquoi combiner deux modèles différents Les agents IA possèdent des points forts complémentaires. De nombreux développeurs choisissent Anthropic Claude Code pour le raisonnement d'architecture et les refactorisations complexes, tout en utilisant OpenAI Codex dans le cloud pour la génération rapide de tests unitaires et de modèles de données. Faire tourner les deux sur une machine locale oblige à jongler avec plusieurs terminaux et plusieurs copies Git. Sur le canvas multi-agents, les deux s'exécutent en parallèle dans le cloud. Répartition efficace des tâches La méthode la plus fluide consiste à découper par sous-dossiers : Claude Code travaille sur src/core/ et les schémas de base de données. Codex implémente les tests sous test/ et la documentation dans docs/. Puisque les deux partagent le même dossier, Codex lit immédiatement les nouvelles fonctions créées sans attendre de pull request. Arbitrage en direct par Le Tableau Les conflits sont évités avant même d'atteindre le disque. Dès que Claude Code ouvre un fichier, il en prend la réservation. Codex voit le statut verrouillé sur le canvas et patiente. Consultez notre explication sur plusieurs agents IA sur un même dépôt. Visibilité partagée pour l'équipe Vous et votre équipe pouvez observer les deux terminaux en direct. Lisez notre guide pour savoir comment partager une session de code en temps réel. --- ## Live-Coding-Session mit KI teilen (ohne Screen-Sharing) Source: https://murmell.com/de/how/share-a-coding-session Wofür es wirklich gut ist Jemandem, der neu mit Agenten anfängt, eine Methode zeigen, einen Kunden sehen lassen, dass die Arbeit vorankommt, oder einen Kollegen zusehen lassen, während eine Migration läuft. In allen drei Fällen liegt der Wert darin, während der Arbeit dabei zu sein, nicht danach nachzulesen. Was die zuschauende Person sieht Die Fenster, den Inhalt der Terminals in dem Moment, in dem er sich ändert, das Board der reservierten Dateien und die benannten Cursor der anderen anwesenden Personen. Es ist dieselbe Szene wie bei Ihnen, kein Screenshot. Und wenn sie mitmachen soll Eine schreibend geteilte Canvas ist ein anderer Schritt, und das öffnen die Pläne: Jeder steuert seine eigenen Agenten im selben Projekt. Sehen, was die Canvas macht. --- ## Comment lancer plusieurs agents IA sur un projet Source: https://murmell.com/fr/comment/lancer-plusieurs-agents-ia Ce qu'il faut avoir sous la main Un dépôt, même vide, et un compte chez un fournisseur de modèle. Le reste est fourni par le projet : la machine, le dossier et le tableau qui distribue les fichiers. Un fichier d'instructions à la racine du dépôt change le résultat plus que n'importe quel réglage. Les agents le lisent au démarrage, et il évite les cinq premières erreurs de chacun. Le découpage qui marche La bonne unité n'est pas la fonctionnalité, c'est le fichier. Un agent sur l'API, un sur l'interface, un sur les tests : ils se croisent peu et n'attendent presque jamais. Trois agents sur « la page de paiement » se disputeront les mêmes trois fichiers toute l'heure. Ce que vous regardez pendant Les terminaux défilent dans leurs fenêtres, et le tableau montre qui détient quel chemin. Un agent bloqué est visible avant de faire des dégâts, ce qui est la vraie différence avec une file d'attente invisible. Le mécanisme en détail. --- ## Come eseguire più agenti IA sullo stesso repository (senza conflitti Git) Source: https://murmell.com/it/how/run-several-ai-agents Cosa avere a portata di mano Un repository, anche vuoto, e un account presso un fornitore di modelli. Il resto lo fornisce il progetto: la macchina, la cartella e la bacheca che distribuisce i file. Un file di istruzioni nella radice del repository cambia il risultato più di qualsiasi impostazione. Gli agenti lo leggono all'avvio, e risparmia a ognuno i primi cinque errori. La suddivisione che funziona L'unità giusta non è la funzionalità, è il file. Un agente sull'API, uno sull'interfaccia, uno sui test: si incrociano poco e quasi non si aspettano mai. Tre agenti sulla "pagina di pagamento" si contenderanno gli stessi tre file per un'ora intera. Cosa guardi nel frattempo I terminali scorrono nelle loro finestre, e la bacheca mostra chi tiene quale percorso. Un agente bloccato è visibile prima che faccia danni, il che è la vera differenza rispetto a una coda invisibile. Il meccanismo nel dettaglio. --- ## Cómo ejecutar varios agentes de IA en un mismo repositorio (sin conflictos de Git) Source: https://murmell.com/es/how/run-several-ai-agents Lo que hay que tener a mano Un repositorio, aunque esté vacío, y una cuenta en un proveedor de modelos. El resto lo pone el proyecto: la máquina, el directorio y el tablero que reparte los archivos. Un archivo de instrucciones en la raíz del repositorio cambia el resultado más que cualquier ajuste. Los agentes lo leen al arrancar, y evita los primeros cinco errores de cada uno. El reparto que funciona La unidad correcta no es la función, es el archivo. Un agente en la API, uno en la interfaz, uno en las pruebas: se cruzan poco y casi nunca esperan. Tres agentes en "la página de pago" se pelearán por los mismos tres archivos toda la hora. Lo que miras mientras tanto Las terminales corren en sus ventanas, y el tablero muestra quién tiene cada ruta. Un agente atascado se ve antes de causar daño, y esa es la diferencia real con una cola invisible. El mecanismo en detalle. --- ## Mehrere KI-Agenten in einem Repository gleichzeitig ausführen (ohne Git-Konflikte) Source: https://murmell.com/de/how/run-several-ai-agents Was Sie zur Hand haben sollten Ein Repository, auch ein leeres, und ein Konto bei einem Modellanbieter. Der Rest kommt vom Projekt: die Maschine, das Verzeichnis und das Board, das die Dateien verteilt. Eine Anweisungsdatei im Wurzelverzeichnis des Repositorys ändert das Ergebnis mehr als jede Einstellung. Die Agenten lesen sie beim Start, und sie erspart jedem die ersten fünf Fehler. Die Aufteilung, die funktioniert Die richtige Einheit ist nicht das Feature, es ist die Datei. Ein Agent an der API, einer an der Oberfläche, einer an den Tests: Sie kreuzen sich selten und warten fast nie aufeinander. Drei Agenten auf „die Bezahlseite" streiten sich die ganze Stunde um dieselben drei Dateien. Was Sie währenddessen sehen Die Terminals laufen in ihren Fenstern durch, und das Board zeigt, wer welchen Pfad hält. Ein blockierter Agent ist sichtbar, bevor er Schaden anrichtet, was den echten Unterschied zu einer unsichtbaren Warteschlange ausmacht. Der Mechanismus im Detail. --- ## Comment montrer une session de code en direct Source: https://murmell.com/fr/comment/partager-une-session-de-code À quoi ça sert vraiment Montrer une méthode à quelqu'un qui débute avec les agents, laisser un client voir que le travail avance, ou faire regarder un collègue pendant qu'une migration tourne. Dans les trois cas, la valeur est d'être là pendant, pas de relire après. Ce que le spectateur voit Les fenêtres, le contenu des terminaux au moment où il change, le tableau des fichiers réservés, et les curseurs nommés des autres personnes présentes. C'est la même scène que vous, pas une capture. Et si vous voulez qu’il touche Un canvas partagé en écriture est un autre geste, et c'est ce que les formules ouvrent : chacun pilote ses propres agents dans le même projet. Voir ce que fait le canvas. --- ## Como rodar vários agentes de IA no mesmo repositório (sem conflitos de Git) Source: https://murmell.com/pt/how/run-several-ai-agents O que é preciso ter em mãos Um repositório, mesmo vazio, e uma conta em um provedor de modelo. O resto é fornecido pelo projeto: a máquina, o diretório e o painel que distribui os arquivos. Um arquivo de instruções na raiz do repositório muda o resultado mais do que qualquer configuração. Os agentes o leem ao iniciar, e ele evita os cinco primeiros erros de cada um. A divisão que funciona A unidade certa não é a funcionalidade, é o arquivo. Um agente na API, um na interface, um nos testes: eles se cruzam pouco e quase nunca esperam. Três agentes na "página de pagamento" vão disputar os mesmos três arquivos a hora toda. O que você observa enquanto isso Os terminais rolam em suas janelas, e o painel mostra quem detém qual caminho. Um agente bloqueado fica visível antes de causar estrago, que é a real diferença em relação a uma fila de espera invisível. O mecanismo em detalhe. --- ## How to run several AI agents on one project Source: https://murmell.com/how/run-several-ai-agents What you need first A repository, even an empty one, and an account at a model provider. The rest comes with the project: the machine, the directory, and the board that hands out files. An instructions file at the root of the repository changes the result more than any setting. Agents read it on startup, and it saves each of them the same first five mistakes. The split that works The useful unit is the file, not the feature. One agent on the API, one on the interface, one on the tests: they rarely cross and almost never wait. Three agents on "the checkout page" will fight over the same three files for an hour. What you watch while it runs Terminals scroll in their windows, and the board shows who holds which path. A blocked agent is visible before it does damage, which is the real difference from an invisible queue. The mechanism in full. --- ## How to show a coding session live Source: https://murmell.com/how/share-a-coding-session What it is actually for Showing somebody new to agents how you work, letting a client see that the work is moving, or having a colleague watch while a migration runs. In all three the value is being there during, not reading it after. What the viewer sees The windows, the terminal contents at the moment they change, the board of claimed files, and the named cursors of everybody else in the room. The same scene you have, not a capture of it. If you want them to touch it A canvas shared for writing is a different move, and it is what the plans open: everybody drives their own agents in the same project. See how multiplayer coding with AI agents works. --- ## Как запускать несколько ИИ-агентов в одном репозитории (без конфликтов Git) Source: https://murmell.com/ru/how/run-several-ai-agents Что нужно иметь под рукой Репозиторий, пусть даже пустой, и аккаунт у поставщика модели. Остальное даёт проект: машину, каталог и доску, которая распределяет файлы. Файл с инструкциями в корне репозитория меняет результат сильнее любой настройки. Агенты читают его при запуске, и он избавляет каждого от первых пяти ошибок. Разбиение, которое работает Правильная единица не функция, а файл. Один агент на API, один на интерфейс, один на тесты: они почти не пересекаются и почти никогда не ждут. Три агента на «странице оплаты» будут весь час спорить за одни и те же три файла. Что вы видите во время работы Терминалы идут в своих окнах, а доска показывает, кто держит какой путь. Застрявший агент виден до того, как он успевает навредить, и это настоящая разница с невидимой очередью. Механизм подробно. --- ## Как делиться сессией написания кода с ИИ в реальном времени (без демонстрации экрана) Source: https://murmell.com/ru/how/share-a-coding-session Для чего это действительно нужно Показать метод человеку, который только начинает работать с агентами, дать клиенту увидеть, что работа продвигается, или дать коллеге посмотреть, пока идёт миграция. Во всех трёх случаях ценность в том, чтобы быть рядом во время процесса, а не читать отчёт потом. Что видит зритель Окна, содержимое терминалов в момент изменения, доску занятых файлов и именованные курсоры других присутствующих. Это та же сцена, что и у вас, а не снимок экрана. А если вы хотите дать ему управлять Канвас, открытый на запись, это другое действие, и именно его открывают тарифы: каждый управляет своими агентами в одном проекте. Посмотреть, что делает канвас. --- ## एक ही Git Repo में एक साथ कई AI Agents कैसे चलाएं (बिना Merge Conflicts) Source: https://murmell.com/hi/how/run-several-ai-agents हाथ में क्या होना चाहिए एक रिपॉज़िटरी, भले ही खाली हो, और किसी मॉडल प्रोवाइडर का अकाउंट। बाकी सब प्रोजेक्ट देता है: मशीन, फ़ोल्डर और फ़ाइलें बांटने वाला बोर्ड। रिपॉज़िटरी की जड़ में एक इंस्ट्रक्शन फ़ाइल किसी भी सेटिंग से ज़्यादा नतीजा बदल देती है। एजेंट इसे शुरू में पढ़ते हैं, और यह हर एक की पहली पांच गलतियों से बचा लेती है। बंटवारा जो काम करता है सही इकाई फ़ीचर नहीं, फ़ाइल है। API पर एक एजेंट, इंटरफ़ेस पर एक, टेस्ट पर एक: ये एक-दूसरे से कम टकराते हैं और लगभग कभी इंतज़ार नहीं करते। "पेमेंट पेज" पर तीन एजेंट पूरे घंटे उन्हीं तीन फ़ाइलों के लिए लड़ते रहेंगे। इस दौरान आप क्या देखते हैं टर्मिनल अपनी विंडो में चलते रहते हैं, और बोर्ड दिखाता है कि किसके पास कौन सा रास्ता है। अटका हुआ एजेंट नुकसान करने से पहले दिख जाता है, और अदृश्य कतार से यही असली फ़र्क़ है। यह तरीका विस्तार से। --- ## बिना लोकल इंस्टॉलेशन के ब्राउज़र में Claude Code CLI कैसे चलाएं Source: https://murmell.com/hi/how/use-claude-code-without-installing यह क्यों काम करता है किसी CLI को सिर्फ़ एक टर्मिनल और एक फ़ाइल सिस्टम चाहिए। दोनों प्रोजेक्ट की मशीन पर मौजूद हैं, और टर्मिनल बिना कुछ खोए टैब तक पहुंच जाता है। जो दिखता है वह एक असली pseudo-terminal है, कोई नकल नहीं। साथ में आपको क्या मिलता है आपकी डिस्क साफ़ रहती है। सबके लिए वातावरण एक जैसा है। और आप उसी फ़ोल्डर में किसी दूसरे एजेंट के साथ दूसरी विंडो खोल सकते हैं, जो लोकल इंस्टॉल में मुश्किल होता है। कई एजेंट चलाना। ईमानदार सीमा आप एक कनेक्शन पर निर्भर हैं। किसी अस्थिर नेटवर्क पर दूरस्थ टर्मिनल फिर भी दूरस्थ टर्मिनल ही रहता है, और कोई ऑफ़लाइन मोड नहीं है। --- ## Live AI Coding Session कैसे शेयर करें (बिना स्क्रीन शेयर, मल्टीप्लेयर व्यू) Source: https://murmell.com/hi/how/share-a-coding-session यह असल में किस काम आता है एजेंट के साथ नए किसी को तरीका दिखाना, किसी क्लाइंट को दिखाना कि काम आगे बढ़ रहा है, या किसी साथी को migration चलते समय देखने देना। तीनों मामलों में फ़ायदा उस दौरान वहां होने का है, बाद में पढ़ने का नहीं। देखने वाला क्या देखता है विंडो, बदलते ही टर्मिनल की सामग्री, आरक्षित फ़ाइलों का बोर्ड, और मौजूद बाकी लोगों के नाम वाले कर्सर। यह आपके जैसा ही दृश्य है, कोई स्क्रीनशॉट नहीं। अगर आप चाहें कि वह भी छुए लिखने के अधिकार के साथ साझा किया गया कैनवस अलग बात है, और यही योजनाएं खोलती हैं: हर कोई एक ही प्रोजेक्ट में अपने एजेंट चलाता है। देखें कैनवस क्या करता है। --- ## 로컬 설치 없이 브라우저에서 Claude Code CLI를 바로 실행하는 방법 Source: https://murmell.com/ko/how/use-claude-code-without-installing 이것이 작동하는 이유 CLI에 필요한 것은 터미널과 파일시스템뿐입니다. 둘 다 프로젝트의 머신에 있고, 터미널은 아무것도 잃지 않고 탭까지 옮겨질 수 있습니다. 화면에 보이는 것은 흉내 낸 것이 아니라 진짜 의사 터미널입니다. 덤으로 얻는 것 여러분의 디스크는 깨끗하게 유지됩니다. 환경은 모두에게 동일합니다. 그리고 같은 디렉터리에서 다른 에이전트를 담은 두 번째 창을 열 수 있는데, 이는 로컬 설치에서는 번거로운 일입니다. 여러 에이전트 실행하기. 솔직한 한계 연결에 의존한다는 점입니다. 불안정한 네트워크 위의 원격 터미널은 여전히 원격 터미널이며, 오프라인 모드는 없습니다. --- ## 실시간 AI 코딩 세션 공유 방법 (화면 공유 없는 멀티플레이어 뷰) Source: https://murmell.com/ko/how/share-a-coding-session 실제로 쓰이는 상황 에이전트를 처음 접하는 사람에게 방법을 보여주거나, 고객에게 작업이 진행되고 있다는 것을 보여주거나, 마이그레이션이 돌아가는 동안 동료가 지켜보게 하는 경우입니다. 세 경우 모두 가치는 나중에 다시 읽는 것이 아니라 그 자리에 함께 있는 데 있습니다. 보는 사람이 보게 되는 것 창들, 바뀌는 순간의 터미널 내용, 점유된 파일 보드, 그리고 함께 있는 다른 사람들의 이름이 붙은 커서입니다. 여러분과 같은 장면이지, 캡처 화면이 아닙니다. 상대방이 조작하길 원한다면 쓰기 권한으로 공유된 캔버스는 별개의 일이며, 그것이 요금제가 여는 부분입니다. 같은 프로젝트 안에서 각자 자신의 에이전트를 조작하게 됩니다. 캔버스가 무엇을 하는지 보기. --- ## 동일한 Git 저장소에서 여러 AI 에이전트를 동시 실행하는 방법 (충돌 방지) Source: https://murmell.com/ko/how/run-several-ai-agents 미리 준비해야 할 것 비어 있어도 상관없는 저장소 하나와 모델 제공자 계정 하나. 나머지는 프로젝트가 마련해 줍니다. 머신, 디렉터리, 파일을 분배하는 보드입니다. 저장소 루트에 있는 지침 파일은 어떤 설정보다도 결과를 크게 바꿉니다. 에이전트는 시작할 때 이를 읽고, 각자의 처음 다섯 가지 실수를 막아줍니다. 효과적인 분할 방식 적절한 단위는 기능이 아니라 파일입니다. API에 하나, 인터페이스에 하나, 테스트에 하나씩 에이전트를 두면 거의 겹치지 않고 거의 기다리지 않습니다. "결제 페이지"에 에이전트 셋을 두면 한 시간 내내 같은 세 파일을 두고 다투게 됩니다. 작업 중에 보게 되는 것 터미널은 각자의 창에서 흘러가고, 보드는 누가 어떤 경로를 쥐고 있는지 보여줍니다. 막힌 에이전트는 피해를 내기 전에 보이며, 이것이 보이지 않는 대기열과의 진짜 차이입니다. 메커니즘 자세히 보기. --- ## ローカルインストール不要でブラウザからClaude Code CLIを実行する方法 Source: https://murmell.com/ja/how/use-claude-code-without-installing なぜこれで動くのか CLIに必要なのはターミナルとファイルシステムだけです。両方ともプロジェクトのマシン上に存在し、 ターミナルは何も失わずにタブまで運べます。表示されるのは本物の擬似端末であり、再現ではありません。 その過程で得られるもの ディスクはきれいなまま保たれます。環境は全員にとって同一です。そして同じディレクトリで別のエージェント の2つ目のウィンドウを開けます。ローカルインストールではこれは面倒な作業です。 複数のエージェントを動かす。 正直な限界 接続に依存します。不安定なネットワーク上のリモートターミナルは、やはりリモートターミナルであり、 オフラインモードはありません。 --- ## AIコーディングセッションをリアルタイム共有する方法（画面共有不要） Source: https://murmell.com/ja/how/share-a-coding-session 実際に役立つ場面 エージェントを使い始めた人にやり方を見せる、顧客に作業が進んでいることを見せる、マイグレーションが 動いている間に同僚に見てもらう。3つのケースすべてで、価値は後で読み返すことではなく、その場に 居合わせることにあります。 見る人が見るもの ウィンドウ、変化する瞬間のターミナルの内容、確保済みファイルのボード、そして居合わせる他の人の 名前付きカーソルです。あなたと同じ場面であり、キャプチャではありません。 相手に操作してほしい場合 書き込み権限付きで共有されたキャンバスは別の話で、それこそが各プランが開くものです。各自が同じ プロジェクトで自分のエージェントを操作します。キャンバスの機能を見る。 --- ## 如何免本地安装直接在浏览器中运行 Claude Code Source: https://murmell.com/zh/how/use-claude-code-without-installing 为什么这样能行 一个 CLI 只需要一个终端和一套文件系统。这两样在项目的机器上都有,而终端可以原样搬到一个浏览器标签页里,不丢失任何东西。你看到的是真正的伪终端,不是重新拼出来的画面。 顺带得到的好处 你的硬盘保持干净。每个人的环境都完全一样。而且你可以在同一个目录里再开一个窗口,换一个代理,这在本地安装上会很麻烦。同时运行多个代理。 诚实说说局限 你依赖网络连接。不稳定的网络上的远程终端终究是远程终端,没有离线模式。 --- ## 如何实时分享 AI 编程会话（多人免安装在线旁观） Source: https://murmell.com/zh/how/share-a-coding-session 它到底有什么用 向刚接触代理的人演示一种方法,让客户看到工作确实在推进,或者在一次迁移进行时让同事盯着看。这三种情况里,价值都在于"当场在场",而不是事后回看记录。 旁观者能看到什么 所有窗口、终端内容随时变化的过程、被占用文件的看板,以及在场其他人带名字的光标。这就是你看到的那同一幅场景,不是一份录屏。 如果你想让他动手 以可写方式分享画布是另一个动作,也正是付费套餐开放的能力:每个人在同一个项目里操作自己的代理。了解与 AI 代理的多人协作编码原理。。 --- ## 如何在同一个项目仓库同时运行多个 AI 代理（避免 Git 冲突） Source: https://murmell.com/zh/how/run-several-ai-agents 手边要准备什么 一个仓库,哪怕是空的,再加一个模型厂商的账号。其余的都由项目本身提供:机器、目录,以及分发文件的看板。 在仓库根目录放一份指令文件,比任何设置都更能改变结果。代理启动时会读取它,它能帮每个代理避开最初的五个错误。 真正有效的分工方式 合适的单位不是功能,而是文件。一个代理管接口,一个管界面,一个管测试:他们很少交叉,几乎不用互相等待。三个代理一起管"支付页面"这种任务划分,会让他们整整一个小时都在争抢同样那三个文件。 过程中你在看什么 终端在各自的窗口里滚动输出,看板显示谁占着哪个路径。一个卡住的代理在造成损失之前就能被看见,这正是它和一条看不见的等待队列的真正区别。这套机制的详细说明。 --- ## 同一リポジトリで複数のAIエージェントを同時実行する方法（Gitコンフリクト防止） Source: https://murmell.com/ja/how/run-several-ai-agents 手元に用意しておくもの 空でも構わないのでリポジトリと、モデルプロバイダーのアカウント。残りはプロジェクトが用意します。 マシン、ディレクトリ、ファイルを配分するボードです。 リポジトリのルートにある指示ファイルは、どんな設定よりも結果を変えます。エージェントは起動時に それを読み、それぞれの最初の5つのミスを防ぎます。 うまくいく分割の仕方 適切な単位は機能ではなくファイルです。APIに1つ、インターフェースに1つ、テストに1つのエージェント を置けば、ほとんど交差せず、ほぼ待つことがありません。「決済ページ」に3つのエージェントを置くと、 1時間ずっと同じ3つのファイルを取り合うことになります。 作業中に見るもの ターミナルはそれぞれのウィンドウで流れ、ボードはどのパスを誰が保持しているかを示します。行き詰まった エージェントは被害が出る前に見えるので、見えないキューとの本当の違いはここにあります。 仕組みの詳細。 --- ## Murmell compared, tool by tool Source: https://murmell.com/vs Where a second agent works ToolWhere its second agent works CursorAn isolated VM, on a branch cloned from your repository DevinA full Devin in its own virtual machine, with its own terminal and browser JulesA clone of your repository on a cloud VM Copilot and Agent HQOne branch at a time, in an ephemeral environment powered by GitHub Actions Codex cloudA dedicated cloud environment per task Replit AgentA Replit project it builds and hosts WindsurfIts own git worktree under ~/.windsurf/worktrees, up to twenty per workspace ConductorIts own workspace on your Mac, with its own branch, files and terminal OpenHands Agent CanvasIts own git worktree, a second copy of your files on a branch of its own Vibe KanbanA workspace per task, on your own machine CodegOn your own machine, in the sessions you already run there Gemini Code AssistYour editor, in an agent mode session, on a plan you approve first MurmellOne shared directory, after it claims the paths it is about to touch A cloud machine of its own, per task The agent gets a clone of your repository, works on a branch and hands back a pull request. Nothing is shared until review. Murmell vs Cursor. One editor per person and one VM per agent, against one canvas and one directory for everybody. Murmell vs Devin. Parallel by separation against parallel by sharing, and when each shape is the right one. Murmell vs Google Jules. A plan you approve and a pull request you review, against terminals you watch in one shared tree. Murmell vs GitHub Copilot and Agent HQ. Where agent work converges: at the pull request, or in the working tree. Murmell vs Codex cloud. Why running the Codex CLI on a shared canvas is a different thing from delegating a task to it. Murmell vs Replit Agent. Building an app from nothing against running several agents on a codebase that already exists. Your own machine, one workspace per task The code never leaves your disk. Parallel agents are kept apart by a worktree or a workspace each, and you merge them yourself. Murmell vs Windsurf. A worktree per conversation on your own machine, against one shared directory in the cloud. Murmell vs Conductor. A Mac app with a workspace per task, against a cloud canvas with one directory for all of them. Murmell vs OpenHands Agent Canvas. The closest comparison on the list: a worktree per agent against one tree with file reservations. Murmell vs Vibe Kanban. A kanban board over local agent runs, against a shared canvas over one cloud directory. Murmell vs Codeg. Aggregating local agent sessions against running the agents on one shared cloud directory. One agent at a time, in your editor No documented parallelism: one supervised agent, in the tool where you already write. Murmell vs Gemini Code Assist. One supervised agent in your editor, against several unsupervised ones in a directory you watch. What the comparison is not None of these pages says the other tool is worse. A worktree per agent is the right answer when the work is a queue of separate tasks and the code has to stay on hardware you control, and two of the pages say so in as many words. Murmell is the answer when several agents should be in the same directory at the same time and other people need to watch it happen. What Murmell is covers that side. --- ## Murmell im Vergleich, Werkzeug für Werkzeug Source: https://murmell.com/de/vs Eine Cloud-Maschine pro Aufgabe Der Agent erhält einen Klon Ihres Repositorys, arbeitet auf einem Branch und liefert eine Pull-Request. Nichts wird vor der Durchsicht geteilt. Murmell gegenüber Cursor. Ein Editor pro Person und eine Maschine pro Agent, gegen eine Canvas und ein Verzeichnis für alle. Murmell gegenüber Devin. Parallelität durch Trennung gegen Parallelität durch Teilen, und wann welche Form die richtige ist. Murmell gegenüber Google Jules. Ein Plan, den Sie freigeben, und eine Pull-Request, die Sie durchsehen, gegen Terminals, die Sie in einem einzigen Baum ansehen. Murmell gegenüber GitHub Copilot und Agent HQ. Wo die Arbeit der Agenten zusammenläuft: bei der Pull-Request, oder in der Arbeitskopie. Murmell gegenüber Codex Cloud. Warum das Codex-CLI auf einer geteilten Canvas zu starten nicht dasselbe ist wie ihm eine Aufgabe zu delegieren. Murmell gegenüber Replit Agent. Eine Anwendung aus dem Nichts bauen, gegen mehrere Agenten an bestehendem Code arbeiten lassen. Ein Bereich pro Aufgabe, auf Ihrer Maschine Dieselbe Wahl, bei Ihnen: ein Worktree oder ein Arbeitsverzeichnis pro Agent, und eine Zusammenführung am Ende. Der Code verlässt das Haus nicht, und niemand sonst sieht die Sitzung. Murmell gegenüber Windsurf. Ein Worktree pro Konversation auf Ihrer Maschine, gegen ein geteiltes Verzeichnis in der Cloud. Murmell gegenüber Conductor. Eine Mac-App mit einem Bereich pro Aufgabe, gegen eine Cloud-Canvas mit einem einzigen Verzeichnis für alle. Murmell gegenüber OpenHands Agent Canvas. Der Vergleich, der der Liste am nächsten kommt: ein Worktree pro Agent gegen einen einzigen Baum mit Dateireservierungen. Murmell gegenüber Vibe Kanban. Ein Kanban-Board über lokalen Läufen, gegen eine geteilte Canvas über einem Cloud-Verzeichnis. Murmell gegenüber Codeg. Lokale Sitzungen sammeln, gegen Agenten auf einem geteilten Cloud-Verzeichnis laufen lassen. Ein Agent nach dem anderen, in Ihrem Editor Keine dokumentierte Parallelität: ein Agent, überwacht, in dem Werkzeug, in dem Sie bereits schreiben. Murmell gegenüber Gemini Code Assist. Ein überwachter Agent in Ihrem Editor, gegen mehrere unüberwachte Agenten in einem Verzeichnis, das Sie ansehen. Derselbe Agent, anderswo Das CLI ist auf beiden Seiten identisch. Was sich ändert, ist die Maschine, auf der es läuft, und die Anzahl der Personen, die zusehen können. Murmell gegenüber Claude Code im Web. Dasselbe CLI an zwei Orten: eine isolierte Maschine pro Sitzung, gegen mehrere Agenten auf einer Canvas und eine einzige Arbeitskopie. Die Frage, die man sich stellen sollte Berühren sich Ihre Aufgaben? Sind sie wirklich unabhängig, kostet die Isolierung per Maschine nichts, und jedes Werkzeug der ersten Liste reicht. Sobald sie sich Dateien teilen, muss jemand wieder zusammennähen, und genau dort ändert das geteilte Verzeichnis den Tag. Wie die Regel funktioniert. --- ## Murmell comparado, ferramenta por ferramenta Source: https://murmell.com/pt/vs Uma máquina na nuvem por tarefa O agente recebe um clone do seu repositório, trabalha em uma branch e entrega uma pull request. Nada é compartilhado antes da revisão. Murmell frente ao Cursor. Um editor por pessoa e uma máquina por agente, contra um canvas e um diretório para todo mundo. Murmell frente ao Devin. O paralelismo por separação contra o paralelismo por compartilhamento, e quando cada forma é a certa. Murmell frente ao Google Jules. Um plano que você aprova e uma pull request que você revisa, contra terminais que você observa em uma única árvore. Murmell frente ao GitHub Copilot e Agent HQ. Onde o trabalho dos agentes converge: na pull request, ou na cópia de trabalho. Murmell frente ao Codex cloud. Por que executar o CLI Codex em um canvas compartilhado não é a mesma coisa que delegar uma tarefa a ele. Murmell frente ao Replit Agent. Fabricar um aplicativo do zero, contra fazer vários agentes trabalharem em um código que já existe. Um espaço por tarefa, na sua máquina A mesma escolha, na sua casa: um worktree ou um diretório de trabalho por agente, e uma fusão no final. O código não sai, e mais ninguém vê a sessão. Murmell frente ao Windsurf. Um worktree por conversa na sua máquina, contra um diretório compartilhado na nuvem. Murmell frente ao Conductor. Um aplicativo para Mac com um espaço por tarefa, contra um canvas na nuvem com um único diretório para todos. Murmell frente ao OpenHands Agent Canvas. A comparação mais próxima da lista: um worktree por agente contra uma única árvore com reservas de arquivos. Murmell frente ao Vibe Kanban. Um quadro kanban sobre execuções locais, contra um canvas compartilhado sobre um diretório na nuvem. Murmell frente ao Codeg. Reunir sessões locais, contra rodar os agentes em um diretório na nuvem compartilhado. Um agente por vez, no seu editor Sem paralelismo documentado: um agente, supervisionado, na ferramenta onde você já escreve. Murmell frente ao Gemini Code Assist. Um agente supervisionado no seu editor, contra vários agentes não supervisionados em um diretório que você observa. O mesmo agente, em outro lugar O CLI é idêntico dos dois lados. O que muda é a máquina onde ele roda e o número de pessoas que podem observá-lo. Murmell frente ao Claude Code na web. O mesmo CLI em dois lugares: uma máquina isolada por tarefa, contra vários agentes em um canvas e uma única cópia de trabalho. A pergunta a se fazer Suas tarefas se tocam? Se forem realmente independentes, o isolamento por máquina não custa nada e qualquer ferramenta da primeira lista serve. Assim que compartilham arquivos, alguém vai precisar costurar tudo de novo, e é aí que o diretório compartilhado muda o dia. Como a regra funciona. --- ## Murmell comparado, herramienta por herramienta Source: https://murmell.com/es/vs Una máquina en la nube por tarea El agente recibe un clon de tu repositorio, trabaja en una rama y entrega una pull request. Nada se comparte antes de la revisión. Murmell frente a Cursor. Un editor por persona y una máquina por agente, contra un canvas y un directorio para todos. Murmell frente a Devin. El paralelismo por separación contra el paralelismo por reparto, y cuándo cada forma es la correcta. Murmell frente a Google Jules. Un plan que apruebas y una pull request que revisas, contra terminales que miras en un único árbol. Murmell frente a GitHub Copilot y Agent HQ. Dónde converge el trabajo de los agentes: en la pull request, o en la copia de trabajo. Murmell frente a Codex cloud. Por qué lanzar el CLI de Codex en un canvas compartido no es lo mismo que delegarle una tarea. Murmell frente a Replit Agent. Fabricar una aplicación desde cero, contra hacer trabajar varios agentes sobre un código que ya existe. Un espacio por tarea, en tu propia máquina La misma elección, en tu casa: un worktree o un directorio de trabajo por agente, y una fusión al final. El código no sale, y nadie más ve la sesión. Murmell frente a Windsurf. Un worktree por conversación en tu máquina, contra un directorio compartido en la nube. Murmell frente a Conductor. Una aplicación de Mac con un espacio por tarea, contra un canvas en la nube con un solo directorio para todos. Murmell frente a OpenHands Agent Canvas. La comparación más cercana de la lista: un worktree por agente contra un único árbol con reservas de archivos. Murmell frente a Vibe Kanban. Un tablero kanban sobre ejecuciones locales, contra un canvas compartido sobre un directorio en la nube. Murmell frente a Codeg. Reunir sesiones locales, contra hacer correr los agentes en un directorio compartido en la nube. Un agente a la vez, en tu editor Sin paralelismo documentado: un agente, supervisado, en la herramienta donde ya escribes. Murmell frente a Gemini Code Assist. Un agente supervisado en tu editor, contra varios agentes sin supervisión en un directorio que miras. El mismo agente, en otro sitio El CLI es idéntico en los dos lados. Lo que cambia es la máquina donde corre y cuánta gente puede mirarla. Murmell frente a Claude Code en la web. El mismo CLI en dos sitios: una máquina aislada por tarea, contra varios agentes en un canvas y una sola copia de trabajo. La pregunta que hay que hacerse ¿Tus tareas se tocan? Si son de verdad independientes, el aislamiento por máquina no cuesta nada y cualquier herramienta de la primera lista sirve. En cuanto comparten archivos, alguien tendrá que coser, y ahí es donde el directorio compartido cambia el día. Cómo funciona la regla. --- ## Murmell comparé, outil par outil Source: https://murmell.com/fr/vs Une machine cloud par tâche L'agent reçoit un clone de votre dépôt, travaille sur une branche et rend une pull request. Rien n'est partagé avant la relecture. Murmell face à Cursor. Un éditeur par personne et une machine par agent, contre un canvas et un dossier pour tout le monde. Murmell face à Devin. Le parallélisme par séparation contre le parallélisme par partage, et quand chaque forme est la bonne. Murmell face à Google Jules. Un plan que vous approuvez et une pull request que vous relisez, contre des terminaux que vous regardez dans un seul arbre. Murmell face à GitHub Copilot et Agent HQ. Où le travail des agents converge : à la pull request, ou dans la copie de travail. Murmell face à Codex cloud. Pourquoi lancer le CLI Codex sur un canvas partagé n'est pas la même chose que lui déléguer une tâche. Murmell face à Replit Agent. Fabriquer une application à partir de rien, contre faire travailler plusieurs agents sur un code qui existe. Un espace par tâche, sur votre machine Même choix, chez vous : un worktree ou un dossier de travail par agent, et une fusion à la fin. Le code ne sort pas, et personne d'autre ne voit la séance. Murmell face à Windsurf. Un worktree par conversation sur votre machine, contre un dossier partagé dans le cloud. Murmell face à Conductor. Une application Mac avec un espace par tâche, contre un canvas cloud avec un seul dossier pour tous. Murmell face à OpenHands Agent Canvas. La comparaison la plus proche de la liste : un worktree par agent contre un seul arbre avec des réservations de fichiers. Murmell face à Vibe Kanban. Un tableau kanban au-dessus d'exécutions locales, contre un canvas partagé au-dessus d'un dossier cloud. Murmell face à Codeg. Rassembler des sessions locales, contre faire tourner les agents sur un dossier cloud partagé. Un agent à la fois, dans votre éditeur Pas de parallélisme documenté : un agent, supervisé, dans l'outil où vous écrivez déjà. Murmell face à Gemini Code Assist. Un agent supervisé dans votre éditeur, contre plusieurs agents non supervisés dans un dossier que vous regardez. Le même agent, ailleurs Le CLI est identique des deux côtés. Ce qui change est la machine où il tourne et le nombre de personnes qui peuvent la regarder. Murmell face à Claude Code sur le web. Le même CLI à deux endroits : une machine isolée par tâche, contre plusieurs agents sur un canvas et une seule copie de travail. La question à se poser Est-ce que vos tâches se touchent ? Si elles sont vraiment indépendantes, l'isolation par machine ne coûte rien et tous les outils de la première liste font l'affaire. Dès qu'elles partagent des fichiers, quelqu'un devra recoudre, et c'est là que le dossier partagé change la journée. Comment la règle fonctionne. --- ## Murmell a confronto, strumento per strumento Source: https://murmell.com/it/vs Una macchina cloud per compito L'agente riceve un clone del tuo repository, lavora su un branch e restituisce una pull request. Niente viene condiviso prima della revisione. Murmell contro Cursor. Un editor a persona e una macchina per agente, contro un canvas e una cartella per tutti. Murmell contro Devin. Il parallelismo per separazione contro il parallelismo per condivisione, e quando ogni forma è quella giusta. Murmell contro Google Jules. Un piano che approvi e una pull request che rileggi, contro terminali che guardi in un solo albero. Murmell contro GitHub Copilot e Agent HQ. Dove converge il lavoro degli agenti: alla pull request, o nella copia di lavoro. Murmell contro Codex Cloud. Perché lanciare il CLI Codex su un canvas condiviso non è la stessa cosa di delegargli un compito. Murmell contro Replit Agent. Costruire un'applicazione dal nulla, contro far lavorare più agenti su codice che esiste già. Uno spazio per compito, sulla tua macchina Stessa scelta, da te: un worktree o una cartella di lavoro per agente, e un'unione alla fine. Il codice non esce, e nessun altro vede la sessione. Murmell contro Windsurf. Un worktree per conversazione sulla tua macchina, contro una cartella condivisa nel cloud. Murmell contro Conductor. Un'app Mac con uno spazio per compito, contro un canvas cloud con un'unica cartella per tutti. Murmell contro OpenHands Agent Canvas. Il confronto più vicino della lista: un worktree per agente contro un solo albero con prenotazioni di file. Murmell contro Vibe Kanban. Una bacheca kanban sopra esecuzioni locali, contro un canvas condiviso sopra una cartella cloud. Murmell contro Codeg. Raccogliere sessioni locali, contro far girare gli agenti su una cartella cloud condivisa. Un agente alla volta, nel tuo editor Nessun parallelismo documentato: un agente, supervisionato, nello strumento dove già scrivi. Murmell contro Gemini Code Assist. Un agente supervisionato nel tuo editor, contro più agenti non supervisionati in una cartella che guardi. Lo stesso agente, altrove Il CLI è identico da entrambe le parti. Quello che cambia è la macchina dove gira e il numero di persone che possono guardarla. Murmell contro Claude Code sul web. Lo stesso CLI in due posti: una macchina isolata per compito, contro più agenti su un canvas e un'unica copia di lavoro. La domanda da porsi I tuoi compiti si toccano? Se sono davvero indipendenti, l'isolamento per macchina non costa nulla e tutti gli strumenti della prima lista vanno bene. Appena condividono file, qualcuno dovrà ricucire, ed è lì che la cartella condivisa cambia la giornata. Come funziona la regola. --- ## Murmell в сравнении с другими инструментами Source: https://murmell.com/ru/vs Одна облачная машина на задачу Агент получает клон вашего репозитория, работает на ветке и возвращает pull request. До ревью ничего не разделяется. Murmell против Cursor. Редактор на человека и машина на агента, против канваса и каталога для всех. Murmell против Devin. Параллелизм через разделение против параллелизма через совместное использование, и когда каждая форма верна. Murmell против Google Jules. План, который вы утверждаете, и pull request, который вы проверяете, против терминалов, за которыми вы наблюдаете в одном дереве. Murmell против GitHub Copilot и Agent HQ. Где сходится работа агентов: в pull request, или в рабочей копии. Murmell против Codex cloud. Почему запуск CLI Codex на общем канвасе — это не то же самое, что делегировать ему задачу. Murmell против Replit Agent. Создание приложения с нуля против работы нескольких агентов над существующим кодом. Одно пространство на задачу, на вашей машине Тот же выбор с вашей стороны: worktree или рабочий каталог на агента, и одно слияние в конце. Код не выходит наружу, и никто другой не видит сессию. Murmell против Windsurf. Worktree на диалог на вашей машине против общего каталога в облаке. Murmell против Conductor. Mac-приложение с пространством на задачу против облачного канваса с одним каталогом для всех. Murmell против OpenHands Agent Canvas. Самое близкое сравнение в списке: worktree на агента против одного дерева с резервированием файлов. Murmell против Vibe Kanban. Канбан-доска над локальными запусками против общего канваса над облачным каталогом. Murmell против Codeg. Собирать уже существующие локальные сессии против запуска агентов в общем облачном каталоге. Один агент за раз, в вашем редакторе Никакого документированного параллелизма: один агент, под наблюдением, в инструменте, которым вы уже пользуетесь. Murmell против Gemini Code Assist. Один агент под наблюдением в вашем редакторе против нескольких агентов без наблюдения в каталоге, за которым вы следите. Тот же агент, в другом месте CLI идентичен с обеих сторон. Меняется машина, на которой он выполняется, и число людей, которые могут за ним наблюдать. Murmell против Claude Code в вебе. Один и тот же CLI в двух местах. Изолированная машина на задачу против нескольких агентов на канвасе и одной рабочей копии. Вопрос, который стоит задать себе Соприкасаются ли ваши задачи? Если они действительно независимы, изоляция по машинам ничего не стоит, и все инструменты из первого списка подойдут. Как только они начинают делить файлы, кому-то придётся сшивать, и именно тогда общий каталог меняет день. Как работает правило. --- ## Murmell की तुलना, टूल दर टूल Source: https://murmell.com/hi/vs हर काम के लिए एक क्लाउड मशीन एजेंट को आपकी रिपॉज़िटरी का क्लोन मिलता है, यह किसी ब्रांच पर काम करता है और pull request लौटाता है। रिव्यू से पहले कुछ भी साझा नहीं होता। Cursor के मुकाबले Murmell. हर व्यक्ति के लिए एक एडिटर और हर एजेंट के लिए एक मशीन, बनाम सबके लिए एक कैनवस और एक फ़ोल्डर। Devin के मुकाबले Murmell. अलगाव से मिलने वाली समांतरता बनाम साझा करने से मिलने वाली समांतरता, और हर एक सही कब है। Google Jules के मुकाबले Murmell. एक प्लान जिसे आप मंज़ूर करते हैं और एक pull request जिसे आप रिव्यू करते हैं, बनाम एक ही पेड़ में टर्मिनल जिन्हें आप देखते हैं। GitHub Copilot और Agent HQ के मुकाबले Murmell. एजेंट का काम कहां मिलता है: pull request पर, या वर्किंग कॉपी में। Codex cloud के मुकाबले Murmell. साझा कैनवस पर Codex CLI चलाना किसी काम को सौंपने जैसा क्यों नहीं है। Replit Agent के मुकाबले Murmell. शून्य से ऐप बनाना, बनाम मौजूद कोड पर कई एजेंट से काम करवाना। हर काम के लिए एक जगह, आपकी मशीन पर वही चुनाव, आपके यहां: हर एजेंट के लिए एक worktree या वर्किंग फ़ोल्डर, और आख़िर में एक मर्ज। कोड बाहर नहीं जाता, और सेशन कोई और नहीं देखता। Windsurf के मुकाबले Murmell. हर बातचीत के लिए आपकी मशीन पर एक worktree, बनाम क्लाउड में एक साझा फ़ोल्डर। Conductor के मुकाबले Murmell. हर काम के लिए एक जगह वाला Mac ऐप, बनाम सबके लिए एक ही फ़ोल्डर वाला क्लाउड कैनवस। OpenHands Agent Canvas के मुकाबले Murmell. इस लिस्ट की सबसे करीबी तुलना: हर एजेंट के लिए एक worktree, बनाम एक ही पेड़ फ़ाइल आरक्षण के साथ। Vibe Kanban के मुकाबले Murmell. लोकल रन के ऊपर एक कानबान बोर्ड, बनाम क्लाउड फ़ोल्डर के ऊपर एक साझा कैनवस। Codeg के मुकाबले Murmell. लोकल सेशन इकट्ठा करना, बनाम एक साझा क्लाउड फ़ोल्डर पर एजेंट चलाना। एक बार में एक एजेंट, आपके एडिटर में कोई दस्तावेज़ीकृत समांतरता नहीं: एक एजेंट, निगरानी में, उसी टूल में जहां आप पहले से लिखते हैं। Gemini Code Assist के मुकाबले Murmell. आपके एडिटर में एक निगरानी वाला एजेंट, बनाम एक फ़ोल्डर में कई बिना-निगरानी वाले एजेंट जिन्हें आप देखते हैं। वही एजेंट, कहीं और CLI दोनों तरफ़ एक जैसा है। जो बदलता है वह है जिस मशीन पर यह चलता है, और कितने लोग इसे देख सकते हैं। वेब पर Claude Code के मुकाबले Murmell. एक ही CLI दो जगह: हर काम के लिए एक अलग मशीन, बनाम कैनवस पर कई एजेंट और एक ही वर्किंग कॉपी। खुद से पूछने लायक सवाल क्या आपके काम एक-दूसरे को छूते हैं? अगर वे सच में स्वतंत्र हैं, तो मशीन के हिसाब से अलगाव की कोई कीमत नहीं, और पहली लिस्ट के सारे टूल काम करेंगे। जैसे ही वे फ़ाइलें साझा करने लगें, किसी को सिलाई करनी पड़ेगी, और तभी साझा फ़ोल्डर दिन बदल देता है। नियम कैसे काम करता है। --- ## 도구별로 Murmell 비교하기 Source: https://murmell.com/ko/vs 작업마다 클라우드 머신 하나 에이전트는 여러분 저장소의 클론을 받아 브랜치에서 작업하고 풀 리퀘스트를 돌려줍니다. 리뷰 전에는 아무것도 공유되지 않습니다. Murmell과 Cursor 비교. 한 사람에 하나의 에디터, 에이전트마다 하나의 머신인 세계와, 모두를 위한 캔버스와 하나의 디렉터리인 세계. Murmell과 Devin 비교. 분리를 통한 병렬 처리 대 공유를 통한 병렬 처리, 그리고 각 형태가 옳은 경우. Murmell과 Google Jules 비교. 여러분이 승인하는 계획과 리뷰하는 풀 리퀘스트 대, 하나의 트리 안에서 지켜보는 터미널들. Murmell과 GitHub Copilot, Agent HQ 비교. 에이전트의 작업이 어디서 모이는가. 풀 리퀘스트에서, 아니면 작업 복사본 안에서. Murmell과 Codex cloud 비교. Codex CLI를 공유 캔버스에서 실행하는 것이 작업을 위임하는 것과 왜 다른지. Murmell과 Replit Agent 비교. 아무것도 없는 상태에서 애플리케이션을 만드는 것 대, 존재하는 코드에서 여러 에이전트를 작업시키는 것. 작업마다 공간 하나, 여러분의 머신 위에서 같은 선택을 여러분 쪽에서 합니다. 에이전트마다 worktree나 작업 디렉터리 하나, 그리고 마지막에 병합 한 번. 코드는 밖으로 나가지 않고, 다른 누구도 그 세션을 보지 못합니다. Murmell과 Windsurf 비교. 여러분 머신 위 대화마다 worktree 하나 대, 클라우드 안의 공유 디렉터리. Murmell과 Conductor 비교. 작업마다 공간 하나를 가진 Mac 애플리케이션 대, 모두를 위한 디렉터리 하나를 가진 클라우드 캔버스. Murmell과 OpenHands Agent Canvas 비교. 목록에서 가장 가까운 비교입니다. 에이전트마다 worktree 하나 대, 파일 점유가 있는 하나의 트리. Murmell과 Vibe Kanban 비교. 로컬 실행 위의 칸반 보드 대, 클라우드 디렉터리 위의 공유 캔버스. Murmell과 Codeg 비교. 이미 있는 로컬 세션을 모으는 것 대, 공유 클라우드 디렉터리에서 에이전트를 실행하는 것. 한 번에 에이전트 하나, 여러분의 에디터 안에서 기록된 병렬 처리는 없습니다. 에이전트 하나가, 여러분이 이미 쓰고 있는 도구 안에서 감독받습니다. Murmell과 Gemini Code Assist 비교. 여러분의 에디터 안에서 감독받는 에이전트 하나 대, 지켜보는 디렉터리 안의 감독받지 않는 여러 에이전트. 같은 에이전트, 다른 장소에서 CLI는 양쪽에서 동일합니다. 달라지는 것은 그것이 실행되는 머신과, 그것을 볼 수 있는 사람의 수입니다. Murmell과 웹의 Claude Code 비교. 같은 CLI가 두 장소에서. 작업마다 격리된 머신 대 캔버스 위 여러 에이전트와 하나의 작업 복사본. 스스로에게 물어야 할 것 여러분의 작업들은 서로 맞닿아 있나요? 정말로 독립적이라면 머신 단위 격리는 아무 비용도 들지 않고, 첫 번째 목록의 도구들이 모두 잘 작동합니다. 파일을 공유하기 시작하는 순간 누군가는 이어 붙여야 합니다. 그것이 공유 디렉터리가 하루를 바꾸는 지점입니다. 규칙이 작동하는 방식. --- ## Murmellをツールごとに比較する Source: https://murmell.com/ja/vs タスクごとに1台のクラウドマシン エージェントはあなたのリポジトリのクローンを受け取り、ブランチ上で作業し、プルリクエストを返します。レビューの前には何も共有されません。 MurmellとCursorの比較. 1人1エディタ、1エージェント1マシンの世界と、全員のためのキャンバスと1つのディレクトリの世界。 MurmellとDevinの比較. 分離による並行性と共有による並行性、そしてそれぞれの形が正しいのはどんなときか。 MurmellとGoogle Julesの比較. 承認する計画とレビューするプルリクエストと、1本の木の中で見るターミナルの違い。 MurmellとGitHub Copilot、Agent HQの比較. エージェントの作業がどこで収束するか。プルリクエストか、作業コピーか。 MurmellとCodex cloudの比較. 共有キャンバスでCodex CLIを起動することは、タスクを委任することと同じではない理由。 MurmellとReplit Agentの比較. 何もない状態からアプリケーションを作ることと、既存のコードで複数のエージェントを働かせることの違い。 タスクごとに1つのスペース、あなたのマシン上 同じ選択を、あなたの側で。エージェントごとにworktreeか作業ディレクトリ、最後に1回のマージです。コードは外に出ず、他の誰もそのセッションを見ません。 MurmellとWindsurfの比較. あなたのマシン上の会話ごとのworktreeと、クラウド上の共有ディレクトリ。 MurmellとConductorの比較. タスクごとにスペースを持つMacアプリと、全員のための1つのディレクトリを持つクラウドキャンバス。 MurmellとOpenHands Agent Canvasの比較. リストの中で最も近い比較。エージェントごとのworktreeと、ファイル確保付きの1本の木。 MurmellとVibe Kanbanの比較. ローカル実行の上に乗るカンバンボードと、クラウドディレクトリの上に乗る共有キャンバス。 MurmellとCodegの比較. ローカルのセッションを集めることと、共有クラウドディレクトリでエージェントを動かすことの違い。 一度に1つのエージェント、あなたのエディタの中で 記録されている並行処理はありません。1つのエージェントが、あなたがすでに書いているツールの中で監督されます。 MurmellとGemini Code Assistの比較. あなたのエディタの中の監督付きエージェントと、あなたが見るディレクトリの中の監督なしの複数エージェント。 同じエージェント、別の場所で CLIは両側で同一です。変わるのは動くマシンと、それを見られる人数です。 MurmellとウェブのClaude Codeの比較. 同じCLIが2つの場所に。タスクごとの隔離マシンと、キャンバス上の複数エージェントかつ単一の作業コピー。 自分に問うべきこと あなたのタスクは互いに触れ合っていますか?本当に独立しているなら、マシンごとの隔離は何のコストも かからず、最初のリストのツールはすべてうまくいきます。ファイルを共有し始めた瞬間、誰かが縫い合わせる 必要が出てきます。それこそが共有ディレクトリが1日を変える場面です。 ルールの仕組み。 --- ## Murmell 逐一对比 Source: https://murmell.com/zh/vs 每个任务一台云端机器 代理拿到你仓库的一份克隆,在一个分支上工作,交出一个 pull request。审阅之前什么都不共享。 Murmell 对比 Cursor. 一人一个编辑器、一个代理一台机器,对比一块画布、一个目录给所有人共用。 Murmell 对比 Devin. 靠隔离实现并行,对比靠共享实现并行,以及各自适合的场景。 Murmell 对比 Google Jules. 一份你批准的计划和一个你审阅的 pull request,对比在同一棵代码树里你能实时看到的终端。 Murmell 对比 GitHub Copilot 与 Agent HQ. 代理的工作在哪里汇合:是在 pull request,还是在工作副本里。 Murmell 对比 Codex Cloud. 在共享画布上运行 Codex CLI,和把一个任务委托出去,是两件不同的事,原因在这里。 Murmell 对比 Replit Agent. 从零造一个应用,对比让多个代理在已经存在的代码上工作。 每个任务一个空间,在你自己的机器上 同样的选择,只是在本地:一个代理一个 worktree 或工作目录,最后合并。代码不外传,也没有别人看到这个过程。 Murmell 对比 Windsurf. 你机器上每段对话一个 worktree,对比云端的一个共享目录。 Murmell 对比 Conductor. 一款一个任务一个空间的 Mac 应用,对比一块所有人共用一个目录的云端画布。 Murmell 对比 OpenHands Agent Canvas. 这份对比列表里最接近的一组:一个代理一个 worktree,对比一整棵树加文件占用机制。 Murmell 对比 Vibe Kanban. 本地执行之上的一块看板,对比云端目录之上的一块共享画布。 Murmell 对比 Codeg. 汇总本地会话,对比在共享云端目录上直接启动代理。 同一时间一个代理,在你的编辑器里 没有文档说明的并行能力:一个受监督的代理,在你已经在用的工具里。 Murmell 对比 Gemini Code Assist. 编辑器里一个受监督的代理,对比一个你旁观的目录里多个不受监督的代理。 同一个代理,换个地方 CLI 在两边完全一样。变化的是它运行的机器,以及能旁观它的人数。 Murmell 对比网页版 Claude Code. 同一个 CLI,两种运行方式:每个任务一台隔离机器,还是画布上多个代理共用一份工作副本。 该问自己的问题 你的任务会互相碰到吗?如果它们真的互不相关,按机器隔离不花什么代价,第一组里的任何工具都够用。一旦它们开始共用文件,总得有人来缝合,这时共享目录就能改变整个工作日。这条规则如何运作。 --- ## Murmell gegenüber Claude Code im Web Source: https://murmell.com/de/vs/claude-code Der eigentliche Unterschied Das ist kein Vergleich zwischen zwei Modellen, sondern zwischen zwei Orten. Das CLI ist auf beiden Seiten dasselbe. Bei Anthropic erhält jede Web-Sitzung ihre eigene virtuelle Maschine, die Arbeit läuft dort abseits und kommt als Pull-Request zurück. Auf Murmell läuft dasselbe Programm in einem Fenster der Canvas, auf einer Maschine, die wir betreiben, neben den anderen Agenten und im selben Verzeichnis wie sie. Die praktische Folge ist die Gleichzeitigkeit. Zwei isolierte Sitzungen können sich nicht stören, aber auch nicht gemeinsam an derselben Funktion arbeiten. Zwei Agenten in einem geteilten Verzeichnis können das, sofern ein Schiedsrichter die Dateien verteilt. Während zusehen, oder danach lesen Ein Link zu einer Web-Sitzung zeigt den Zustand beim Öffnen. Ein Canvas-Link zeigt die laufende Szene: die Fenster, die durchlaufenden Terminals, die Cursor der anwesenden Personen. Der Unterschied zählt, wenn jemand eingreifen muss, bevor es fertig ist, statt am Ende nachzulesen. Welches nehmen Claude Code im Web, wenn eine Aufgabe klar, isolierbar ist, und die Pull-Request das richtige Rückgabeformat ist. Murmell, wenn mehrere Agenten gemeinsam am selben Projekt vorankommen müssen, oder wenn andere Personen die Sitzung sehen sollen. Was Claude Code in einem Tab ergibt. --- ## Murmell frente a Claude Code en la web Source: https://murmell.com/es/vs/claude-code La diferencia real No es una comparación entre dos modelos, es una comparación entre dos lugares. El CLI es el mismo en los dos lados. En Anthropic, cada sesión web recibe su propia máquina virtual, el trabajo se hace aparte y vuelve como pull request. En Murmell, el mismo programa corre en una ventana del canvas, en una máquina que operamos, junto a los demás agentes y en el mismo directorio que ellos. La consecuencia práctica es la simultaneidad. Dos sesiones aisladas no pueden estorbarse, pero tampoco pueden trabajar juntas en la misma función. Dos agentes en un directorio compartido sí pueden, siempre que un árbitro reparta los archivos. Mirar durante, o leer después Un enlace de sesión web muestra el estado al abrirlo. Un enlace de canvas muestra la escena en curso: las ventanas, las terminales corriendo, los cursores de la gente presente. La diferencia importa cuando alguien tiene que intervenir antes del final en vez de revisar al final. Cuál elegir Claude Code en la web cuando una tarea es nítida, aislable, y la pull request es el formato de retorno correcto. Murmell cuando varios agentes deben avanzar juntos en el mismo proyecto, o cuando otras personas deben ver la sesión. Cómo es Claude Code en una pestaña. --- ## Murmell face à Claude Code sur le web Source: https://murmell.com/fr/vs/claude-code La vraie différence Ce n'est pas une comparaison entre deux modèles, c'est une comparaison entre deux endroits. Le CLI est le même des deux côtés. Chez Anthropic, chaque session web reçoit sa propre machine virtuelle, le travail y est fait à l'écart et revient en pull request. Sur Murmell, le même programme tourne dans une fenêtre du canvas, sur une machine que nous opérons, à côté des autres agents et dans le même dossier qu'eux. La conséquence pratique est la simultanéité. Deux sessions isolées ne peuvent pas se gêner, et ne peuvent pas non plus travailler ensemble sur la même fonctionnalité. Deux agents dans un dossier partagé le peuvent, à condition qu'un arbitre distribue les fichiers. Regarder pendant, ou lire après Un lien de session web montre l'état à l'ouverture. Un lien de canvas montre la scène en cours : les fenêtres, les terminaux qui défilent, les curseurs des gens présents. La différence compte quand quelqu'un doit intervenir avant la fin plutôt que relire à la fin. Lequel prendre Claude Code sur le web quand une tâche est nette, isolable, et que la pull request est le bon format de retour. Murmell quand plusieurs agents doivent avancer ensemble sur le même projet, ou quand d'autres personnes doivent voir la séance. Découvrez notre exécuteur Claude Code cloud, notre guide pour utiliser Claude Code sans l'installer, ou explorez le canvas multi-agents. --- ## वेब पर Claude Code के मुकाबले Murmell Source: https://murmell.com/hi/vs/claude-code असली फ़र्क़ यह दो मॉडल की नहीं, दो जगहों की तुलना है। CLI दोनों तरफ़ एक जैसा है। Anthropic के यहां, हर वेब सेशन को अपनी वर्चुअल मशीन मिलती है, काम अलग होता है और pull request के तौर पर लौटता है। Murmell पर, वही प्रोग्राम कैनवस की एक विंडो में चलता है, हमारी चलाई मशीन पर, बाकी एजेंट के साथ और उन्हीं के फ़ोल्डर में। व्यावहारिक नतीजा है साथ-साथ काम करना। दो अलग सेशन एक-दूसरे को परेशान नहीं कर सकते, लेकिन एक ही फ़ीचर पर साथ काम भी नहीं कर सकते। साझा फ़ोल्डर में दो एजेंट कर सकते हैं, बशर्ते कोई arbiter फ़ाइलें बांटे। बीच में देखना, या बाद में पढ़ना वेब सेशन का लिंक खोलते समय की स्थिति दिखाता है। कैनवस का लिंक चल रहा दृश्य दिखाता है: विंडो, चलते टर्मिनल, मौजूद लोगों के कर्सर। जब किसी को अंत से पहले दखल देना हो, बाद में पढ़ने की बजाय, तब यह फ़र्क़ मायने रखता है। कौन सा लें वेब पर Claude Code तब जब काम साफ़, अलग किया जा सकने वाला हो, और pull request सही जवाब का रूप हो। Murmell तब जब कई एजेंट को एक ही प्रोजेक्ट पर साथ आगे बढ़ना हो, या जब दूसरे लोगों को सेशन देखना हो। टैब में Claude Code कैसा दिखता है। --- ## Murmell contro Claude Code sul web Source: https://murmell.com/it/vs/claude-code La vera differenza Non è un confronto tra due modelli, è un confronto tra due luoghi. Il CLI è lo stesso su entrambi i lati. Presso Anthropic, ogni sessione web riceve la propria macchina virtuale, il lavoro vi viene fatto in disparte e torna come pull request. Su Murmell, lo stesso programma gira in una finestra del canvas, su una macchina che gestiamo noi, accanto agli altri agenti e nella stessa cartella. La conseguenza pratica è la simultaneità. Due sessioni isolate non possono disturbarsi, ma non possono nemmeno lavorare insieme sulla stessa funzionalità. Due agenti in una cartella condivisa possono, a condizione che un arbitro distribuisca i file. Guardare durante, o leggere dopo Un link di sessione web mostra lo stato all'apertura. Un link di canvas mostra la scena in corso: le finestre, i terminali che scorrono, i cursori delle persone presenti. La differenza conta quando qualcuno deve intervenire prima della fine invece di rileggere alla fine. Quale scegliere Claude Code sul web quando un compito è netto, isolabile, e la pull request è il formato giusto per il risultato. Murmell quando più agenti devono avanzare insieme sullo stesso progetto, o quando altre persone devono vedere la sessione. Cosa dà Claude Code in una scheda. --- ## MurmellとウェブのClaude Codeの比較 Source: https://murmell.com/ja/vs/claude-code 本当の違い 2つのモデルの比較ではなく、2つの場所の比較です。CLIは両側で同じです。Anthropic側では各ウェブ セッションが独自の仮想マシンを受け取り、作業は離れた場所で行われ、プルリクエストとして戻って きます。Murmellでは同じプログラムがキャンバスのウィンドウの中で動き、私たちが運用するマシン上で、 他のエージェントと並んで、同じディレクトリの中で動きます。 実際的な結果は同時性です。2つの隔離されたセッションは互いを邪魔することはできませんが、同じ 機能について一緒に作業することもできません。共有ディレクトリの中の2つのエージェントはそれが できます。調停者がファイルを配分している限りは。 作業中に見るか、後で読むか ウェブセッションのリンクは、開いた時点の状態を示します。キャンバスのリンクは、現在進行中の場面 を示します。ウィンドウ、流れるターミナル、居合わせる人々のカーソル。この違いは、最後に読み返す のではなく、終わる前に誰かが介入する必要があるときに重要になります。 どちらを選ぶか タスクが明確で切り分けやすく、プルリクエストが適切な返答の形であるなら、ウェブ版Claude Codeです。 複数のエージェントが同じプロジェクトで一緒に進める必要がある、あるいは他の人がセッションを見る 必要があるなら、Murmellです。タブの中のClaude Code が何をもたらすか。 --- ## Murmell과 웹의 Claude Code 비교 Source: https://murmell.com/ko/vs/claude-code 진짜 차이 두 모델을 비교하는 것이 아니라 두 장소를 비교하는 것입니다. CLI는 양쪽에서 동일합니다. Anthropic 쪽에서는 각 웹 세션이 자체 가상 머신을 받고, 작업은 그곳에서 따로 이루어진 뒤 풀 리퀘스트로 돌아옵니다. Murmell에서는 같은 프로그램이 저희가 운영하는 머신의 캔버스 창 안에서, 다른 에이전트들 옆에서, 같은 디렉터리 안에서 실행됩니다. 실질적인 결과는 동시성입니다. 격리된 두 세션은 서로 방해할 수 없지만, 같은 기능에서 함께 작업할 수도 없습니다. 공유 디렉터리의 두 에이전트는 조정자가 파일을 분배해준다면 가능합니다. 작업 중에 보는 것, 또는 끝난 뒤 읽는 것 웹 세션 링크는 여는 순간의 상태를 보여줍니다. 캔버스 링크는 진행 중인 장면을 보여줍니다. 창들, 흘러가는 터미널, 함께 있는 사람들의 커서까지요. 끝난 뒤 다시 읽는 대신 끝나기 전에 누군가 개입해야 할 때 이 차이가 중요해집니다. 어느 것을 고를지 작업이 명확하고 분리 가능하며 풀 리퀘스트가 알맞은 반환 형식일 때는 웹의 Claude Code입니다. 여러 에이전트가 같은 프로젝트에서 함께 진행해야 하거나, 다른 사람들이 그 장면을 봐야 할 때는 Murmell입니다. 탭 속 Claude Code가 어떤 모습인지. --- ## Murmell frente ao Claude Code na web Source: https://murmell.com/pt/vs/claude-code A diferença real Não é uma comparação entre dois modelos, é uma comparação entre dois lugares. O CLI é o mesmo dos dois lados. Na Anthropic, cada sessão web recebe sua própria máquina virtual, o trabalho é feito à parte e volta como pull request. No Murmell, o mesmo programa roda em uma janela do canvas, em uma máquina que operamos, ao lado dos outros agentes e no mesmo diretório que eles. A consequência prática é a simultaneidade. Duas sessões isoladas não podem atrapalhar uma à outra, mas também não podem trabalhar juntas na mesma funcionalidade. Dois agentes em um diretório compartilhado podem, desde que um árbitro distribua os arquivos. Assistir durante, ou ler depois Um link de sessão web mostra o estado no momento em que é aberto. Um link de canvas mostra a cena em andamento: as janelas, os terminais rolando, os cursores das pessoas presentes. A diferença importa quando alguém precisa intervir antes do fim em vez de revisar no fim. Qual escolher Claude Code na web quando uma tarefa é bem definida, isolável, e a pull request é o formato certo de retorno. Murmell quando vários agentes precisam avançar juntos no mesmo projeto, ou quando outras pessoas precisam ver a sessão. O que dá o Claude Code em uma aba. --- ## Murmell против Claude Code в вебе Source: https://murmell.com/ru/vs/claude-code Настоящая разница Это сравнение не двух моделей, а двух мест. CLI одинаковый с обеих сторон. У Anthropic каждая веб-сессия получает свою виртуальную машину, работа выполняется отдельно и возвращается в виде pull request. В Murmell та же программа работает в окне канваса, на машине, которой управляем мы, рядом с другими агентами и в том же каталоге, что и они. Практическое следствие, одновременность. Две изолированные сессии не могут мешать друг другу, но и не могут вместе работать над одной функцией. Два агента в общем каталоге могут, если координатор распределяет файлы. Наблюдать во время, или читать после Ссылка на веб-сессию показывает состояние на момент открытия. Ссылка на канвас показывает происходящую сцену: окна, идущие терминалы, курсоры присутствующих людей. Эта разница важна, когда кому-то нужно вмешаться до конца, а не перечитывать после. Что выбрать Claude Code в вебе, когда задача чёткая, изолируемая, и pull request, подходящая форма ответа. Murmell, когда нескольким агентам нужно продвигаться вместе над одним проектом, или когда другие люди должны видеть сессию. Как выглядит Claude Code во вкладке. --- ## Murmell vs Claude Code on the web Source: https://murmell.com/vs/claude-code What Claude Code already does Anthropic describes the CLI as available “in your terminal, IDE, desktop app, and browser”, and the browser version runs “on Anthropic-managed cloud infrastructure”. You point it at a repository, it clones the code, works, and pushes a branch. The documentation is explicit about the shape of that machine: “each session runs in an isolated, Anthropic-managed VM”, and “code is analyzed and modified within isolated VMs before creating PRs”. That isolation is the right design for the thing it does. A task you start and walk away from should not be able to touch anything you did not hand it, and a pull request is a clean place for finished work to wait. You can run several tasks at once, and each one gets its own machine and its own branch. Where Murmell sits differently Murmell removes the copies. Several agents run on one cloud machine, in one checkout, and an agent claims a path before it writes to it. The board keeps one holder per path and refuses everybody else until that holder lets go. Nothing has to be merged at the end because nothing forked at the start. The second difference is who is in the room. A Murmell canvas is multiplayer while the work happens: the windows, the terminal output and the named cursors move under everybody at once. Anthropic is precise about the web equivalent, and the sentence is worth reading closely. Recipients of a shared session “see the latest state when they open the link, but their view doesn’t update in real time”. A link to a session is a report. A canvas is a room. The third is the agent you are allowed to bring. Murmell is not tied to one vendor: Claude Code, Codex, Kimi and OpenCode run in the same canvas, on the same directory, reserving files from the same board. Two agents from two companies can work on one feature in the same hour. Where Claude Code wins Everywhere the work is yours alone, which is most of the time. The terminal, the IDE extensions, the desktop app and the phone are all one engine, and a session follows you between them. Nothing in Murmell competes with typing claude in a project you already have checked out. Isolation also wins whenever the task should be quarantined. Anthropic keeps git credentials out of the sandbox entirely and handles authentication “through a secure proxy using scoped credentials”. If the job is to let an agent loose on something you have not read yet, a private VM that can only ever produce a pull request is the safer container. Which to pick Use Claude Code on its own when one agent is enough and the output belongs in a branch you review later. Use Murmell when several agents have to touch the same files in the same hour, when the useful thing is a colleague watching the run rather than reading the diff afterwards, or when the agents come from more than one vendor. The CLI is the same either way. Check our Claude Code cloud runner, learn how to use Claude Code without installing anything, or explore the multi-agent canvas. --- ## Murmell 对比网页版 Claude Code Source: https://murmell.com/zh/vs/claude-code 真正的区别 这不是两个模型之间的比较,是两个地方之间的比较。CLI 本身在两边是同一个。在 Anthropic 那边,每个网页会话拿到自己的一台虚拟机,工作在别处完成,再以 pull request 的形式回来。在 Murmell 上,同一个程序运行在画布的一个窗口里,机器由我们运营,和其他代理挨在一起、在同一个目录里。 由此带来的实际差别是能否同时进行。两个隔离的会话互不打扰,但也没法一起做同一个功能。共享目录里的两个代理可以,前提是有一个仲裁者来分配文件。 边看边做,还是事后再读 一个网页会话的链接展示的是打开那一刻的状态。一个画布链接展示的是正在进行的场景:窗口、滚动的终端、在场者的光标。这个差别在有人需要在结束之前介入,而不是结束之后再读的时候才真正要紧。 选哪个 任务边界清晰、可以独立处理、pull request 是合适的交付形式时,选网页版 Claude Code。多个代理需要在同一个项目上协同推进,或者需要让其他人看到这个过程时,选 Murmell。Claude Code 在标签页里是什么样子。 --- ## Murmell gegenüber Codeg Source: https://murmell.com/de/vs/codeg Sammeln, oder starten Beide Produkte blicken auf dasselbe Durcheinander: überall Agentensitzungen, kein Gesamtüberblick. Codeg räumt es nachträglich auf, indem es liest, was auf Ihrer Festplatte existiert. Murmell verhindert, dass es entsteht, indem es der Ort ist, von dem die Sitzungen ausgehen. Was die Cloud ändert Eine von Murmell gestartete Sitzung lebt auf einer gemieteten Maschine, überlebt also das Schließen des Tabs, und ein Link reicht, um sie zu zeigen. Eine von Ihrer Maschine gesammelte Sitzung bleibt an Ihre Maschine gebunden. Welches nehmen Codeg, wenn Ihr Rechner bereits der Ort ist, an dem alles läuft, und ein Gesamtüberblick fehlt. Murmell, wenn die Arbeit anderswo stattfinden soll, mit mehreren Agenten, in einem gemeinsamen Verzeichnis. Was das gemeinsame Verzeichnis tragfähig macht. --- ## Murmell frente a Codeg Source: https://murmell.com/es/vs/codeg Reunir, o arrancar Los dos productos miran el mismo desorden: sesiones de agentes por todas partes, ninguna vista de conjunto. Codeg lo ordena después, leyendo lo que existe en tu disco. Murmell evita que se cree, siendo el lugar de donde salen las sesiones. Lo que cambia la nube Una sesión lanzada desde Murmell vive en una máquina alquilada, así que sobrevive al cierre de la pestaña y un enlace basta para mostrarla. Una sesión reunida desde tu máquina sigue atada a tu máquina. Cuál elegir Codeg si tu equipo ya es el sitio donde todo corre y falta una vista. Murmell si el trabajo debe hacerse en otro lugar, con varios agentes, en un directorio común. Lo que hace sostenible el directorio común. --- ## Murmell face à Codeg Source: https://murmell.com/fr/vs/codeg Rassembler, ou démarrer Les deux produits regardent le même désordre : des sessions d'agents partout, aucune vue d'ensemble. Codeg le range après coup, en lisant ce qui existe sur votre disque. Murmell évite qu'il se crée, en étant l'endroit d'où les sessions partent. Ce que le cloud change Une session lancée depuis Murmell vit sur une machine louée, donc elle survit à la fermeture de l'onglet et un lien suffit pour la montrer. Une session rassemblée depuis votre machine reste attachée à votre machine. Lequel prendre Codeg si votre poste est déjà l'endroit où tout tourne et qu'il manque une vue. Murmell si le travail doit se faire ailleurs, à plusieurs agents, dans un dossier commun. Ce qui rend le dossier commun tenable. --- ## Codeg के मुकाबले Murmell Source: https://murmell.com/hi/vs/codeg इकट्ठा करना, या शुरू करना दोनों उत्पाद एक ही गड़बड़ी देखते हैं: हर जगह एजेंट सेशन, कोई पूरी तस्वीर नहीं। Codeg इसे बाद में सुलझाता है, आपकी डिस्क पर जो मौजूद है उसे पढ़कर। Murmell इसे बनने ही नहीं देता, क्योंकि सेशन वहीं से शुरू होते हैं। क्लाउड से क्या बदलता है Murmell से शुरू किया गया सेशन किराए की मशीन पर जीता है, इसलिए यह टैब बंद होने के बाद भी बचता है और इसे दिखाने के लिए एक लिंक काफ़ी है। आपकी मशीन से इकट्ठा किया गया सेशन आपकी मशीन से बंधा रहता है। कौन सा लें Codeg अगर आपका कंप्यूटर पहले से वह जगह है जहां सब चलता है और बस एक साझा नज़र की कमी है। Murmell अगर काम कहीं और, कई एजेंट के साथ, एक साझा फ़ोल्डर में होना चाहिए। साझा फ़ोल्डर को टिकाऊ क्या बनाता है। --- ## Murmell contro Codeg Source: https://murmell.com/it/vs/codeg Raccogliere, o avviare I due prodotti guardano lo stesso disordine: sessioni di agenti ovunque, nessuna vista d'insieme. Codeg lo riordina dopo, leggendo ciò che esiste sul tuo disco. Murmell evita che si crei, essendo il punto da cui le sessioni partono. Cosa cambia il cloud Una sessione avviata da Murmell vive su una macchina affittata, quindi sopravvive alla chiusura della scheda e un link basta per mostrarla. Una sessione raccolta dalla tua macchina resta legata alla tua macchina. Quale scegliere Codeg se il tuo computer è già il posto dove tutto gira e manca una vista. Murmell se il lavoro deve farsi altrove, con più agenti, in una cartella comune. Cosa rende sostenibile la cartella comune. --- ## MurmellとCodegの比較 Source: https://murmell.com/ja/vs/codeg 集めるか、始めるか 両方の製品は同じ乱雑さを見ています。至る所にエージェントのセッションがあり、全体を見渡すビュー がありません。Codegはそれを事後に、あなたのディスク上に既にあるものを読み取ることで整理します。 Murmellはそれが生まれるのを防ぎます。セッションが出発する場所そのものになることで。 クラウドが変えること Murmellから起動されたセッションは借りたマシン上で生きるため、タブを閉じても生き残り、リンク1つ で見せられます。あなたのマシンから集約されたセッションは、あなたのマシンに縛られたままです。 どちらを選ぶか すでにあなたの環境がすべてが動く場所で、ビューが足りないだけならCodegです。作業を別の場所で、 複数のエージェントで、共通のディレクトリで行う必要があるならMurmellです。 共通ディレクトリを成り立たせているもの。 --- ## Murmell과 Codeg 비교 Source: https://murmell.com/ko/vs/codeg 모으기, 또는 시작하기 두 제품 모두 같은 혼란을 봅니다. 여기저기 흩어진 에이전트 세션들, 전체를 보는 눈이 없다는 것. Codeg는 여러분 디스크에 이미 존재하는 것을 읽어 나중에 정리합니다. Murmell은 세션이 시작되는 곳 자체가 됨으로써 그 혼란이 생기는 것을 막습니다. 클라우드가 바꾸는 것 Murmell에서 시작된 세션은 빌린 머신 위에서 살아 있으므로 탭을 닫아도 살아남고, 링크 하나면 보여줄 수 있습니다. 여러분 머신에서 모아진 세션은 여러분 머신에 계속 묶여 있습니다. 어느 것을 고를지 여러분의 컴퓨터가 이미 모든 것이 돌아가는 곳이고 부족한 것이 전체를 보는 뷰라면 Codeg입니다. 작업이 다른 곳에서, 여러 에이전트로, 공동 디렉터리 안에서 이루어져야 한다면 Murmell입니다. 공동 디렉터리를 지속 가능하게 만드는 것. --- ## Murmell frente ao Codeg Source: https://murmell.com/pt/vs/codeg Reunir, ou iniciar Os dois produtos olham para a mesma bagunça: sessões de agentes por toda parte, nenhuma visão geral. Codeg organiza isso depois, lendo o que existe no seu disco. Murmell evita que ela se crie, sendo o lugar de onde as sessões partem. O que a nuvem muda Uma sessão iniciada a partir do Murmell vive em uma máquina alugada, então ela sobrevive ao fechamento da aba e um link é suficiente para mostrá-la. Uma sessão reunida a partir da sua máquina continua presa à sua máquina. Qual escolher Codeg se o seu computador já é o lugar onde tudo roda e falta uma visão geral. Murmell se o trabalho precisa acontecer em outro lugar, com vários agentes, em um diretório comum. O que torna o diretório comum viável. --- ## Murmell против Codeg Source: https://murmell.com/ru/vs/codeg Собирать, или запускать Оба продукта смотрят на один и тот же беспорядок: сессии агентов повсюду, никакого общего обзора. Codeg наводит порядок постфактум, читая то, что уже есть на вашем диске. Murmell не даёт этому беспорядку возникнуть, становясь местом, откуда сессии начинаются. Что меняет облако Сессия, запущенная из Murmell, живёт на арендованной машине, поэтому переживает закрытие вкладки, и одной ссылки достаточно, чтобы её показать. Сессия, собранная с вашей машины, остаётся привязанной к вашей машине. Что выбрать Codeg, если ваш компьютер уже место, где всё работает, и не хватает только общего обзора. Murmell, если работа должна выполняться в другом месте, несколькими агентами, в общем каталоге. Что делает общий каталог жизнеспособным. --- ## Murmell vs Codeg Source: https://murmell.com/vs/codeg The real difference Codeg brings many agents into one unified workspace and supports conversation aggregation, importing sessions from every agent it knows about by scanning their default local data directories. Inside a single session the main agent can delegate to sub-agents of a different kind, so Claude Code can call Codex, and parallel work uses built-in git worktree flows. So the parallelism is still a worktree each, and the history is still whatever ran on your computer. Murmell is the other arrangement. The agents run on cloud machines, share one checkout, and ask before they write: an agent claims the paths it is about to touch, the board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted before it lands. The rule is enforced by the server rather than suggested to the model. And a Murmell canvas has other people in it. Send a read link and they see the windows, the terminal contents and a named cursor each, live, while it happens. Close your tab and the agents keep working. Where Codeg wins Your existing history. If you have months of Claude Code and Codex transcripts sitting in local directories, Codeg is the tool that goes and gets them, and nothing about Murmell reaches back into work that ran somewhere else. It covers far more agents than Murmell launches today, it is Apache-2.0 so you can read and change it, and it installs as a desktop app or as a server of your own under Docker. Murmell is not open source and cannot be self-hosted. Which to pick Pick Codeg when the agents already run on your machine and the problem is that their work is scattered across a dozen places. Pick Murmell when the problem is that two agents cannot safely edit the same file, or that nobody else can see the run. Every project gets a private repository, pushed to as the work goes and once more before a machine is torn down, and the machine executing agent code holds no database and no decryption key. See how several agents work in one repository. --- ## Murmell 对比 Codeg Source: https://murmell.com/zh/vs/codeg 汇总,还是启动 两款产品面对的是同一种混乱:代理会话散落各处,没有全局视图。Codeg 事后整理,读取你硬盘上已经存在的内容。Murmell 从源头避免这种混乱,因为会话本来就是从这里发起的。 云端改变了什么 从 Murmell 启动的会话运行在一台租用的机器上,所以关掉标签页它照样活着,一个链接就能展示出来。从你自己机器上汇总的会话,始终绑在你的机器上。 选哪个 如果你的电脑已经是一切运行的地方,只是缺一个总览视图,选 Codeg。如果工作需要在别处完成,由多个代理在一个共同目录里进行,选 Murmell。是什么让共同目录能撑得住。 --- ## Murmell frente a Codex cloud Source: https://murmell.com/es/vs/codex-cloud Dos momentos distintos Los dos productos no apuntan al mismo instante. OpenAI presenta Codex cloud como una forma de lanzar tareas en entornos aislados, trabajar en paralelo y arrancar desde la web, GitHub, Linear o Slack, con un resumen y un diff al final. Es delegación: te vas, vuelve hecho. Murmell apunta a la hora en la que el trabajo se hace. La terminal es visible, la salida corre, y un segundo agente puede trabajar en el mismo directorio al mismo tiempo porque un árbitro reparte los archivos. Lo que permite compartir Dos entornos aislados producen dos diffs que hay que coser. Dos agentes en un directorio compartido producen un único estado, y las colisiones se rechazan en el momento en que ocurren en vez de descubrirse en la revisión. El detalle del mecanismo. Cuál elegir Codex cloud para una tarea acotada que quieres recibir terminada, sin mirar. Murmell cuando la sesión misma importa: varios agentes en un proyecto, y gente mirando mientras tanto. Los dos usan la cuenta de OpenAI que ya tienes. --- ## Murmell face à Codex cloud Source: https://murmell.com/fr/vs/codex-cloud Deux moments différents Les deux produits ne visent pas le même instant. OpenAI présente Codex cloud comme une façon de lancer des tâches dans des environnements isolés, de travailler en parallèle et de démarrer depuis le web, GitHub, Linear ou Slack, avec un résumé et un diff à la fin. C'est de la délégation : vous partez, ça revient. Murmell vise l'heure pendant laquelle le travail se fait. Le terminal est visible, la sortie défile, et un deuxième agent peut travailler dans le même dossier au même moment parce qu'un arbitre distribue les fichiers. Ce que le partage permet Deux environnements isolés produisent deux diffs qu'il faut recoudre. Deux agents dans un dossier partagé produisent un état unique, et les collisions sont refusées au moment où elles se produisent plutôt que découvertes à la relecture. Le détail du mécanisme. Lequel prendre Codex cloud pour une tâche cadrée que vous voulez récupérer finie, sans regarder. Murmell quand la séance elle-même compte : plusieurs agents sur un projet, et des gens qui regardent pendant. Les deux utilisent le compte OpenAI que vous avez déjà. --- ## Codex cloud के मुकाबले Murmell Source: https://murmell.com/hi/vs/codex-cloud दो अलग पल दोनों उत्पाद एक ही पल पर निशाना नहीं साधते। OpenAI Codex cloud को अलग वातावरण में काम शुरू करने, समांतर काम करने और वेब, GitHub, Linear या Slack से शुरुआत करने का तरीका बताता है, आख़िर में एक सारांश और diff के साथ। यह सौंपना है: आप चले जाते हैं, नतीजा वापस आता है। Murmell उस घंटे को निशाना बनाता है जब काम हो रहा होता है। टर्मिनल दिखता है, आउटपुट चलता रहता है, और उसी पल एक ही फ़ोल्डर में दूसरा एजेंट भी काम कर सकता है क्योंकि arbiter फ़ाइलें बांट देता है। साझा करने से क्या मिलता है दो अलग वातावरण दो diff बनाते हैं जिन्हें सिलना पड़ता है। साझा फ़ोल्डर में दो एजेंट एक ही स्थिति बनाते हैं, और टकराव उसी पल मना कर दिया जाता है जब वह होता है, बाद में रिव्यू में पता चलने की बजाय। तरीके का विवरण। कौन सा लें Codex cloud किसी साफ़-सुथरे काम के लिए जिसे आप बिना देखे खत्म पाना चाहते हैं। Murmell तब जब सेशन खुद मायने रखता है: एक प्रोजेक्ट पर कई एजेंट, और दौरान देखने वाले लोग। दोनों वही OpenAI अकाउंट इस्तेमाल करते हैं जो आपके पास पहले से है। --- ## MurmellとCodex cloudの比較 Source: https://murmell.com/ja/vs/codex-cloud 異なる2つの瞬間 2つの製品は同じ瞬間を狙っていません。OpenAIはCodex cloudを、隔離された環境でタスクを起動し、並行 して作業し、ウェブ、GitHub、Linear、Slackから開始できるものとして紹介しており、最後には要約と diffが返ってきます。これは委任です。あなたは離れ、戻ってくる。 Murmellは作業が行われているその時間を狙います。ターミナルが見え、出力が流れ、2番目のエージェント は同じ瞬間に同じディレクトリで作業できます。調停者がファイルを配分している限りは。 共有が可能にすること 2つの隔離環境は縫い合わせる必要のある2つのdiffを生みます。共有ディレクトリの中の2つのエージェント は1つの状態を生み、衝突は後で発見されるのではなく、発生した瞬間に拒否されます。 仕組みの詳細。 どちらを選ぶか 見張らずに完成した状態で受け取りたい、範囲の明確なタスクにはCodex cloudです。セッション自体が 重要なとき、つまり複数のエージェントがプロジェクトで動き、その間人々が見ているときはMurmellです。 どちらもすでに持っているOpenAIのアカウントを使います。 --- ## Murmell과 Codex cloud 비교 Source: https://murmell.com/ko/vs/codex-cloud 서로 다른 두 순간 두 제품은 같은 순간을 겨냥하지 않습니다. OpenAI는 Codex cloud를 격리된 환경에서 작업을 실행하고, 병렬로 작업하고, 웹, GitHub, Linear, Slack에서 시작할 수 있는 방법으로, 마지막에 요약과 diff가 나오는 것으로 소개합니다. 이것은 위임입니다. 여러분은 떠나고, 결과가 돌아옵니다. Murmell은 작업이 이루어지는 그 시간을 겨냥합니다. 터미널이 보이고, 출력이 흘러가며, 조정자가 파일을 분배해주므로 두 번째 에이전트가 같은 순간 같은 디렉터리에서 작업할 수 있습니다. 공유가 가능하게 하는 것 격리된 두 환경은 이어 붙여야 할 diff 두 개를 만듭니다. 공유 디렉터리의 두 에이전트는 하나의 상태를 만들고, 충돌은 나중에 리뷰에서 발견되는 대신 발생하는 순간 거부됩니다. 메커니즘 자세히 보기. 어느 것을 고를지 범위가 명확한 작업을 지켜보지 않고 끝난 채로 받고 싶다면 Codex cloud입니다. 세션 자체가 중요할 때는, 즉 여러 에이전트가 하나의 프로젝트에서, 지켜보는 사람들과 함께일 때는 Murmell입니다. 둘 다 이미 가지고 있는 OpenAI 계정을 씁니다. --- ## Murmell frente ao Codex cloud Source: https://murmell.com/pt/vs/codex-cloud Dois momentos diferentes Os dois produtos não visam o mesmo momento. A OpenAI apresenta o Codex cloud como uma forma de iniciar tarefas em ambientes isolados, trabalhar em paralelo e começar pela web, GitHub, Linear ou Slack, com um resumo e um diff no final. É delegação: você sai, e volta pronto. Murmell mira a hora em que o trabalho está sendo feito. O terminal fica visível, a saída rola, e um segundo agente pode trabalhar no mesmo diretório ao mesmo tempo porque um árbitro distribui os arquivos. O que o compartilhamento permite Dois ambientes isolados produzem dois diffs que precisam ser costurados. Dois agentes em um diretório compartilhado produzem um único estado, e as colisões são recusadas no momento em que acontecem em vez de descobertas na revisão. O detalhe do mecanismo. Qual escolher Codex cloud para uma tarefa bem definida que você quer receber pronta, sem acompanhar. Murmell quando a própria sessão importa: vários agentes em um projeto, e gente assistindo durante. Os dois usam a conta OpenAI que você já tem. --- ## Murmell против Codex cloud Source: https://murmell.com/ru/vs/codex-cloud Два разных момента Оба продукта нацелены не на один и тот же момент. OpenAI представляет Codex cloud как способ запускать задачи в изолированных окружениях, работать параллельно и начинать из веба, GitHub, Linear или Slack, с итоговыми сводкой и diff. Это делегирование: вы уходите, результат возвращается. Murmell нацелен на тот самый час, когда работа выполняется. Терминал виден, вывод идёт, и второй агент может работать в том же каталоге в тот же момент, потому что координатор распределяет файлы. Что даёт совместное использование Два изолированных окружения производят два diff, которые нужно сшивать. Два агента в общем каталоге производят одно состояние, а столкновения отклоняются в момент возникновения, а не обнаруживаются при ревью. Механизм подробно. Что выбрать Codex cloud для чёткой задачи, которую хочется получить готовой, не наблюдая. Murmell, когда важна сама сессия: несколько агентов над одним проектом, и люди, наблюдающие за процессом. Оба используют аккаунт OpenAI, который у вас уже есть. --- ## Murmell vs Codex cloud Source: https://murmell.com/vs/codex-cloud The real difference The two products are not aimed at the same moment. OpenAI describes Codex cloud as a way to “run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, Linear, or Slack”, with dedicated environments for the long ones and a summary and diff at the end. Isolation is the design, and the diff is the handoff. Murmell has no handoff, because there is nothing to hand back. The agents are already in the working tree. Codex claims the paths it is about to touch, the board keeps one holder per path and refuses everyone else until it is released, and Claude Code waits its turn on the same files. That rule is enforced by the server, not suggested to the model. And Murmell is not the agent. It runs the CLIs. Switching from Codex to another agent leaves the directory, the reservations and the history where they are, because those belong to the canvas rather than to whichever CLI is attached to it. Where Codex cloud wins The model and the reach of it. Codex is on the web, in a desktop app, in your editor, in the terminal and inside ChatGPT, all on one account, and you configure the dependencies and setup steps a repository needs once. Work can be started from Slack or Linear without anybody opening a browser tab that looks like a desk. If what you want is a task delegated and forgotten until it is reviewable, Codex cloud is already good at that and Murmell does not try to be. Which to pick Pick Codex cloud when one agent can finish the job alone and the diff is all you need to see. Pick Murmell when you want more than one agent on the same files at once, when you want to read the terminal instead of the summary, or when someone else should be watching. The machine that executes agent code holds no database and no decryption key, so an agent that gets out of its box finds nothing to take. See how several agents work in one repository. --- ## Murmell gegenüber Codex Cloud Source: https://murmell.com/de/vs/codex-cloud Zwei unterschiedliche Momente Die beiden Produkte zielen nicht auf denselben Moment. OpenAI präsentiert Codex Cloud als eine Möglichkeit, Aufgaben in isolierten Umgebungen zu starten, parallel zu arbeiten und aus dem Web, GitHub, Linear oder Slack zu beginnen, mit einer Zusammenfassung und einem Diff am Ende. Das ist Delegation: Sie gehen weg, es kommt zurück. Murmell zielt auf die Stunde, in der die Arbeit stattfindet. Das Terminal ist sichtbar, die Ausgabe läuft durch, und ein zweiter Agent kann zur selben Zeit im selben Verzeichnis arbeiten, weil ein Schiedsrichter die Dateien verteilt. Was das Teilen ermöglicht Zwei isolierte Umgebungen erzeugen zwei Diffs, die zusammengenäht werden müssen. Zwei Agenten in einem geteilten Verzeichnis erzeugen einen einzigen Zustand, und Kollisionen werden in dem Moment verweigert, in dem sie entstehen, statt bei der Durchsicht entdeckt zu werden. Der Mechanismus im Detail. Welches nehmen Codex Cloud für eine klar umrissene Aufgabe, die Sie fertig zurückholen wollen, ohne zuzusehen. Murmell, wenn die Sitzung selbst zählt: mehrere Agenten an einem Projekt, und Leute, die währenddessen zusehen. Beide nutzen das OpenAI-Konto, das Sie bereits haben. --- ## Murmell contro Codex Cloud Source: https://murmell.com/it/vs/codex-cloud Due momenti diversi I due prodotti non puntano allo stesso istante. OpenAI presenta Codex Cloud come un modo per lanciare compiti in ambienti isolati, lavorare in parallelo e partire dal web, GitHub, Linear o Slack, con un riassunto e un diff alla fine. È delega: parti, torna. Murmell punta all'ora in cui il lavoro si fa. Il terminale è visibile, l'output scorre, e un secondo agente può lavorare nella stessa cartella nello stesso momento perché un arbitro distribuisce i file. Cosa permette la condivisione Due ambienti isolati producono due diff da ricucire. Due agenti in una cartella condivisa producono uno stato unico, e le collisioni vengono rifiutate nel momento in cui si verificano invece di essere scoperte alla revisione. Il dettaglio del meccanismo. Quale scegliere Codex Cloud per un compito ben definito che vuoi recuperare finito, senza guardare. Murmell quando la sessione in sé conta: più agenti su un progetto, e gente che guarda durante. Entrambi usano l'account OpenAI che hai già. --- ## Murmell 对比 Codex Cloud Source: https://murmell.com/zh/vs/codex-cloud 两个不同的时刻 两款产品瞄准的不是同一个时刻。OpenAI 把 Codex Cloud 定位为一种在隔离环境里启动任务、并行工作、从网页、GitHub、Linear 或 Slack 发起的方式,结尾给出一份摘要和一个 diff。这是委托:你离开,结果回来。 Murmell 瞄准的是工作实际发生的那个小时。终端可见,输出在滚动,第二个代理可以在同一时刻、同一个目录里工作,因为有一个仲裁者在分配文件。 共享带来了什么 两个隔离环境会产出两份需要缝合的 diff。共享目录里的两个代理产出的是同一个统一状态,冲突在发生的那一刻就被拒绝,而不是等到审阅时才被发现。机制的详细说明。 选哪个 任务边界清晰、你想不看过程直接拿到成品时,选 Codex Cloud。会话本身很重要:多个代理在一个项目上、有人在旁观时,选 Murmell。两者用的都是你已经有的 OpenAI 账号。 --- ## Murmell gegenüber Conductor Source: https://murmell.com/de/vs/conductor Auf Ihrer Festplatte, oder auf einer gemieteten Maschine Conductor setzt auf lokal: Die App ist auf Ihrem Mac, die Dateien auch, und nichts durchquert das Netzwerk. Das ist das beste Argument dieses Vergleichs, und es lässt sich nicht diskutieren, wenn interne Richtlinien es verlangen. Was das Lokale kostet, ist die Präsenz. Die Arbeit stoppt, wenn die Maschine sich schließt, und jemandem eine Sitzung zu zeigen bedeutet, einen Bildschirm zu teilen. Ein Bereich pro Aufgabe, oder ein Verzeichnis für alle Conductor isoliert jeden Agenten in seinem Bereich, mit seinem Branch und seinem Diff, und Sie fügen beim Zusammenführen zusammen. Murmell erzeugt keine Kopien: Die Kollision wird im Moment des Schreibens verweigert. Der Mechanismus. Welches nehmen Conductor für einen einzelnen Entwickler auf einem Mac, mit Code, der nicht raus darf. Murmell, wenn die Sitzung gemeinschaftlich ist und die Agenten in derselben Ecke des Projekts arbeiten. --- ## Murmell frente a Conductor Source: https://murmell.com/es/vs/conductor En tu disco, o en una máquina alquilada Conductor asume lo local: la aplicación está en tu Mac, los archivos también, y nada cruza la red. Es el mejor argumento de la comparación, y no se discute cuando la política interna lo exige. Lo que cuesta lo local es la presencia. El trabajo se detiene cuando la máquina se cierra, y mostrar una sesión a alguien significa compartir pantalla. Un espacio por tarea, o un directorio para todos Conductor aísla a cada agente en su espacio, con su rama y su diff, y los reúnes en la fusión. Murmell no fabrica copias: la colisión se rechaza en el momento de la escritura. El mecanismo. Cuál elegir Conductor para un desarrollador solo en un Mac, con código que no puede salir. Murmell cuando la sesión es colectiva y los agentes trabajan en el mismo rincón del proyecto. --- ## Murmell face à Conductor Source: https://murmell.com/fr/vs/conductor Sur votre disque, ou sur une machine louée Conductor assume le local : l'application est sur votre Mac, les fichiers aussi, et rien ne traverse le réseau. C'est le meilleur argument de la comparaison, et il ne se discute pas quand la politique interne l'exige. Ce que le local coûte, c'est la présence. Le travail s'arrête quand la machine se ferme, et montrer une séance à quelqu'un veut dire partager un écran. Un espace par tâche, ou un dossier pour tous Conductor isole chaque agent dans son espace, avec sa branche et son diff, et vous rassemblez à la fusion. Murmell ne fabrique pas de copies : la collision est refusée au moment de l'écriture. Le mécanisme. Lequel prendre Conductor pour un développeur seul sur un Mac, avec du code qui ne sort pas. Murmell quand la séance est collective et que les agents travaillent dans le même coin du projet. --- ## Conductor के मुकाबले Murmell Source: https://murmell.com/hi/vs/conductor आपकी डिस्क पर, या किराए की मशीन पर Conductor लोकल तरीका अपनाता है: ऐप आपके Mac पर है, फ़ाइलें भी, और नेटवर्क से कुछ भी नहीं गुज़रता। यह इस तुलना का सबसे मज़बूत तर्क है, और जब आंतरिक नीति इसकी मांग करती है तो इस पर बहस नहीं होती। लोकल होने की कीमत मौजूदगी है। मशीन बंद होने पर काम रुक जाता है, और किसी को सेशन दिखाने का मतलब है स्क्रीन शेयर करना। हर काम के लिए जगह, या सबके लिए फ़ोल्डर Conductor हर एजेंट को उसकी जगह में अलग रखता है, अपनी ब्रांच और diff के साथ, और आप मर्ज पर सब जोड़ते हैं। Murmell कॉपियां नहीं बनाता: टकराव को लिखने के पल ही मना कर दिया जाता है। तरीका। कौन सा लें Conductor Mac पर अकेले काम करने वाले डेवलपर के लिए, जिसका कोड बाहर नहीं जाता। Murmell तब जब सेशन सबका हो और एजेंट प्रोजेक्ट के एक ही कोने में काम कर रहे हों। --- ## Murmell contro Conductor Source: https://murmell.com/it/vs/conductor Sul tuo disco, o su una macchina affittata Conductor assume il locale: l'app è sul tuo Mac, i file pure, e nulla attraversa la rete. È il miglior argomento del confronto, e non si discute quando la politica interna lo richiede. Ciò che il locale costa è la presenza. Il lavoro si ferma quando la macchina si chiude, e mostrare una sessione a qualcuno vuol dire condividere lo schermo. Uno spazio per compito, o una cartella per tutti Conductor isola ogni agente nel proprio spazio, con il suo branch e il suo diff, e tu riunisci alla fusione. Murmell non fabbrica copie: la collisione viene rifiutata nel momento della scrittura. Il meccanismo. Quale scegliere Conductor per uno sviluppatore solo su un Mac, con codice che non esce. Murmell quando la sessione è collettiva e gli agenti lavorano nello stesso angolo del progetto. --- ## MurmellとConductorの比較 Source: https://murmell.com/ja/vs/conductor あなたのディスクか、借りたマシンか Conductorはローカルであることを前提としています。アプリはあなたのMac上にあり、ファイルもそこに あり、何もネットワークを越えません。これはこの比較の中で最も強い論点であり、社内ポリシーがそれ を要求するときは議論の余地がありません。 ローカルであることの代償は立ち会いです。マシンを閉じると作業は止まり、誰かにセッションを見せる には画面共有が必要になります。 タスクごとのスペースか、全員のための1つのディレクトリか Conductorは各エージェントをそれぞれのスペースに、独自のブランチとdiffとともに隔離し、マージの 時点でまとめます。Murmellはコピーを作りません。衝突は書き込みの瞬間に拒否されます。 仕組み。 どちらを選ぶか Macで1人で作業していて、コードが外に出ないならConductorです。セッションが集団的で、エージェント がプロジェクトの同じ一角で作業するならMurmellです。 --- ## Murmell과 Conductor 비교 Source: https://murmell.com/ko/vs/conductor 여러분의 디스크 위, 또는 빌린 머신 위 Conductor는 로컬을 전제로 합니다. 애플리케이션도, 파일도 여러분의 Mac에 있고, 네트워크를 건너는 것은 아무것도 없습니다. 이는 이 비교에서 가장 강력한 주장이며, 내부 정책이 이를 요구할 때는 논쟁의 여지가 없습니다. 로컬이 치르는 대가는 현장성입니다. 머신이 닫히면 작업도 멈추고, 누군가에게 세션을 보여주려면 화면을 공유해야 합니다. 작업마다 공간 하나, 또는 모두를 위한 디렉터리 하나 Conductor는 각 에이전트를 자체 브랜치와 diff를 가진 공간에 격리하고, 병합할 때 모읍니다. Murmell은 복사본을 만들지 않습니다. 충돌은 쓰기 순간에 거부됩니다. 메커니즘. 어느 것을 고를지 Mac에서 혼자 작업하고 코드가 밖으로 나가지 않아야 하는 개발자에게는 Conductor입니다. 세션이 여럿이 함께하는 것이고 에이전트들이 프로젝트의 같은 구석에서 작업할 때는 Murmell입니다. --- ## Murmell frente ao Conductor Source: https://murmell.com/pt/vs/conductor No seu disco, ou em uma máquina alugada Conductor assume o local: o aplicativo está no seu Mac, os arquivos também, e nada atravessa a rede. É o melhor argumento da comparação, e não se discute quando a política interna exige. O que o local custa é a presença. O trabalho para quando a máquina se fecha, e mostrar uma sessão para alguém significa compartilhar a tela. Um espaço por tarefa, ou um diretório para todos Conductor isola cada agente em seu espaço, com sua branch e seu diff, e você reúne tudo na fusão. Murmell não fabrica cópias: a colisão é recusada no momento da escrita. O mecanismo. Qual escolher Conductor para um desenvolvedor sozinho em um Mac, com código que não sai dali. Murmell quando a sessão é coletiva e os agentes trabalham no mesmo canto do projeto. --- ## Murmell против Conductor Source: https://murmell.com/ru/vs/conductor На вашем диске, или на арендованной машине Conductor полагается на локальность: приложение на вашем Mac, файлы тоже, и ничего не пересекает сеть. Это самый сильный аргумент этого сравнения, и он неоспорим, когда этого требует внутренняя политика. Цена локальности, присутствие. Работа останавливается, когда машина закрывается, а показать сессию кому-то означает демонстрацию экрана. Пространство на задачу, или каталог для всех Conductor изолирует каждого агента в своём пространстве, со своей веткой и diff, а вы собираете всё при слиянии. Murmell не создаёт копий: столкновение отклоняется в момент записи. Механизм. Что выбрать Conductor для одного разработчика на Mac, чей код не выходит наружу. Murmell, когда сессия коллективная, а агенты работают в одном углу проекта. --- ## Murmell vs Conductor Source: https://murmell.com/vs/conductor The real difference Conductor describes itself as a way to “run parallel Claude Code, Codex, and Cursor agents in isolated workspaces on your Mac”, and its documentation says each task gets its own workspace, branch, files, terminal, diff and review path. Every agent is separated from every other one, and you bring the results together yourself when you merge. Murmell keeps one set of files. Agents claim a path before they write to it, the board keeps one holder per path and refuses everyone else until it is released, and a colliding write is snapshotted rather than lost. There is no merge at the end because there was no branch at the start. Where the work runs matters as much as how it is split. Conductor uses your laptop, so the agents stop when it sleeps. Murmell agents run on cloud machines: close the tab, close the lid, and the terminals carry on. Come back and the output is there, and so is anyone else you gave a link to, with a name and a color on their cursor. Where Conductor wins Your code never leaves your machine. There is no upload, no cloud account and no third party in the path between the agent and your files, and everything your local network can reach the agent can reach too. For a lot of teams that ends the security conversation before it starts, and Murmell has no self-hosted option to answer it with. It is also a native app, so it is quick, it works with the local tools you already have installed, and reviewing several diffs next to each other is the thing it was built to do well. Which to pick Pick Conductor when you work alone, the code should stay on your disk, and separate workspaces are the right way to keep agents out of each other’s way. Pick Murmell when the agents need to be in the same tree, when the work should survive your laptop closing, or when somebody else should be watching it happen. Every project gets a private repository, pushed to as the work goes and once more before a machine is torn down. See how several agents work in one repository. --- ## Murmell 对比 Conductor Source: https://murmell.com/zh/vs/conductor 在自己硬盘上,还是在租用的机器上 Conductor 认定本地就是答案:应用在你的 Mac 上,文件也在,什么都不经过网络。这是这次对比里最硬的论点,在内部政策要求这样做的时候没有讨论余地。 本地的代价是在场:机器一关,工作就停了,想给别人展示一次会话就得共享屏幕。 一个任务一个空间,还是所有人一个目录 Conductor 把每个代理隔离在自己的空间里,各自有分支和 diff,合并时再汇总。Murmell 不制造拷贝:冲突在写入那一刻就被拒绝。机制说明。 选哪个 独自在 Mac 上工作、代码不能外传,选 Conductor。会话是团体性的、代理们在项目的同一个角落工作,选 Murmell。 --- ## Murmell gegenüber GitHub Copilot und Agent HQ Source: https://murmell.com/de/vs/github-copilot Der eigentliche Unterschied GitHub ist klar bei der Arbeitseinheit: ein Branch, eine flüchtige Umgebung, eine Pull-Request pro Aufgabe. Der Kommandoposten dient zum Verteilen und Verfolgen. Alles läuft bei der Durchsicht zusammen, was zu einem Produkt passt, dessen Kern die Durchsicht seit fünfzehn Jahren ist. Murmell lässt es früher zusammenlaufen. Die Agenten gehen nicht jeder für sich: Sie sind im selben Verzeichnis, und der Konflikt wird vor dem Schreiben gelöst statt danach. Was bei der Durchsicht ankommt, ist bereits ein einziger Zustand. Was man sieht Eine Pull-Request zeigt das Ergebnis. Eine Canvas zeigt die Herstellung: die Terminals, die Fehler, die Neuanläufe, und die anwesenden Personen. Für ein Pair oder um jemandem eine Methode zu zeigen, ist das nicht dasselbe. Welches nehmen Copilot und Agent HQ, wenn Ihre Aufgaben unabhängig sind, in Tickets verfolgt werden, und die Durchsicht der richtige Termin ist. Murmell, wenn mehrere Agenten in derselben Ecke des Codes zur selben Zeit arbeiten müssen. Wie der Konflikt geschlichtet wird. --- ## Murmell frente a GitHub Copilot y Agent HQ Source: https://murmell.com/es/vs/github-copilot La diferencia real GitHub es claro sobre la unidad de trabajo: una rama, un entorno efímero, una pull request por tarea. El puesto de mando sirve para repartir y seguir. Todo converge en la revisión, lo que es coherente con un producto cuyo corazón es la revisión desde hace quince años. Murmell hace converger antes. Los agentes no parten cada uno por su lado: están en el mismo directorio, y el conflicto se resuelve antes de escribir en vez de después. Lo que llega a la revisión ya es un único estado. Lo que se ve Una pull request muestra el resultado. Un canvas muestra la fabricación: las terminales, los errores, los reintentos, y la gente presente. Para trabajar en pareja o para mostrarle un método a alguien, no es lo mismo. Cuál elegir Copilot y Agent HQ cuando tus tareas son independientes, están registradas en tickets, y la revisión es la cita correcta. Murmell cuando varios agentes deben trabajar en el mismo rincón del código al mismo tiempo. Cómo se arbitra el conflicto. --- ## Murmell face à GitHub Copilot et Agent HQ Source: https://murmell.com/fr/vs/github-copilot La vraie différence GitHub est clair sur l'unité de travail : une branche, un environnement éphémère, une pull request par tâche. Le poste de commande sert à distribuer et à suivre. Tout converge à la relecture, ce qui est cohérent avec un produit dont la relecture est le cœur depuis quinze ans. Murmell fait converger plus tôt. Les agents ne partent pas chacun de leur côté : ils sont dans le même dossier, et le conflit se règle avant l'écriture plutôt qu'après. Ce qui arrive à la relecture est déjà un état unique. Ce qui se voit Une pull request montre le résultat. Un canvas montre la fabrication : les terminaux, les erreurs, les reprises, et les gens présents. Pour un binôme ou pour montrer une méthode à quelqu'un, ce n'est pas la même chose. Lequel prendre Copilot et Agent HQ quand vos tâches sont indépendantes, tracées par des tickets, et que la relecture est le bon rendez-vous. Murmell quand plusieurs agents doivent travailler dans le même coin du code au même moment. Comment le conflit est arbitré. --- ## GitHub Copilot और Agent HQ के मुकाबले Murmell Source: https://murmell.com/hi/vs/github-copilot असली फ़र्क़ GitHub काम की इकाई पर साफ़ है: एक ब्रांच, एक अस्थायी वातावरण, सौंपे गए हर काम के लिए एक pull request। कमांड सेंटर बांटने और नज़र रखने के काम आता है। सब कुछ रिव्यू पर मिलता है, जो उस उत्पाद के मुताबिक ही है जिसका दिल पंद्रह साल से रिव्यू ही रहा है। Murmell पहले ही मिला देता है। एजेंट अलग-अलग नहीं जाते: वे एक ही फ़ोल्डर में होते हैं, और टकराव बाद की बजाय लिखने से पहले सुलझ जाता है। रिव्यू तक जो पहुंचता है वह पहले से एक ही स्थिति होती है। जो दिखता है एक pull request नतीजा दिखाता है। एक कैनवस बनने की प्रक्रिया दिखाता है: टर्मिनल, गलतियां, फिर से कोशिशें, और मौजूद लोग। किसी जोड़ी के लिए, या किसी को तरीका दिखाने के लिए, यह एक जैसी बात नहीं है। कौन सा लें Copilot और Agent HQ तब जब आपके काम स्वतंत्र हों, टिकट से ट्रैक किए जाते हों, और रिव्यू सही मौका हो। Murmell तब जब कई एजेंट को एक ही समय कोड के एक ही कोने में काम करना हो। टकराव कैसे सुलझाया जाता है। --- ## Murmell contro GitHub Copilot e Agent HQ Source: https://murmell.com/it/vs/github-copilot La vera differenza GitHub è chiaro sull'unità di lavoro: un branch, un ambiente effimero, una pull request per compito. Il posto di comando serve a distribuire e a seguire. Tutto converge alla revisione, il che è coerente con un prodotto la cui revisione è il cuore da quindici anni. Murmell fa convergere prima. Gli agenti non partono ciascuno per conto proprio: sono nella stessa cartella, e il conflitto si risolve prima della scrittura invece che dopo. Quello che arriva alla revisione è già uno stato unico. Cosa si vede Una pull request mostra il risultato. Un canvas mostra la lavorazione: i terminali, gli errori, le riprese, e le persone presenti. Per lavorare in coppia o per mostrare un metodo a qualcuno non è la stessa cosa. Quale scegliere Copilot e Agent HQ quando i tuoi compiti sono indipendenti, tracciati da ticket, e la revisione è l'appuntamento giusto. Murmell quando più agenti devono lavorare nello stesso angolo di codice nello stesso momento. Come viene arbitrato il conflitto. --- ## MurmellとGitHub Copilot、Agent HQの比較 Source: https://murmell.com/ja/vs/github-copilot 本当の違い GitHubは作業の単位について明確です。ブランチ、使い捨て環境、タスクごとに1つのプルリクエスト。 コマンドセンターは配布と追跡に使います。すべてがレビューの時点で収束し、これはレビューが15年間 中心だった製品として一貫しています。 Murmellはもっと早く収束させます。エージェントはそれぞれ別の場所に向かうのではなく、同じディレクトリ の中にいます。衝突は後ではなく、書き込みの前に解決されます。レビューに来るものはすでに1つの状態です。 見えるもの プルリクエストは結果を示します。キャンバスは製作過程を示します。ターミナル、エラー、やり直し、 そして居合わせる人々です。ペアプログラミングや、誰かにやり方を見せる場面では、これは同じこと ではありません。 どちらを選ぶか タスクが独立していて、チケットで追跡され、レビューが正しい約束の場であるならCopilotとAgent HQ です。複数のエージェントが同じ時間に同じコードの一角で作業する必要があるならMurmellです。 競合がどう調停されるか。 --- ## Murmell과 GitHub Copilot, Agent HQ 비교 Source: https://murmell.com/ko/vs/github-copilot 진짜 차이 GitHub는 작업 단위를 명확히 합니다. 브랜치 하나, 일회용 환경 하나, 작업마다 풀 리퀘스트 하나. 지휘 본부는 배정하고 추적하는 역할을 합니다. 모든 것이 리뷰에서 수렴하며, 이는 리뷰가 15년 동안 핵심이었던 제품과 일관됩니다. Murmell은 더 일찍 수렴합니다. 에이전트들은 각자 따로 가지 않습니다. 같은 디렉터리 안에 있고, 충돌은 이후가 아니라 쓰기 전에 해결됩니다. 리뷰에 도착하는 것은 이미 하나의 상태입니다. 눈에 보이는 것 풀 리퀘스트는 결과를 보여줍니다. 캔버스는 만들어지는 과정을 보여줍니다. 터미널, 오류, 재시도, 그리고 함께 있는 사람들까지요. 페어 작업이나 누군가에게 방법을 보여줄 때는 이것이 같은 것이 아닙니다. 어느 것을 고를지 작업이 독립적이고, 티켓으로 추적되며, 리뷰가 알맞은 약속일 때는 Copilot과 Agent HQ입니다. 여러 에이전트가 같은 순간 같은 코드 구역에서 작업해야 할 때는 Murmell입니다. 충돌이 어떻게 조정되는지. --- ## Murmell frente ao GitHub Copilot e Agent HQ Source: https://murmell.com/pt/vs/github-copilot A diferença real O GitHub é claro sobre a unidade de trabalho: uma branch, um ambiente efêmero, uma pull request por tarefa. O painel de controle serve para distribuir e acompanhar. Tudo converge na revisão, o que é coerente com um produto cujo coração é a revisão há quinze anos. Murmell faz convergir mais cedo. Os agentes não partem cada um para seu lado: eles estão no mesmo diretório, e o conflito se resolve antes da escrita em vez de depois. O que chega na revisão já é um único estado. O que se vê Uma pull request mostra o resultado. Um canvas mostra a fabricação: os terminais, os erros, as tentativas, e as pessoas presentes. Para uma dupla ou para mostrar um método a alguém, não é a mesma coisa. Qual escolher Copilot e Agent HQ quando suas tarefas são independentes, rastreadas por tickets, e a revisão é o encontro certo. Murmell quando vários agentes precisam trabalhar no mesmo canto do código ao mesmo tempo. Como o conflito é arbitrado. --- ## Murmell против GitHub Copilot и Agent HQ Source: https://murmell.com/ru/vs/github-copilot Настоящая разница GitHub чётко определяет единицу работы: одна ветка, одно одноразовое окружение, один pull request на задачу. Командный центр служит для распределения и отслеживания. Всё сходится при ревью, что согласуется с продуктом, для которого ревью было ядром пятнадцать лет. Murmell сходится раньше. Агенты не расходятся каждый в свою сторону: они в одном каталоге, и конфликт решается до записи, а не после. То, что приходит на ревью, уже единое состояние. Что видно Pull request показывает результат. Канвас показывает процесс создания: терминалы, ошибки, повторные попытки и присутствующих людей. Для парной работы или чтобы показать кому-то метод, это не одно и то же. Что выбрать Copilot и Agent HQ, когда ваши задачи независимы, отслеживаются тикетами, а ревью, подходящая точка встречи. Murmell, когда нескольким агентам нужно работать в одном участке кода в один и тот же момент. Как решается конфликт. --- ## Murmell vs GitHub Copilot and Agent HQ Source: https://murmell.com/vs/github-copilot The real difference GitHub is explicit about the unit of work. The Copilot coding agent has “its own ephemeral development environment, powered by GitHub Actions”, it “can only work on one branch at a time”, and it “can open exactly one pull request to address each task it is assigned”. Mission control then lets you “choose from a fleet of agents, assign them work in parallel, and track their progress from any device”. Parallel means many branches at once, and everything converges at review. Murmell converges earlier. Agents work in one checkout on one cloud machine and claim a path before writing to it, so the collision is settled while it is still a question of whose turn it is rather than a question of which diff survives. A colliding write is snapshotted before it lands. The other gap is the watching. Agent HQ tracks progress; Murmell shows the terminal. Send a read link and someone sees the actual output scrolling, which window each person is looking at, and a named cursor for each of them. Where Agent HQ wins It is already where your code lives. Branch controls, rulesets, required checks, identity and org policy all apply to agents the same way they apply to people, and nobody has to configure a second place for any of it. GitHub puts it as “agents and developers building together, on the infrastructure you already trust”, and that is a genuine advantage that no separate product can copy. It also lets you bring several vendors’ agents into one interface, give them a persona from a file in the repository, and run them on your own runners. If your governance story has to be one story, Agent HQ is that story. Which to pick Pick Copilot and Agent HQ for work that decomposes into issues, where the review process is the product and each agent can be left alone on a branch until it is done. Pick Murmell for the hour where several agents have to move through the same files together, or where a colleague needs to be looking at the run with you. It sits before the pull request rather than instead of it. See how several agents work in one repository. --- ## Murmell 对比 GitHub Copilot 与 Agent HQ Source: https://murmell.com/zh/vs/github-copilot 真正的区别 GitHub 把工作单位说得很清楚:一个分支,一个一次性环境,每个任务一个 pull request。指挥台负责分配和追踪。一切都在审阅这一步汇合,这和一个把审阅当作核心已经做了十五年的产品是一致的。 Murmell 让汇合发生得更早。代理不是各走各的:他们在同一个目录里,冲突在写入之前就被解决,而不是之后。到审阅那一步时,呈现的已经是一个统一的状态。 能看到什么 一个 pull request 展示结果。一块画布展示制作过程:终端、报错、重试,以及在场的人。对结对编程,或者向别人演示一种方法来说,这完全是两回事。 选哪个 任务互相独立、由工单追踪、审阅是合适的交接点时,选 Copilot 和 Agent HQ。多个代理需要在同一时间处理代码库的同一个角落时,选 Murmell。冲突是怎么被仲裁的。 --- ## Murmell gegenüber Cursor Source: https://murmell.com/de/vs/cursor Der eigentliche Unterschied Cursor beschreibt sein Modell unumwunden: Die Agenten laufen in isolierten Maschinen mit einer vollständigen Umgebung statt auf Ihrem Laptop, klonen das Repository, arbeiten auf einem separaten Branch und pushen zur Weiterführung. Sie starten so viele, wie Sie wollen. Die Isolierung macht das sicher, und der Branch ist der Ort, an dem die Arbeit wartet. Murmell entfernt die Kopien. Die Agenten teilen sich eine einzige Arbeitskopie, und ein Agent reserviert einen Pfad, bevor er hineinschreibt. Das Board hält einen Inhaber pro Pfad und verweigert alle anderen, bis er ihn freigibt. Am Ende gibt es nichts zusammenzuführen, weil am Anfang nichts auseinandergelaufen ist. Der zweite Unterschied betrifft die Menschen, nicht die Agenten. Cursor ist ein Editor pro Person, und das Ergebnis wird geteilt, nachdem es existiert. Eine Murmell-Canvas versammelt mehrere Personen, während die Arbeit läuft. Wo Cursor gewinnt Die Bearbeitung, und das ist nicht knapp. Die Autovervollständigung, die Inline-Änderungen und die gesamte Oberfläche des handgeschriebenen Codes gehören Cursor, und Murmell tritt dagegen nicht an. Cursor weiß auch, wie man diese Agenten im eigenen Netzwerk laufen lässt. Murmell hat keine selbst gehostete Option: Wenn Ihr Code nicht raus darf, ist die Frage geklärt. Welches nehmen Cursor, wenn Sie selbst schreiben, oder wenn die Antwort auf „mehr Arbeit" lautet „mehr unabhängige Agenten, jeder auf seinem Branch". Murmell, wenn mehrere Agenten dieselben Dateien innerhalb derselben Stunde anfassen müssen, oder wenn es nützlich ist, dass andere die Sitzung ansehen, statt später den Diff durchzugehen. Sehen, was die Canvas macht. --- ## Murmell frente a Cursor Source: https://murmell.com/es/vs/cursor La diferencia real Cursor describe su modelo sin rodeos: los agentes corren en máquinas aisladas con un entorno completo en vez de en tu portátil, clonan el repositorio, trabajan en una rama separada y envían el resultado para retomarlo. Lanzas los que quieras. El aislamiento es lo que hace eso seguro, y la rama es el lugar donde el trabajo espera. Murmell elimina las copias. Los agentes comparten una sola copia de trabajo, y un agente reserva una ruta antes de escribir en ella. El tablero mantiene un titular por ruta y niega a todos los demás hasta que la libera. Nada se fusiona al final porque nada divergió al principio. La segunda diferencia es sobre las personas, no sobre los agentes. Cursor es un editor por persona, y el resultado se comparte una vez que existe. Un canvas de Murmell contiene a varias personas mientras el trabajo se hace. Dónde gana Cursor La edición, y no por poco. El autocompletado, las ediciones en línea y toda la superficie de escribir código a mano pertenecen a Cursor, y Murmell no compite en eso. Cursor también hace correr esos agentes dentro de tu propia red. Murmell no tiene opción auto-hospedada: si tu código no puede salir, la pregunta está resuelta. Cuál elegir Cursor cuando escribes tú mismo, o cuando la respuesta a "más trabajo" es "más agentes independientes, cada uno en su rama". Murmell cuando varios agentes tienen que tocar los mismos archivos en la misma hora, o cuando lo útil es que otros miren la sesión en vez de leer el diff después. Ver qué hace el canvas. --- ## Murmell face à Cursor Source: https://murmell.com/fr/vs/cursor La vraie différence Cursor décrit son modèle sans détour : les agents tournent dans des machines isolées avec un environnement complet plutôt que sur votre portable, ils clonent le dépôt, travaillent sur une branche séparée et poussent pour reprise. Vous en lancez autant que vous voulez. L'isolation est ce qui rend la chose sûre, et la branche est l'endroit où le travail attend. Murmell supprime les copies. Les agents partagent une seule copie de travail, et un agent réserve un chemin avant d'y écrire. Le tableau tient un détenteur par chemin et refuse tous les autres jusqu'à ce qu'il le rende. Rien ne fusionne à la fin parce que rien n'a divergé au début. La deuxième différence concerne les gens, pas les agents. Cursor, c'est un éditeur par personne, et le résultat se partage une fois qu'il existe. Un canvas Murmell contient plusieurs personnes pendant que le travail se fait. Là où Cursor gagne L'édition, et ce n'est pas serré. La complétion, les modifications en ligne et toute la surface de l'écriture à la main appartiennent à Cursor, et Murmell ne se bat pas là-dessus. Cursor sait aussi faire tourner ces agents à l'intérieur de votre réseau. Murmell n'a pas d'option auto-hébergée : si votre code n'a pas le droit de sortir, la question est réglée. Lequel prendre Cursor quand c'est vous qui écrivez, ou quand la réponse à « plus de travail » est « plus d'agents indépendants, chacun sur sa branche ». Murmell quand plusieurs agents doivent toucher les mêmes fichiers dans la même heure, ou quand l'utile est que d'autres regardent la séance plutôt qu'ils relisent le diff. Découvrez notre canvas multi-agents, voyez comment plusieurs agents partagent un même dépôt, ou lancez Claude Code et Codex dans le cloud. --- ## Cursor के मुकाबले Murmell Source: https://murmell.com/hi/vs/cursor असली फ़र्क़ Cursor अपना मॉडल सीधे बताता है: एजेंट अलग मशीनों में पूरे वातावरण के साथ चलते हैं, आपके लैपटॉप की बजाय, वे रिपॉज़िटरी क्लोन करते हैं, एक अलग ब्रांच पर काम करते हैं और आगे लेने के लिए push करते हैं। आप जितने चाहें उतने चला सकते हैं। अलगाव ही इसे सुरक्षित बनाता है, और ब्रांच वह जगह है जहां काम इंतज़ार करता है। Murmell कॉपियां हटा देता है। एजेंट एक ही वर्किंग कॉपी साझा करते हैं, और लिखने से पहले एजेंट एक रास्ता आरक्षित करता है। बोर्ड हर रास्ते का एक मालिक रखता है और जब तक वह उसे छोड़ न दे बाकी सबको मना कर देता है। आख़िर में कुछ मर्ज नहीं होता क्योंकि शुरुआत में कुछ अलग हुआ ही नहीं। दूसरा फ़र्क़ एजेंट का नहीं, लोगों का है। Cursor हर व्यक्ति के लिए एक एडिटर है, और नतीजा बनने के बाद साझा होता है। Murmell का कैनवस काम होते समय ही कई लोगों को साथ रखता है। जहां Cursor जीतता है एडिटिंग, और यह करीबी मुकाबला नहीं है। ऑटो-कम्प्लीट, इनलाइन बदलाव और हाथ से लिखने की पूरी सतह Cursor की है, और Murmell इस पर नहीं लड़ता। Cursor अपने नेटवर्क के अंदर भी ये एजेंट चला सकता है। Murmell का कोई सेल्फ़-होस्टेड विकल्प नहीं है: अगर आपके कोड को बाहर जाने का हक़ नहीं, तो सवाल सुलझ गया। कौन सा लें Cursor तब जब कोड आप लिखते हैं, या जब "ज़्यादा काम" का जवाब "ज़्यादा स्वतंत्र एजेंट, हर एक अपनी ब्रांच पर" हो। Murmell तब जब कई एजेंट को एक ही घंटे में एक ही फ़ाइलों को छूना हो, या जब फ़ायदा diff पढ़ने की बजाय दूसरों के सेशन देखने में हो। देखें कैनवस क्या करता है। --- ## Murmell contro Cursor Source: https://murmell.com/it/vs/cursor La vera differenza Cursor descrive il proprio modello senza giri di parole: gli agenti girano in macchine isolate con un ambiente completo invece che sul tuo portatile, clonano il repository, lavorano su un branch separato e inviano per la ripresa. Ne lanci quanti vuoi. L'isolamento è ciò che rende la cosa sicura, e il branch è dove il lavoro aspetta. Murmell elimina le copie. Gli agenti condividono un'unica copia di lavoro, e un agente riserva un percorso prima di scriverci. La bacheca tiene un titolare per percorso e nega tutti gli altri finché non lo rilascia. Nulla fonde alla fine perché nulla è divergente all'inizio. La seconda differenza riguarda le persone, non gli agenti. Cursor è un editor a persona, e il risultato si condivide una volta che esiste. Un canvas Murmell contiene più persone mentre il lavoro si fa. Dove vince Cursor L'editing, e non di poco. Il completamento, le modifiche in linea e tutta la superficie della scrittura a mano appartengono a Cursor, e Murmell non si batte su quel terreno. Cursor sa anche far girare questi agenti dentro la tua rete. Murmell non ha opzione self-hosted: se il tuo codice non può uscire, la domanda è già risolta. Quale scegliere Cursor quando scrivi tu stesso, o quando la risposta a "più lavoro" è "più agenti indipendenti, ciascuno sul proprio branch". Murmell quando più agenti devono toccare gli stessi file nella stessa ora, o quando è utile che altri guardino la sessione invece di rileggere il diff. Guarda cosa fa il canvas. --- ## MurmellとCursorの比較 Source: https://murmell.com/ja/vs/cursor 本当の違い Cursorは自分のモデルを率直に説明しています。エージェントはノートパソコンではなく、完全な環境を 持つ隔離されたマシンで動き、リポジトリをクローンし、分離されたブランチで作業し、再開のために プッシュします。好きなだけ起動できます。隔離がこれを安全にし、ブランチが作業の待機場所になります。 Murmellはコピーをなくします。エージェントは1つの作業コピーを共有し、書き込む前にパスを確保します。 ボードはパスごとに1人の所有者を保持し、解放されるまで他の全員を拒否します。最初に何も分岐しなかった ので、最後に何もマージしません。 2つ目の違いは、エージェントではなく人に関するものです。Cursorは1人1エディタで、結果はできてから 共有されます。Murmellのキャンバスは、作業が行われている間に複数の人を含みます。 Cursorが勝る場所 編集で、それも僅差ではありません。補完、インライン編集、手書きのあらゆる面はCursorのものであり、 Murmellはそこでは戦いません。Cursorはこれらのエージェントをあなたのネットワークの中で動かすこと もできます。Murmellには自己ホスト型の選択肢がありません。コードが外に出せないなら、その問いは すでに答えが出ています。 どちらを選ぶか 自分で書くとき、あるいは「もっと作業を」への答えが「もっと独立したエージェントを、それぞれ自分の ブランチで」であるときはCursorです。 複数のエージェントが同じ1時間の中で同じファイルに触れる必要があるとき、あるいは他の人がdiffを 読み返すのではなくセッションを見ることが有用なときはMurmellです。キャンバスの機能 を見る。 --- ## Murmell과 Cursor 비교 Source: https://murmell.com/ko/vs/cursor 진짜 차이 Cursor는 자신의 모델을 솔직하게 설명합니다. 에이전트는 여러분의 노트북이 아니라 완전한 환경을 가진 격리된 머신에서 실행되며, 저장소를 클론하고, 분리된 브랜치에서 작업하고, 재개를 위해 푸시합니다. 원하는 만큼 실행할 수 있습니다. 격리가 이를 안전하게 만들고, 브랜치는 작업이 기다리는 장소입니다. Murmell은 복사본을 없앱니다. 에이전트는 하나의 작업 복사본을 공유하고, 쓰기 전에 경로를 점유합니다. 보드는 경로마다 소유자 한 명을 유지하고, 놓아줄 때까지 나머지 모두를 거부합니다. 처음부터 아무것도 갈라지지 않았으니, 마지막에 병합할 것도 없습니다. 두 번째 차이는 에이전트가 아니라 사람에 관한 것입니다. Cursor는 한 사람에 하나의 에디터고, 결과는 만들어진 뒤에 공유됩니다. Murmell 캔버스는 작업이 진행되는 동안 여러 사람을 담습니다. Cursor가 이기는 지점 편집이고, 큰 차이로 이깁니다. 자동완성, 인라인 수정, 손으로 쓰는 모든 면은 Cursor의 영역이며, Murmell은 거기서 경쟁하지 않습니다. Cursor는 이 에이전트들을 여러분의 네트워크 안에서도 실행할 수 있습니다. Murmell에는 자체 호스팅 옵션이 없습니다. 코드가 밖으로 나갈 수 없다면 질문은 이미 답이 나온 것입니다. 어느 것을 고를지 직접 코드를 쓸 때, 또는 "더 많은 작업"에 대한 답이 "각자 자기 브랜치를 가진 더 많은 독립 에이전트"일 때는 Cursor입니다. 여러 에이전트가 같은 한 시간 안에 같은 파일을 건드려야 할 때, 또는 다른 사람들이 diff를 다시 읽기보다 세션을 지켜보는 것이 유용할 때는 Murmell입니다. 캔버스가 무엇을 하는지 보기. --- ## Murmell frente ao Cursor Source: https://murmell.com/pt/vs/cursor A diferença real O Cursor descreve seu modelo sem rodeios: os agentes rodam em máquinas isoladas com um ambiente completo em vez do seu notebook, clonam o repositório, trabalham em uma branch separada e enviam para retomada. Você inicia quantos quiser. O isolamento é o que torna isso seguro, e a branch é o lugar onde o trabalho espera. Murmell elimina as cópias. Os agentes compartilham uma única cópia de trabalho, e um agente reserva um caminho antes de escrever nele. O painel mantém um titular por caminho e nega todos os outros até que ele o libere. No final não há nada para fundir porque nada divergiu no início. A segunda diferença é sobre as pessoas, não sobre os agentes. Cursor é um editor por pessoa, e o resultado se compartilha depois que existe. Um canvas do Murmell reúne várias pessoas enquanto o trabalho está sendo feito. Onde o Cursor ganha A edição, e não por pouco. O autocompletar, as edições em linha e toda a superfície de escrever código à mão pertencem ao Cursor, e Murmell não compete nisso. O Cursor também sabe rodar esses agentes dentro da sua própria rede. Murmell não tem opção auto-hospedada: se o seu código não pode sair, a questão está resolvida. Qual escolher Cursor quando é você quem escreve, ou quando a resposta para "mais trabalho" é "mais agentes independentes, cada um na sua branch". Murmell quando vários agentes precisam tocar nos mesmos arquivos na mesma hora, ou quando o útil é que outros assistam à sessão em vez de revisar o diff depois. Veja o que o canvas faz. --- ## Murmell против Cursor Source: https://murmell.com/ru/vs/cursor Настоящая разница Cursor описывает свою модель без обиняков: агенты работают на изолированных машинах с полным окружением вместо вашего ноутбука, клонируют репозиторий, работают на отдельной ветке и отправляют результат для продолжения. Вы запускаете сколько хотите. Изоляция делает это безопасным, а ветка, место, где работа ждёт. Murmell убирает копии. Агенты делят одну рабочую копию, и агент резервирует путь перед тем, как в него писать. Доска держит одного владельца на путь и отказывает всем остальным, пока он его не отпустит. В конце ничего не сливается, потому что вначале ничего не разошлось. Второе отличие касается людей, а не агентов. Cursor, это редактор на человека, и результат делится, когда он уже существует. Канвас Murmell содержит несколько людей, пока работа выполняется. Где выигрывает Cursor Редактирование, и с большим отрывом. Автодополнение, встроенные правки и вся поверхность ручного письма принадлежат Cursor, и Murmell там не конкурирует. Cursor также умеет запускать этих агентов внутри вашей сети. У Murmell нет опции самостоятельного хостинга: если ваш код не имеет права выходить наружу, вопрос уже решён. Что выбрать Cursor, когда пишете вы сами, или когда ответ на «больше работы», это «больше независимых агентов, каждый на своей ветке». Murmell, когда нескольким агентам нужно затронуть одни и те же файлы в один и тот же час, или когда полезнее, чтобы другие наблюдали за сессией, а не перечитывали diff. Посмотреть, что делает канвас. --- ## Murmell vs Cursor Source: https://murmell.com/vs/cursor The real difference Cursor documents the cloud model plainly: agents “run in isolated VMs in the cloud with full development environments instead of on your local machine”, and they “clone your repo from GitHub, GitLab, Azure DevOps Services, or Bitbucket Cloud and work on a separate branch, then push changes to your repo for handoff”. You can run as many in parallel as you like. Isolation is what makes that safe, and a branch is where the work waits for you. Murmell removes the copies. Agents share one checkout, and an agent claims a path before it writes to it. The board keeps one holder per path and refuses everyone else until that holder releases it. Nothing merges at the end because nothing forked at the start. The second difference is about people rather than agents. Cursor is one editor per person, and agent output is shared once it exists. A Murmell canvas has more than one person in it while the work happens. Guests see the windows, the terminal contents and where everyone is looking, with a color and a name on each cursor. Where Cursor wins The editing itself, which is not close. Tab completion, inline edits and the whole surface of writing code by hand belong to Cursor, and Murmell does not compete for that work. Cursor also gives its cloud agents a remote desktop, so you can use the changed software and edit it yourself without checking the branch out locally. And it will run those agents inside your own network. Cursor made self-hosted cloud agents generally available, with a worker process that “connects outbound via HTTPS to Cursor’s cloud” and no inbound ports to open. Murmell has no self-hosted option today. If your code is not allowed to leave your infrastructure, that decides it. Which to pick Pick Cursor when you are the one writing, or when the answer to more work is more independent agents each on their own branch. Pick Murmell when several agents have to touch the same files in the same hour, or when the useful thing is other people watching the run rather than reading the diff. Murmell launches the Claude Code and Codex CLIs on its own machines within the multi-agent canvas. See how several agents work in one repository, or explore multiplayer coding with AI agents. --- ## Murmell 对比 Cursor Source: https://murmell.com/zh/vs/cursor 真正的区别 Cursor 把自己的模式说得很直白:代理运行在隔离机器上,拥有完整环境,而不是在你的笔记本上;它们克隆仓库,在独立分支上工作,推送回来等你接手。你想开多少个都行。隔离让这一切变得安全,分支是工作等待的地方。 Murmell 去掉了拷贝这一步。代理共用同一份工作副本,写入前先占用要动的路径。看板保证每个路径只有一个持有者,并拒绝所有其他人,直到它被释放。结尾不需要合并,因为一开始就没有分叉。 第二个区别关于人,不是代理。Cursor 是一人一个编辑器,结果做出来之后才分享。Murmell 的一块画布在工作进行的过程中就容纳多个人。 Cursor 更强的地方 编辑体验,而且差距不小。补全、行内修改,以及手写代码的整个表面都属于 Cursor,Murmell 不在这方面竞争。Cursor 也能让这些代理运行在你自己的网络内部。Murmell 没有自托管选项:如果你的代码不允许离开内网,这个问题在这里就有了答案。 选哪个 你自己动手写代码,或者"要干更多活"这个问题的答案是"更多互相独立、各自在自己分支上的代理"时,选 Cursor。 多个代理需要在同一个小时内碰同样的文件,或者价值在于让别人旁观整个过程而不是事后读 diff 时,选 Murmell。查看多个代理如何共用同一个仓库。。 --- ## Murmell gegenüber Devin Source: https://murmell.com/de/vs/devin Zwei Wege, schneller zu werden Devin skaliert durch Trennung. Wenn eine Aufgabe groß ist, delegiert es an weitere Devin-Instanzen, jede in ihrer isolierten Maschine, und eine koordinierende Sitzung zerlegt und fügt danach zusammen. Das ist sauber und braucht keine Schlichtung: Zwei Agenten, die nichts teilen, können sich nicht stören. Murmell skaliert durch Teilen. Ein Verzeichnis, mehrere Agenten, und eine vom Server durchgesetzte Schreibregel. Am Ende gibt es nichts zusammenzuführen, weil es immer nur einen Zustand gab. Was jede Form kostet Die Trennung kostet beim Zusammennähen: Je mehr Agenten, desto mehr Ergebnisse müssen zusammenpassen, und Unverträglichkeiten zeigen sich spät. Das Teilen kostet beim Warten: Ein Agent, der eine von einem anderen gehaltene Datei will, wartet, und dieses Warten ist auf dem Bildschirm sichtbar. Das sichtbare Warten ist das bessere der beiden Probleme. Man löst es, indem man dem blockierten Agenten sofort eine andere Aufgabe gibt, statt einen Konflikt eine Stunde später zu entdecken. Welches nehmen Devin, wenn Sie ein Ticket delegieren und zu einem Ergebnis zurückkehren wollen. Murmell, wenn Sie während der Arbeit dabei sein wollen, mit mehreren Agenten am selben Code und Leuten, die zusehen. Die Canvas ansehen. --- ## Murmell frente a Devin Source: https://murmell.com/es/vs/devin Dos formas de ir más rápido Devin escala por separación. Cuando una tarea es grande, delega en otros Devin, cada uno en su máquina aislada, y una sesión coordinadora divide y luego reúne. Es limpio, y no exige ningún arbitraje: dos agentes que no comparten nada no pueden estorbarse. Murmell escala por reparto. Un directorio, varios agentes, y una regla de escritura aplicada por el servidor. No hay nada que reunir al final porque nunca hubo más que un estado. Lo que cuesta cada forma La separación cuesta en la costura: cuantos más agentes, más resultados que hacer encajar, y las incompatibilidades aparecen tarde. El reparto cuesta en la espera: un agente que quiere un archivo que tiene otro espera, y esa espera es visible en pantalla. La espera visible es el mejor de los dos problemas. Se resuelve dándole otra tarea al agente atascado, de inmediato, en vez de descubrir un conflicto una hora después. Cuál elegir Devin cuando quieres confiar un ticket y volver ante un resultado. Murmell cuando quieres estar presente durante, con varios agentes en el mismo código y gente mirando. Ver el canvas. --- ## Murmell face à Devin Source: https://murmell.com/fr/vs/devin Deux façons d'aller plus vite Devin passe à l'échelle par séparation. Quand une tâche est grosse, il délègue à d'autres Devin, chacun dans sa machine isolée, et une session coordinatrice découpe puis rassemble. C'est propre, et ça ne demande aucun arbitrage : deux agents qui ne partagent rien ne peuvent pas se gêner. Murmell passe à l'échelle par partage. Un dossier, plusieurs agents, et une règle d'écriture appliquée par le serveur. Il n'y a rien à rassembler à la fin parce qu'il n'y a jamais eu qu'un état. Ce que chaque forme coûte La séparation coûte à la couture : plus il y a d'agents, plus il y a de résultats à faire tenir ensemble, et les incompatibilités apparaissent tard. Le partage coûte à l'attente : un agent qui veut un fichier tenu par un autre attend, et cette attente est visible à l'écran. L'attente visible est le meilleur des deux problèmes. Elle se règle en donnant une autre tâche à l'agent bloqué, tout de suite, au lieu de découvrir un conflit une heure plus tard. Lequel prendre Devin quand vous voulez confier un ticket et revenir devant un résultat. Murmell quand vous voulez être là pendant, avec plusieurs agents sur le même code et des gens qui regardent. Voir le canvas. --- ## Devin के मुकाबले Murmell Source: https://murmell.com/hi/vs/devin तेज़ जाने के दो तरीके Devin अलगाव से बड़े होते जाते हैं। जब कोई काम बड़ा हो, यह दूसरे Devin को सौंपता है, हर एक अपनी अलग मशीन में, और एक समन्वय करने वाला सेशन बांटता और फिर इकट्ठा करता है। यह साफ़-सुथरा है, और इसे किसी arbiter की ज़रूरत नहीं: दो एजेंट जो कुछ भी साझा नहीं करते, वे एक-दूसरे को परेशान नहीं कर सकते। Murmell साझा करने से बड़ा होता है। एक फ़ोल्डर, कई एजेंट, और सर्वर का लागू किया लेखन नियम। आख़िर में कुछ इकट्ठा नहीं करना पड़ता क्योंकि कभी एक से ज़्यादा स्थिति रही ही नहीं। हर तरीके की कीमत अलगाव की कीमत सिलाई में लगती है: जितने ज़्यादा एजेंट, उतने ज़्यादा नतीजे जिन्हें साथ जोड़ना पड़ता है, और असंगतियां देर से सामने आती हैं। साझा करने की कीमत इंतज़ार में लगती है: किसी और के पास मौजूद फ़ाइल चाहने वाला एजेंट इंतज़ार करता है, और यह इंतज़ार स्क्रीन पर दिखता है। दिखने वाला इंतज़ार दोनों समस्याओं में से बेहतर है। इसे सुलझाने के लिए बस अटके हुए एजेंट को तुरंत कोई और काम दे दें, एक घंटे बाद टकराव का पता चलने की बजाय। कौन सा लें Devin तब जब आप कोई टिकट सौंपना चाहते हैं और नतीजे के सामने वापस आना चाहते हैं। Murmell तब जब आप दौरान वहां रहना चाहते हैं, एक ही कोड पर कई एजेंट के साथ और देखने वाले लोगों के साथ। कैनवस देखें। --- ## Murmell contro Devin Source: https://murmell.com/it/vs/devin Due modi di andare più veloci Devin scala per separazione. Quando un compito è grande, delega ad altri Devin, ciascuno nella propria macchina isolata, e una sessione coordinatrice divide e poi riunisce. È pulito, e non richiede alcun arbitraggio: due agenti che non condividono nulla non possono disturbarsi. Murmell scala per condivisione. Una cartella, più agenti, e una regola di scrittura applicata dal server. Non c'è nulla da riunire alla fine perché non è mai esistito che uno stato. Cosa costa ogni forma La separazione costa alla cucitura: più agenti ci sono, più risultati bisogna far combaciare, e le incompatibilità appaiono tardi. La condivisione costa all'attesa: un agente che vuole un file tenuto da un altro aspetta, e quest'attesa è visibile a schermo. L'attesa visibile è il migliore dei due problemi. Si risolve dando subito un altro compito all'agente bloccato, invece di scoprire un conflitto un'ora dopo. Quale scegliere Devin quando vuoi affidare un ticket e tornare davanti a un risultato. Murmell quando vuoi essere presente durante, con più agenti sullo stesso codice e gente che guarda. Guarda il canvas. --- ## MurmellとDevinの比較 Source: https://murmell.com/ja/vs/devin 速く進む2つの方法 Devinは分離によって規模を拡大します。タスクが大きいとき、他のDevinに委任し、それぞれが独自の隔離 マシンの中で動き、調整セッションが分割してからまとめます。これはきれいで、調停を一切必要としません。 何も共有しない2つのエージェントは互いを邪魔できません。 Murmellは共有によって規模を拡大します。1つのディレクトリ、複数のエージェント、サーバーが強制する 書き込みルール。最後にまとめるものは何もありません。状態は常に1つしかなかったからです。 それぞれの形の代償 分離は縫い合わせに代償を払います。エージェントが増えるほど、まとめるべき結果が増え、非互換性は 遅く現れます。共有は待ちに代償を払います。他が保持しているファイルを欲しがるエージェントは待ち、 その待ちは画面に見えます。 見える待ちは2つの問題の中でより良い方です。行き詰まったエージェントに別のタスクをすぐ与える ことで解決でき、1時間後に競合を発見するよりましです。 どちらを選ぶか チケットを任せて結果の前に戻りたいならDevinです。作業中に立ち会いたく、同じコードに複数のエージェント がいて、人々が見ているならMurmellです。キャンバスを見る。 --- ## Murmell과 Devin 비교 Source: https://murmell.com/ko/vs/devin 더 빨리 가는 두 가지 방법 Devin은 분리를 통해 확장합니다. 작업이 크면 다른 Devin들에게 위임하고, 각자 격리된 머신에서, 조정 세션이 나누고 다시 모읍니다. 깔끔하고, 어떤 조정도 필요 없습니다. 아무것도 공유하지 않는 두 에이전트는 서로 방해할 수 없기 때문입니다. Murmell은 공유를 통해 확장합니다. 디렉터리 하나, 여러 에이전트, 그리고 서버가 강제하는 쓰기 규칙 하나입니다. 마지막에 모을 것이 없습니다. 처음부터 상태가 하나뿐이었기 때문입니다. 각 형태가 치르는 대가 분리는 이어 붙이는 데 대가를 치릅니다. 에이전트가 많을수록 함께 맞춰야 할 결과가 많아지고, 불일치는 늦게 드러납니다. 공유는 기다림에 대가를 치릅니다. 다른 에이전트가 쥔 파일을 원하는 에이전트는 기다리고, 이 대기는 화면에 보입니다. 보이는 대기는 두 문제 중 더 나은 쪽입니다. 한 시간 뒤에 충돌을 발견하는 대신 막힌 에이전트에게 즉시 다른 작업을 주는 것으로 해결됩니다. 어느 것을 고를지 티켓을 맡기고 결과 앞으로 돌아오고 싶다면 Devin입니다. 작업이 이루어지는 동안 함께 있고 싶고, 여러 에이전트가 같은 코드에서 작업하며 사람들이 지켜본다면 Murmell입니다. 캔버스 보기. --- ## Murmell frente ao Devin Source: https://murmell.com/pt/vs/devin Duas formas de ir mais rápido Devin escala por separação. Quando uma tarefa é grande, ele delega a outros Devin, cada um em sua máquina isolada, e uma sessão coordenadora divide e depois reúne. É limpo, e não exige nenhuma arbitragem: dois agentes que não compartilham nada não podem atrapalhar um ao outro. Murmell escala por compartilhamento. Um diretório, vários agentes, e uma regra de escrita aplicada pelo servidor. Não há nada para reunir no final porque nunca existiu mais de um estado. O que cada forma custa A separação custa na costura: quanto mais agentes, mais resultados para encaixar juntos, e as incompatibilidades aparecem tarde. O compartilhamento custa na espera: um agente que quer um arquivo detido por outro espera, e essa espera fica visível na tela. A espera visível é o melhor dos dois problemas. Ela se resolve dando outra tarefa ao agente bloqueado, imediatamente, em vez de descobrir um conflito uma hora depois. Qual escolher Devin quando você quer delegar um ticket e voltar para ver um resultado. Murmell quando você quer estar presente durante, com vários agentes no mesmo código e gente assistindo. Veja o canvas. --- ## Murmell против Devin Source: https://murmell.com/ru/vs/devin Два способа идти быстрее Devin масштабируется через разделение. Когда задача крупная, он делегирует другим Devin, каждому в своей изолированной машине, а координирующая сессия делит и затем собирает. Это чисто, и не требует никакой координации: два агента, которые ничего не делят, не могут мешать друг другу. Murmell масштабируется через совместное использование. Один каталог, несколько агентов и одно правило записи, применяемое сервером. В конце нечего собирать, потому что состояние всегда было одно. Что стоит каждая форма Разделение платит за сшивание: чем больше агентов, тем больше результатов нужно свести воедино, а несовместимости проявляются поздно. Совместное использование платит за ожидание: агент, которому нужен файл, занятый другим, ждёт, и это ожидание видно на экране. Видимое ожидание, лучшая из двух проблем. Она решается тем, что застрявшему агенту сразу дают другую задачу, вместо того чтобы обнаружить конфликт через час. Что выбрать Devin, когда вы хотите поручить тикет и вернуться к готовому результату. Murmell, когда вы хотите быть рядом во время процесса, с несколькими агентами над одним кодом и людьми, которые наблюдают. Посмотреть канвас. --- ## Murmell vs Devin Source: https://murmell.com/vs/devin The real difference Devin scales by separation. When a task is large it delegates to other Devins, and Cognition describes each one as “a full Devin, running in its own isolated virtual machine with its own terminal, browser, and development environment”. A coordinating session scopes the work, hands out the pieces and compiles the results. Murmell scales by sharing. Every agent on a canvas works in the same checkout on the same cloud machine. Before an agent writes to a path it claims it. The board records one holder per path and refuses everyone else until the holder releases it, and that rule is enforced by the server rather than suggested to the model. A colliding write is snapshotted before it lands. Splitting the work is a decision. Sharing a tree is a negotiation. This changes what you can ask for. Work spread across isolated machines has to be split cleanly at the start, because nothing can be renegotiated once the copies have diverged. Agents in one tree renegotiate as they go: one takes the router file, the next waits for it, then takes it. Where Devin wins Devin is much further along at being left alone. It ships pull requests, picks up review feedback and CI results, and gets handed work from Linear, Slack and the other places your tickets already live. It starts each session from a saved machine snapshot, so your dependencies are installed before it types anything, and it reads its own past sessions to get better at your codebase over time. If success means a ticket going in one end and a merged branch coming out the other, Devin is the product built for exactly that. Murmell asks more of you, because it is a room you sit in. Which to pick Pick Devin when work arrives as tickets that do not touch each other, and you would rather read the result than the run. Pick Murmell when the change is one refactor across one tree, when you want to see the terminals as they type, or when the people you work with need to be on the same screen. Send a read link and they are in the room: the windows, the terminal contents and the named cursors, live. Read links are free and there is no cap on them. Close the tab and the agents keep working. Both can be true in the same week. See how several agents work in one repository. --- ## Murmell 对比 Devin Source: https://murmell.com/zh/vs/devin 两种提速方式 Devin 靠隔离来扩展规模。任务一大,它就把活儿分给其他 Devin,每个都在自己的隔离机器里,一个协调会话负责拆分再汇总。这很干净,也不需要任何仲裁:两个互不共享任何东西的代理不可能互相打扰。 Murmell 靠共享来扩展规模。一个目录,多个代理,一条由服务器强制执行的写入规则。结尾不需要汇总什么,因为从头到尾就只有一个状态。 各自的代价 隔离的代价在缝合:代理越多,需要拼在一起的结果就越多,不兼容的问题往往到很晚才暴露。共享的代价在等待:一个代理想要的文件被另一个占着,它就得等,而这个等待在屏幕上是看得见的。 看得见的等待是两种问题里更好的那一种。解法是立刻给卡住的代理换一件事做,而不是一小时后才发现冲突。 选哪个 想把一个任务交出去、回来看结果时,选 Devin。想全程在场、让多个代理在同一份代码上工作、还有人在旁观时,选 Murmell。查看多个代理如何共用同一个仓库。。 --- ## Murmell gegenüber Gemini Code Assist Source: https://murmell.com/de/vs/gemini-code-assist Der eigentliche Unterschied Gemini Code Assist ist um Zustimmung herum gebaut. Google beschreibt den Agentenmodus als Änderungen an mehreren Dateien mit dem Kontext des gesamten Projekts und menschlicher Bestätigung, und bei einer komplexen Aufgabe schlägt es einen Plan vor, den Sie diskutieren und anpassen können, bevor irgendetwas beginnt. Das ist eine ernsthafte Antwort auf das Vertrauensproblem, und sie kostet einen Austausch am Anfang jeder Aufgabe. Murmell beantwortet dasselbe Problem, indem es zeigt statt fragt. Das Terminal ist sichtbar, während der Agent arbeitet, also greifen Sie ein, wenn es entgleist, statt vorher zuzustimmen. Der zweite Unterschied ist die Anzahl. Ein Editor enthält eine Agentenmodus-Sitzung, und nichts in Googles Dokumentation spricht von mehreren Sitzungen in einem gemeinsamen Verzeichnis. Für genau diesen Fall existiert Murmell. Wo Gemini Code Assist gewinnt Die Kontextgröße und der Preis, und beides zählt. Es ist im Editor, den Sie bereits haben, funktioniert mit dem Google-Konto, das Ihr Unternehmen bereits bezahlt, und die kostenlose Stufe reicht jemandem als komplette Installation. Der GitHub-Prüfer ist ebenfalls wirklich nützlich und hat hier kein Gegenstück. Murmell pusht die Arbeit in ein Repository und lässt die Durchsicht dort, wo sie schon ist. Welches nehmen Gemini Code Assist, wenn Sie den Code schreiben und einen guten Agenten daneben wollen, im Editor. Murmell, wenn es die Agenten sind, die schreiben, mehrere gleichzeitig, und der Raum zählt. Was ein Cloud-KI-Agent tut. --- ## Murmell frente a Gemini Code Assist Source: https://murmell.com/es/vs/gemini-code-assist La diferencia real Gemini Code Assist está construido alrededor del consentimiento. Google describe el modo agente como cambios en varios archivos con el contexto de todo el proyecto y una validación humana, y para una tarea compleja propone un plan que puedes discutir y ajustar antes de que empiece nada. Es una respuesta seria al problema de la confianza, y cuesta un ir y venir al inicio de cada tarea. Murmell responde al mismo problema mostrando en vez de preguntando. La terminal es visible mientras el agente trabaja, así que interrumpes cuando se desvía en vez de aprobar antes de que empiece. La segunda diferencia es el número. Un editor contiene una sesión de modo agente, y nada en la documentación de Google habla de varias sesiones en un mismo directorio. Murmell existe para ese caso. Dónde gana Gemini Code Assist El tamaño del contexto y el precio, y los dos cuentan. Está en el editor que ya tienes, funciona con la cuenta de Google que tu empresa ya paga, y la oferta gratuita basta para ser la instalación completa de alguien. El revisor de GitHub también es realmente útil y no tiene equivalente aquí. Murmell envía el trabajo a un repositorio y deja la revisión donde ya está. Cuál elegir Gemini Code Assist cuando escribes el código y quieres un buen agente al lado, en el editor. Murmell cuando son los agentes quienes lo escriben, varios a la vez, y la sala importa. Qué hace un agente de IA en la nube. --- ## Murmell face à Gemini Code Assist Source: https://murmell.com/fr/vs/gemini-code-assist La vraie différence Gemini Code Assist est construit autour du consentement. Google décrit le mode agent comme des modifications sur plusieurs fichiers avec le contexte du projet entier et une validation humaine, et pour une tâche complexe il propose un plan que vous pouvez discuter et ajuster avant que quoi que ce soit commence. C'est une réponse sérieuse au problème de la confiance, et elle coûte un aller-retour au début de chaque tâche. Murmell répond au même problème en montrant plutôt qu'en demandant. Le terminal est visible pendant que l'agent travaille, donc vous interrompez quand ça dérape au lieu d'approuver avant que ça commence. La deuxième différence est le nombre. Un éditeur contient une session de mode agent, et rien dans la documentation de Google ne parle de plusieurs sessions dans un même dossier. Murmell existe pour ce cas. Là où Gemini Code Assist gagne La taille du contexte et le prix, et les deux comptent. Il est dans l'éditeur que vous avez déjà, il marche avec le compte Google que votre entreprise paie déjà, et l'offre gratuite suffit à être l'installation complète de quelqu'un. Le relecteur GitHub est aussi vraiment utile et n'a pas d'équivalent ici. Murmell pousse le travail dans un dépôt et laisse la relecture là où elle est déjà. Lequel prendre Gemini Code Assist quand vous écrivez le code et voulez un bon agent à côté, dans l'éditeur. Murmell quand ce sont les agents qui l'écrivent, plusieurs à la fois, et que la salle compte. Ce que fait un agent IA cloud. --- ## Gemini Code Assist के मुकाबले Murmell Source: https://murmell.com/hi/vs/gemini-code-assist असली फ़र्क़ Gemini Code Assist सहमति के इर्द-गिर्द बना है। Google agent mode को पूरे प्रोजेक्ट के context और इंसानी पुष्टि के साथ कई फ़ाइलों में बदलाव बताता है, और किसी जटिल काम के लिए यह एक ऐसा प्लान सुझाता है जिस पर आप शुरू होने से पहले बात कर सकते हैं और बदल सकते हैं। यह भरोसे की समस्या का गंभीर जवाब है, और हर काम की शुरुआत में एक आगे-पीछे की कीमत लेता है। Murmell उसी समस्या का जवाब मांगने की बजाय दिखाकर देता है। एजेंट के काम करते समय टर्मिनल दिखता है, इसलिए आप शुरू होने से पहले मंज़ूरी देने की बजाय गड़बड़ होने पर बीच में रोकते हैं। दूसरा फ़र्क़ संख्या का है। एक एडिटर में agent mode का एक सेशन होता है, और Google के डॉक्यूमेंटेशन में एक ही फ़ोल्डर में कई सेशन की कोई बात नहीं। Murmell इसी मामले के लिए है। जहां Gemini Code Assist जीतता है Context का आकार और कीमत, और दोनों मायने रखते हैं। यह उसी एडिटर में है जो आपके पास पहले से है, आपकी कंपनी के पहले से भुगतान वाले Google अकाउंट से चलता है, और मुफ़्त लेवल किसी के पूरे सेटअप के लिए काफ़ी है। GitHub रिव्यूअर भी असल में उपयोगी है और इसका यहां कोई जोड़ नहीं। Murmell काम को रिपॉज़िटरी में भेज देता है और रिव्यू को वहीं छोड़ देता है जहां वह पहले से है। कौन सा लें Gemini Code Assist तब जब आप कोड लिखते हैं और उसी एडिटर में एक अच्छा एजेंट चाहते हैं। Murmell तब जब एजेंट खुद लिखते हैं, कई एक साथ, और कमरा मायने रखता है। क्लाउड AI एजेंट क्या करता है। --- ## Murmell contro Gemini Code Assist Source: https://murmell.com/it/vs/gemini-code-assist La vera differenza Gemini Code Assist è costruito attorno al consenso. Google descrive la modalità agente come modifiche su più file con il contesto dell'intero progetto e una convalida umana, e per un compito complesso propone un piano che puoi discutere e regolare prima che qualcosa inizi. È una risposta seria al problema della fiducia, e costa un andirivieni all'inizio di ogni compito. Murmell risponde allo stesso problema mostrando invece che chiedendo. Il terminale è visibile mentre l'agente lavora, quindi interrompi quando le cose vanno storte invece di approvare prima che inizino. La seconda differenza è il numero. Un editor contiene una sessione di modalità agente, e nulla nella documentazione di Google parla di più sessioni in una stessa cartella. Murmell esiste per questo caso. Dove vince Gemini Code Assist La dimensione del contesto e il prezzo, ed entrambi contano. È nell'editor che hai già, funziona con l'account Google che la tua azienda paga già, e l'offerta gratuita basta a essere l'installazione completa di qualcuno. Il revisore GitHub è anche davvero utile e non ha equivalente qui. Murmell invia il lavoro in un repository e lascia la revisione dove già si trova. Quale scegliere Gemini Code Assist quando scrivi il codice e vuoi un buon agente accanto, nell'editor. Murmell quando sono gli agenti a scriverlo, più insieme, e la stanza conta. Cosa fa un agente IA cloud. --- ## MurmellとGemini Code Assistの比較 Source: https://murmell.com/ja/vs/gemini-code-assist 本当の違い Gemini Code Assistは同意を中心に構築されています。Googleはエージェントモードを、プロジェクト全体 のコンテキストと人間による検証を伴う複数ファイルの変更として説明しており、複雑なタスクには何かが 始まる前に議論し調整できる計画を提示します。これは信頼の問題への真剣な答えであり、各タスクの最初 に1往復のやり取りという代償を払います。 Murmellは同じ問題に、尋ねる代わりに見せることで答えます。エージェントが作業している間ターミナル が見えるので、始まる前に承認するのではなく、脱線したときに中断します。 2つ目の違いは数です。1つのエディタには1つのエージェントモードセッションが入り、Googleのドキュメント には同じディレクトリの中の複数のセッションについての記述がありません。Murmellはまさにこのケース のために存在します。 Gemini Code Assistが勝る場所 コンテキストの大きさと価格、どちらも重要です。すでに使っているエディタの中にあり、あなたの会社 がすでに支払っているGoogleアカウントで動き、無料枠だけで誰かの環境全体になり得ます。 GitHubのレビュアーも本当に有用で、ここには対応するものがありません。Murmellは作業をリポジトリに プッシュし、レビューはすでにある場所に任せます。 どちらを選ぶか コードを書くのがあなた自身で、隣に良いエージェントが欲しいならGemini Code Assistです。書くのが エージェントで、複数が同時に動き、部屋が重要ならMurmellです。 クラウドAIエージェントが何をするか。 --- ## Murmell과 Gemini Code Assist 비교 Source: https://murmell.com/ko/vs/gemini-code-assist 진짜 차이 Gemini Code Assist는 동의를 중심으로 만들어졌습니다. Google은 에이전트 모드를 프로젝트 전체 컨텍스트를 가진 여러 파일 수정과 사람의 검증으로 설명하며, 복잡한 작업에는 무언가가 시작되기 전에 논의하고 조정할 수 있는 계획을 제시합니다. 이는 신뢰 문제에 대한 진지한 답이며, 각 작업 시작마다 한 번의 왕복 대가를 치릅니다. Murmell은 같은 문제에 요청하는 대신 보여주는 것으로 답합니다. 에이전트가 작업하는 동안 터미널이 보이므로, 시작하기 전에 승인하는 대신 잘못될 때 개입합니다. 두 번째 차이는 숫자입니다. 에디터 하나는 에이전트 모드 세션 하나를 담고, Google의 문서 어디에도 같은 디렉터리에서 여러 세션에 대한 이야기는 없습니다. Murmell은 이 경우를 위해 존재합니다. Gemini Code Assist가 이기는 지점 컨텍스트 크기와 가격이며, 둘 다 중요합니다. 여러분이 이미 쓰고 있는 에디터 안에 있고, 여러분 회사가 이미 결제하고 있는 Google 계정으로 작동하며, 무료 등급이 누군가의 완전한 설치가 되기에 충분합니다. GitHub 리뷰어도 정말 유용하고 여기에는 대응물이 없습니다. Murmell은 작업을 저장소로 밀어넣고 리뷰는 이미 있던 곳에 남겨둡니다. 어느 것을 고를지 직접 코드를 쓰고 옆에 좋은 에이전트를 원한다면 에디터 안에 있는 Gemini Code Assist입니다. 에이전트들이 코드를 쓰고, 동시에 여럿이며, 방이 중요할 때는 Murmell입니다. 클라우드 AI 에이전트가 하는 일. --- ## Murmell frente ao Gemini Code Assist Source: https://murmell.com/pt/vs/gemini-code-assist A diferença real Gemini Code Assist é construído em torno do consentimento. O Google descreve o modo agente como modificações em vários arquivos com o contexto do projeto inteiro e uma validação humana, e para uma tarefa complexa ele propõe um plano que você pode discutir e ajustar antes de qualquer coisa começar. É uma resposta séria ao problema da confiança, e custa uma ida e volta no início de cada tarefa. Murmell responde ao mesmo problema mostrando em vez de perguntar. O terminal fica visível enquanto o agente trabalha, então você interrompe quando algo sai do rumo em vez de aprovar antes de começar. A segunda diferença é a quantidade. Um editor contém uma sessão de modo agente, e nada na documentação do Google fala de várias sessões no mesmo diretório. Murmell existe para esse caso. Onde o Gemini Code Assist ganha O tamanho do contexto e o preço, e os dois importam. Ele está no editor que você já tem, funciona com a conta Google que sua empresa já paga, e a oferta gratuita é suficiente para ser a instalação completa de alguém. O revisor do GitHub também é realmente útil e não tem equivalente aqui. Murmell envia o trabalho para um repositório e deixa a revisão onde ela já está. Qual escolher Gemini Code Assist quando você escreve o código e quer um bom agente ao lado, no editor. Murmell quando são os agentes que escrevem, vários de uma vez, e a sala importa. O que faz um agente de IA na nuvem. --- ## Murmell против Gemini Code Assist Source: https://murmell.com/ru/vs/gemini-code-assist Настоящая разница Gemini Code Assist построен вокруг согласия. Google описывает режим агента как правки по нескольким файлам с контекстом всего проекта и проверкой человеком, а для сложной задачи предлагает план, который можно обсудить и скорректировать до того, как что-либо начнётся. Это серьёзный ответ на проблему доверия, и он стоит одного обмена в начале каждой задачи. Murmell отвечает на ту же проблему, показывая, а не спрашивая. Терминал виден, пока агент работает, поэтому вы вмешиваетесь, когда что-то идёт не так, вместо того чтобы утверждать до начала. Второе отличие, в числе. Один редактор вмещает одну сессию режима агента, и нигде в документации Google не говорится о нескольких сессиях в одном каталоге. Murmell существует именно для этого случая. Где выигрывает Gemini Code Assist Размер контекста и цена, и оба фактора важны. Он в редакторе, которым вы уже пользуетесь, работает с аккаунтом Google, за который уже платит ваша компания, и бесплатного уровня достаточно, чтобы стать чьей-то полной установкой. Ревьюер GitHub тоже действительно полезен, и здесь ему нет аналога. Murmell отправляет работу в репозиторий и оставляет ревью там, где оно уже было. Что выбрать Gemini Code Assist, когда вы пишете код и хотите хорошего агента рядом, в редакторе. Murmell, когда код пишут агенты, несколько одновременно, и важна комната. Что делает облачный ИИ-агент. --- ## Murmell vs Gemini Code Assist Source: https://murmell.com/vs/gemini-code-assist The real difference Gemini Code Assist is built around consent. Google describes agent mode as multiple file edits with full project context and a human in the loop, and for a complex task it proposes a plan you can question and adjust before anything begins. That is a serious answer to the trust problem, and it costs a round trip at the start of every task. Murmell answers the same problem by showing rather than asking. The terminal is visible while the agent works, so you interrupt when it goes wrong instead of approving before it starts. The second difference is number. One editor holds one agent mode session, and Google documents nothing about several of them in one directory. Murmell exists for that case: an agent claims the paths it is about to write, the server refuses everybody else, and five can work in the same checkout without a merge at the end. Where Gemini Code Assist wins Context length and price, and both matter. It sits in the editor you already have, it works with the Google account your company already pays for, and the free tier is generous enough to be somebody’s whole setup. The GitHub reviewer is also genuinely useful and has no equivalent here. Murmell pushes work to a repository and leaves review where your review already is. Which to pick Gemini Code Assist when you write the code and want a good agent beside you inside the editor. Murmell when the agents write it, several at a time, and the room matters. What a cloud agent actually does. --- ## Murmell 对比 Gemini Code Assist Source: https://murmell.com/zh/vs/gemini-code-assist 真正的区别 Gemini Code Assist 是围绕"同意"搭建的。Google 把代理模式描述为跨多文件修改,带着完整项目上下文,加上人工确认;复杂任务还会先给出一份你可以讨论、调整的计划,等一切开始之前。这是对信任问题的严肃回应,代价是每个任务开始前都要来回一趟。 Murmell 用"展示"而不是"询问"来回应同一个问题。代理工作时终端是可见的,所以你是在出问题时打断,而不是在开始前批准。 第二个区别是数量。一个编辑器容纳一个代理模式会话,Google 的文档里没有提到同一个目录里的多个会话。Murmell 正是为这种情况存在的。 Gemini Code Assist 更强的地方 上下文窗口的大小和价格,两者都很重要。它就在你已经在用的编辑器里,能用你公司已经付费的 Google 账号,免费额度就足够成为某些人的完整配置。 GitHub 上的审阅代理也确实好用,这里没有对应的功能。Murmell 把工作推送进一个仓库,审阅仍留在它原本所在的地方。 选哪个 自己写代码、想在编辑器里配一个好帮手,选 Gemini Code Assist。写代码的是多个代理、房间本身很重要,选 Murmell。云端 AI 代理具体做什么。 --- ## Murmell gegenüber Google Jules Source: https://murmell.com/de/vs/google-jules Der Plan, oder die Sitzung Jules ist um eine vorherige Zustimmung herum gebaut: Es liest, schlägt eine Vorgehensweise vor, und schreibt erst, nachdem Sie ja gesagt haben. Das ist eine ernsthafte Antwort auf das Vertrauensproblem, und sie kostet einen Austausch vor jeder Aufgabe. Murmell antwortet anders. Das Terminal ist sichtbar, während der Agent arbeitet, also kommt das Vertrauen aus dem, was Sie sehen, statt aus dem, was Sie freigegeben haben. Sie greifen ein, wenn es schiefgeht, ohne auf das Ende zu warten. Eine Kopie gegen ein Verzeichnis Ein Klon pro Aufgabe macht die Aufgaben unabhängig und ihre Zusammenführung manuell. Ein geteiltes Verzeichnis macht die Zusammenführung überflüssig, sofern das Schreiben geschiedst wird. Die Regel, die es schlichtet. Welches nehmen Jules für eine Aufgabe, die man delegiert und als Pull-Request abholt, ohne sie zu überwachen. Murmell, wenn mehrere Agenten gemeinsam vorankommen und andere Personen die Sitzung sehen sollen. --- ## Murmell frente a Google Jules Source: https://murmell.com/es/vs/google-jules El plan, o la sesión Jules está construido alrededor de un acuerdo previo: lee, propone una forma de proceder, y solo escribe una vez que has dicho que sí. Es una respuesta seria al problema de la confianza, y cuesta un ir y venir antes de cada tarea. Murmell responde de otra manera. La terminal es visible mientras el agente trabaja, así que la confianza viene de lo que ves en vez de lo que aprobaste. Interrumpes cuando algo se tuerce, sin esperar al final. Una copia contra un directorio Un clon por tarea hace las tareas independientes y hace su ensamblaje manual. Un directorio compartido hace el ensamblaje innecesario, siempre que se arbitre la escritura. La regla que lo arbitra. Cuál elegir Jules para una tarea que confías y recuperas como pull request, sin vigilar. Murmell cuando varios agentes avanzan juntos y otras personas deben ver la sesión. --- ## Murmell face à Google Jules Source: https://murmell.com/fr/vs/google-jules Le plan, ou la séance Jules est construit autour d'un accord préalable : il lit, il propose une marche à suivre, et il n'écrit qu'une fois que vous avez dit oui. C'est une réponse sérieuse au problème de la confiance, et elle coûte un aller-retour avant chaque tâche. Murmell répond autrement. Le terminal est visible pendant que l'agent travaille, donc la confiance vient de ce que vous voyez plutôt que de ce que vous avez approuvé. Vous interrompez quand ça part de travers, sans attendre la fin. Une copie contre un dossier Un clone par tâche rend les tâches indépendantes et rend leur assemblage manuel. Un dossier partagé rend l'assemblage inutile, à condition d'arbitrer l'écriture. La règle qui l'arbitre. Lequel prendre Jules pour une tâche qu'on confie et qu'on récupère en pull request, sans surveiller. Murmell quand plusieurs agents avancent ensemble et que d'autres personnes doivent voir la séance. --- ## Google Jules के मुकाबले Murmell Source: https://murmell.com/hi/vs/google-jules प्लान, या सेशन Jules पहले से सहमति के इर्द-गिर्द बना है: यह पढ़ता है, एक तरीका सुझाता है, और तभी लिखता है जब आप हां कहें। यह भरोसे की समस्या का गंभीर जवाब है, और हर काम से पहले एक आगे-पीछे की कीमत लेता है। Murmell अलग जवाब देता है। एजेंट के काम करते समय टर्मिनल दिखता है, इसलिए भरोसा उस पर आधारित होता है जो आप देखते हैं, न कि जिसे आपने मंज़ूर किया। जब कुछ गलत हो, आप अंत का इंतज़ार किए बिना बीच में रोकते हैं। कॉपी, या फ़ोल्डर हर काम के लिए एक क्लोन कामों को स्वतंत्र बनाता है और उन्हें जोड़ना मुश्किल। साझा फ़ोल्डर जोड़ने की ज़रूरत खत्म कर देता है, बशर्ते लेखन नियंत्रित हो। नियंत्रण करने वाला नियम। कौन सा लें Jules किसी ऐसे काम के लिए जिसे सौंपकर बिना निगरानी pull request में पाना हो। Murmell तब जब कई एजेंट साथ आगे बढ़ें और दूसरे लोगों को सेशन देखना हो। --- ## Murmell contro Google Jules Source: https://murmell.com/it/vs/google-jules Il piano, o la sessione Jules è costruito attorno a un accordo preliminare: legge, propone un modo di procedere, e scrive solo dopo che hai detto sì. È una risposta seria al problema della fiducia, e costa un andirivieni prima di ogni compito. Murmell risponde diversamente. Il terminale è visibile mentre l'agente lavora, quindi la fiducia viene da ciò che vedi invece che da ciò che hai approvato. Interrompi quando qualcosa va storto, senza aspettare la fine. Una copia contro una cartella Un clone per compito rende i compiti indipendenti e ne rende manuale l'assemblaggio. Una cartella condivisa rende l'assemblaggio inutile, a patto di arbitrare la scrittura. La regola che la arbitra. Quale scegliere Jules per un compito che affidi e recuperi come pull request, senza sorvegliarlo. Murmell quando più agenti avanzano insieme e altre persone devono vedere la sessione. --- ## MurmellとGoogle Julesの比較 Source: https://murmell.com/ja/vs/google-jules 計画か、セッションか Julesは事前の合意を中心に構築されています。読み、進め方を提案し、あなたが同意して初めて書き込み ます。これは信頼の問題への真剣な答えであり、各タスクの前に1往復の代償を払います。 Murmellは別の答え方をします。エージェントが作業している間ターミナルが見えるので、信頼は承認した ことではなく見えているものから生まれます。終わりを待たずに、うまくいかなくなったら中断できます。 コピーか、ディレクトリか タスクごとのクローンはタスクを独立させ、その組み立てを手作業にします。共有ディレクトリは組み立て を不要にします。書き込みが調停されている限りは。それを調停するルール。 どちらを選ぶか 見張らずに任せてプルリクエストとして回収したいタスクにはJulesです。複数のエージェントが一緒に 進み、他の人がセッションを見る必要があるならMurmellです。 --- ## Murmell과 Google Jules 비교 Source: https://murmell.com/ko/vs/google-jules 계획, 또는 세션 Jules는 사전 합의를 중심으로 만들어졌습니다. 읽고, 진행 방향을 제안하고, 여러분이 승낙한 뒤에야 씁니다. 이는 신뢰 문제에 대한 진지한 답이며, 작업마다 한 번의 왕복 대가를 치릅니다. Murmell은 다르게 답합니다. 에이전트가 작업하는 동안 터미널이 보이므로, 신뢰는 여러분이 승인한 것이 아니라 보는 것에서 옵니다. 끝날 때까지 기다리지 않고 잘못될 때 개입합니다. 복사본 대 디렉터리 작업마다 클론 하나는 작업을 독립적으로 만들고 조합을 수작업으로 만듭니다. 공유 디렉터리는 조합을 불필요하게 만듭니다. 쓰기가 조정된다면요. 그것을 조정하는 규칙. 어느 것을 고를지 맡기고 지켜보지 않은 채 풀 리퀘스트로 받고 싶은 작업에는 Jules입니다. 여러 에이전트가 함께 진행하고 다른 사람들이 그 세션을 봐야 할 때는 Murmell입니다. --- ## Murmell frente ao Google Jules Source: https://murmell.com/pt/vs/google-jules O plano, ou a sessão Jules é construído em torno de um acordo prévio: ele lê, propõe um plano de ação, e só escreve depois que você disse sim. É uma resposta séria ao problema da confiança, e custa uma ida e volta antes de cada tarefa. Murmell responde de outra forma. O terminal fica visível enquanto o agente trabalha, então a confiança vem do que você vê em vez do que você aprovou. Você interrompe quando algo sai do rumo, sem esperar o final. Uma cópia contra um diretório Um clone por tarefa torna as tarefas independentes e torna sua montagem manual. Um diretório compartilhado torna a montagem desnecessária, desde que a escrita seja arbitrada. A regra que arbitra isso. Qual escolher Jules para uma tarefa que você delega e recebe de volta como pull request, sem supervisionar. Murmell quando vários agentes avançam juntos e outras pessoas precisam ver a sessão. --- ## Murmell против Google Jules Source: https://murmell.com/ru/vs/google-jules План, или сессия Jules построен вокруг предварительного согласия: он читает, предлагает план действий и пишет только после того, как вы сказали да. Это серьёзный ответ на проблему доверия, и он стоит одного обмена перед каждой задачей. Murmell отвечает иначе. Терминал виден, пока агент работает, поэтому доверие приходит из того, что вы видите, а не из того, что вы утвердили. Вы вмешиваетесь, когда что-то идёт не так, не дожидаясь конца. Копия против каталога Клон на задачу делает задачи независимыми и делает их сборку ручной. Общий каталог делает сборку ненужной, при условии что запись координируется. Правило, которое это координирует. Что выбрать Jules для задачи, которую поручают и получают в виде pull request, не наблюдая. Murmell, когда несколько агентов продвигаются вместе, а другие люди должны видеть сессию. --- ## Murmell vs Google Jules Source: https://murmell.com/vs/google-jules The real difference Jules works on a copy. Google describes it clearly: it “fetches your repository, clones it to a Cloud VM, and develops a plan”, then “creates a PR of the changes”. Tasks run at the same time as each other, and how many you can have in flight is capped by plan. Each one is on its own, working alone in its own clone. Murmell has one clone and several agents in it. An agent claims the paths it is about to touch before it writes, the board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted rather than lost. Two agents can be halfway through the same feature at the same moment. The other difference is what you see. Jules shows you a plan then a diff. Murmell shows you the terminals, and so does everyone you sent the link to. Where Jules wins The plan step, which is the best-behaved thing in this comparison. Jules tells you what it intends to do and waits, so a wrong assumption costs you a sentence instead of an hour. Murmell has nothing that disciplined; it hands you real terminals and expects you to steer. Jules is also the shortest path from a GitHub issue to a reviewable branch with no new surface to learn. You label the issue and it appears in your pull requests. If your team measures agents by merged pull requests, that is a real advantage. Which to pick Pick Jules for a queue of contained jobs. A version bump or a flaky test, each on its own branch, agreed in advance and reviewed later. Pick Murmell when the job does not fit in one agent’s head, when the files overlap, or when the run itself is the thing worth watching. Closing the tab does not stop anything, and every project gets a private repository that is pushed to as the work happens, including one last push before a machine is torn down. See how several agents work in one repository. --- ## Murmell 对比 Google Jules Source: https://murmell.com/zh/vs/google-jules 计划,还是过程本身 Jules 建立在事先达成一致的基础上:它先读,再提出一个方案,得到你的同意之后才动手写。这是对信任问题的严肃回应,代价是每个任务开始前都要来回确认一次。 Murmell 用另一种方式回应。代理工作时终端是可见的,信任来自你看到的东西,而不是你批准过的东西。出问题时你直接打断,不用等到结束。 一份拷贝,还是一个目录 每个任务一份克隆让任务彼此独立,但也让拼装变成人工活。共享一个目录让拼装这一步直接消失,前提是写入被仲裁。仲裁写入的那条规则。 选哪个 把一个任务交出去、不用盯着、结果以 pull request 形式收回,选 Jules。多个代理需要一起推进、还需要其他人看到这个过程,选 Murmell。 --- ## Murmell gegenüber OpenHands Agent Canvas Source: https://murmell.com/de/vs/openhands Dieselbe Idee, zwei Antworten Das ist der Vergleich, der der Liste am nächsten kommt: Beide Produkte gehen von der Feststellung aus, dass parallele Agenten eine Fläche verdienen statt eines Tabs. Die Abweichung liegt darin, was man dem zweiten Agenten gibt. Agent Canvas gibt ihm einen Worktree: eine zweite Kopie Ihrer Dateien, auf seinem Branch. Das ist robust, es ist Git, und es funktioniert ohne Schiedsrichter. Murmell gibt ihm dasselbe Verzeichnis wie den anderen, mit einer Reservierung vor dem Schreiben. Wo OpenHands gewinnt Selbst-Hosting und der Quellcode. Es läuft auf Ihrer Hardware, Sie können es ändern, und nichts verlässt Ihr Netzwerk. Wenn das die Bedingung ist, ist die Frage geklärt: Murmell betreibt die Maschinen, das ist das Produkt. Welches nehmen Agent Canvas, wenn der Code auf Hardware bleiben muss, die Sie kontrollieren, oder wenn isolierte parallele Läufe genau die Form Ihrer Arbeit sind. Murmell, wenn mehrere Agenten denselben Code anfassen müssen und andere Personen zusehen sollen. Wie die Reservierung funktioniert. --- ## Murmell frente a OpenHands Agent Canvas Source: https://murmell.com/es/vs/openhands La misma idea, dos respuestas Es la comparación más cercana de la lista: los dos productos parten de que los agentes paralelos merecen una superficie propia en vez de una pestaña. La divergencia está en qué se le da al segundo agente. Agent Canvas le da un worktree: una segunda copia de tus archivos, en su rama. Es robusto, es git, y funciona sin árbitro. Murmell le da el mismo directorio que a los demás, con una reserva antes de escribir. Dónde gana OpenHands El auto-hospedaje y el código fuente. Corre en tu propio hardware, puedes modificarlo, y nada sale de tu red. Si esa es la condición, la pregunta está resuelta: Murmell opera las máquinas, eso es el producto. Cuál elegir Agent Canvas cuando el código debe quedarse en hardware que controlas, o cuando ejecuciones paralelas aisladas son exactamente la forma de tu trabajo. Murmell cuando varios agentes deben tocar el mismo código y otras personas deben mirar. Cómo funciona la reserva. --- ## Murmell face à OpenHands Agent Canvas Source: https://murmell.com/fr/vs/openhands La même idée, deux réponses C'est la comparaison la plus proche de la liste : les deux produits partent du constat que les agents parallèles méritent une surface plutôt qu'un onglet. La divergence est sur ce qu'on donne au deuxième agent. Agent Canvas lui donne un worktree : une deuxième copie de vos fichiers, sur sa branche. C'est robuste, c'est du git, et ça marche sans arbitre. Murmell lui donne le même dossier que les autres, avec une réservation avant écriture. Là où OpenHands gagne L'auto-hébergement et le code source. Il tourne sur votre matériel, vous pouvez le modifier, et rien ne sort de votre réseau. Si c'est la condition, la question est réglée : Murmell opère les machines, c'est le produit. Lequel prendre Agent Canvas quand le code doit rester sur du matériel que vous contrôlez, ou quand des exécutions parallèles isolées sont exactement la forme de votre travail. Murmell quand plusieurs agents doivent toucher le même code et que d'autres personnes doivent regarder. Comment la réservation fonctionne. --- ## OpenHands Agent Canvas के मुकाबले Murmell Source: https://murmell.com/hi/vs/openhands एक ही सोच, दो जवाब यह इस लिस्ट की सबसे करीबी तुलना है: दोनों उत्पाद इस बात से शुरू होते हैं कि समांतर एजेंट को टैब की बजाय एक सतह मिलनी चाहिए। फ़र्क़ इसमें है कि दूसरे एजेंट को क्या दिया जाता है। Agent Canvas उसे एक worktree देता है: आपकी फ़ाइलों की एक दूसरी कॉपी, अपनी ब्रांच पर। यह मज़बूत है, यह git है, और बिना arbiter के काम करता है। Murmell उसे बाकियों जैसा ही फ़ोल्डर देता है, लिखने से पहले आरक्षण के साथ। जहां OpenHands जीतता है सेल्फ़-होस्टिंग और सोर्स कोड। यह आपके हार्डवेयर पर चलता है, आप इसे बदल सकते हैं, और कुछ भी आपके नेटवर्क से बाहर नहीं जाता। अगर यही शर्त है, तो सवाल सुलझ गया: Murmell खुद मशीनें चलाता है, यही उत्पाद है। कौन सा लें Agent Canvas तब जब कोड आपके नियंत्रण वाले हार्डवेयर पर रहना चाहिए, या जब अलग-अलग समांतर रन ठीक आपके काम का रूप हों। Murmell तब जब कई एजेंट को एक ही कोड छूना हो और दूसरे लोगों को देखना हो। आरक्षण कैसे काम करता है। --- ## Murmell contro OpenHands Agent Canvas Source: https://murmell.com/it/vs/openhands La stessa idea, due risposte È il confronto più vicino della lista: entrambi i prodotti partono dalla constatazione che gli agenti paralleli meritano una superficie invece che una scheda. La divergenza sta in cosa si dà al secondo agente. Agent Canvas gli dà un worktree: una seconda copia dei tuoi file, sul suo branch. È robusto, è git, e funziona senza arbitro. Murmell gli dà la stessa cartella degli altri, con una prenotazione prima della scrittura. Dove vince OpenHands L'auto-hosting e il codice sorgente. Gira sul tuo hardware, puoi modificarlo, e nulla esce dalla tua rete. Se questa è la condizione, la domanda è già risolta: Murmell gestisce le macchine, è questo il prodotto. Quale scegliere Agent Canvas quando il codice deve restare su hardware che controlli, o quando esecuzioni parallele isolate sono esattamente la forma del tuo lavoro. Murmell quando più agenti devono toccare lo stesso codice e altre persone devono guardare. Come funziona la prenotazione. --- ## MurmellとOpenHands Agent Canvasの比較 Source: https://murmell.com/ja/vs/openhands 同じ発想、2つの答え リストの中で最も近い比較です。両方の製品は、並行するエージェントはタブではなく専用の面にふさわしい という同じ観察から出発しています。分岐点は2番目のエージェントに何を与えるかです。 Agent Canvasはworktreeを与えます。自分のブランチ上のあなたのファイルの2つ目のコピーです。頑丈で、 gitそのもので、調停者なしで機能します。Murmellは他と同じディレクトリを与え、書き込み前の確保を 伴います。 OpenHandsが勝る場所 自己ホスティングとソースコードです。あなたのハードウェア上で動き、変更でき、ネットワークから何も 出ません。それが条件ならその問いはすでに答えが出ています。Murmellはマシンを運用すること自体が 製品だからです。 どちらを選ぶか コードが自分の管理下のハードウェアに留まる必要がある、あるいは隔離された並行実行がまさにあなたの 作業の形であるならAgent Canvasです。複数のエージェントが同じコードに触れる必要があり、他の人が 見る必要があるならMurmellです。確保の仕組み。 --- ## Murmell과 OpenHands Agent Canvas 비교 Source: https://murmell.com/ko/vs/openhands 같은 발상, 두 가지 답 목록에서 가장 가까운 비교입니다. 두 제품 모두 병렬 에이전트에는 탭이 아니라 표면이 필요하다는 관찰에서 출발합니다. 갈라지는 지점은 두 번째 에이전트에게 무엇을 주는가입니다. Agent Canvas는 worktree를 줍니다. 자체 브랜치 위에 있는 여러분 파일의 두 번째 복사본입니다. 견고하고, git이며, 조정자 없이도 작동합니다. Murmell은 다른 에이전트들과 같은 디렉터리를 주고, 쓰기 전에 점유하게 합니다. OpenHands가 이기는 지점 자체 호스팅과 소스 코드입니다. 여러분의 하드웨어에서 실행되고, 수정할 수 있으며, 네트워크 밖으로 아무것도 나가지 않습니다. 이것이 조건이라면 질문은 이미 답이 나온 것입니다. Murmell은 머신을 운영하는 것 자체가 제품입니다. 어느 것을 고를지 코드가 여러분이 통제하는 하드웨어에 남아야 하거나, 격리된 병렬 실행이 여러분 작업의 정확한 형태일 때는 Agent Canvas입니다. 여러 에이전트가 같은 코드를 건드려야 하고 다른 사람들이 지켜봐야 할 때는 Murmell입니다. 점유가 작동하는 방식. --- ## Murmell frente ao OpenHands Agent Canvas Source: https://murmell.com/pt/vs/openhands A mesma ideia, duas respostas É a comparação mais próxima da lista: os dois produtos partem da constatação de que agentes paralelos merecem uma superfície em vez de uma aba. A divergência está no que se dá ao segundo agente. Agent Canvas dá a ele um worktree: uma segunda cópia dos seus arquivos, na sua branch. É robusto, é git, e funciona sem árbitro. Murmell dá a ele o mesmo diretório que os outros, com uma reserva antes da escrita. Onde o OpenHands ganha O auto-hospedamento e o código-fonte. Ele roda no seu hardware, você pode modificá-lo, e nada sai da sua rede. Se essa for a condição, a questão está resolvida: Murmell opera as máquinas, esse é o produto. Qual escolher Agent Canvas quando o código precisa ficar em hardware que você controla, ou quando execuções paralelas isoladas são exatamente a forma do seu trabalho. Murmell quando vários agentes precisam tocar no mesmo código e outras pessoas precisam assistir. Como a reserva funciona. --- ## Murmell против OpenHands Agent Canvas Source: https://murmell.com/ru/vs/openhands Одна и та же идея, два ответа Это самое близкое сравнение в списке: оба продукта исходят из наблюдения, что параллельным агентам нужна поверхность, а не вкладка. Расхождение в том, что отдаётся второму агенту. Agent Canvas даёт ему worktree: вторую копию ваших файлов на его собственной ветке. Это надёжно, это git, и работает без координатора. Murmell даёт ему тот же каталог, что и остальным, с резервированием перед записью. Где выигрывает OpenHands Самостоятельный хостинг и исходный код. Он работает на вашем оборудовании, вы можете его изменять, и ничто не покидает вашу сеть. Если это условие, вопрос уже решён: Murmell сам управляет машинами, это и есть продукт. Что выбрать Agent Canvas, когда код должен оставаться на оборудовании, которое вы контролируете, или когда изолированные параллельные запуски, точная форма вашей работы. Murmell, когда нескольким агентам нужно затронуть один и тот же код, а другие люди должны наблюдать. Как работает резервирование. --- ## Murmell vs OpenHands Agent Canvas Source: https://murmell.com/vs/openhands The real difference This is the closest tool on the list, and the difference is one design decision. Agent Canvas runs several agents at once and isolates each in its own git worktree, all visible from one interface. Isolation is how it keeps them from colliding, and a worktree is a real second copy of your files on a branch of its own. Murmell does not isolate them. Every agent on a canvas is in the same checkout, and the safety comes from asking rather than from separating: an agent claims the paths it is about to touch, the board records one holder per path and refuses everyone else until that holder releases it, and a colliding write is snapshotted before it lands. The rule is enforced by the server, not suggested to the model. A worktree keeps agents apart. A reservation lets them stand in the same room. The second difference is people. Agent Canvas starts on your own machine, one browser, one person. A Murmell canvas is a room: send a read link and someone else sees the windows, the terminal contents and a named cursor for everybody in it, live. Closing your tab does not stop the agents. Where OpenHands wins You can read all of it and you can run all of it. Agent Canvas is open source under the MIT license, starts locally with one command and no Docker required, and connects to a Docker container, a VM you own or a cluster in your own network. The enterprise edition self-hosts inside your VPC. Murmell has no self-hosted option today, and if your code cannot leave your infrastructure the comparison stops there. Its automations go further than ours too. Slack, cron, polling and event triggers ship in the product, and there is a Python library underneath if you want to write your own runner. Murmell launches CLIs on a canvas and nothing else. Which to pick Pick Agent Canvas when the code has to stay on hardware you control, when you want to change the tool itself, or when isolated parallel runs are exactly the shape of your work. Pick Murmell when the agents genuinely need to be in the same tree, or when the run needs an audience. The machine that executes agent code holds no database and no decryption key, so an agent that escapes its box finds nothing worth taking, and work is pushed to a private repository per project. See how several agents work in one repository. --- ## Murmell 对比 OpenHands Agent Canvas Source: https://murmell.com/zh/vs/openhands 同一个想法,两种答案 这是这份列表里最接近的一组对比:两款产品都认定并行代理需要一个自己的界面,而不是一个标签页。分歧在于给第二个代理什么。 Agent Canvas 给它一个 worktree:你文件的第二份拷贝,在它自己的分支上。这很稳健,是标准的 git 用法,不需要任何仲裁者。Murmell 给它和其他代理一样的那个目录,写入前先占用。 OpenHands 更强的地方 自托管和开放源码。它运行在你自己的硬件上,你可以修改它,没有任何东西离开你的网络。如果这是硬性条件,问题就已经有了答案:Murmell 运营机器,这就是产品本身。 选哪个 代码必须留在你能控制的硬件上,或者隔离的并行执行正好符合你的工作方式,选 Agent Canvas。多个代理需要碰同样的代码、还需要其他人旁观,选 Murmell。占用机制如何运作。 --- ## Murmell gegenüber Replit Agent Source: https://murmell.com/de/vs/replit-agent Zwei Ausgangspunkte Replit geht von einem Satz aus und liefert eine Online-Anwendung. Das ist der kürzeste Weg von einer Idee zu etwas, das man zeigen kann, und nichts an Murmell macht das. Murmell geht von einem bestehenden Repository aus, mit seiner Historie, seinen Tests und seinen Gewohnheiten. Die nützliche Arbeit ist nicht das Erschaffen, sondern das Ändern, ohne etwas kaputtzumachen, und das zu mehreren. Was „zusammen" bedeutet Bei Replit bearbeiten mehrere Personen ein Projekt. Auf Murmell sehen mehrere Personen mehreren Agenten bei der Arbeit zu, und jede steuert ihre eigenen. Zusehen kostet weder Platz noch Konto. Welches nehmen Replit Agent, um einen Prototyp aus dem Nichts herauszubringen und online zu stellen. Murmell, um ein bestehendes Projekt mit mehreren Agenten im selben Verzeichnis voranzubringen. Die Canvas ansehen. --- ## Murmell frente a Replit Agent Source: https://murmell.com/es/vs/replit-agent Dos puntos de partida Replit parte de una frase y entrega una aplicación en línea. Es el camino más corto entre una idea y algo que se puede mostrar, y nada en Murmell hace eso. Murmell parte de un repositorio que existe, con su historial, sus pruebas y sus costumbres. El trabajo útil no es crear, es modificar sin romper, y entre varios. Lo que significa "juntos" En Replit, varias personas editan un proyecto. En Murmell, varias personas miran a varios agentes trabajar, y cada una controla los suyos. Mirar no cuesta plaza ni cuenta. Cuál elegir Replit Agent para sacar un prototipo de la nada y ponerlo en línea. Murmell para hacer avanzar un proyecto existente con varios agentes en el mismo directorio. Ver el canvas. --- ## Murmell face à Replit Agent Source: https://murmell.com/fr/vs/replit-agent Deux points de départ Replit part d'une phrase et rend une application en ligne. C'est le chemin le plus court entre une idée et quelque chose qu'on peut montrer, et rien dans Murmell ne fait ça. Murmell part d'un dépôt qui existe, avec son historique, ses tests et ses habitudes. Le travail utile n'est pas de créer, c'est de modifier sans casser, et à plusieurs. Ce que « ensemble » veut dire Chez Replit, plusieurs personnes éditent un projet. Sur Murmell, plusieurs personnes regardent plusieurs agents travailler, et chacune pilote les siens. Regarder ne coûte ni siège ni compte. Lequel prendre Replit Agent pour sortir un prototype de rien et le mettre en ligne. Murmell pour faire avancer un projet existant avec plusieurs agents dans le même dossier. Voir le canvas. --- ## Replit Agent के मुकाबले Murmell Source: https://murmell.com/hi/vs/replit-agent दो शुरुआती बिंदु Replit एक वाक्य से शुरू होता है और एक लाइव ऐप देता है। यह किसी आइडिया और दिखाने लायक किसी चीज़ के बीच सबसे छोटा रास्ता है, और Murmell में ऐसा कुछ नहीं है। Murmell मौजूद रिपॉज़िटरी से शुरू होता है, अपने इतिहास, टेस्ट और आदतों के साथ। यहां काम बनाना नहीं, बिना तोड़े बदलना है, और वह भी कई लोगों के साथ। "साथ" का मतलब क्या है Replit पर, कई लोग एक प्रोजेक्ट एडिट करते हैं। Murmell पर, कई लोग कई एजेंट को काम करते देखते हैं, और हर एक अपने एजेंट चलाता है। देखने के लिए न सीट चाहिए न अकाउंट। कौन सा लें शून्य से कोई प्रोटोटाइप निकालकर लाइव करने के लिए Replit Agent। मौजूद प्रोजेक्ट को कई एजेंट के साथ एक ही फ़ोल्डर में आगे बढ़ाने के लिए Murmell। कैनवस देखें। --- ## Murmell contro Replit Agent Source: https://murmell.com/it/vs/replit-agent Due punti di partenza Replit parte da una frase e restituisce un'applicazione online. È il percorso più breve tra un'idea e qualcosa da mostrare, e niente in Murmell fa questo. Murmell parte da un repository che esiste, con la sua cronologia, i suoi test e le sue abitudini. Il lavoro utile non è creare, è modificare senza rompere, e farlo in più persone. Cosa vuol dire "insieme" Da Replit, più persone modificano un progetto. Su Murmell, più persone guardano più agenti lavorare, e ciascuna pilota i propri. Guardare non costa né un posto né un account. Quale scegliere Replit Agent per tirare fuori un prototipo dal nulla e metterlo online. Murmell per far avanzare un progetto esistente con più agenti nella stessa cartella. Guarda il canvas. --- ## MurmellとReplit Agentの比較 Source: https://murmell.com/ja/vs/replit-agent 2つの出発点 Replitは一文から出発し、オンラインのアプリケーションを返します。アイデアから見せられるものまで の最短経路であり、Murmellにはそれに該当するものがありません。 Murmellは、履歴、テスト、慣習を持つ既存のリポジトリから出発します。役に立つ作業は作ることではなく、 壊さずに変更すること、しかも複数人でです。 「一緒に」が意味すること Replitでは複数の人がプロジェクトを編集します。Murmellでは複数の人が複数のエージェントの作業を見て、 それぞれが自分のエージェントを操作します。見るだけならシートもアカウントも要りません。 どちらを選ぶか 何もないところからプロトタイプを作ってオンラインに出すならReplit Agentです。既存のプロジェクトを、 同じディレクトリの中の複数のエージェントで前進させるならMurmellです。キャンバスを 見る。 --- ## Murmell과 Replit Agent 비교 Source: https://murmell.com/ko/vs/replit-agent 서로 다른 두 출발점 Replit은 한 문장에서 시작해 온라인 애플리케이션을 만듭니다. 아이디어와 보여줄 수 있는 무언가 사이의 가장 짧은 길이며, Murmell에는 이에 해당하는 것이 없습니다. Murmell은 이미 존재하는 저장소에서 출발합니다. 이력과 테스트와 습관을 가진 채로요. 유용한 작업은 만드는 것이 아니라, 망가뜨리지 않고 수정하는 것입니다. 그것도 여럿이서요. "함께"가 뜻하는 것 Replit에서는 여러 사람이 프로젝트를 편집합니다. Murmell에서는 여러 사람이 여러 에이전트가 작업하는 것을 지켜보고, 각자 자신의 에이전트를 조작합니다. 보는 것은 좌석도 계정도 요구하지 않습니다. 어느 것을 고를지 아무것도 없는 상태에서 프로토타입을 뽑아 온라인에 올리려면 Replit Agent입니다. 여러 에이전트로 같은 디렉터리에서 기존 프로젝트를 진행시키려면 Murmell입니다. 캔버스 보기. --- ## Murmell frente ao Replit Agent Source: https://murmell.com/pt/vs/replit-agent Dois pontos de partida Replit parte de uma frase e entrega um aplicativo no ar. É o caminho mais curto entre uma ideia e algo que se pode mostrar, e nada no Murmell faz isso. Murmell parte de um repositório que já existe, com seu histórico, seus testes e seus hábitos. O trabalho útil não é criar, é modificar sem quebrar, e em grupo. O que "junto" quer dizer Na Replit, várias pessoas editam um projeto. No Murmell, várias pessoas assistem a vários agentes trabalhando, e cada uma pilota os seus. Assistir não custa nem vaga nem conta. Qual escolher Replit Agent para tirar um protótipo do zero e colocá-lo no ar. Murmell para fazer um projeto existente avançar com vários agentes no mesmo diretório. Veja o canvas. --- ## Murmell против Replit Agent Source: https://murmell.com/ru/vs/replit-agent Две разные точки старта Replit начинает с одной фразы и создаёт онлайн-приложение. Это кратчайший путь от идеи до того, что можно показать, и в Murmell нет ничего подобного. Murmell начинает с существующего репозитория, с его историей, тестами и привычками. Полезная работа не в создании, а в изменении без поломки, причём вместе с другими. Что значит «вместе» У Replit несколько человек редактируют проект. У Murmell несколько человек наблюдают за работой нескольких агентов, и каждый управляет своими собственными. Наблюдение не требует ни места, ни аккаунта. Что выбрать Replit Agent, чтобы вытащить прототип из ничего и разместить его онлайн. Murmell, чтобы продвигать существующий проект несколькими агентами в одном каталоге. Посмотреть канвас. --- ## Murmell vs Replit Agent Source: https://murmell.com/vs/replit-agent The real difference Replit owns the whole road. It says Agent “writes code, sets up infrastructure, and tests the result”, needs no technical knowledge from you, keeps checkpoints you can roll back to, and takes the app all the way to deployment. The agent is the interface, and the terminal is an implementation detail you are not asked to look at. Murmell is the opposite arrangement. The terminal is the point. You open Claude Code or Codex in a window, you read what it actually printed, and you open a second one beside it in the same checkout. An agent claims a path before it writes, the board keeps one holder per path and refuses everyone else until it is released, and a colliding write is snapshotted before it lands. Murmell does not host anything: work goes to a private repository for the project. Where Replit wins Two things, and both are large. It gets you from a sentence to a URL without leaving the tab, with the database and the hosting handled, and Murmell has none of that. And its multiplayer is older and wider than ours. Replit documents that several people can work in the same project at the same time with cursor presence, and each of them can start their own thread with Agent. Murmell shows guests the canvas live, with a name and a color on each cursor, but two people typing raw keys into the same terminal is not built yet. If a colleague needs to take the keyboard from you in the same shell today, Replit does that and Murmell does not. Which to pick Pick Replit when the app does not exist yet and you want it running by this evening, or when the people building it would rather not think about infrastructure. Pick Murmell when the codebase is already real, the change is bigger than one agent, and you want to watch the run. Read links cost nothing and are not capped, edit links are capped by plan, and the machine that executes agent code holds no database and no decryption key. See how several agents work in one repository. --- ## Murmell 对比 Replit Agent Source: https://murmell.com/zh/vs/replit-agent 两个不同的起点 Replit 从一句话开始,交出一个上线的应用。这是从想法到能演示的东西之间最短的路径,Murmell 完全不做这件事。 Murmell 从一个已经存在的仓库开始,带着它的历史、测试和团队习惯。真正有价值的工作不是从零创造,而是在不弄坏的前提下修改,而且是多人一起。 "一起"具体指什么 在 Replit 上,多个人一起编辑一个项目。在 Murmell 上,多个人看着多个代理工作,各自操作自己的那部分。旁观不占席位,也不需要账号。 选哪个 从零做出一个原型并上线,选 Replit Agent。让一个已经存在的项目在多个代理的共同推进下前进,选 Murmell。查看多个代理如何共用同一个仓库。。 --- ## Murmell gegenüber Vibe Kanban Source: https://murmell.com/de/vs/vibe-kanban Ordnen, oder zusehen Ein Kanban-Board beantwortet die Frage „wo steht jede Sache". Das ist nützlich, wenn Arbeit wartet, sich jemand annimmt und sie zurückgibt. Eine Canvas beantwortet „wer schreibt gerade was", was die richtige Frage ist, wenn fünf Agenten gleichzeitig laufen. Lokal gegen Cloud Vibe Kanban startet die Agenten auf Ihrer Maschine, also ist Ihre Maschine die Grenze: Sie muss eingeschaltet bleiben, und niemand sonst sieht etwas. Auf Murmell leben die Sitzungen auf einer gemieteten Maschine, und ein Link reicht, damit jemand zusieht. Welches nehmen Vibe Kanban, wenn Sie eine Warteschlange von Aufgaben haben, die einzeln auf Ihrem Rechner durchlaufen sollen. Murmell, wenn sie gemeinsam am selben Code laufen. Was sie am Überschreiben hindert. --- ## Murmell frente a Vibe Kanban Source: https://murmell.com/es/vs/vibe-kanban Ordenar, o mirar Un tablero kanban responde a la pregunta "cómo va cada cosa". Es útil cuando el trabajo espera, se toma y se entrega. Un canvas responde a "quién escribe qué ahora mismo", que es la pregunta correcta cuando cinco agentes corren a la vez. Local contra nube Vibe Kanban lanza los agentes en tu máquina, así que tu máquina es el límite: debe quedarse encendida, y nadie más ve nada. En Murmell las sesiones viven en una máquina alquilada, y un enlace basta para que alguien mire. Cuál elegir Vibe Kanban cuando tienes una cola de tareas que pasar una a una en tu equipo. Murmell cuando corren juntas sobre el mismo código. Lo que evita que se pisen. --- ## Murmell face à Vibe Kanban Source: https://murmell.com/fr/vs/vibe-kanban Ranger, ou regarder Un tableau kanban répond à la question « où en est chaque chose ». C'est utile quand le travail attend, se prend et se rend. Un canvas répond à « qui écrit quoi maintenant », ce qui est la bonne question quand cinq agents tournent en même temps. Local contre cloud Vibe Kanban lance les agents sur votre machine, donc votre machine est la limite : elle doit rester allumée, et personne d'autre ne voit rien. Sur Murmell les sessions vivent sur une machine louée, et un lien suffit pour que quelqu'un regarde. Lequel prendre Vibe Kanban quand vous avez une file de tâches à faire passer une par une sur votre poste. Murmell quand elles tournent ensemble sur le même code. Ce qui les empêche de s'écraser. --- ## Vibe Kanban के मुकाबले Murmell Source: https://murmell.com/hi/vs/vibe-kanban सजाना, या देखना कानबान बोर्ड इस सवाल का जवाब देता है "हर चीज़ किस हाल में है"। यह तब काम आता है जब काम इंतज़ार करता है, उठाया जाता है और सौंपा जाता है। कैनवस "अभी कौन क्या लिख रहा है" का जवाब देता है, जो सही सवाल है जब पांच एजेंट एक साथ चल रहे हों। लोकल बनाम क्लाउड Vibe Kanban एजेंट को आपकी मशीन पर चलाता है, इसलिए आपकी मशीन ही सीमा है: यह चालू रहनी चाहिए, और कोई और कुछ नहीं देखता। Murmell पर सेशन किराए की मशीन पर जीते हैं, और देखने के लिए एक लिंक काफ़ी है। कौन सा लें Vibe Kanban तब जब आपकी अपनी मशीन पर एक-एक करके निपटाने के लिए कामों की कतार हो। Murmell तब जब वे एक ही कोड पर साथ चल रहे हों। उन्हें एक-दूसरे को मिटाने से क्या रोकता है। --- ## Murmell contro Vibe Kanban Source: https://murmell.com/it/vs/vibe-kanban Ordinare, o guardare Una bacheca kanban risponde alla domanda "a che punto è ogni cosa". È utile quando il lavoro aspetta, viene preso in carico e restituito. Un canvas risponde a "chi scrive cosa adesso", che è la domanda giusta quando cinque agenti girano insieme. Locale contro cloud Vibe Kanban lancia gli agenti sulla tua macchina, quindi la tua macchina è il limite: deve restare accesa, e nessun altro vede nulla. Su Murmell le sessioni vivono su una macchina noleggiata, e basta un link perché qualcuno guardi. Quale scegliere Vibe Kanban quando hai una fila di compiti da far passare uno per uno sul tuo computer. Murmell quando girano insieme sullo stesso codice. Cosa impedisce loro di sovrascriversi. --- ## MurmellとVibe Kanbanの比較 Source: https://murmell.com/ja/vs/vibe-kanban 整理するか、見るか カンバンボードは「それぞれが今どの段階か」という問いに答えます。作業が待ち、受け取られ、返される 場面で役に立ちます。キャンバスは「今誰が何を書いているか」に答えます。これは5つのエージェントが 同時に動いているときに正しい問いです。 ローカルか、クラウドか Vibe Kanbanはあなたのマシン上でエージェントを起動するので、あなたのマシンが限界になります。起動 し続ける必要があり、他の誰も何も見られません。Murmellではセッションは借りたマシン上で生き、リンク 1つで誰かが見られます。 どちらを選ぶか 自分のマシンで1つずつこなすタスクの列があるならVibe Kanbanです。それらが同じコードの上で一緒に 動くならMurmellです。互いを上書きしないようにして いるもの。 --- ## Murmell과 Vibe Kanban 비교 Source: https://murmell.com/ko/vs/vibe-kanban 정리하기, 또는 지켜보기 칸반 보드는 "각각이 어느 단계인가"라는 질문에 답합니다. 작업이 기다리고, 맡겨지고, 돌려지는 상황에 유용합니다. 캔버스는 "지금 누가 무엇을 쓰고 있는가"에 답하며, 이는 다섯 에이전트가 동시에 실행 중일 때 물어야 할 질문입니다. 로컬 대 클라우드 Vibe Kanban은 여러분의 머신에서 에이전트를 실행하므로 여러분의 머신이 한계입니다. 계속 켜져 있어야 하고, 다른 누구도 아무것도 볼 수 없습니다. Murmell에서는 세션이 빌린 머신 위에서 살아 있고, 링크 하나면 누군가가 지켜볼 수 있습니다. 어느 것을 고를지 자신의 컴퓨터에서 하나씩 처리할 작업 목록이 있다면 Vibe Kanban입니다. 그것들이 같은 코드 위에서 함께 실행될 때는 Murmell입니다. 서로 덮어쓰지 않게 막는 것. --- ## Murmell frente ao Vibe Kanban Source: https://murmell.com/pt/vs/vibe-kanban Organizar, ou assistir Um quadro kanban responde à pergunta "em que pé está cada coisa". É útil quando o trabalho espera, é pego e é entregue. Um canvas responde a "quem está escrevendo o quê agora", que é a pergunta certa quando cinco agentes rodam ao mesmo tempo. Local contra nuvem Vibe Kanban inicia os agentes na sua máquina, então sua máquina é o limite: ela precisa ficar ligada, e mais ninguém vê nada. No Murmell as sessões vivem em uma máquina alugada, e um link é suficiente para que alguém assista. Qual escolher Vibe Kanban quando você tem uma fila de tarefas para passar uma a uma no seu computador. Murmell quando elas rodam juntas no mesmo código. O que impede que se sobrescrevam. --- ## Murmell против Vibe Kanban Source: https://murmell.com/ru/vs/vibe-kanban Организовать, или наблюдать Канбан-доска отвечает на вопрос «на каком этапе каждая из них». Это полезно, когда работа ждёт, берётся и возвращается. Канвас отвечает на вопрос «кто что пишет сейчас», а это правильный вопрос, когда пять агентов работают одновременно. Локально против облака Vibe Kanban запускает агентов на вашей машине, поэтому ваша машина, это предел: она должна оставаться включённой, и никто другой ничего не видит. В Murmell сессии живут на арендованной машине, и одной ссылки достаточно, чтобы кто-то мог наблюдать. Что выбрать Vibe Kanban, если у вас есть очередь задач, которые нужно обрабатывать по одной на своём компьютере. Murmell, когда они выполняются вместе над одним и тем же кодом. Что не даёт им перезаписывать друг друга. --- ## Murmell vs Vibe Kanban Source: https://murmell.com/vs/vibe-kanban Read this first The project’s own repository carries a notice that Vibe Kanban is sunsetting, with a link to the announcement. It is Apache-2.0 licensed, so the code stays available to run and to fork, but that notice belongs at the top of any comparison rather than in a footnote. Check it before you build a team habit on top of it. The real difference Vibe Kanban organizes by task. Its pitch is breadth of agents, listing Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, OpenCode, Droid and others, with a workspace per task and a line-by-line diff you comment on before sending feedback back to the agent. It installs with one command and runs locally. Murmell organizes by directory. Agents are not separated: they share one checkout, and each claims the paths it is about to touch before writing. The board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted before it lands. Two agents can work through the same feature in the same minute. The agents also run on cloud machines rather than your laptop, so closing the tab does not kill them, and other people can be in the canvas while it happens. A read link shows the windows, the terminal contents and a named cursor for each person, live, and read links are not capped. Where Vibe Kanban wins The board itself is a better fit for a queue than a canvas is. If your day is twenty small independent jobs, columns beat windows, and the diff review flow with comments going straight back to the agent is a tight loop. It also runs on your own machine with your own keys, it supports more agents than Murmell launches today, and being Apache-2.0 means you can read it and change it. Murmell is not open source and has no self-hosted option. Which to pick Pick a local board when the work is a queue of separate tasks, the code should not leave your disk, and you want to own the tool. Pick Murmell when several agents have to touch the same files, when the run should keep going without you, or when the people you work with need to see it. Work is pushed to a private repository per project, including one last push before a machine is torn down. See how several agents work in one repository. --- ## Murmell 对比 Vibe Kanban Source: https://murmell.com/zh/vs/vibe-kanban 整理,还是旁观 一块看板回答的问题是"每件事现在到哪一步了"。这在工作需要排队、领取、交付的时候很有用。一块画布回答的是"现在是谁在写什么",这才是五个代理同时运行时该问的问题。 本地对比云端 Vibe Kanban 在你自己的机器上启动代理,所以你的机器就是边界:它必须一直开着,而且没有别人能看到任何东西。在 Murmell 上,会话运行在一台租用的机器上,一个链接就足以让人旁观。 选哪个 有一串任务要在自己的机器上一个个过,选 Vibe Kanban。任务需要在同一份代码上一起进行,选 Murmell。是什么防止他们互相覆盖。 --- ## Murmell gegenüber Windsurf Source: https://murmell.com/de/vs/windsurf Der eigentliche Unterschied Windsurf ist bei seinem Mechanismus deutlich, was den Vergleich leicht ehrlich macht. Die parallelen Agenten erhalten Worktrees: eine echte zweite Kopie Ihrer Dateien auf einem eigenen Branch, sodass ein Agent, der kompiliert und testet, den Bereich nicht stört, in dem Sie tippen. Der Arena-Modus geht weiter und gibt jedem Modell einen Worktree, um ihre Antworten auf dieselbe Anfrage zu vergleichen. Das ist gut gemachte Isolierung, und sie hat die Kosten, die Isolierung immer hat. Zwanzig Worktrees sind zwanzig Kopien, und jede endet mit einer Zusammenführung. Der Konflikt wird nicht vermieden, er wird auf den Moment verschoben, in dem Sie den Button drücken. Murmell entfernt die Kopien. Ein Verzeichnis, und ein Agent reserviert die Pfade, die er anfassen wird, bevor er schreibt. Das Board führt einen Inhaber pro Pfad und verweigert alle anderen, bis er ihn freigibt, sodass ein zweiter Agent dreißig Sekunden wartet, statt eine Dateiversion zu erzeugen, die man später abgleichen muss. Wo Windsurf gewinnt Der Editor, und die Tatsache, dass er auf Ihrer Maschine läuft. Nichts wird hochgeladen, der Code bleibt auf Ihrer Festplatte, und die Agenten arbeiten an den Dateien, die Sie vor sich haben. Murmell hat keine selbst gehostete Option: Wenn der Code nicht raus darf, ist die Frage geklärt. Welches nehmen Windsurf, wenn Sie den Code von Hand schreiben und parallele Läufe daneben wollen. Murmell, wenn es die Agenten sind, die schreiben, mehrere gleichzeitig, in derselben Ecke des Projekts, und jemand anderes zusehen soll. Wie die Reservierung funktioniert. --- ## Murmell frente a Windsurf Source: https://murmell.com/es/vs/windsurf La diferencia real Windsurf es explícito sobre su mecanismo, lo que hace fácil comparar con honestidad. Los agentes paralelos reciben worktrees: una segunda copia real de tus archivos en una rama propia, así que un agente que compila y prueba no molesta al espacio donde escribes. El modo arena va más allá y da un worktree a cada modelo para comparar sus respuestas a la misma petición. Es aislamiento bien hecho, y tiene el coste que el aislamiento siempre tiene. Veinte worktrees son veinte copias, y cada una termina con una fusión. El conflicto no se evita, se pospone al momento en que pulsas el botón. Murmell elimina las copias. Un directorio, y un agente reserva las rutas que va a tocar antes de escribir. El tablero mantiene un titular por ruta y niega a todos los demás hasta que la libera, así que un segundo agente espera treinta segundos en vez de producir una versión del archivo que habrá que reconciliar más tarde. Dónde gana Windsurf El editor, y el hecho de que esté en tu máquina. Nada se sube, el código se queda en tu disco, y los agentes trabajan sobre los archivos que tienes delante. Murmell no tiene opción auto-hospedada: si el código no puede salir, la pregunta está resuelta. Cuál elegir Windsurf cuando escribes el código a mano y quieres ejecuciones paralelas al lado. Murmell cuando son los agentes los que escriben, varios a la vez, en el mismo rincón del proyecto, y alguien más debe mirar. Cómo funciona la reserva. --- ## Murmell face à Windsurf Source: https://murmell.com/fr/vs/windsurf La vraie différence Windsurf est explicite sur son mécanisme, ce qui rend la comparaison facile à faire honnêtement. Les agents parallèles reçoivent des worktrees : une vraie deuxième copie de vos fichiers sur une branche à eux, donc un agent qui compile et teste ne dérange pas l'espace où vous tapez. Le mode arène va plus loin et donne un worktree à chaque modèle pour comparer leurs réponses sur la même demande. C'est de l'isolation bien faite, et elle a le coût que l'isolation a toujours. Vingt worktrees, c'est vingt copies, et chacune se termine par une fusion. Le conflit n'est pas évité, il est reporté au moment où vous appuyez sur le bouton. Murmell supprime les copies. Un dossier, et un agent réserve les chemins qu'il va toucher avant d'écrire. Le tableau tient un détenteur par chemin et refuse tous les autres jusqu'à ce qu'il le rende, donc un deuxième agent attend trente secondes au lieu de produire une version du fichier qu'il faudra réconcilier plus tard. Là où Windsurf gagne L'éditeur, et le fait qu'il soit sur votre machine. Rien n'est téléversé, le code reste sur votre disque, et les agents travaillent sur les fichiers que vous avez sous les yeux. Murmell n'a pas d'option auto-hébergée : si le code n'a pas le droit de sortir, la question est réglée. Lequel prendre Windsurf quand vous écrivez le code à la main et voulez des exécutions parallèles à côté. Murmell quand ce sont les agents qui écrivent, plusieurs en même temps, dans le même coin du projet, et que quelqu'un d'autre doit regarder. Comment la réservation fonctionne. --- ## Windsurf के मुकाबले Murmell Source: https://murmell.com/hi/vs/windsurf असली फ़र्क़ Windsurf अपने तरीके पर साफ़ है, जो इस तुलना को ईमानदारी से करना आसान बनाता है। समांतर एजेंट को worktree मिलते हैं: आपकी फ़ाइलों की एक असली दूसरी कॉपी, अपनी ब्रांच पर, इसलिए compile और test करने वाला एजेंट उस जगह को नहीं छेड़ता जहां आप टाइप करते हैं। Arena mode और आगे जाकर हर मॉडल को एक worktree देता है ताकि एक ही अनुरोध पर उनके जवाब तुलना किए जा सकें। यह अच्छी तरह किया गया अलगाव है, और इसकी कीमत वही है जो अलगाव की हमेशा रही है। बीस worktree का मतलब बीस कॉपियां, और हर एक आख़िर में एक मर्ज पर खत्म होती है। टकराव टलता नहीं, बस उस पल तक टल जाता है जब आप बटन दबाते हैं। Murmell कॉपियां हटा देता है। एक फ़ोल्डर, और लिखने से पहले एजेंट उन रास्तों को आरक्षित करता है जिन्हें वह छूने वाला है। बोर्ड हर रास्ते का एक मालिक रखता है और जब तक वह उसे न छोड़े बाकी सबको मना कर देता है, इसलिए दूसरा एजेंट फ़ाइल का ऐसा वर्ज़न बनाने की बजाय जिसे बाद में मिलाना पड़े, तीस सेकंड इंतज़ार करता है। जहां Windsurf जीतता है एडिटर, और यह तथ्य कि यह आपकी मशीन पर है। कुछ भी अपलोड नहीं होता, कोड आपकी डिस्क पर रहता है, और एजेंट उन्हीं फ़ाइलों पर काम करते हैं जो आपके सामने हैं। Murmell के पास कोई सेल्फ़-होस्टेड विकल्प नहीं: अगर कोड को बाहर जाने का हक़ नहीं, तो सवाल सुलझ गया। कौन सा लें Windsurf तब जब आप हाथ से कोड लिखते हैं और साथ में समांतर रन चाहते हैं। Murmell तब जब एजेंट खुद लिखते हैं, कई एक साथ, प्रोजेक्ट के एक ही कोने में, और किसी और को देखना हो। आरक्षण कैसे काम करता है। --- ## Murmell contro Windsurf Source: https://murmell.com/it/vs/windsurf La vera differenza Windsurf è esplicito sul proprio meccanismo, il che rende facile fare il confronto onestamente. Gli agenti paralleli ricevono worktree: una vera seconda copia dei tuoi file su un branch tutto loro, quindi un agente che compila e testa non disturba lo spazio dove scrivi. La modalità arena va oltre e dà un worktree a ogni modello per confrontare le loro risposte sulla stessa richiesta. È isolamento fatto bene, e ha il costo che l'isolamento ha sempre avuto. Venti worktree sono venti copie, e ognuna finisce con un'unione. Il conflitto non è evitato, viene rimandato al momento in cui premi il pulsante. Murmell elimina le copie. Una cartella, e un agente riserva i percorsi che toccherà prima di scrivere. La bacheca tiene un titolare per percorso e nega tutti gli altri finché non lo rilascia, quindi un secondo agente aspetta trenta secondi invece di produrre una versione del file da riconciliare più tardi. Dove vince Windsurf L'editor, e il fatto che sia sulla tua macchina. Niente viene caricato, il codice resta sul tuo disco, e gli agenti lavorano sui file che hai sotto gli occhi. Murmell non ha un'opzione auto-ospitata: se il codice non può uscire, la domanda è già risolta. Quale scegliere Windsurf quando scrivi il codice a mano e vuoi esecuzioni parallele accanto. Murmell quando sono gli agenti a scrivere, più insieme, nello stesso angolo del progetto, e qualcun altro deve guardare. Come funziona la prenotazione. --- ## MurmellとWindsurfの比較 Source: https://murmell.com/ja/vs/windsurf 本当の違い Windsurfは自分の仕組みについて明確で、それが比較を正直に行いやすくしています。並行するエージェント はworktreeを受け取ります。自分のブランチ上のあなたのファイルの本物の2つ目のコピーであり、コンパイル しテストするエージェントは、あなたが入力している環境を乱しません。アリーナモードはさらに進み、同じ 依頼への回答を比較するために各モデルにworktreeを与えます。 これはよくできた隔離であり、隔離が常に持つコストがあります。20個のworktreeは20個のコピーであり、 それぞれがマージで終わります。競合は避けられているのではなく、ボタンを押す瞬間まで先送りされている だけです。 Murmellはコピーをなくします。1つのディレクトリ、そしてエージェントは書き込む前に触れるパスを確保 します。ボードはパスごとに1人の所有者を保持し、解放されるまで他の全員を拒否します。だから2番目の エージェントは、後で調整が必要になるファイルのバージョンを生み出す代わりに、30秒待つだけです。 Windsurfが勝る場所 エディタと、それが自分のマシン上にあることです。何もアップロードされず、コードはディスクに残り、 エージェントはあなたが目の前にしているファイルの上で作業します。Murmellには自己ホスト型の選択肢が ありません。コードが外に出せないなら、その問いはすでに答えが出ています。 どちらを選ぶか 自分の手でコードを書き、隣で並行実行をしたいならWindsurfです。書くのがエージェントで、複数が同時に、 プロジェクトの同じ一角で動き、誰かが見る必要があるならMurmellです。 確保の仕組み。 --- ## Murmell과 Windsurf 비교 Source: https://murmell.com/ko/vs/windsurf 진짜 차이 Windsurf는 자신의 메커니즘을 명확히 밝히고 있어서 이 비교를 정직하게 하기 쉽습니다. 병렬 에이전트는 worktree를 받습니다. 자체 브랜치 위에 있는 여러분 파일의 진짜 두 번째 복사본이므로, 컴파일하고 테스트하는 에이전트가 여러분이 타이핑하는 공간을 방해하지 않습니다. 아레나 모드는 한 발 더 나아가 여러 모델이 같은 요청에 대한 답을 비교할 수 있도록 모델마다 worktree를 줍니다. 잘 만들어진 격리이고, 격리가 늘 그렇듯 대가를 치릅니다. worktree 20개는 복사본 20개이고, 각각은 병합으로 끝납니다. 충돌은 피해지는 것이 아니라 버튼을 누르는 순간으로 미뤄질 뿐입니다. Murmell은 복사본을 없앱니다. 디렉터리 하나, 그리고 에이전트는 쓰기 전에 건드릴 경로를 점유합니다. 보드는 경로마다 소유자 한 명을 유지하고 놓아줄 때까지 다른 모두를 거부하므로, 두 번째 에이전트는 나중에 조정해야 할 파일 버전을 만드는 대신 30초를 기다립니다. Windsurf가 이기는 지점 에디터, 그리고 그것이 여러분의 머신에 있다는 점입니다. 아무것도 업로드되지 않고, 코드는 디스크에 남으며, 에이전트는 여러분이 눈앞에 두고 있는 파일에서 작업합니다. Murmell에는 자체 호스팅 옵션이 없습니다. 코드가 밖으로 나갈 수 없다면 질문은 이미 답이 나온 것입니다. 어느 것을 고를지 직접 손으로 코드를 쓰고 옆에서 병렬 실행을 원한다면 Windsurf입니다. 에이전트들이 쓰는 쪽이고, 동시에 여럿이며, 프로젝트의 같은 구석에서, 다른 누군가가 지켜봐야 할 때는 Murmell입니다. 점유가 작동하는 방식. --- ## Murmell frente ao Windsurf Source: https://murmell.com/pt/vs/windsurf A diferença real Windsurf é explícito sobre seu mecanismo, o que torna a comparação fácil de fazer com honestidade. Os agentes paralelos recebem worktrees: uma segunda cópia de verdade dos seus arquivos em uma branch própria, então um agente que compila e testa não perturba o espaço onde você digita. O modo arena vai além e dá um worktree a cada modelo para comparar suas respostas sobre o mesmo pedido. É isolamento bem feito, e tem o custo que o isolamento sempre tem. Vinte worktrees são vinte cópias, e cada uma termina em uma fusão. O conflito não é evitado, é adiado para o momento em que você aperta o botão. Murmell elimina as cópias. Um diretório, e um agente reserva os caminhos que vai tocar antes de escrever. O painel mantém um titular por caminho e nega todos os outros até que ele o libere, então um segundo agente espera trinta segundos em vez de produzir uma versão do arquivo que precisará ser reconciliada depois. Onde o Windsurf ganha O editor, e o fato de estar na sua máquina. Nada é enviado, o código continua no seu disco, e os agentes trabalham nos arquivos que você tem diante dos olhos. Murmell não tem opção auto-hospedada: se o código não pode sair, a questão está resolvida. Qual escolher Windsurf quando você escreve o código à mão e quer execuções paralelas ao lado. Murmell quando são os agentes que escrevem, vários ao mesmo tempo, no mesmo canto do projeto, e alguém mais precisa assistir. Como a reserva funciona. --- ## Murmell против Windsurf Source: https://murmell.com/ru/vs/windsurf Настоящая разница Windsurf прямо раскрывает свой механизм, что делает это сравнение легко честным. Параллельные агенты получают worktree: настоящую вторую копию ваших файлов на их собственной ветке, поэтому агент, который компилирует и тестирует, не мешает пространству, где печатаете вы. Режим арены идёт дальше и даёт worktree каждой модели, чтобы сравнить их ответы на один и тот же запрос. Это хорошо сделанная изоляция, и у неё есть цена, которую изоляция всегда имеет. Двадцать worktree, это двадцать копий, и каждая заканчивается слиянием. Конфликт не избегается, он лишь откладывается до момента нажатия кнопки. Murmell убирает копии. Один каталог, и агент резервирует пути, которые собирается затронуть, перед тем как писать. Доска держит одного владельца на путь и отказывает всем остальным, пока он его не отпустит, поэтому второй агент ждёт тридцать секунд вместо того, чтобы создать версию файла, которую придётся согласовывать позже. Где выигрывает Windsurf Редактор, и то, что он на вашей машине. Ничего не загружается, код остаётся на диске, и агенты работают с файлами, которые у вас перед глазами. У Murmell нет опции самостоятельного хостинга: если код не может выйти наружу, вопрос уже решён. Что выбрать Windsurf, когда вы пишете код вручную и хотите параллельные запуски рядом. Murmell, когда пишут агенты, несколько одновременно, в одном участке проекта, и кто-то ещё должен наблюдать. Как работает резервирование. --- ## Murmell vs Windsurf Source: https://murmell.com/vs/windsurf The real difference Windsurf is explicit about the mechanism, which makes this an easy comparison to make honestly. Parallel agents get worktrees: a real second checkout of your files on a branch of its own, so one agent building and testing cannot disturb the workspace you are typing in. Arena mode goes further and gives each model its own worktree to compare answers on the same prompt. That is isolation done properly, and it has the cost isolation always has. Twenty worktrees is twenty copies, and every one of them ends with a merge. The conflict is not avoided, it is deferred to the moment you press the button. Murmell removes the copies. One directory, and an agent claims the paths it is about to touch before it writes. The board keeps one holder per path and refuses everybody else until it lets go, so a second agent waits for thirty seconds instead of producing a version of the file that has to be reconciled later. Where Windsurf wins The editor, and the fact that it is on your machine. Nothing is uploaded, the code stays on your disk, and the agents run against the same files you are looking at. Murmell has no self-hosted option, so if the code is not allowed to leave, that decides it. The command center is also a good answer to a real problem: agents running in more than one place need somewhere to be supervised from. It supervises them for one person, at one machine, which is where the two products part. Which to pick Windsurf when you are writing code by hand and want parallel runs beside you. Murmell when the agents are doing the writing, several at once, in the same corner of the project, and somebody else needs to watch. How the claim works. --- ## Murmell 对比 Windsurf Source: https://murmell.com/zh/vs/windsurf 真正的区别 Windsurf 对自己的机制说得很直白,这让这次对比很容易做得诚实。并行代理拿到的是 worktree:你文件真正的第二份拷贝,在属于它们自己的分支上,所以一个正在编译测试的代理不会打扰你正在敲字的那个工作区。竞技场模式走得更远,给每个模型一个 worktree,好在同一个请求上比较它们的回答。 这是做得很好的隔离,代价也是隔离一贯的代价。二十个 worktree 就是二十份拷贝,每一份最后都要合并一次。冲突没有被避免,只是被推迟到了你按下按钮的那一刻。 Murmell 去掉了拷贝这一步。一个目录,代理写入前先占用要动的路径。看板为每个路径保持一个持有者,拒绝所有其他人直到它被释放,所以第二个代理等的是三十秒,而不是产出一个日后还要协调的文件版本。 Windsurf 更强的地方 编辑器本身,以及它就在你自己的机器上这件事。没有任何东西被上传,代码留在你的硬盘上,代理处理的是你眼前的这些文件。Murmell 没有自托管选项:如果代码不允许离开,这个问题已经有了答案。 选哪个 自己动手写代码、想要旁边有并行执行时,选 Windsurf。写代码的是代理、多个同时进行、在项目的同一个角落、还需要别人旁观时,选 Murmell。占用机制如何运作。 --- ## Engineering notes from building Murmell Source: https://murmell.com/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Watching a terminal you do not host August 4, 2026 What it takes to keep a browser attached to an agent running on somebody else’s machine, and the two things that break silently when it is done carelessly. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever What a link has to carry to share a live coding session August 4, 2026 The three things a share link has to carry, and why the live preview behind it is the part that is easy to get dangerously wrong. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Codex on your laptop, Codex in the cloud, and a third place August 4, 2026 Why choosing between the Codex CLI and Codex cloud is a question about who is watching, not about how much compute you want. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container What stops Claude Code on its first launch in a container July 25, 2026 The three prompts that block a fresh Claude Code agent in a container, measured through a real pty. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Reserving a file before you write it July 25, 2026 Why several agents on one directory have to claim a path first, and what the server does when one of them does not. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace The machine that runs the agents holds no secrets July 25, 2026 Why the half of the server that executes model-written code is kept away from the database, and what the separation cost to build. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one What we found when we put agents on a cloud sandbox July 25, 2026 What a managed cloud sandbox platform allows and refuses, measured against a probe pool rather than read in a document. --- ## Entwicklungsnotizen aus dem Aufbau von Murmell Source: https://murmell.com/de/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Remote-PTY-Terminal-Streaming im Browser über WebSockets in Echtzeit 4. August 2026 Was nötig ist, um einen Browser zuverlässig mit einem entfernten Agenten zu verbinden, und welche zwei lautlosen Fehler drohen. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Live-Coding-Sessions teilen: Status-Synchronisation und Read-Only-Protokoll 4. August 2026 Die drei Bestandteile eines Freigabelinks und warum Live-Previews strenge Zugriffskontrollen erfordern. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Codex lokal vs. Codex in der Cloud: Multi-Agenten-Entwicklung im gemeinsamen Workspace 4. August 2026 Warum die Wahl zwischen Codex CLI und Cloud-Codex eine Frage der Aufsicht und nicht der Rechenleistung ist. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container Die 3 Hürden beim Erststart von Claude Code im Docker-Container 25. Juli 2026 Die drei interaktiven Hürden von Claude Code, gemessen an echten PTYs. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Datei-Reservierungssystem: Code-Konflikte bei mehreren KI-Agenten im selben Repo verhindern 25. Juli 2026 Warum mehrere Agenten in einem Verzeichnis Schreibansprüche anmelden müssen und wie der Server Konflikte verhindert. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace Zero-Trust-Cloud-Sandbox: Ausführungsmaschinen speichern keine Zugangsdaten 25. Juli 2026 Warum die ausführende Maschine isoliert ist und wie die Rollenarchitektur aufgebaut ist. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one Erkenntnisse beim Einsatz von KI-Agenten in Cloud-Sandboxes: Messungen und Praxis 25. Juli 2026 Was Cloud-Sandbox-Plattformen erlauben und verbieten, basierend auf realen Tests. --- ## Notas de ingeniería sobre la construcción de Murmell Source: https://murmell.com/es/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Cómo transmitir terminales PTY remotos al navegador en tiempo real con WebSocket 4 de agosto de 2026 Qué se necesita para mantener un navegador conectado a un agente en una máquina remota y los dos fallos silenciosos si se hace con descuido. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Compartir sesiones de código en vivo: protocolo de sincronización y enlaces de solo lectura 4 de agosto de 2026 Las tres cosas que transporta un enlace de sesión compartida y por qué la vista previa en vivo es crítica para la seguridad. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Codex local vs Codex en la nube: programar con múltiples agentes en un espacio compartido 4 de agosto de 2026 Por qué elegir entre Codex CLI y Codex cloud depende de la supervisión y no de la capacidad de cómputo. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container Los 3 problemas al iniciar Claude Code por primera vez en un contenedor Docker 25 de julio de 2026 Los tres bloqueos que frenan a Claude Code en un contenedor medidos a través de una pty real. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Reserva de archivos: cómo evitar que múltiples agentes de IA se sobreescriban en un repositorio 25 de julio de 2026 Por qué varios agentes en un directorio deben reclamar las rutas previamente y cómo actúa el servidor ante escrituras no autorizadas. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace Arquitectura Zero-Trust: la máquina en la nube que ejecuta los agentes no guarda credenciales 25 de julio de 2026 Por qué la máquina de ejecución está aislada de la base de datos y la arquitectura técnica empleada. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one Qué aprendimos al ejecutar agentes de IA en sandboxes en la nube: hallazgos y rendimiento 25 de julio de 2026 Lo que permite y deniega una plataforma de sandbox en la nube según mediciones reales. --- ## Notas de engenharia sobre a construção do Murmell Source: https://murmell.com/pt/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Streaming de terminais PTY remotos no navegador em tempo real com WebSocket 4 de agosto de 2026 O que é necessário para manter um navegador conectado a um agente remoto e as falhas silenciosas que ocorrem por descuido. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Compartilhar sessões de código ao vivo: Protocolo de sincronização e links somente leitura 4 de agosto de 2026 Os três elementos transportados por um link e por que o preview ao vivo exige isolamento rigoroso. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Codex local vs Codex na nuvem: Programação multi-agente num workspace compartilhado 4 de agosto de 2026 Por que escolher entre Codex CLI e Codex cloud depende da supervisão e não de poder computacional. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container Os 3 desafios ao iniciar o Claude Code pela primeira vez em contêiner Docker 25 de julho de 2026 Os três bloqueios interativos do Claude Code medidos em pty real. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Reserva de arquivos: Como evitar conflitos entre múltiplos agentes de IA no mesmo repositório 25 de julho de 2026 Por que múltiplos agentes devem reservar arquivos e como o servidor trata conflitos. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace Arquitetura Zero-Trust: A máquina na nuvem que executa os agentes não guarda credenciais 25 de julho de 2026 A arquitetura que mantém a execução isolada do banco de dados e dos segredos. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one O que aprendemos ao rodar agentes de IA em sandboxes na nuvem: Resultados e benchmarks 25 de julho de 2026 O que plataformas de sandbox permitem e bloqueiam, com base em testes práticos. --- ## Notes d’ingénierie sur la conception de Murmell Source: https://murmell.com/fr/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Observer un terminal que vous n’hébergez pas 4 août 2026 Ce qu’exige le maintien d’un navigateur connecté à un agent distant, et les deux défaillances silencieuses en cas de négligence. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Ce qu’un lien doit transporter pour partager une session de code en direct 4 août 2026 Les trois informations portées par un lien de partage, et pourquoi la prévisualisation en direct exige une sécurité sans compromis. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Codex sur votre portable, Codex dans le cloud, et un troisième espace 4 août 2026 Pourquoi choisir entre le CLI Codex et Codex cloud relève de l’observation du travail et non de la puissance de calcul. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container Ce qui bloque Claude Code lors de son premier lancement en conteneur 25 juillet 2026 Les trois invites qui bloquent un agent Claude Code dans un conteneur neuf, mesurées sur un véritable pty. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Réserver un fichier avant de l’écrire 25 juillet 2026 Pourquoi plusieurs agents sur un même dossier doivent réserver leurs chemins, et comment le serveur gère les conflits. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace La machine qui exécute les agents ne détient aucun secret 25 juillet 2026 Pourquoi la machine exécutant le code des agents est isolée des secrets et de la base de données, et l’architecture mise en œuvre. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one Ce que nous avons appris en déployant des agents sur une sandbox cloud 25 juillet 2026 Ce qu’une plateforme cloud de conteneurs autorise et refuse, mesuré sur banc d’essai réel. --- ## Note di ingegneria sullo sviluppo di Murmell Source: https://murmell.com/it/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Streaming di terminali PTY remoti nel browser in tempo reale tramite WebSocket 4 agosto 2026 Requisiti per mantenere un browser collegato a un agente remoto e i due guasti silenziosi da evitare. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Condividere sessioni di codice dal vivo: Protocollo di sincronizzazione e link di sola lettura 4 agosto 2026 I tre elementi di un link di condivisione e l’importanza della sicurezza nelle anteprime live. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Codex locale vs Codex nel cloud: Programmazione multi-agente in uno spazio condiviso 4 agosto 2026 Perché scegliere tra Codex CLI e Codex cloud dipende dalla supervisione richiesta e non dalla potenza di calcolo. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container I 3 ostacoli al primo avvio di Claude Code in un container Docker 25 luglio 2026 I tre blocchi interattivi di Claude Code misurati su veri pty. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Riserva dei file: Come evitare conflitti tra più agenti IA sullo stesso repository 25 luglio 2026 Perché più agenti devono richiedere i file in anticipo e come il server gestisce i conflitti. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace Architettura Zero-Trust: La macchina cloud che esegue gli agenti non custodisce credenziali 25 luglio 2026 L’architettura a ruoli che isola l’esecuzione dei modelli dai dati sensibili. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one Cosa abbiamo imparato eseguendo agenti IA in sandbox cloud: Risultati e benchmark 25 luglio 2026 Cosa consentono e bloccano le piattaforme di sandbox cloud secondo misurazioni reali. --- ## Инженерные заметки о создании Murmell Source: https://murmell.com/ru/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Потоковая передача вывода удаленного PTY-терминала в браузер через WebSocket 4 августа 2026 г. Что требуется для надежной связи браузера с удаленным агентом и две скрытые проблемы при неосторожной реализации. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Совместный просмотр сессий разработки: Протокол синхронизации и ссылки для чтения 4 августа 2026 г. Три компонента ссылки общего доступа и вопросы безопасности живого предпросмотра. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Локальный Codex vs Облачный Codex: Мультиагентная разработка в общем пространстве 4 августа 2026 г. Почему выбор между Codex CLI и Codex cloud зависит от формата контроля, а не от вычислительных мощностей. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container 3 проблемы при первом запуске Claude Code в Docker-контейнере 25 июля 2026 г. Три интерактивных барьера Claude Code, измеренные на реальных PTY. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused Резервирование файлов: Защита от конфликтов при работе нескольких ИИ-агентов в одном репо 25 июля 2026 г. Зачем агентам заранее запрашивать пути к файлам и как сервер предотвращает конфликты. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace Архитектура Zero-Trust: Облачные машины с агентами не содержат ключей и секретов 25 июля 2026 г. Почему машина исполнения изолирована от секретов и как устроена ролевая модель. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one Опыт запуска ИИ-агентов в облачных песочницах: Замеры и результаты тестирования 25 июля 2026 г. Реальные возможности и ограничения платформ облачных песочниц. --- ## Murmell निर्माण के इंजीनियरिंग नोट्स Source: https://murmell.com/hi/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing Browser में Remote PTY Terminal Streaming और Real-time Multi-user Observation 4 अगस्त 2026 रिमोट एजेंट से ब्राउज़र को जोड़े रखने की तकनीकी आवश्यकताएं और लापरवाही बरतने पर होने वाली दो शांत विफलताएं। Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever Live AI Coding Session Share करना: State Sync और Read Link प्रोटोकॉल 4 अगस्त 2026 शेयर लिंक के तीन घटक और लाइव प्रीव्यू का सुरक्षा ढांचा। Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory Local Codex बनाम Cloud Codex: Shared Workspace में मल्टी-एजेंट कोडिंग 4 अगस्त 2026 Codex CLI और क्लाउड Codex का चुनाव कंप्यूट क्षमता का नहीं बल्कि निगरानी के तरीके का है। Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container Docker Container में Claude Code पहली बार रन करने की 3 मुख्य चुनौतियां 25 जुलाई 2026 असली PTY पर मापी गई Claude Code की तीन शुरुआती रुकावटें। Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused File Reservation सिस्टम: एक ही Repo में कई AI Agents के बीच Conflicts कैसे रोकें 25 जुलाई 2026 मल्टी-एजेंट वातावरण में पाथ रिज़र्व करने की आवश्यकता और टकराव प्रबंधन। A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace Stateless Cloud Sandbox: AI Agent चलाने वाली मशीन में कोई Credentials नहीं होते 25 जुलाई 2026 एक्ज़ीक्यूशन मशीन को डेटाबेस और गोपनीय डेटा से अलग रखने वाला आर्किटेक्चर। A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one Cloud Sandbox में AI Agents चलाने के प्रैक्टिकल अनुभव और Benchmark Findings 25 जुलाई 2026 क्लाउड सैंडबॉक्स इंफ्रास्ट्रक्चर की वास्तविक क्षमताओं और सीमाओं का विश्लेषण। --- ## Murmell 개발 엔지니어링 노트 Source: https://murmell.com/ko/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing 원격 PTY 터미널의 WebSocket 실시간 스트리밍 및 다중 사용자 관찰 아키텍처 2026년 8월 4일 원격 에이전트와 브라우저를 안정적으로 연결하기 위한 기술 요건과 주의하지 않으면 발생하는 두 가지 오류. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever 라이브 코딩 세션 공유: 상태 동기화 및 읽기 전용 링크 프로토콜 2026년 8월 4일 공유 링크가 전달하는 세 가지 핵심 요소와 라이브 프리뷰의 보안 설계. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory 로컬 Codex vs 클라우드 Codex: 공유 작업 공간에서의 멀티 에이전트 협업 2026년 8월 4일 Codex CLI와 클라우드 Codex의 선택이 연산력이 아닌 감독 방식의 차이인 이유. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container Docker 컨테이너 환경에서 Claude Code 첫 실행 시 발생하는 3가지 문제와 해결책 2026년 7월 25일 실제 PTY 측정을 통해 분석한 Claude Code 초기 실행 차단 요인. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused 파일 사전 예약 시스템: 단일 저장소 내 다중 AI 에이전트 간 코드 충돌 방지 2026년 7월 25일 다중 에이전트 환경에서 경로를 선점해야 하는 이유와 서버의 충돌 방지 메커니즘. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace 제로 트러스트 클라우드 샌드박스: 에이전트 실행 머신에 자격 증명을 두지 않는 보안 설계 2026년 7월 25일 실행 머신을 데이터베이스 및 비밀 정보로부터 완벽히 분리하는 아키텍처. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one 클라우드 샌드박스에서 AI 에이전트를 구동하며 얻은 실측 결과와 벤치마크 분석 2026년 7월 25일 클라우드 샌드박스 인프라의 허용 및 제약 사항에 대한 실측 데이터. --- ## Murmell 開発エンジニアリングノート Source: https://murmell.com/ja/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing リモートPTY端末のWebSocketストリーミングとリアルタイム共同観察の設計 2026年8月4日 リモートマシン上のエージェントにブラウザを接続し続けるための技術要件と、放置すると発生する2つのサイレント障害。 Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever ライブコーディングセッション共有：状態同期と閲覧専用プロトコル 2026年8月4日 共有リンクが運ぶ3つの要素と、安全なライブプレビューを実現するアーキテクチャ。 Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory ローカルCodexとクラウドCodex：共有ワークスペースでの第3の開発形態 2026年8月4日 Codex CLI とクラウド Codex の選択が計算力ではなく監視スタイルの違いである理由。 Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container DockerコンテナでClaude Code初回起動時に直面する3つの技術課題 2026年7月25日 実 PTY 計測による Claude Code 初回起動時の3つの対話的ブロッキング要因。 Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused ファイル事前予約システム：同一リポジトリでの複数AIエージェントのコード衝突を防ぐ 2026年7月25日 複数エージェントがファイルパスを事前予約すべき理由とサーバーの競合制御。 A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace ゼロトラスト・クラウドサンドボックス：エージェント実行マシンに機密を置かない安全設計 2026年7月25日 実行環境をデータベースや秘密情報から完全隔離するアーキテクチャ。 A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one クラウドサンドボックスでAIエージェントを動かした実測結果とパフォーマンス検証 2026年7月25日 クラウドサンドボックス環境の許容事項と制約に関する実測検証。 --- ## 构建 Murmell 的工程手记 Source: https://murmell.com/zh/blog A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing 构建远程 PTY 终端流式传输与实时多人协同观察架构 2026年8月4日 保持浏览器与远程运行代理的可靠连接所需的技术细节，以及处理不当时会悄然发生的两类故障。 Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever 实时共享 AI 编程会话：只读链接协议与状态同步设计 2026年8月4日 共享链接必须承载的三项核心数据，以及为什么其背后的实时预览极易产生严重安全漏洞。 Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory 本地 Codex 与云端 Codex：在统一共享空间中的多代理协作 2026年8月4日 为什么选择 Codex CLI 还是云端 Codex 取决于谁在监督，而非算力大小。 Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container 容器中首次启动 Claude Code 的三个阻碍与解决方案 2026年7月25日 通过真实 pty 测量的全新容器中阻塞 Claude Code 代理启动的三道关卡。 Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused 写入前预留文件：解决多 AI 代理在同一仓库的代码冲突 2026年7月25日 为什么同一个目录中的多个代理必须先声明路径占用，以及当发生违规写入时服务器如何处理。 A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace 零信任云沙箱架构：运行 AI 代理的机器不持有凭据与敏感信息 2026年7月25日 为什么执行模型代码的机器与数据库彻底隔离，以及构建这一隔离架构的技术细节。 A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one AI 代理在云端沙箱运行的实测发现与工程踩坑记录 2026年7月25日 托管云沙箱平台所允许和拒绝的操作细节，全部来自真实探针集群的实测数据。 --- ## Codex local vs Codex na nuvem: Programação multi-agente num workspace compartilhado Source: https://murmell.com/pt/blog/codex-on-your-laptop-and-in-the-cloud «Local ou na nuvem» não é uma questão de poder de processamento, mas de contrato de trabalho e de quem acompanha a execução. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryA delegação retorna um diff. Agentes que já trabalham juntos no mesmo diretório dispensam reconciliações posteriores. Local: você no ciclo de interação A CLI local oferece a resposta mais rápida e direta, mas depende integralmente do computador ligado. Ela impede colaboração com o time e dificulta rodar múltiplos agentes simultâneos sem conflitos. Nuvem: a tarefa é delegada e retorna um diff O Codex cloud é excelente para tarefas isoladas e pontuais em projetos consolidados. Contudo, para construir novas aplicações com múltiplos agentes, o isolamento impede que um veja as definições do outro. O terceiro espaço: a CLI em máquina remota O Murmell oferece a CLI autêntica em um terminal na nuvem, sempre visível e colaborativo. Você preserva o controle da CLI e ganha a persistência da nuvem e o diretório compartilhado. Utiliza-se a sua própria conta oficial sem taxas adicionais de modelo. Como escolher Para tarefas pontuais e isoladas, use a nuvem assíncrona. Para desenvolver sistemas completos com múltiplos agentes e equipe, use um espaço compartilhado. A mecânica do repositório compartilhado é explicada em vários agentes de IA num repositório, e a inicialização em contêiner em primeira inicialização do Claude Code. --- ## Codex sur votre portable, Codex dans le cloud, et un troisième espace Source: https://murmell.com/fr/blog/codex-on-your-laptop-and-in-the-cloud « Local ou cloud » semble être une question de puissance brute, comme si la version cloud n’était que le même agent soutenu par une machine plus imposante. Il n’en est rien. Ce sont deux produits distincts avec des contrats différents, et ce qui diverge fondamentalement est la personne censée observer le déroulement. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryLa délégation produit un diff. Un agent déjà présent dans l’arborescence n’a rien à renvoyer. En local : vous êtes dans la boucle et fournissez l’environnement Le CLI sur votre machine offre la boucle la plus serrée. Il voit le dossier sur lequel vous travaillez, lance vos tests avec vos variables d’environnement et vous suivez chaque ligne en direct. La correction est immédiate car vous êtes présent dès qu’un écart survient. Cependant, l’exécution est liée à votre machine. L’opération cesse dès que vous rabattez l’écran. Un second agent exige une seconde copie de travail ou risque d’écraser le premier. Et personne d’autre ne peut observer l’avancement sans partage d’écran. Dans le cloud : la tâche part et un diff revient OpenAI conçoit Codex cloud pour exécuter des tâches dans des conteneurs isolés en parallèle, initiées depuis le web, GitHub, Linear ou Slack, avec un résumé et un diff au terme du processus. C’est un contrat précis : vous confiez une tâche et recevez une proposition de code. Pour une tâche bien délimitée sur un dépôt mature (corriger un test instable, mettre à jour une dépendance), ce contrat est parfait. Vous ne souhaitez pas observer l’agent mais obtenir une pull request. Ce modèle devient inadapté quand plusieurs agents construisent une même application de concert. L’isolation empêche le second agent de voir le type que le premier vient d’écrire une minute auparavant, provoquant des redéclarations et des conflits de fusion sur les fichiers générés. Réserver un fichier avant d’écrire expose cet argument en détail. Le troisième espace : le CLI sur une machine distante Il existe une alternative : le véritable CLI Codex, dans un terminal authentique, sur une machine cloud, toujours sous vos yeux. Vous conservez les atouts du local (le vrai CLI, la sortie intégrale, l’interruption à la volée) tout en profitant des avantages du cloud : l’exécution survit à la fermeture de votre portable et plusieurs agents collaborent dans un dossier unique grâce aux réservations de fichiers. De plus, n’importe quel collègue peut rejoindre la session d’un simple clic. Vous conservez vos comptes. Murmell ne revend pas de jetons : il démarre les CLI que vous possédez déjà (Codex, Claude Code) dans le même répertoire partagé. Choisir en toute clarté Pour une tâche unitaire dont vous attendez une pull request finale, déléguez-la à un service asynchrone. Pour concevoir une application avec plusieurs agents ou en équipe, l’exécution doit être partagée dans un répertoire commun. C’est la vision que nous bâtissons. Comparatif Murmell et Codex cloud met en regard ces deux approches. Le fonctionnement du dépôt partagé est détaillé dans plusieurs agents IA sur un même dépôt, et la configuration en conteneur dans ce qui bloque Claude Code au premier lancement. --- ## Codex local vs Codex en la nube: programar con múltiples agentes en un espacio compartido Source: https://murmell.com/es/blog/codex-on-your-laptop-and-in-the-cloud «Local o en la nube» suena a una pregunta sobre potencia de cómputo. En realidad son dos productos con contratos distintos, y lo que verdaderamente cambia es quién supervisa la ejecución. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryLa delegación devuelve un diff. Un agente que ya opera dentro del árbol de trabajo no necesita reconciliación posterior. Local: estás en el bucle de interacción y eres el entorno La CLI local ofrece el ciclo más directo. Ve tu código, ejecuta tus pruebas y te permite corregir al agente al instante. Sin embargo, está atado a tu máquina física: se detiene al cerrar la tapa y no permite colaboración en equipo. Nube: la tarea se delega y regresa como un diff Codex cloud ejecuta tareas en contenedores aislados y devuelve una propuesta final. Para tareas concretas en repositorios maduros es un modelo ideal. Pero cuando varios agentes construyen una aplicación juntos, el aislamiento les impide ver el código que acaban de escribir los demás, provocando duplicaciones y conflictos. El tercer espacio: la CLI en una máquina en la nube Existe una alternativa: la verdadera CLI de Codex ejecutándose en una máquina en la nube en un terminal auténtico, siempre visible. Conservas la inmediatez de la CLI local, la persistencia de la nube y la capacidad de compartir el espacio de trabajo con tu equipo. Mantienes tus cuentas oficiales sin sobrecostes por modelos. Cómo elegir de forma honesta Para tareas independientes delega en la nube asíncrona. Para construir aplicaciones en equipo con múltiples agentes, un directorio compartido con reservas es el camino adecuado. El funcionamiento del repositorio compartido se detalla en múltiples agentes de IA en un repositorio, y la configuración en contenedor en primer inicio de Claude Code. --- ## Codex locale vs Codex nel cloud: Programmazione multi-agente in uno spazio condiviso Source: https://murmell.com/it/blog/codex-on-your-laptop-and-in-the-cloud «Locale o cloud» non è una questione di pura potenza computazionale, ma di contratto operativo e supervisione. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryLa delega produce un diff. Agenti che collaborano nella stessa cartella non necessitano di riconciliazioni a posteriori. Locale: interazione diretta sul proprio dispositivo La CLI locale garantisce il controllo più immediato ma è vincolata allo stato del computer. Impedisce la collaborazione in team e complica l’uso di più agenti paralleli. Cloud: delega autonoma con ritorno di un diff Codex cloud è ideale per task ben delimitati su basi di codice mature. Tuttavia, per sviluppare nuove applicazioni con più agenti, l’isolamento impedisce la condivisione immediata del codice. Il terzo spazio: la CLI su macchina remota Murmell offre la vera CLI Codex in un terminale cloud sempre visibile e condivisibile. Combina i vantaggi della CLI con la persistenza del cloud e la prenotazione dei file. Si utilizzano gli account ufficiali senza costi aggiuntivi di intermediazione. Scegliere con chiarezza Per task isolati affidati al cloud asincrono. Per sviluppare sistemi completi con più agenti in team, scegli un ambiente condiviso. La gestione del repository condiviso è descritta in più agenti IA su un unico repository, e l’avvio in container in primo avvio di Claude Code. --- ## Codex lokal vs. Codex in der Cloud: Multi-Agenten-Entwicklung im gemeinsamen Workspace Source: https://murmell.com/de/blog/codex-on-your-laptop-and-in-the-cloud «Lokal oder Cloud» ist keine Frage der Rechenleistung, sondern eine Frage des Arbeitsvertrags und der Aufsicht. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryDelegation liefert ein Diff. Agenten, die bereits im selben Verzeichnis arbeiten, erfordern kein nachträgliches Zusammenführen. Lokal: Direkte Interaktion auf dem eigenen Rechner Die lokale CLI bietet die unmittelbarste Rückkopplung, endet jedoch beim Schließen des Laptops. Sie verhindert Team-Zusammenarbeit und erschwert parallele Agentenläufe ohne Dateikonflikte. Cloud: Autonome Delegation mit Ergebnis als Diff Cloud-Codex eignet sich hervorragend für abgegrenzte Einzelaufgaben in etablierten Repositories. Bei der gemeinsamen Erstellung neuer Anwendungen verhindert die Isolation jedoch, dass Agenten voneinander wissen. Der dritte Raum: Die CLI auf einer entfernten Maschine Murmell bietet die echte Codex CLI in einem Cloud-Terminal, dauerhaft sichtbar und kollaborativ. Sie behalten die direkte Kontrolle der CLI bei voller Cloud-Persistenz und Dateireservierung. Eigene offizielle Accounts werden direkt genutzt. Die richtige Wahl treffen Für unabhängige Einzelaufgaben delegieren Sie an die asynchrone Cloud. Für kollaborative Neuentwicklungen nutzen Sie ein geteiltes Verzeichnis. Die Mechanismen des geteilten Verzeichnisses werden in mehrere KI-Agenten in einem Repository erklärt, Container-Setups in Claude Code beim Erststart. --- ## Локальный Codex vs Облачный Codex: Мультиагентная разработка в общем пространстве Source: https://murmell.com/ru/blog/codex-on-your-laptop-and-in-the-cloud «Локально или в облаке» — это вопрос не вычислительной мощности, а формата надзора за исполнением задач. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryДелегирование возвращает diff. Агенты, работающие в общем дереве файлов, не требуют последующего слияния. Локально: прямое взаимодействие на личном компьютере Локальный CLI дает мгновенную обратную связь, но жестко привязан к включенному ноутбуку. Он не позволяет организовать командную работу и параллельный запуск агентов без конфликтов. Облако: автономная задача с возвратом в виде diff Codex cloud идеален для точечных задач в зрелых проектах. Однако при совместной разработке нового приложения изоляция мешает агентам видеть код друг друга. Третье пространство: CLI на удаленной машине Murmell предлагает запуск оригинального Codex CLI в облачном терминале с возможностью совместного просмотра. Вы сохраняете отзывчивость CLI, получая стабильность облака и безопасность резервирования файлов. Используются ваши собственные официальные аккаунты без скрытых наценок. Как сделать выбор Для изолированных задач делегируйте исполнение в асинхронное облако. Для командного создания проектов используйте общую директорию. Механика общего репозитория изложена в несколько ИИ-агентов в одном репозитории, а запуск в контейнере — в первый запуск Claude Code. --- ## Local Codex बनाम Cloud Codex: Shared Workspace में मल्टी-एजेंट कोडिंग Source: https://murmell.com/hi/blog/codex-on-your-laptop-and-in-the-cloud «लोकल या क्लाउड» केवल मशीन की शक्ति का प्रश्न नहीं है, बल्कि इस बात का है कि कार्य की निगरानी कौन कर रहा है। Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryटास्क सौंपने पर diff मिलता है। एक ही डायरेक्टरी में काम करने वाले एजेंटों को बाद में मर्ज करने की ज़रूरत नहीं होती। लोकल: आप सीधे संवाद में हैं लोकल CLI सबसे तेज़ प्रतिक्रिया देता है लेकिन लैपटॉप की स्थिति पर निर्भर रहता है। यह टीम सहयोग और बिना टकराव के कई एजेंट चलाने में बाधा बनता है। क्लाउड: कार्य सौंपना और diff प्राप्त करना स्पष्ट एकल कार्यों के लिए क्लाउड डेलिगेशन सबसे अच्छा है। लेकिन जब कई एजेंट नया ऐप बना रहे हों, तो अलगाव के कारण वे एक-दूसरे का कोड नहीं देख पाते। तीसरा स्थान: रिमोट मशीन पर असली CLI Murmell क्लाउड टर्मिनल में असली Codex CLI प्रदान करता है जो हमेशा दृश्यमान और साझा करने योग्य है। यह लोकल नियंत्रण और क्लाउड की निरंतरता को फ़ाइल रिज़र्वेशन के साथ जोड़ता है। आपके आधिकारिक खाते बिना किसी अतिरिक्त लागत के उपयोग होते हैं। सही विकल्प चुनना अलग-थलग कार्यों को क्लाउड को सौंपें। टीम और कई एजेंटों के साथ नए प्रोजेक्ट के लिए साझा कैनवस चुनें। साझा रिपॉजिटरी की प्रक्रिया एक ही रेपो में कई AI एजेंट में और कंटेनर सेटअप कंटेनर में Claude Code का पहला लॉन्च में समझाया गया है। --- ## 로컬 Codex vs 클라우드 Codex: 공유 작업 공간에서의 멀티 에이전트 협업 Source: https://murmell.com/ko/blog/codex-on-your-laptop-and-in-the-cloud «로컬인가 클라우드인가»는 하드웨어 스펙의 문제가 아니라 누가 작업을 감독하는가에 대한 계약의 차이입니다. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory작업 위임은 diff를 반환합니다. 동일한 디렉터리에서 협력하는 에이전트는 사후 병합이 필요하지 않습니다. 로컬: 사용자가 직접 상호작용하는 환경 로컬 CLI는 가장 즉각적인 피드백을 제공하지만 PC의 상태에 종속됩니다. 팀 협업이 어렵고 다중 에이전트 동시 실행 시 파일 덮어쓰기 위험이 있습니다. 클라우드: 작업을 위임하고 diff를 수령 명확히 정의된 단일 작업에는 비동기 클라우드 위임이 이상적입니다. 하지만 다중 에이전트로 새 앱을 구축할 때는 격리 환경으로 인해 상호 코드 참조가 불가능합니다. 제3의 공간: 원격 머신에서 실행되는 실제 CLI Murmell은 클라우드 터미널에서 실제 Codex CLI를 상시 구동 가능한 형태로 제공합니다. 로컬의 제어력과 클라우드의 영속성을 결합하고 파일 선점 시스템으로 충돌을 방지합니다. 공식 계정을 그대로 사용합니다. 선택의 기준 독립된 단일 작업은 비동기 클라우드에 위임하고, 협업 프로젝트는 공유 캔버스를 선택하세요. 공유 저장소 작동 방식은 단일 저장소에서의 다중 AI 에이전트 운용, 컨테이너 초기화는 Claude Code 첫 실행 시의 3가지 관문에서 확인하실 수 있습니다. --- ## ローカルCodexとクラウドCodex：共有ワークスペースでの第3の開発形態 Source: https://murmell.com/ja/blog/codex-on-your-laptop-and-in-the-cloud 「ローカルかクラウドか」はマシンスペックの問題と誤解されがちですが、本質は誰が作業を監督するかという契約の違いです。 Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryタスク委任は diff を返します。同じディレクトリ内で協調動作するエージェントは事後マージを必要としません。 ローカル：対話ループの中に人間がいる環境 手元の CLI は最も素早い修正ループを提供しますが、ノートPCの稼働状態に縛られます。 チーム共有が難しく、複数エージェントを同時実行するとファイル上書きのリスクが生じます。 クラウド：タスクを委任し diff を受け取る 明確に定義された単一タスクには非同期クラウド委任が最適です。 しかし複数エージェントで新規アプリを共創する場合、隔離環境では互いの型定義が見えずコンフリクトします。 第3の環境：リモートマシン上で動く本物の CLI Murmell は本物の Codex CLI をクラウド上の常時接続ターミナルで提供します。 ローカルの手応えとクラウドの永続性を両立し、ファイル予約により安全に協調動作します。 公式アカウントをそのまま利用できます。 選び方の基準 独立した個別タスクは非同期クラウドへ。複数エージェントやチームで開発を進めるなら共有キャンバスを選択してください。 共有リポジトリの仕組みは 同一リポジトリでの複数AIエージェント実行、コンテナ初期設定は Claude Code 初回起動の関門 をご覧ください。 --- ## 本地 Codex 与云端 Codex：在统一共享空间中的多代理协作 Source: https://murmell.com/zh/blog/codex-on-your-laptop-and-in-the-cloud “本地还是云端”听起来像是一个关于算力的问题，人们常以为云端版本只是给同一个代理配备了更强性能的服务器。事实并非如此。这是两种具备不同协作契约的产品，核心差异在于究竟由谁来监督执行过程。 Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directory委托任务返回一个 Diff。已经在目录树内部协同工作的代理则无需事后合并。 本地：你身处交互回路中，且你是运行时环境 本地机器上的 CLI 提供了最紧凑的反馈闭环。它能直接访问你正在查看的代码目录，使用你的本地环境变量运行测试，并且你能实时看到输出的每一行。由于你在现场，纠错最为迅速。 但它在各个维度上都受限于本地设备。盖上电脑即宣告运行结束。运行第二个代理需要第二份代码检出，否则两者会在同一个目录中发生写入冲突。而且没有屏幕共享，其他团队成员无法看到任何进展。 云端：任务被派发出去，最终返回一个 Diff OpenAI 对云端 Codex 的定位是在并行的隔离云环境中运行任务，从 Web、GitHub、Linear 或 Slack 触发，并在任务结束时返回总结与 Diff。这是一种明确的交付契约：你移交任务，最终得到代码提议，隔离是其设计核心。 对于成熟代码库中定义明确的独立任务（修复偶发测试故障、升级依赖、跨文件迁移模式），这种契约非常出色。你不需要监视过程，你只需要一份 Pull Request。 但当两三个代理协同构建同一个全新应用时，这种契约就会失效。隔离导致第二个代理无法感知第一个代理一分钟前刚定义好的类型，从而重复声明，导致生成文件发生严重的合并冲突。写入前先占用文件对该问题进行了全面剖析。 第三种形态：在远程机器上运行 CLI 本身 在这两者之间存在一个容易被忽视的形态：在云端机器的真实终端中运行相同的 Codex CLI，依然实时呈现在你的眼前。 你保留了本地运行的一切优势：真实的 CLI、完整的实时输出、随时打断的能力；同时获得了云端的一切优势：运行不受本地设备休眠影响，多个代理通过文件路径占用机制安全共享同一个目录。最重要的是，团队成员只要打开链接就能共同置身于协作空间中。 账号依然属于你。Murmell 不转售模型，而是在同一个项目目录中并排启动你已付费的 CLI（Codex、Claude Code）。切换工具不会破坏目录结构、文件占用记录或 Git 历史。 如何做出客观的选择 如果工作是一项边界清晰的独立任务且你期望获得 Pull Request，请直接委托给异步云端服务。 如果工作是一个需要多代理协同构建或需要多人实时把控方向的项目，执行环境必须置于所有人皆可访问的共享目录中。这正是我们构建的形态。Murmell 与 Codex cloud 的对比详细罗列了各项维度的异同。 关于共享仓库机制的解析请参阅 多个 AI 代理共用同一个仓库，容器配置请参阅 Claude Code 首次启动的阻碍。 --- ## Codex on your laptop, Codex in the cloud, and a third place Source: https://murmell.com/blog/codex-on-your-laptop-and-in-the-cloud “Local or cloud” sounds like a question about compute, and people ask it as though the cloud version were the same agent with a bigger machine behind it. It is not. The two are different products with different contracts, and the thing that actually differs is who is expected to be watching. Above, a task leaves for an isolated environment and returns as a diff. Below, the agent works inside the shared tree and there is nothing to hand back.a task, delegatedits own environmenta diffthe same agent, insideone directoryDelegation returns a diff. An agent already inside the tree has nothing to hand back. Local: you are in the loop, and you are the runtime The CLI on your own machine is the tightest version of the loop. It sees the checkout you are looking at, it can run your tests with your environment variables, and you read every line as it happens. Nothing is faster to correct, because you are already there when it goes wrong. It is also bound to the machine in every sense. The run ends with the lid. A second agent means a second checkout, or two agents writing over each other in one. And nobody else can see any of it without a call and a screen share. Cloud: the task leaves, and a diff comes back OpenAI describes Codex cloud as running tasks in isolated cloud environments, in parallel, started from the web, GitHub, Linear or Slack, with dedicated environments for the long ones and a summary and a diff at the end. Read that as a contract rather than as a feature list: you hand over a task, you get back a proposal, and the isolation is the design. For a well specified job in a mature repository, that contract is excellent. Fix this flake, upgrade that dependency, port this pattern across forty files. You did not want to watch, you wanted a pull request, and the environment being disposable is exactly right. It is the wrong contract for the case people describe to us most often, which is two or three agents building one application at the same time. Isolation makes the second agent unable to see the type the first one finished a minute ago, so it declares it again. On a young codebase the diffs collide on the generated files nobody owns. Reserving a file before you write it is that argument in full. The third place: the CLI itself, on a machine you do not own There is an option between the two that is easy to miss because it is not a different agent. It is the same Codex CLI, in a real terminal, on a cloud machine, still in front of you. You keep what local gives you: the real CLI, the whole output, the ability to interrupt it mid sentence. You gain what cloud gives you: the run outlives the lid, and several agents work in one directory instead of one each, because a claim on each path keeps them from writing over each other. And you gain the thing neither has, which is that somebody else can open the link and be in the room while it happens. The account stays yours. Murmell is not the agent and does not resell one; it starts the CLI you already pay for, beside Claude Code, in the same project directory. Switching between them leaves the directory, the reservations and the history where they are, because those belong to the canvas rather than to whichever CLI is attached to it. How to choose, honestly If the work is one bounded task and you want a pull request, delegate it. Codex cloud does that better than watching ever will, and it reaches into Slack and Linear where the work is already described. If the work is a thing being built, by more than one agent or in front of more than one person, then the run needs to be somewhere everybody can reach and the agents need to share a directory. That is a different shape, and it is the one we build. Murmell compared with Codex cloud puts the same three questions to both, side by side. The mechanics of sharing a repository are explained in multiple AI agents on one repo, and container setup in what stops Claude Code on first launch. --- ## Compartilhar sessões de código ao vivo: Protocolo de sincronização e links somente leitura Source: https://murmell.com/pt/blog/sharing-a-live-coding-session Compartilhar tela mostra a tela de alguém, o que não faz sentido para agentes que rodam por vinte minutos. Criamos um simples link para colocar o convidado na mesma sala. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverUm link, três assentos e nenhum endereço público exposto. Três elementos sem transmissão de vídeo Nenhum vídeo é transmitido. O link apenas carrega o canvas de destino, o nível de permissão e o nome do participante. As restrições de permissão são validadas criptograficamente no token e não apenas ocultadas na interface. Os participantes são desenhados no canvas com seus respectivos estados de observação ou edição. A segurança da prévia em tempo real O canvas exibe uma janela de prévia ao vivo conectada ao servidor local da sandbox. Evitamos a criação de domínios públicos para cada sandbox, eliminando riscos de vazamento de aplicações incompletas. A prévia é roteada diretamente pela conexão autenticada do canvas. O compromisso de engenharia Rotear o tráfego web pela sessão autenticada exige mais engenharia, mas proporciona segurança absoluta. A transformação da colaboração Transformar a sessão em um link elimina reuniões desnecessárias e mantém os agentes trabalhando continuamente. A colaboração ao vivo é apresentada em programação multiplayer com agentes de IA, e a estabilidade da conexão em observar um terminal remoto. --- ## Compartir sesiones de código en vivo: protocolo de sincronización y enlaces de solo lectura Source: https://murmell.com/es/blog/sharing-a-live-coding-session Compartir pantalla muestra la pantalla de una persona, lo cual no encaja con un agente que opera de forma autónoma durante veinte minutos. Lo que necesitábamos era un simple enlace que situara a quien lo abre dentro de la misma sala. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverUn enlace, tres asientos y una dirección pública que deliberadamente no existe. Tres elementos, ninguno de ellos un flujo de vídeo No se transmite ningún vídeo por streaming. La sesión no está en el portátil de nadie, así que unirse es cuestión de recibir tres datos: el lienzo, los permisos y el nombre de usuario. El permiso vive en el token de acceso y no solo en la interfaz gráfica. Un enlace sin permisos de escritura garantiza un aislamiento estricto. Cada participante aparece con un punto de color y su nombre, indicando si está observando o editando. La parte crítica: la vista previa en vivo Los agentes construyen una aplicación y el lienzo incluye una vista previa en vivo que refleja el servidor de desarrollo del sandbox. Rechazamos asignar nombres de dominio públicos a cada sandbox, ya que publicaría aplicaciones en desarrollo en direcciones predecibles. La vista previa se transmite exclusivamente a través de la sesión autenticada existente mediante peticiones hacia localhost dentro del sandbox. El compromiso asumido Hacer pasar el tráfico de desarrollo por la sesión autenticada requiere mayor ingeniería pero garantiza una seguridad total. Lo que realmente cambia el compartir Cuando una sesión es un enlace y no una máquina local, la colaboración ocurre sin fricción y los agentes no se detienen al cerrar la pestaña. La colaboración en tiempo real se explica en programación multijugador con agentes IA, y la conexión en observar un terminal remoto. --- ## Condividere sessioni di codice dal vivo: Protocollo di sincronizzazione e link di sola lettura Source: https://murmell.com/it/blog/sharing-a-live-coding-session La condivisione schermo tradizionale non è adatta per agenti autonomi. Abbiamo creato un link che consente di entrare direttamente nella stessa stanza virtuale. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverUn link, tre postazioni e nessun indirizzo pubblico esposto. Tre elementi senza streaming video Nessun flusso video viene trasmesso. Il link trasporta solo canvas, permessi e nome. I vincoli di autorizzazione sono applicati crittograficamente nel token e non solo nell’interfaccia. Ogni partecipante appare sul canvas con il proprio stato di visualizzazione o modifica. La sicurezza dell’anteprima live Il canvas integra una finestra di anteprima live collegata al server interno della sandbox. Rifiutiamo domini pubblici generici per evitare l’esposizione involontaria di codice in sviluppo. L’anteprima transita unicamente attraverso la connessione autenticata del canvas. Il compromesso ingegneristico Inoltrare il traffico tramite sessione richiede più lavoro ma assicura una protezione totale. L’impatto sulla collaborazione Rendere la sessione un link elimina le riunioni inutili e lascia gli agenti operare costantemente. La collaborazione in tempo reale è spiegata in programmazione multiplayer con agenti IA, e la gestione della connessione in osservare un terminale remoto. --- ## Streaming de terminais PTY remotos no navegador em tempo real com WebSocket Source: https://murmell.com/pt/blog/watching-a-terminal-you-do-not-host Mover um agente para a nuvem é a parte fácil: um contêiner, uma imagem e uma CLI. A parte que decide se o produto é utilizável é a conexão com o navegador que o assiste. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingO fluxo vai da direita para a esquerda. O congestionamento começa no navegador e quem pode agir está na outra ponta. O notebook deixa de ser o ambiente de execução A razão para mover um agente para fora do computador não é desempenho, mas desvincular a execução do dispositivo físico. Essa mudança coloca uma conexão de rede no centro da arquitetura, sujeita a lentidões e oscilações. A sandbox inicia a conexão de saída A máquina que executa os agentes não possui portas públicas. Ela abre uma conexão com o plano de controle e multiplexa todos os navegadores por ela. Isso foca os desafios de engenharia no comportamento da conexão ativa quando há lentidão de rede. Primeira falha silenciosa: medir o socket errado Um agente compilando código verborrágico gera dados mais rápido do que o navegador pode renderizar. Medir o socket local da sandbox é inútil, pois sua conexão com o plano de controle é rápida. O congestionamento real está no socket do navegador. A detecção deve ocorrer no leitor lento e a contrapressão deve retroceder via TCP até a sandbox. Pausar leituras no link compartilhado afeta outros usuários, logo as retenções devem durar apenas milissegundos. Segunda falha silenciosa: ping que sempre responde Pings de WebSocket recebem resposta automática da pilha de rede do sistema operacional, mascarando abas fechadas ou travadas. O plano de controle deve notificar explicitamente a saída do usuário para que o terminal não continue transmitindo no vazio. Por que isso não é secundário Colocar uma CLI em um contêiner é trivial. A confiabilidade reside na gestão transparente do estado da conexão. O quadro de reservas é tratado em um artigo próprio, e o isolamento de segredos em um terceiro. --- ## Cómo transmitir terminales PTY remotos al navegador en tiempo real con WebSocket Source: https://murmell.com/es/blog/watching-a-terminal-you-do-not-host Mover un agente a una máquina en la nube es la mitad fácil, y es de la que todo el mundo escribe: un contenedor, una imagen y una CLI dentro. La mitad que decide si el producto es utilizable es la conexión entre esa máquina y el navegador que la observa, y falla de dos maneras silenciosas. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingEl flujo viaja de derecha a izquierda. La congestión se origina en el navegador y el único actor que puede actuar está en el extremo opuesto. La pantalla deja de ser el entorno de ejecución La razón para mover un agente fuera de tu portátil no es que el portátil sea lento, sino que la ejecución deja de pertenecer a un dispositivo físico. El proceso del agente vive en la máquina que operamos; tu navegador solo envía pulsaciones y dibuja lo que recibe. Esa frase sitúa una conexión de red en el centro del producto. Cada pulsación y cada byte de salida cruza ahora una red sujeta a retrasos y desconexiones. El sandbox inicia la conexión saliente La máquina que ejecuta los agentes no tiene un punto de entrada público. Abre una conexión hacia el plano de control y la mantiene, multiplexando todos los navegadores sobre ese enlace. Esto significa que los fallos relevantes no tratan sobre la accesibilidad inicial, sino sobre lo que ocurre en un enlace activo que se degrada. Primer fallo silencioso: medir el socket incorrecto Un agente que compila un proyecto con abundante salida genera texto más rápido de lo que un navegador puede renderizarlo. Alguien debe frenar al productor. Medir el socket local del sandbox es un error, ya que su enlace con el plano de control es rápido y acepta todo de inmediato. El socket congestionado es el del navegador en el otro extremo. La detección debe ocurrir en el lector lento y la contrapresión debe viajar hacia atrás. El plano de control detiene la lectura del sandbox cuando el navegador se retrasa, permitiendo que TCP ajuste la ventana de recepción. Retener lecturas en un enlace compartido bloquea a los demás espectadores. Por tanto, las retenciones solo deben durar milisegundos y el control individual de velocidad corresponde al plano de control. Segundo fallo silencioso: un ping que siempre responde Un ping WebSocket estándar recibe respuesta de la pila de red del sistema operativo, no de la aplicación. Una pestaña cerrada o un ordenador suspendido seguirán respondiendo durante un tiempo. El extremo que termina el socket del navegador es el único que sabe si el usuario se ha ido, por lo que lo comunica explícitamente sobre el enlace. Por qué esto no es un detalle secundario Cualquiera puede meter una CLI en un contenedor. Lo que decide si los desarrolladores confían en dejar agentes trabajando es si la conexión es honesta sobre su estado. El tablero de reservas que evita colisiones se detalla en un artículo propio, y la separación de secretos en un tercero. --- ## Observer un terminal que vous n’hébergez pas Source: https://murmell.com/fr/blog/watching-a-terminal-you-do-not-host Déplacer un agent vers une machine cloud est la moitié simple, et c’est celle dont tout le monde parle. Un conteneur, une image, un CLI à l’intérieur. La moitié qui détermine si le produit est utilisable est la liaison entre cette machine et le navigateur qui l’observe, et elle échoue de deux manières qu’aucun test ne remarque et qu’aucun utilisateur ne rapporte correctement. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingLe flux sort de droite à gauche. La congestion commence au niveau du navigateur, et le seul acteur capable d’agir dessus se trouve à l’autre bout. L’ordinateur portable n’est plus le moteur d’exécution La raison de déplacer un agent hors de votre portable n’est pas un manque de puissance. C’est que l’exécution cesse d’appartenir à un appareil physique. Le processus de l’agent et son dépôt vivent sur la machine que nous opérons, votre navigateur transmet les frappes et dessine ce qui revient. Fermer l’écran interrompt l’observation mais pas le travail. Cette phrase place une liaison réseau au cœur du produit. Chaque frappe clavier et chaque octet de sortie traverse désormais un réseau susceptible de ralentir, de caler ou de disparaître sans prévenir. La sandbox initie la connexion sortante La machine exécutant les agents n’a aucun point d’entrée public. Elle ouvre une connexion vers le plan de contrôle et la maintient active, multiplexant tous les navigateurs connectés sur ce lien unique. C’est le modèle éprouvé des runners de CI auto-hébergés : rien à exposer, rien à rediriger, et fonctionnement immédiat derrière tout NAT. Cela implique que les pannes intéressantes ne concernent pas l’accessibilité, mais ce qui se produit sur un lien établi qui se dégrade. Première défaillance silencieuse : mesurer le mauvais socket Un agent compilant un projet verbeux produit du texte plus vite qu’un navigateur ne peut le rendre. Il faut ralentir le producteur. L’approche naïve consiste pour la sandbox à surveiller son propre socket : si le tampon grossit, on arrête d’écrire. C’est une erreur de mesure. Le socket de la sandbox est relié au plan de contrôle, qui est une machine rapide sur un réseau optimal acceptant tout immédiatement. Le socket engorgé est en réalité celui du navigateur, à l’autre bout, géré par un processus distinct. La détection doit s’opérer là où se trouve le lecteur lent, et la pression doit remonter en sens inverse. Le plan de contrôle surveille le socket du navigateur ; dès que celui-ci prend du retard, il cesse de lire la liaison avec la sandbox. TCP s’occupe du reste : la fenêtre de réception se ferme, le tampon de la sandbox augmente enfin, déclenchant l’arrêt d’écriture à la source. Retenir les lectures sur un lien partagé bloque les autres navigateurs. Un lien saturé signale une congestion globale, jamais la lenteur d’un seul spectateur. La rétention ne doit durer que quelques millisecondes, la limitation par spectateur restant la responsabilité du plan de contrôle. Seconde défaillance silencieuse : un ping qui répond toujours Vérifier la présence d’un client par un ping WebSocket est inopérant ici. Un ping reçoit une réponse de la pile réseau sous-jacente et non de l’application. Un onglet fermé, un ordinateur en veille ou une page plantée continuent de répondre aux pings pendant un temps. Le composant terminant le socket du navigateur est le seul à savoir avec certitude si le navigateur est parti. Il le notifie explicitement sur la liaison interne. Quand le lien meurt, chaque session active est fermée localement pour éviter qu’un terminal ne diffuse dans le vide. Ces règles évitent les fuites mémoire invisibles sur des machines délaissées et les sessions qui paraissent actives alors que l’utilisateur est parti depuis une heure. Pourquoi ce n’est pas un détail N’importe qui peut placer un CLI dans un conteneur. Ce qui incite les utilisateurs à laisser tourner leurs agents est la certitude que la liaison est transparente sur son propre état : elle détecte la congestion, identifie le départ du spectateur et agit en conséquence. Le tableau de réservation évitant les collisions entre agents fait l’objet d’un article dédié. L’isolation des secrets hors de la machine d’exécution en forme un troisième. Celui-ci décrit le lien invisible entre les deux. --- ## Streaming di terminali PTY remoti nel browser in tempo reale tramite WebSocket Source: https://murmell.com/it/blog/watching-a-terminal-you-do-not-host Spostare un agente su una macchina cloud è la parte semplice. La metà che determina l’usabilità del sistema è il collegamento stabile tra quella macchina e il browser. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingIl flusso scorre da destra a sinistra. La congestione inizia nel browser e la gestione avviene all’estremo opposto. Il computer portatile non è più l’ambiente di esecuzione La ragione per spostare gli agenti nel cloud è svincolare l’esecuzione dal dispositivo fisico. Questa scelta pone una connessione di rete al centro del prodotto, soggetta a latenze e interruzioni. La sandbox avvia la connessione verso l’esterno La macchina degli agenti non ha porte pubbliche e multiplexa tutti i browser su una sola connessione in uscita. Le complessità ingegneristiche riguardano quindi la gestione della congestione su connessioni attive. Primo guasto silenzioso: misurare il socket errato Un agente che compila genera testo più velocemente di quanto un browser possa visualizzarlo. Misurare il socket locale della sandbox è un errore, poiché il vero collo di bottiglia è il socket del browser all’altro capo. La contropressione deve risalire tramite TCP fino alla sandbox per regolare la velocità di scrittura. Le pause di lettura devono durare solo millisecondi per non bloccare gli altri osservatori. Secondo guasto silenzioso: un ping che risponde sempre I ping WebSocket ricevono risposta automatica dallo stack di rete del sistema operativo, mascherando tab chiuse o crash. Il piano di controllo deve comunicare esplicitamente la disconnessione alla sandbox. Perché questo aspetto è fondamentale Eseguire una CLI in un container è banale; l’affidabilità dipende dalla gestione veritiera dello stato della connessione. Il tabellone di prenotazione è descritto in un articolo dedicato e l’isolamento dei segreti in un terzo. --- ## Ce qu’un lien doit transporter pour partager une session de code en direct Source: https://murmell.com/fr/blog/sharing-a-live-coding-session Un partage d’écran montre l’écran d’un individu. C’est inadapté pour un agent opérant pendant vingt minutes, car l’intérêt réside dans le travail accompli par la machine et non dans le regard d’un observateur qui peut s’absenter. Nous voulions un simple lien : vous l’envoyez, la personne l’ouvre et se retrouve dans la pièce. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverUn lien, trois sièges, et une adresse publique qui n’existe délibérément pas. Trois éléments, sans aucun flux vidéo Aucun flux vidéo n’est transmis. La session ne tourne sur le portable de personne au départ, rejoindre la session ne consiste donc pas à dupliquer des pixels. Le lien ne transporte que trois faits : le canvas concerné, les autorisations de l’invité et le nom à lui attribuer. Le deuxième point est souvent sous-estimé. Un canvas en lecture seule et un canvas de travail présentent la même vue mais constituent deux produits distincts. La restriction réside dans le jeton d’accès et non dans l’interface graphique. Le troisième élément transforme un écran partagé en une pièce collaborative. Chaque participant est représenté par un point coloré et un nom, avec son état (observation ou édition). Une couleur vive sur ce canvas désigne toujours un agent ou un humain, jamais une décoration. Le piège critique de la prévisualisation Les agents construisent une application, et le but est de la voir s’exécuter. Le canvas intègre un aperçu en direct : une fenêtre affichant ce que le serveur de dev produit dans la sandbox, rafraîchi à chaque modification de code. La tentation classique est d’assigner un sous-domaine public à chaque sandbox. Nous avons exclu cette approche : toute URL publique prévisible exposerait sur Internet une application inachevée contenant potentiellement des failles ou des données sensibles. L’aperçu est donc relayé directement par la session authentifiée. Le navigateur interroge le plan de contrôle avec un jeton éphémère. Le plan de contrôle achemine la requête via le lien existant et la résolution de localhost s’effectue au cœur de la sandbox. Aucun nom d’hôte public n’existe. Le compromis assumé Relayer un serveur de développement via une session WebSocket demande davantage d’ingénierie que de configurer des DNS, et impose des limites sur les volumes de données. C’est le bon choix architectural. Un aperçu sert à vérifier la construction d’une application entre collaborateurs autorisés, avec le niveau exact de permissions du canvas, sans publication sauvage. Ce que le partage transforme Quand une session devient un lien plutôt qu’une machine locale, inviter un collègue ne nécessite plus d’organisation préalable ni d’appel vidéo. Les agents continuent leur travail même après fermeture de l’onglet. Garder ce navigateur connecté de façon intègre garantit qu’un second visiteur ne ralentit jamais le premier. La collaboration en direct est présentée dans coder à plusieurs avec des agents IA, et la résilience du flux dans observer un terminal distant. --- ## Live-Coding-Sessions teilen: Status-Synchronisation und Read-Only-Protokoll Source: https://murmell.com/de/blog/sharing-a-live-coding-session Eine Bildschirmübertragung zeigt den Bildschirm einer Person. Für autonom laufende Agenten brauchten wir stattdessen einen einfachen Link, der Teammitglieder in denselben Raum holt. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverEin Link, drei Plätze und eine öffentliche Adresse, die bewusst nicht existiert. Drei Elemente ohne Videostreaming Es wird kein Video übertragen. Der Link enthält lediglich die Ziel-Canvas-ID, die Berechtigungsstufe und den Nutzernamen. Berechtigungsprüfungen erfolgen kryptografisch im Token und nicht bloß oberflächlich in der Benutzeroberfläche. Jede Person wird auf dem Canvas mit ihrem aktuellen Status (Zuschauen oder Bearbeiten) dargestellt. Sicherheit der Live-Vorschau Das Canvas bietet eine Live-Vorschau des internen Entwicklungsservers der Sandbox. Wir verzichten bewusst auf öffentliche Subdomains, um die Veröffentlichung unfertiger Anwendungen zu verhindern. Die Vorschau wird über die bestehende authentifizierte WebSocket-Verbindung geroutet. Der architektonische Kompromiss Das Proxying über die Session erfordert mehr Entwicklungsaufwand, gewährleistet jedoch lückenlosen Schutz. Was das Teilen verändert Sessions als Links ermöglichen nahtlose Zusammenarbeit ohne Meetings, während Agenten im Hintergrund weiterarbeiten. Echtzeit-Zusammenarbeit wird in Multiplayer-Coding mit KI-Agenten vertieft, Verbindungskontrolle in ein Terminal beobachten. --- ## What a link has to carry to share a live coding session Source: https://murmell.com/blog/sharing-a-live-coding-session A screen share shows a person’s screen. That is the wrong shape for an agent that is going to run for twenty minutes, because the interesting thing is not what somebody is looking at, it is what the machine is doing, and the person may well be asleep. What we wanted instead was a link: you send it, somebody opens it, and they are in the room. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverOne link, three seats, and one address that deliberately does not exist. Three things, and none of them is a video stream Nothing is being streamed. The session is not on anybody’s laptop to begin with, so joining is not a matter of copying pixels from one machine to another. The link has to carry three facts and that is all: which canvas it opens, what the person opening it is allowed to do, and what to call them once they are there. The second one is the one people underestimate. A canvas handed out read only and a canvas handed out to work on are the same picture and a different product, and the difference has to live in the token rather than in the interface. An interface that hides the input box from a viewer is a suggestion; a link that never carried the right to write is a rule. The third turns a shared screen into a room. Every person on the canvas is a colored dot and a name, and the state next to it says whether they are watching or working. That is also the product’s one color rule doing its job: a saturated color on this canvas means an agent or a person, never decoration. The part that is easy to get dangerously wrong Agents build an application, and the point of watching them is seeing it run. So a canvas has a Live Preview: a window showing whatever the development server inside the sandbox is serving, refreshed as the code changes. The tempting implementation is a hostname per canvas. Give the sandbox a public address, point a wildcard certificate at it, done in an afternoon. We refused it, and the reasoning is the same one that governs the recording behind our own sign in: a URL that anybody can reach is a gate you can walk around, and it would mean the sharing feature quietly published somebody’s unfinished application to the internet on a guessable address. The preview is therefore served through the session that is already authenticated. The browser asks the control plane, on a path scoped to the canvas, carrying a grant that lasts minutes rather than forever. The control plane forwards the request across the same link the terminals use, and the fetch to localhost happens inside the sandbox, where it belongs. There is no preview hostname, because there is nothing that could be typed into a browser by somebody who was never given the canvas. What it costs Being honest about the trade: proxying a development server through a session is more work than pointing DNS at it, and it constrains what the preview can do. Every response passes through a bound on its size, and something a browser would happily stream from a public host has to fit through a channel that was built for terminal output. We think that is the right way round. A preview is for watching an application take shape in front of the people who are building it, and for that it needs to be exactly as reachable as the canvas and no more. Anything wider is a publishing feature nobody asked for, shipped by accident. The thing sharing actually changes Once a session is a link rather than a machine, the question of who can look at it stops being a scheduling problem. There is no call to set up and no screen to hand over, and the agents do not stop when the person who started them closes the tab. Keeping that browser attached honestly is its own piece of work, and the reason a second person opening the same canvas does not slow the first one down. How multiple people collaborate in real time is covered in multiplayer coding with AI agents, and connection resilience in watching a terminal you do not host. --- ## Remote-PTY-Terminal-Streaming im Browser über WebSockets in Echtzeit Source: https://murmell.com/de/blog/watching-a-terminal-you-do-not-host Einen Agenten auf eine Cloud-Maschine zu verlegen ist der einfache Teil. Der Teil, der über die Nutzbarkeit entscheidet, ist die stabile Verbindung zwischen dieser Maschine und dem beobachtenden Browser. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingDer Datenfluss läuft von rechts nach links. Engpässe entstehen im Browser, die Regelung erfolgt am entfernten Ende. Der Bildschirm ist nicht mehr die Laufzeitumgebung Der Grund, Agenten in die Cloud zu verlegen, ist nicht mangelnde lokale Rechenleistung, sondern die Entkopplung vom physischen Gerät. Jeder Tastenanschlag und jedes Byte Ausgabe durchquert nun ein Netzwerk, das Schwankungen unterliegt. Die Sandbox wählt sich aus Die Maschine mit den Agenten hat keinen öffentlichen Einstiegspunkt. Sie verbindet sich ausgehend mit der Steuerungsebene. Kritische Fehler betreffen daher nicht die Erreichbarkeit, sondern den Umgang mit Übertragungsverzögerungen. Erster lautloser Fehler: Den falschen Socket messen Ein Agent, der umfangreiche Builds ausführt, erzeugt mehr Text, als ein Browser rendern kann. Den lokalen Socket der Sandbox zu überwachen ist fehlerhaft, da die Verbindung zur Steuerungsebene schnell ist. Der Stau entsteht am Browser-Socket. Die Erkennung muss am langsamen Leser erfolgen und der Gegendruck über TCP an die Sandbox zurückgemeldet werden. Das Anhalten von Leseoperationen darf nur wenige Millisekunden dauern, um andere Zuschauer nicht zu blockieren. Zweiter lautloser Fehler: Ein Ping, der immer antwortet WebSocket-Pings werden vom Betriebssystem-Netzwerkstack beantwortet, nicht von der eigentlichen Web-App. Die Steuerungsebene muss das Schließen eines Tabs explizit über den internen Kanal an die Sandbox melden. Warum dies wesentlich ist Ein CLI in einen Container zu packen ist simpel. Wahre Zuverlässigkeit entsteht durch transparente Verbindungszustände. Das Reservierungs-Board wird in einem eigenen Artikel und die Geheimnis-Isolation in einem dritten behandelt. --- ## Watching a terminal you do not host Source: https://murmell.com/blog/watching-a-terminal-you-do-not-host Moving an agent to a cloud machine is the easy half, and it is the half everybody writes about. A container, an image, a CLI inside it. The half that decides whether the product is usable is the connection between that machine and the browser watching it, and it fails in two ways that no test notices and no user reports accurately. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingOutput runs right to left. The congestion starts at the browser, and the only party that can act on it is at the far end. The lid stops being the runtime The reason to move an agent off your laptop is not that laptops are slow. It is that the run stops belonging to a device. The agent’s process and its checkout live on the machine we run; your browser sends keystrokes and draws what comes back. Closing the lid ends the watching and not the work, and a long build heats up a machine nobody is sitting at. That sentence is easy to write and it puts a connection in the middle of the product. Every keystroke and every byte of output now crosses a network that is allowed to be slow, to stall, and to disappear without telling anybody. The sandbox dials out The machine that runs agents has no public entry point. It opens one connection to the control plane and keeps it, and every browser attached to that machine is multiplexed over that single link. This is the pattern a self-hosted CI runner uses, and it is chosen for the same reasons: nothing has to be exposed, nothing has to be forwarded, and a sandbox behind any amount of NAT works without configuration. It also means the interesting failures are not about reachability. They are about what happens on a link that is up and behaving badly. The first silent failure: measuring the wrong socket An agent that compiles something noisy can produce output faster than a browser can render it. Somebody has to notice and slow the producer down, and the obvious implementation is for the sandbox to watch its own socket: if the buffer grows, stop writing. That measures the wrong thing. The socket the sandbox holds is the link to the control plane, which is a fast machine on a good network and will happily accept everything it is given. The socket that is actually backing up is the one the browser holds, and it is at the other end, terminated by a different process. So the detection has to happen where the slow reader is, and the pressure has to travel back the other way. The control plane watches the browser socket it terminates, and when that browser stops keeping up it stops reading its own link to the sandbox. TCP does the rest: the receive window closes, and the congestion surfaces on the sandbox as its own buffer growing, which is the one place a decision to stop writing can be made. The price is worth naming, because it is the kind of thing that is discovered later and painfully. Holding reads on a shared link is head of line blocking for every other browser on it. A congested link says “this link is congested”, never “this one viewer is slow”, so a hold is only allowed to last milliseconds, and the per viewer limit stays the control plane’s job. Getting that wrong turns one person’s slow laptop into everybody’s stutter. The second silent failure: a ping that always answers The natural way to ask whether the other side is still there is a WebSocket ping. It is also useless for this question, and the reason is worth internalising: a ping is answered by the peer’s network stack, not by the peer’s application. A tab that has been closed, a laptop that has suspended, a page that has crashed: for a while, all of them answer. The half that terminates the browser socket is the only half that can know the browser is gone. So it says so, explicitly, on the link, and the sandbox learns it from that message and from nothing else. When the link itself dies, every connection still open on it is closed locally, once each, so that a terminal never streams output into an address that no longer points at anybody. Both rules exist because the symptom of getting them wrong is not an error. It is a slow leak of memory on a machine nobody is looking at, and a session that looks alive in a dashboard while the person it belongs to went to lunch an hour ago. Why this is not incidental Anyone can put a CLI in a container. What decides whether people leave agents running is whether the connection between the machine and the person is honest about its own state: it knows when it is congested, it knows when its reader is gone, and it says so instead of guessing. The reservation board that keeps several agents out of each other’s way is a different problem and has its own piece. The split that keeps secrets off the machine running model written code is a third. This one is the wire between them, and it is the part a demo never shows. --- ## Потоковая передача вывода удаленного PTY-терминала в браузер через WebSocket Source: https://murmell.com/ru/blog/watching-a-terminal-you-do-not-host Перенос агента на облачную машину — это легкая часть, о которой пишут все. Главная сложность заключается в организации надежного канала связи между этой машиной и браузером. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingПоток данных идет справа налево. Задержки возникают на стороне браузера, а регулирование происходит на удаленном конце. Ноутбук перестает быть средой исполнения Смысл переноса агентов в облако заключается в отвязке выполнения от физического устройства пользователя. Это помещает сетевое соединение в центр архитектуры, делая систему зависимой от качества канала связи. Песочница инициирует исходящее соединение Машина с агентами не имеет публичных портов и держит постоянное исходящее соединение с панелью управления. Поэтому критически важно уметь корректно обрабатывать деградацию качества связи на установленном соединении. Первая скрытая ошибка: измерение не того сокета Агент при активной компиляции генерирует вывод быстрее, чем браузер успевает его отрисовать. Контролировать локальный сокет песочницы бесполезно, так как канал к панели управления быстр. Буферизация происходит на сокете браузера. Обнаружение должно происходить на медленном приемнике, а противодавление транслироваться обратно через TCP в песочницу. Приостановка чтения общего канала не должна превышать нескольких миллисекунд во избежание блокировки других зрителей. Вторая скрытая ошибка: Ping, который всегда отвечает На WebSocket ping отвечает сетевой стек ОС, а не веб-приложение, поэтому закрытые вкладки долго кажутся активными. Панель управления должна явно уведомлять песочницу о закрытии браузера. Почему это важно Запустить CLI в контейнере может каждый. Реальная польза возникает тогда, когда соединение честно отражает свое состояние. Система резервирования файлов описана в отдельной статье, а изоляция секретов — в третьей части. --- ## Совместный просмотр сессий разработки: Протокол синхронизации и ссылки для чтения Source: https://murmell.com/ru/blog/sharing-a-live-coding-session Трансляция экрана не подходит для автономно работающих агентов. Нам нужна была простая ссылка, открыв которую, коллега сразу попадает в общую рабочую комнату. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverОдна ссылка, три рабочих места и принципиальное отсутствие публичного адреса. Три элемента вместо видеотрансляции Никакое видео не передается. Ссылка несет идентификатор холста, уровень прав и имя участника. Разграничение прав заложено в криптографическом токене, а не просто скрыто в интерфейсе. Каждый участник отображается на холсте с указанием режима: наблюдение или редактирование. Безопасность живого предпросмотра Холст включает окно предпросмотра, транслирующее локальный сервер разработки из песочницы. Мы отказались от публичных поддоменов, исключив случайную публикацию недописанного кода в открытом доступе. Предпросмотр передается через существующую аутентифицированную сессию. Инженерный компромисс Проксирование через сессию сложнее настройки DNS, но обеспечивает абсолютную изоляцию. Как это меняет командную работу Сессия по ссылке избавляет от лишних звонков, а агенты продолжают работу независимо от присутствия пользователей. Совместная разработка в реальном времени описана в совместное написание кода с ИИ-агентами, а управление сокетами — в наблюдение за удаленным терминалом. --- ## Browser में Remote PTY Terminal Streaming और Real-time Multi-user Observation Source: https://murmell.com/hi/blog/watching-a-terminal-you-do-not-host एजेंट को क्लाउड मशीन पर ले जाना आसान हिस्सा है। उत्पाद की उपयोगिता इस बात पर निर्भर करती है कि उस मशीन और ब्राउज़र के बीच का कनेक्शन कितना स्थिर है। A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writingडेटा प्रवाह दाएँ से बाएँ चलता है। रुकावट ब्राउज़र पर होती है और नियंत्रण सुदूर छोर पर किया जाता है। स्क्रीन अब रनटाइम नहीं है एजेंट को लैपटॉप से हटाने का कारण गति नहीं, बल्कि काम को भौतिक उपकरण से मुक्त करना है। अब हर कीस्ट्रोक और आउटपुट बाइट नेटवर्क से होकर गुजरता है। सैंडबॉक्स बाहर की ओर कनेक्शन बनाता है एजेंट मशीन पर कोई पब्लिक पोर्ट नहीं होता। यह कंट्रोल प्लेन से एक आउटबाउंड कनेक्शन बनाकर सभी ब्राउज़र को उसी पर जोड़ता है। इसलिए मुख्य चुनौती सक्रिय कनेक्शन पर कंजेशन को नियंत्रित करने की होती है। पहली शांत विफलता: गलत सॉकेट मापना तेज़ बिल्ड प्रक्रिया ब्राउज़र की रेंडरिंग क्षमता से अधिक तेज़ी से आउटपुट उत्पन्न करती है। सैंडबॉक्स सॉकेट को मापने से रुकावट का पता नहीं चलता क्योंकि असली रुकावट ब्राउज़र सॉकेट पर होती है। धीमे पाठक पर रुकावट पहचान कर TCP के ज़रिए बैकप्रेशर सैंडबॉक्स तक भेजा जाता है। साझा लिंक पर रुकावट कुछ मिलीसेकंड ही रहनी चाहिए ताकि अन्य दर्शक प्रभावित न हों। दूसरी शांत विफलता: पिंग जो हमेशा उत्तर देता है WebSocket ping का उत्तर OS नेटवर्क स्टैक स्वचालित रूप से देता है, जिससे बंद टैब भी सक्रिय प्रतीत होते हैं। कंट्रोल प्लेन स्पष्ट रूप से सैंडबॉक्स को ब्राउज़र हटने की सूचना भेजता है। यह क्यों महत्वपूर्ण है कंटेनर में CLI चलाना सरल है, लेकिन कनेक्शन की स्थिति का सही प्रबंधन ही विश्वसनीयता तय करता है। फ़ाइल टकराव रोकने वाला बोर्ड अलग लेख में और सुरक्षा ढांचा तीसरे लेख में समझाया गया है। --- ## Live AI Coding Session Share करना: State Sync और Read Link प्रोटोकॉल Source: https://murmell.com/hi/blog/sharing-a-live-coding-session स्क्रीन शेयरिंग केवल एक व्यक्ति की स्क्रीन दिखाती है, जो स्वायत्त एजेंटों के लिए सही नहीं है। हमें एक साधारण लिंक चाहिए था जिससे कोई भी उसी कमरे में प्रवेश कर सके। Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comneverएक लिंक, तीन सीटें, और कोई सार्वजनिक पता नहीं। बिना वीडियो स्ट्रीमिंग के तीन तत्व कोई वीडियो स्ट्रीम नहीं भेजा जाता। लिंक केवल कैनवस आईडी, अनुमति और उपयोगकर्ता नाम भेजता है। अनुमतियाँ टोकन स्तर पर जाँची जाती हैं, केवल यूआई में छिपाई नहीं जातीं। प्रत्येक व्यक्ति रंगीन कर्सर के साथ अपनी स्थिति (देखना या संपादन) के साथ दिखाई देता है। लाइव प्रीव्यू की सुरक्षा कैनवस में सैंडबॉक्स के अंदर चलने वाले डेवलपमेंट सर्वर का लाइव प्रीव्यू शामिल होता है। हमने पब्लिक सबडोमेन को अस्वीकार किया ताकि अधूरा कोड इंटरनेट पर लीक न हो। प्रीव्यू प्रमाणित WebSocket सेशन के ज़रिए ही localhost पर भेजा जाता है। इंजीनियरिंग समझौता सेशन के माध्यम से प्रॉक्सी करना अधिक कठिन है लेकिन पूर्ण सुरक्षा प्रदान करता है। सहयोग में बदलाव सेशन लिंक बनने से बिना किसी मीटिंग के टीम के साथ काम करना और देखना आसान हो जाता है। लाइव सहयोग प्रणाली AI एजेंटों के साथ मल्टीप्लेयर कोडिंग में और कनेक्शन सुरक्षा रिमोट टर्मिनल की निगरानी में विस्तृत है। --- ## 라이브 코딩 세션 공유: 상태 동기화 및 읽기 전용 링크 프로토콜 Source: https://murmell.com/ko/blog/sharing-a-live-coding-session 화면 공유는 장시간 자율 작동하는 에이전트에 적합하지 않습니다. 링크 하나로 같은 가상 공간에 입장할 수 있는 시스템을 구축했습니다. Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever하나의 링크, 세 개의 좌석, 그리고 존재하지 않는 공개 주소. 비디오 스트리밍이 아닌 세 가지 정보 비디오를 스트리밍하지 않으며 대상 캔버스, 권한, 사용자 이름만 전송합니다. 권한 제한은 UI 요소 숨김이 아니라 토큰 레벨에서 엄격히 검증됩니다. 참여자는 이름이 표시된 컬러 커서로 상태(관찰/편집)와 함께 표시됩니다. 라이브 프리뷰 보안 캔버스는 샌드박스 내부 개발 서버의 출력을 보여주는 라이브 프리뷰를 제공합니다. 미완성 코드 유출을 방지하기 위해 공개 서브도메인 할당을 배제했습니다. 프리뷰는 인증된 WebSocket 세션을 통해서만 localhost로 프록시됩니다. 설계상 절충안 세션을 통한 프록시는 구현이 까다롭지만 완벽한 접근 제어를 보장합니다. 협업 방식의 변화 세션이 링크화되면서 별도 미팅 없이도 언제든 에이전트의 작업을 공유하고 검토할 수 있습니다. 실시간 협업 메커니즘은 AI 에이전트와의 멀티플레이어 코딩, 스트리밍 제어는 직접 호스팅하지 않는 터미널 관찰에서 다룹니다. --- ## 원격 PTY 터미널의 WebSocket 실시간 스트리밍 및 다중 사용자 관찰 아키텍처 Source: https://murmell.com/ko/blog/watching-a-terminal-you-do-not-host 에이전트를 클라우드로 옮기는 것은 쉬운 절반입니다. 제품의 사용성을 결정하는 핵심은 원격 머신과 브라우저 사이의 안정적인 연결 제어입니다. A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing출력은 오른쪽에서 왼쪽으로 흐릅니다. 정체는 브라우저에서 시작되며 제어는 원격지에서 수행됩니다. 화면이 더 이상 런타임이 아니다 에이전트를 클라우드로 옮기는 이유는 성능 때문이 아니라 실행을 특정 물리 기기로부터 분리하기 위함입니다. 모든 키 입력과 출력 바이트가 네트워크를 경유하게 됩니다. 샌드박스의 아웃바운드 연결 에이전트 머신에는 공개 엔드포인트가 없으며 제어 평면을 향해 단일 연결을 유지하고 모든 브라우저를 멀티플렉싱합니다. 따라서 도달 가능성보다 연결 유지 중 발생하는 혼잡 제어가 중요합니다. 첫 번째 은밀한 장애: 잘못된 소켓 측정 로그가 많은 빌드는 브라우저 렌더링 속도보다 빠르게 출력을 생성합니다. 샌드박스 로컬 소켓을 측정하면 제어 평면과의 고속 네트워크로 인해 버퍼 정체를 감지할 수 없습니다. 느린 수신측에서 감지하여 TCP 백프레셔를 샌드박스까지 역방향으로 전달해야 합니다. 공유 링크의 읽기 일시 중단은 수 밀리초 단위로 신속하게 제어되어야 합니다. 두 번째 은밀한 장애: 항상 응답하는 Ping WebSocket ping은 OS 네트워크 스택이 자동 응답하므로 닫힌 탭도 응답하는 문제가 발생합니다. 제어 평면이 브라우저 종료를 샌드박스에 명시적으로 전달해야 합니다. 이것이 핵심인 이유 CLI를 컨테이너에 넣는 것은 간단합니다. 연결 상태를 정직하게 관리하는 것이 실용성의 핵심입니다. 파일 충돌 방지 보드는 별도 글에서, 비밀 정보 격리는 세 번째 글에서 다룹니다. --- ## ライブコーディングセッション共有：状態同期と閲覧専用プロトコル Source: https://murmell.com/ja/blog/sharing-a-live-coding-session 画面共有は1人の画面を映すだけですが、20分間自律動作するエージェントには不向きです。必要なのはURL1つで同じ部屋に入れる仕組みでした。 Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever1つのリンク、3つの席、そして意図的に存在しない公開アドレス。 動画配信ではない3つの情報 動画ストリーミングは一切行いません。リンクが運ぶのは、対象キャンバス、権限、ユーザー名のみです。 閲覧権限の制限はUIの非表示だけでなく、トークンレベルで厳格に制御されます。 参加者は名前付きカラーカーソルで表示され、閲覧中か編集中かが一目で分かります。 ライブプレビューの安全設計 キャンバスには開発サーバーの出力を描画するライブプレビューウィンドウが含まれます。 公開サブドメインを割り当てると未完成アプリが外部流出するため、これを排除しました。 プレビューは認証済み WebSocket セッションを経由して localhost へアクセスします。 設計上のトレードオフ セッション経由のプロキシはDNS設定より複雑ですが、完全なアクセス制限を実現できます。 共有がもたらす変化 セッションがリンクになることで、事前の会議設定なしにいつでもエージェントの作業を共有・確認できます。 リアルタイム協調開発の詳細は AIエージェントとのマルチプレイヤー開発、ターミナル接続制御は 自分がホストしていないターミナルを見守る技術 をご覧ください。 --- ## リモートPTY端末のWebSocketストリーミングとリアルタイム共同観察の設計 Source: https://murmell.com/ja/blog/watching-a-terminal-you-do-not-host エージェントをクラウドマシンに移すのは簡単な半分であり、誰もが語る部分です。製品の実用性を左右するもう半分は、そのマシンとブラウザ間の接続制御です。 A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing出力は右から左へ流れます。輻輳はブラウザ側で発生し、対応できる唯一の主体は遠隔地にいます。 画面が実行環境ではなくなる エージェントをローカルから移す理由はPCの性能ではなく、実行を特定デバイスから解放するためです。 これにより、すべてのキーストロークと出力バイトがネットワークを経由することになります。 サンドボックスが外向きに接続する エージェントを実行するマシンには公開ポートがありません。制御プレーンに対して1本の外向き接続を張り、全ブラウザを多重化します。 したがって、到達性ではなく、接続維持時の輻輳制御こそが重要になります。 第1のサイレント障害：誤ったソケットの監視 大量のログを出すビルドでは、ブラウザの描画能力を超える速度で出力が生成されます。 サンドボックス自身のソケットを監視しても、制御プレーンとの高速回線では詰まりません。詰まっているのはブラウザ側のソケットです。 遅い受信側で検知し、TCPのバックプレッシャーをサンドボックスまで伝播させて書き込みを一時停止します。 共有リンクでの読み込み停止は他者にも影響するため、ミリ秒単位で素早く制御します。 第2のサイレント障害：常に返答してしまう Ping WebSocket の ping は OS のネットワークスタックが自動返答するため、タブを閉じても反応し続けます。 制御プレーンがブラウザの切断を明示的にサンドボックスへ送信し、不要な出力を止めます。 なぜこれが本質なのか CLI をコンテナに入れるだけなら誰でもできます。接続状態を正直に管理することこそが実用性の分かれ目です。 ファイルの衝突を防ぐ予約ボードは専用記事で、秘密情報の分離は第3の記事で解説しています。 --- ## 实时共享 AI 编程会话：只读链接协议与状态同步设计 Source: https://murmell.com/zh/blog/sharing-a-live-coding-session 屏幕共享展示的是某个人的屏幕画面。对于可能持续运行二十分钟的代理而言，这种模式并不适用，因为关键在于机器正在做什么，而发起者可能已经去休息了。我们想要的是一个简单的链接：发送出去，对方点击打开，便直接置身于同一个房间中。 Three named people on one canvas, reached by a link. The preview is served through the session; a public address for it is refused.one linkaminaeditingmosseditingjonasviewinglive preview*.preview.murmell.comnever一个链接，三个席位，以及一个刻意不存在的公网地址。 三项数据，且没有一项是视频流 系统没有传输任何视频流。会话原本就没有运行在任何人的笔记本上，因此加入并不是在两台电脑之间复制像素。链接只需传递三个基本事实：打开哪块画布、进入者被允许做什么，以及在房间里如何称呼他们。 第二点往往被人们低估。只读画布与可编辑画布展现相同的画面，但属于两种完全不同的产品形态，这种差异必须固化在 Token 权限中，而不能仅停留在前端界面上。对观察者隐藏输入框只是一种界面建议；而未授予写权限的链接则是不可逾越的安全规则。 第三点将共享屏幕转变为协作空间。画布上的每个人都显示为一个彩色圆点和名字，旁边的状态标明他们是在观看还是在编辑。画布上的鲜艳色彩只代表代理或人类，绝不用于装饰。 极易产生严重安全隐患的预览环节 代理负责构建应用程序，观看它们的核心目的在于观察应用的运行效果。因此画布提供了实时预览：一个展示沙箱内开发服务器渲染内容的窗口，并随代码修改自动刷新。 最具有诱惑力但也最危险的做法是为每个沙箱分配独立的公网二级域名。我们坚决拒绝了这种方案：任何公开可访问的 URL 都是可被绕过的后门，这意味着共享功能会悄然将某人未完成的开发应用以可猜测的域名发布到公网上。 因此，预览完全通过已认证的会话通道进行转发。浏览器向控制平面发起请求，携带分钟级有效期的短期授权凭据。控制平面通过终端复用的同一链路转发请求，并在沙箱内部请求 localhost。根本不存在任何公网预览主机名。 为此付出的权衡代价 通过 WebSocket 会话反向代理开发服务器比单纯配置 DNS 复杂得多，并对单次响应大小施加了上限约束。 我们认为这种取舍是完全正确的。预览的初衷是让构建应用的团队成员实时验证成果，其可访问范围应严格等同于画布本身的权限，杜绝任何意外的公开泄露。 共享机制真正改变了什么 当会话变成一个链接而非一台本地机器时，协作不再需要预约时间或发起会议，即使创建者关闭标签页，代理也会持续运转。保持浏览器与远程终端的可靠连接探讨了底层的连接保障。 关于实时多人协作的机制请参阅 与 AI 代理的多人协作编码，终端流控请参阅 观察不属于你的终端。 --- ## 构建远程 PTY 终端流式传输与实时多人协同观察架构 Source: https://murmell.com/zh/blog/watching-a-terminal-you-do-not-host 把代理搬到云端机器上是简单的一半，也是所有人都在讨论的一半：一个容器、一个镜像、里面运行着 CLI。决定产品是否可用的另一半，是这台机器与观察它的浏览器之间的连接，它会以任何测试都无法察觉、用户也无法准确报告的两种方式悄然失效。 A browser, a control plane and a sandbox. Output flows right to left; the congestion that starts at the browser has to be felt at the sandbox.browsercontrolsandboxoutputoutputslowholdreceive window closesstop writing输出从右向左流动。拥塞始于浏览器端，而唯一能够采取干预措施的参与方却在最远端。 笔记本不再是运行环境 把代理移出笔记本的原因并不是笔记本速度慢，而是让执行过程不再依附于某台物理设备。代理的进程和代码检出运行在我们运营的机器上；你的浏览器负责传输按键并渲染回传的字符。合上笔记本只会中断旁观，不会停止工作。 这一句话在产品的核心位置引入了一条网络连接。每一次按键和每一个字节的输出现在都要穿越一条可能变慢、停滞或毫无预兆中断的网络链路。 沙箱主动发起外联 运行代理的机器没有公开的入口点。它向控制平面打开一条连接并长期保持，连接到该机器的所有浏览器都通过这一条链路进行多路复用。这是自托管 CI runner 采用的模式，原因也完全相同：不需要暴露任何端口，不需要配置转发，处于任何 NAT 之后的沙箱都能直接工作。 这也意味着真正有价值的故障与连通性无关，而在于一条已建立但状态恶化的链路会发生什么。 第一类隐形故障：测量了错误的套接字 编译大量日志的代理产生输出的速度可能远快于浏览器的渲染速度。必须有人察觉并让生产者减速，最直观的实现是让沙箱监视自己的套接字：如果缓冲区增大，就暂停写入。 这测量了错误的对象。沙箱持有的套接字是通往控制平面的链路，控制平面是一台拥有良好网络的高性能机器，会欣然接受发给它的一切。真正发生积压的套接字是浏览器持有的那一个，位于网络最远端，由完全不同的进程处理。 因此，拥塞检测必须发生在慢速读取端，压力必须反向传回。控制平面监控它所维护的浏览器套接字，当该浏览器跟不上节奏时，停止读取与沙箱之间的链路。TCP 会处理剩余部分：接收窗口关闭，拥塞最终在沙箱端体现为其自身缓冲区的增长，这也是唯一能够做出暂停写入决策的地方。 在共享链路上暂停读取会导致其上的所有其他浏览器发生队头阻塞。拥塞的链路只会表明整条链路发生拥塞，绝不会标识出某一个慢速观众。因此暂停只能持续数毫秒，针对单个观众的限速仍由控制平面负责。 第二类隐形故障：永远会自动回复的 Ping 询问对端是否在线的常规方式是 WebSocket ping。但这在这里毫无意义，因为 ping 是由对端的操作系统网络栈自动回复的，而不是由对端应用程序回复。一个已关闭的标签页、一台休眠的笔记本、一个崩溃的网页，在一段时间内都会照常回复 ping。 负责维护浏览器套接字的一端是唯一能确认浏览器已离开的角色。因此它会在内部链路中显式发送离开消息，沙箱仅凭该消息做出判断。当链路本身断开时，其上保持的所有连接都会在本地关闭一次，确保终端绝不会向无效地址持续推送输出。 这两条规则的存在是为了避免内存泄露以及在控制台上显示虚假活跃会话。 为什么这不是次要细节 任何人都能把 CLI 放进容器。决定人们是否愿意长久运行代理的关键，在于机器与人之间的连接能否真实反映自身状态：它清楚何时发生拥塞，知晓观察者何时离开，并据实做出反应。 防止多个代理相互干扰的预约看板是另一个独立问题，有专门的文章阐述。防止运行模型代码的机器接触机密信息的架构隔离则是第三篇文章的主题。本篇探讨的是贯穿它们之间的通信纽带。 --- ## La machine qui exécute les agents ne détient aucun secret Source: https://murmell.com/fr/blog/machine-with-no-secrets Un agent parvenant à s’échapper de son conteneur ne doit rien trouver qui vaille la peine d’être dérobé. Cela dépend de ce que la machine contient physiquement. Nous avons scindé l’architecture en deux : la moitié exécutant les agents ne possède aucun accès à la base de données et aucune clé de déchiffrement. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceTout ce qui peut déchiffrer des données réside d’un côté. De l’autre ne se trouvent que les agents et le dossier de travail. Deux rôles distincts pour un cloisonnement étanche La partie authentification gère la base de données (comptes, canvas, jetons chiffrés) sur un réseau privé sans port public. La partie exécution fait tourner du code généré par des modèles et doit rester isolée. Toutes les vérifications d’accès sont isolées dans des fonctions pures ne lisant ni base de données ni horloge système : export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckRéduction des privilèges aux interfaces Les méthodes exposées à la machine d’exécution sont strictement réduites : L’obtention de l’identité renvoie uniquement un nom et un email, sans jamais transmettre le hachage de mot de passe Argon2id présent dans la ligne utilisateur. La récupération des identifiants est contextualisée au canvas actif et oubliée immédiatement après l’opération de synchronisation git. La restriction stricte des données est une propriété de sécurité fondamentale. Architecture par rôles Plutôt que deux binaires divergents, l’application utilise un binaire unique paramétré par des rôles vérifiés à la compilation et aux tests : export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Le rôle sandbox fonctionne sans base de données et refuse toute connexion directe depuis un navigateur, n’acceptant que les connexions relayées par le plan de contrôle. L’isolation des machines est expliquée dans la machine cloud où tournent les agents, et nos retours d’expérience dans résultats des tests en sandbox cloud. --- ## What we found when we put agents on a cloud sandbox Source: https://murmell.com/blog/cloud-sandbox-findings The plan said the machine running the agents would keep its network shut and the terminals would dial out to us. A probe pool answered differently on both counts, and the architecture moved to match. Every claim below came back from a real request. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneOne channel through the wall, carrying frames both ways, and nothing at all without a token. Everything hung on the WebSocket Agents live in terminals, and a terminal is a stream. If the platform’s entry point had only allowed request and response, the whole shape would have needed rethinking. It allows the upgrade, and it moves frames in both directions. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverWith no token the same request is 403 Unauthenticated. That is the finding that matters most: the machine that executes model-written code has no public surface of its own, and the platform’s identity layer holds the door rather than a secret we invented and have to rotate. The trap is the audience. This is Azure Container Apps dynamic sessions, and the token has to be issued for the dynamic sessions audience. A management audience token, which is the one every example and every CLI hands you first, is refused with a 403 that looks exactly like the unauthenticated case. That is worth an hour of somebody’s afternoon, so it is written down here. One identifier is one container Two different identifiers on the same pool give two different containers, with different hostnames inside them. That is the primitive the product needed: one canvas, one machine. It also means the canvas identifier can be the routing key directly, so there is no registry of tunnels to keep, nothing to reconcile after a restart, and no state that can disagree with reality. Egress cannot be switched off The earlier version of the plan named the platform’s no-egress mode as the native hardening, and that sentence read like a fact. It is unusable. With egress off the machine reaches neither our own control half, nor the code host, nor the model API, and an agent that cannot reach the model is not an agent. With egress on, the code host answered 200, the model API answered 401, which is the answer that proves it is reachable, and our own site answered 200. All three are needed for an agent to do anything. So the isolation cannot come from cutting the network. It has to come from what the machine holds, which is why the database connection and the decryption key were taken off it instead. The one thing the platform had already closed: the instance metadata address is unreachable from inside a session, so there is nothing to block there. The platform decides more of the architecture than the design does. Three details that will bite The proxy announces a ceiling of thirty minutes per request, in a header on the way in. Whether it applies to a WebSocket is not something a document will tell you, and the only way to find out is to hold one open for longer than that. Either way the control half has to be able to reconnect a live link without the browser noticing, which is a thing worth building before you need it. The identifier is not in the environment. A session gets an instance value and nothing else, and the identifier appears only in a forwarded path header. So the machine cannot know which canvas it is serving when it boots. It learns that from the opening frame of the link, which turned out to be the shape the protocol wanted anyway. The lifecycle is not only a timer. There is an exit-driven mode as well, which matters because putting a canvas to sleep is a decision the watcher makes about whether anything is happening, not a decision a wall clock makes. What the measurement changed The plan had the machine dialling out to us, chosen on the assumption that dialling in was impossible. It is not impossible, and now both directions stand up, with a real trade between them. Dialling out needs a registry of tunnels and a shared secret we would have to invent. Dialling in needs neither, because the canvas identifier routes and the platform authenticates, but it couples our control half to one vendor’s API. The decision was to not decide, in the protocol. The relay envelope wraps a connection, not a direction. Dialling in is wired first because it is the shortest path and it is proven. Dialling out stays available the day portability matters more than convenience, and it costs nothing today to keep it available. If you are building the same thing Measure the platform before you draw the diagram. The first version of that section was written from documentation and reasoning, and it read like a set of facts. The probe overturned part of it, including the piece the entire hardening story had been resting on. Write down the guess that cost you an hour. The audience mismatch produced a 403 identical to the one you get with no credential at all, which is the kind of detail that never makes it into a release note and always makes it into somebody’s afternoon. Keep the transport out of the protocol. The direction a connection is opened in turned out to be a deployment detail, and the only reason that was cheap is that nothing in the message format had an opinion about it. The architectural consequences of these findings are detailed in the machine that runs the agents holds no secrets, and how we run remote sessions in watching a terminal you do not host. --- ## Erkenntnisse beim Einsatz von KI-Agenten in Cloud-Sandboxes: Messungen und Praxis Source: https://murmell.com/de/blog/cloud-sandbox-findings Der ursprüngliche Plan sah vor, den ausgehenden Netzwerkverkehr der Agenten komplett zu sperren. Praxistests zeigten jedoch, dass Agenten Zugriff auf Modell-APIs und Git benötigen. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneEin einziger bidirektionaler Kanal, geschützt durch Authentifizierungs-Token. Zentrale Bedeutung von WebSockets Interaktive Terminals erfordern kontinuierliche Datenströme via HTTP-Upgrade. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverUngültige Anfragen werden sofort mit 403 Unauthenticated abgewiesen. Ausgehender Datenverkehr ist zwingend nötig Ohne Netzzugang können Agenten weder Modell-APIs noch Git erreichen. Sicherheit muss in den verwahrten Daten liegen. Plattform-Bedingungen bestimmen die Architektur stärker als theoretische Entwürfe. Praktische Schlussfolgerungen Messen Sie Infrastruktur frühzeitig und entkoppeln Sie Netzwerkprotokolle von Anwendungslogik. Die architektonischen Konsequenzen werden in die Maschine mit den Agenten speichert keine Geheimnisse vertieft, das Streaming in ein Terminal beobachten. --- ## Datei-Reservierungssystem: Code-Konflikte bei mehreren KI-Agenten im selben Repo verhindern Source: https://murmell.com/de/blog/reserving-a-file Geben Sie drei Agenten dasselbe Repository ohne Regeln und sie überschreiben sich innerhalb einer Minute. Die Trennung in isolierte Branches erschwert gemeinsame Neuentwicklungen. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedEin Inhaber pro Pfad. Konfliktbehaftete Schreibvorgänge werden am Board gestoppt, bevor sie die Festplatte erreichen. Die realen Nachteile separater Branches Separate Branches verhindern, dass ein Agent neu definierte Typen des anderen sofort verwenden kann. Gemeinsame Projektdateien erleiden unlösbare Merge-Konflikte. Live-Previews spiegeln nur Bruchteile der Anwendung wider. Die manuelle Zusammenführung bindet wertvolle Entwicklungszeit. Daher teilen sich alle Agenten ein einziges Verzeichnis. Zeitlich begrenzte Leases ohne Deadlocks Eine Reservierung umfasst Pfade, Agenten-ID, Modus und Ablaufzeit. Exklusiver Modus für Schreibzugriff, geteilter Modus für Leseabhängigkeiten. export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }Abgewiesene Anfragen liefern sofort Details zum aktuellen Inhaber zur Aufgabenanpassung. Leases verlängern sich bei echten Schreibvorgängen automatisch und werden beim Beenden des Prozesses freigegeben. Freiwillige Einhaltung ist Optimierung; serverseitige Durchsetzung ist die Sicherheitsgarantie. Serverseitige Überwachung des Dateisystems Ein Dateisystem-Watcher prüft jede Schreiboperation auf gültige Reservierungen. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationBei unberechtigten Zugriffen wird vor der Anzeige ein Snapshot zur Wiederherstellung erstellt. Der Verursacher wird gestoppt und der rechtmäßige Inhaber über Änderungen informiert. Automatische Zuordnung Jeder Git-Commit wird automatisch dem zuständigen Agenten zugeordnet. Die Gesamtarchitektur wird in mehrere KI-Agenten in einem Repository erläutert, die Terminalanbindung in ein Terminal beobachten. --- ## Die 3 Hürden beim Erststart von Claude Code im Docker-Container Source: https://murmell.com/de/blog/claude-code-first-launch Ein Agent, der ein Banner ausgibt und wartet, erzeugt Bytes, die im Log wie Erfolg aussehen. In einem neuen Container stoppt Claude Code dreimal vor jeder eigentlichen Arbeit. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerDie Reihenfolge ist zwingend. Das Beantworten der ersten beiden verhindert nicht den Stopp bei der dritten. Die drei Hürden in zeitlicher Abfolge SchrittAbfrageinhalt Ersteinrichtungs-AssistentAuswahl des Farbschemas / Themes Workspace-VertrauensprüfungVertrauen Sie diesem Projektverzeichnis? API-Key-BestätigungMöchten Sie diesen API-Schlüssel verwenden? Unvollständige Vorkonfigurationen lassen den Agenten an der nächsten Hürde stranden. Messmatrix aus der Praxis Gemessen mit claude 2.1.220 in einer frischen HOME-Umgebung: Gesetzte KonfigurationVerhalten des Agenten KeineBlockiert bei Theme-Auswahl Nur theme in settings.jsonWeiterhin blockiert bei Theme-Auswahl hasCompletedOnboarding in .claude.jsonErreicht Vertrauensdialog + hasTrustDialogAccepted für aufgelösten PfadErreicht Prompt ("Not logged in") + ANTHROPIC_API_KEY in UmgebungBlockiert bei API-Key-Bestätigung + customApiKeyResponses.approvedVoll einsatzbereit Die Falle mit relativen Pfaden Pfadangaben in ~/.claude.json müssen zwingend kanonisch aufgelöst sein (ohne Symlinks). export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }Die Bestätigung des Schlüssels Die Key-Abfrage wählt standardmäßig 2. No (recommended). Das CLI speichert die letzten 20 Zeichen als Genehmigungs-Token. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }Unwirksame Abkürzungen Der Parameter --permission-mode bypassPermissions umgeht den Vertrauensdialog nicht. Ein Theme ist Kosmetik. Das Löschen von Dateien ist eine kritische Entscheidung. Wir automatisieren die Einrichtung, belassen sensible Werkzeugfreigaben jedoch unter menschlicher Kontrolle. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };Die Cloud-Ausführung wird in Claude Code in der Cloud ausführen beschrieben, die Verbindungskontrolle in ein Terminal beobachten. --- ## What stops Claude Code on its first launch in a container Source: https://murmell.com/blog/claude-code-first-launch An agent that starts, paints a banner and then waits is producing bytes. Bytes look like success in a log. On a fresh container Claude Code stops three times before it does any work, and each stop is a question asked of a terminal with nobody in front of it. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerThe order matters. An agent that has answered the first two still stops at the third. The three stops, in the order an agent meets them stopwhat it asks the first-launch assistantChoose the text style that looks best the workspace trust checkIs this a project you created or one you trust? the provider key checkDo you want to use this API key? The first and the third are global to the machine. The second is recorded per directory. Closing one of them moves the agent forward exactly one stop, which is why anything short of all three reads as progress and delivers nothing. What was measured Every row below is claude 2.1.220 driven through a real pty, one fresh HOME per row. None of it is inferred from the name of a field. seededwhat the agent did nothingblocked on the theme picker settings.json theme alonestill blocked on the theme picker .claude.json hasCompletedOnboardingreached the trust dialog plus projects[resolved].hasTrustDialogAcceptedreached the prompt, “Not logged in” plus ANTHROPIC_API_KEY in the environmentblocked: “Do you want to use this API key?” plus customApiKeyResponses.approvedreached the prompt, “API Usage Billing” Three of those rows contradict what looks obvious. theme on its own does not silence the theme picker. Nobody needs to try that again. hasCompletedOnboarding on its own does silence it, on this version. A key listed in customApiKeyResponses.rejected does not prompt at all. It silently drops the key, and the status line reads “Not logged in”. So a stale rejection has to be cleared for the key being approved, not merely appended past. The trap in the trust key Trust lives in ~/.claude.json under projects[path], and the path is the resolved one. Both places Murmell creates a directory use mkdtempSync, which on macOS hands back /var/folders/… while the resolved path is /private/var/folders/…. Seeding the unresolved key looks completely correct. It writes a plausible entry, the file now says the project is trusted, and the dialog still appears. That one cost a day. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }realpathSync throws for a path that does not exist, which is a real case: a workspace can be torn down before this runs. Falling back to the path as given writes a useless but harmless entry, and the agent asks the question exactly as it does today. The stop nobody had found The provider key check is the expensive one, because its default answer is 2. No (recommended). A person connects a provider in the interface, the key travels correctly all the way into the environment of the pty, and the agent offers to throw it away with throwing it away pre-selected. What the CLI records is not the key. It is the last twenty characters of one. That was established by driving a pty through the prompt, answering yes, and reading back what the CLI wrote: for sk-ant-api03-PROBE-TAIL-abcdef1234567890 it stored exactly AIL-abcdef1234567890. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }That it is a suffix is also what makes writing it acceptable at all. A file that recorded whole keys would be one more place a key lives, and the rest of this codebase goes to real trouble to keep a key out of the logs and off the wire. Two answers that look right and are not --permission-mode bypassPermissions does not open the trust gate. It governs tool permissions, which is a different question in the same shape. Pre-seeding the unresolved path does not work either, for the reason above. Both were tried against a real pty before this was written, and both are worth stating so nobody spends the afternoon again. A theme is not a decision. Deleting a file is. This removes questions of configuration. It never removes questions of judgment. Whether a directory is yours is a fact the server already knows on the user’s behalf, and asking an empty terminal does not make it safer, it only makes the product not run. Whether to delete a file or force a push is a different kind of question, and an agent must still ask it. So there is deliberately no --dangerously-skip-permissions anywhere in this path, and the tool allowance stays empty. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };Empty on purpose, and it has to stay empty. This grants trust in the directory. It is not permission to act inside it. Why the version is read from the binary The onboarding record carries the version of the CLI it was written for, and that value is compared against the installed one. A literal in the source is correct until the image updates its CLI, and from then on it pins an onboarding state that no longer matches the binary: a regression that arrives on somebody else’s release schedule, in production, with nothing in any test suite to notice. So it is read, and when the read fails nothing is written. Not knowing is a first-class answer. Reading it costs a process. claude --version was measured at 40ms warm and 430ms on a virgin HOME, and it creates no files, so the probe does not itself trigger any of the onboarding this exists to pre-empt. Its stdin is closed rather than inherited, because a CLI that decides to ask something must not be able to hang the spawn. Preparing must never cost the session The caller is the path that spawns an agent, immediately before the pty. Failing to prepare costs a keypress. Throwing costs the session. Every error here is swallowed and the worst case is the behavior we already had. There is a second reason for restraint. ~/.claude.json is shared: agents write to it constantly, and in production they run as the same user with the same HOME, so a read then write can lose somebody else’s concurrent update. Nothing is written when the file already says what it should. Every write lands through a temp file and a rename in the same directory, so a reader sees the old file or the new one and never a truncated one. The mode is 0o600, because that file also holds credentials. If you are spawning agents yourself Assert on the prompt, not on the output. Our own honest production measurement was that agents started, painted a banner and stopped, and the arriving bytes made it read as a success for longer than it should have. Drive a real pty and read back what the CLI wrote. Every useful thing on this page came from doing that, and the two guesses that looked most reasonable were both wrong. Before you silence a prompt, say which of the two kinds it is. Anyone widening a file like this one should be able to answer that in a sentence, and if they cannot, the prompt stays. How Claude Code runs in our cloud environment is covered in running Claude Code in the cloud, and connection resilience is detailed in watching a terminal you do not host. --- ## Zero-Trust-Cloud-Sandbox: Ausführungsmaschinen speichern keine Zugangsdaten Source: https://murmell.com/de/blog/machine-with-no-secrets Ein Agent, der aus seinem Container ausbricht, darf nichts Lohnenswertes vorfinden. Daher besitzt die Ausführungsumgebung weder Datenbankzugriff noch Entschlüsselungsschlüssel. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceAlle sensiblen Entschlüsselungskomponenten stehen auf einer Seite, auf der anderen nur Agenten und Code. Zwei getrennte Rollen für maximale Sicherheit Die Authentifizierung verwaltet die Datenbank in einem privaten Netzwerk. Die Ausführung erfolgt isoliert davon. Zugriffsentscheidungen sind als reine Funktionen ohne I/O realisiert. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckMinimierung von Daten an Schnittstellen Methoden zur Identitätsprüfung liefern nur Name und E-Mail, niemals Passworthashes. Git-Zugriffstoken werden nur bei Bedarf geladen und sofort wieder aus dem Speicher verworfen. Strikte Datenminimierung ist ein elementares Sicherheitsprinzip. Rollenarchitektur in einem einzigen Binary Die Rolle sandbox läuft ohne Datenbank und akzeptiert nur vom Control Plane weitergeleitete Verbindungen. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Dies schützt Benutzerdaten dauerhaft und zuverlässig. Die Sicherheitsarchitektur wird in eine Cloud-Sandbox für KI-Agenten erklärt, die Messungen in Erkenntnisse aus Cloud-Sandboxes. --- ## Architettura Zero-Trust: La macchina cloud che esegue gli agenti non custodisce credenziali Source: https://murmell.com/it/blog/machine-with-no-secrets Un agente che evade dal container non deve trovare nulla di valore. Abbiamo diviso il sistema affinché l’esecutore non abbia accesso a informazioni riservate. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceTutti i componenti crittografici risiedono su un lato. Sull’altro solo gli agenti e il codice. Due ruoli per un isolamento invalicabile L’autenticazione gestisce il database su rete privata interna. L’esecutore fa girare codice non fidato in isolamento. Le verifiche di accesso sono implementate come funzioni pure deterministiche. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckMinimizzazione dei privilegi alle interfacce I metodi esposti all’esecutore trasmettono solo i dati minimi indispensabili. I token di accesso a GitHub vengono richiesti al bisogno ed eliminati subito dopo il push. La restrizione dei dati è una proprietà di sicurezza fondamentale. Architettura a ruoli su singolo binario Il ruolo sandbox opera senza database e rifiuta connessioni web dirette. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Questa separazione protegge costantemente i dati degli utenti. L’isolamento dei processi è trattato in una sandbox cloud per agenti IA, e i test sul campo in scoperte sulle sandbox cloud. --- ## The machine that runs the agents holds no secrets Source: https://murmell.com/blog/machine-with-no-secrets An agent that gets out of its container should find nothing worth taking. That is a property of what the machine holds, not of how carefully the container was built. So the process was cut in two, and the half that runs the agents was given no database connection and no decryption key. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceEverything that can decrypt something stands on one side. On the other there are agents and a working tree. One process could not be in two places The half that authenticates needs the database: accounts, canvases, share tokens, the encrypted credential for a code host. That database sits on a private network with no public port. The half that runs the agents executes code a model wrote, so it has to sit far away from everything else that network hosts. It was one process doing both jobs, and that is the entire reason the deployment was stuck. Neither shortcut is acceptable. Opening the database to the internet puts a database that also serves other projects on the public road. Moving the executor next to it puts arbitrary code execution beside them. What made the separation cheap The authorisation decision was already a pure function. It does no input or output. It reads no database and no clock. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckAnd the access it judges carries four fields: the user, the account session behind that user, the canvas, and the right held on it. So the far half replays the same policy from four fields the near half hands it. The policy is not copied. It is shared, which is the difference between one rule and two rules that will disagree in six months. The call that counting could not find Every call into the accounts store was located, and each one sat inside a handler belonging to the half with the database: sign-up, log-in, resume, log-out, creating and listing a canvas, share tokens, disconnecting a code host. Not one in spawn, input, resize or kill, and none in any board, project, presence or orchestrator handler. The seam looked clean. Then one turned up that the counting could not have seen, because it is not in a handler at all. A helper called authorFor reads a user row, and it is reached from underneath the spawn path and the orchestrator path, so that a commit is attributed to the real person who asked for it. A measurement that walked the line ranges between handlers was structurally incapable of finding it. The answer was not to move the spawn. The frame stays where the pty is, and that half is handed narrow methods instead of a database URL. Narrow is the security property, not the convenience. The identity method answers a name and an email address, and not the user row. The user row carries an Argon2id password hash. Before the split, the machine that executes arbitrary code was receiving password hashes when what it needed was a name. The fix is not a rule that we do not read that field, because a habit degrades silently. The fix is that the answer has no field a hash could ride in, so the reduction happens on the side that has the database and only the result crosses. The same argument runs twice more. The credential method takes a canvas and never a user, so the subject is derived on the side that routed the request: the credential of the owner of this canvas can never widen into any credential in the database. And the canvas method answers three fields rather than the canvas row, because the row also holds the read and edit share links, and the edit one grants write access to whoever has it. Built field by field on the near side, a spread on the far side has nothing to leak. Why it is a role and not two programs Only a small part of the socket server is handlers. The rest is frame validation, connection lifecycle, fan-out, backpressure, keepalive and the sweep that retires idle canvases, and both halves need every line of it. Splitting the files would have duplicated all of it, and two copies of a fan-out is two fan-outs with one bug fixed. Splitting roles duplicates nothing: one binary, one set of shared machinery, and only the active handlers change. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Those two predicates are what keeps the property inseparable from the code. No role both skips the database and serves browsers, and there is a test asserting it for every role that exists, so adding a fourth role that broke the rule would fail rather than ship. The accounts option was already required, with no default and no mode that runs without it, precisely so a deployment cannot serve an unauthenticated socket by forgetting a flag. The new role does not relax that. It is not accounts becoming optional. It is the role that runs with no database and refuses browsers outright, accepting only a relayed connection from a process that has already decided who is asking. An unknown role never falls back to the permissive default either: it throws, because a typo in a deploy variable quietly becoming the everything mode is exactly how a sandbox ends up serving browsers. The credential that has to cross anyway Pushing to a private repository needs two things that now live apart: the encrypted credential, which is in the database, and the cloned repository, which is on the other machine’s disk. So the far half never stores the credential. It asks for it immediately before a push, uses it, and forgets it. A decrypted credential exists only as a local variable inside a single call, and there is a test that walks the object graph to prove nothing parked a copy. What the relay costs Terminal output now crosses twice, which is affordable at this size and reversible later without touching the browser. Two properties nearly broke on the way, and both are the same mistake in different clothes: a relay makes a process measure the relay instead of the thing it thought it was measuring. Backpressure was measured on the browser’s own socket. Behind a relay the far half would be reading the near half’s buffer, so a slow browser could fill the near half’s memory while the far half saw a healthy connection. The near half therefore raises the desync itself and stops reading, which pushes the pressure back over TCP where it belongs. Liveness was answered by the browser’s network stack. Behind a relay the near half would answer in its place, and the far half would believe a dead browser was alive and keep its agents attached to nobody. So the death of a connection is propagated rather than absorbed. The bug class a split creates On the half without the working tree, the project registry is not missing. It is empty, and an empty registry answers every question confidently and wrongly. Repository status with no project fills its whole local half with empty strings and zeros, which on that process is a confident description of a working tree that is alive on another machine. That needed a third predicate, and naming it was most of the fix. export function holdsWorktree(role: Role): boolean { return role !== "control"; }If you are building the same thing Look for the pure function before you look for the file boundary. The one decision that governs everything here had no input or output, and that single fact is what turned a rewrite into a launch mode. Count the calls, then assume the count is wrong. The one call that mattered was in a helper, and it was found by reading rather than by grepping. Reduce at the source. Every object that crosses a boundary should be built field by field on the side that owns it, because the day someone spreads it on the far side is the day you find out what it was carrying. How this isolation works from a product perspective is covered in a cloud sandbox for AI agents, and our empirical findings in cloud sandbox findings. --- ## Ce qui bloque Claude Code lors de son premier lancement en conteneur Source: https://murmell.com/fr/blog/claude-code-first-launch Un agent qui démarre, affiche une bannière et attend produit des octets. Dans un journal de logs, cela ressemble à un succès. Pourtant, dans un conteneur vierge, Claude Code s’arrête trois fois avant tout travail utile, attendant des réponses sur un terminal sans opérateur. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerL’ordre est déterminant. Un agent ayant validé les deux premières étapes reste bloqué à la troisième. Les trois étapes bloquantes dans l’ordre d’apparition ÉtapeQuestion posée Assistant de premier lancementChoix du thème graphique Vérification de confiance du workspaceFaites-vous confiance à ce projet ? Validation de la clé d’APIVoulez-vous utiliser cette clé d’API ? La première et la troisième sont globales à la machine. La deuxième est enregistrée par dossier. Résoudre deux étapes sur trois donne l’illusion d’avancer mais bloque toujours le lancement. Résultats des mesures empiriques Chaque ligne ci-dessous a été mesurée avec claude 2.1.220 sur un vrai pty dans un HOME vierge : Configuration injectéeComportement observé AucuneBloqué sur le sélecteur de thème theme dans settings.json seulToujours bloqué sur le sélecteur de thème hasCompletedOnboarding dans .claude.jsonAtteint le dialogue de confiance + hasTrustDialogAccepted sur le projet résoluAtteint l’invite avec « Not logged in » + ANTHROPIC_API_KEY dans l’environnementBloqué sur « Do you want to use this API key? » + customApiKeyResponses.approvedAtteint l’invite fonctionnelle « API Usage Billing » Le piège du chemin résolu L’état de confiance s’enregistre dans ~/.claude.json sous projects[chemin], où le chemin doit être canonique. Sur macOS, mkdtempSync produit /var/folders/… alors que le chemin résolu est /private/var/folders/…. Injecter le chemin non résolu écrit une clé ignorée par le binaire et le dialogue réapparaît. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }La validation de clé API Le piège de la confirmation de clé API est que son choix par défaut est 2. No (recommended). Le CLI n’enregistre pas la clé entière, mais seulement ses vingt derniers caractères sous forme d’empreinte d’approbation. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }Deux fausses pistes L’option --permission-mode bypassPermissions ne débloque pas le dialogue de confiance initial : elle concerne uniquement les permissions d’outils. De même, injecter un chemin non résolu échoue systématiquement. Un thème n’est pas un choix critique. Supprimer un fichier en est un. Pré-valider la confiance d’un dossier est légitime puisque notre plateforme en est l’instigatrice. En revanche, nous ne court-circuitons pas les autorisations d’outils sensibles en cours de session : const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };Recommandations pour automatiser les lancements d’agents Testez l’état de l’invite de commande et non le simple flux d’octets sortant. Pilotez vos processus via un pty réel et inspectez les fichiers de configuration produits par le CLI. L’exécution de Claude Code dans notre environnement cloud est abordée dans Claude Code dans le navigateur, et la résilience du flux dans observer un terminal distant. --- ## Riserva dei file: Come evitare conflitti tra più agenti IA sullo stesso repository Source: https://murmell.com/it/blog/reserving-a-file Mettere tre agenti sullo stesso codice senza regole porta a sovrascritture in meno di un minuto. Isolarli in rami separati danneggia lo sviluppo collaborativo di nuove applicazioni. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedUn solo titolare per file. I conflitti vengono bloccati dal tabellone prima di toccare il disco. I limiti dell’isolamento su branch separati Branch separati impediscono agli agenti di visualizzare tipi e funzioni appena creati. I file comuni subiscono conflitti di merge non risolvibili automaticamente. L’anteprima live risulta parziale e incompleta. La risoluzione manuale comporta spreco di tempo e token. Per questo motivo gli agenti condividono la stessa cartella. Lease temporanei senza deadlock La prenotazione definisce percorsi, identificativo dell’agente, modalità e scadenza. Modalità esclusiva per scrittura e condivisa per lettura con notifiche di modifica. export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }Le richieste respinte restituiscono i dati del titolare attuale per riorientare il lavoro. I lease si rinnovano a ogni scrittura effettiva e si liberano alla chiusura del processo. La cooperazione del modello è ottimizzazione; il controllo del server è certezza. Monitoraggio attivo del file system Il server controlla ogni scrittura su disco e respinge modifiche non autorizzate. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationIn caso di violazione, viene creato uno snapshot prima che il file venga alterato. L’agente responsabile viene arrestato e il titolare legittimo avvisato. Attribuzione trasparente Ogni commit su Git viene attribuito automaticamente all’agente responsabile della modifica. L’architettura complessiva è descritta in più agenti IA su un unico repository, e i terminali in osservare un terminale remoto. --- ## Os 3 desafios ao iniciar o Claude Code pela primeira vez em contêiner Docker Source: https://murmell.com/pt/blog/claude-code-first-launch Um agente que imprime um cabeçalho e fica parado continua emitindo bytes, parecendo ativo nos logs. Em um contêiner novo, o Claude Code para três vezes antes de produzir código. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerA ordem é fixa. Responder às duas primeiras não impede o travamento na terceira. As três etapas de bloqueio EtapaSolicitação Assistente inicialEscolha do tema visual Confirmação de confiançaVocê confia neste diretório? Confirmação da chave de APIDeseja usar esta chave de API? Resolver parcialmente essas etapas mantém o agente travado. Matriz de testes práticos Medições em ambiente limpo com claude 2.1.220: Configuração injetadaComportamento do agente NenhumaBloqueado no seletor de tema Apenas theme em settings.jsonAinda bloqueado no seletor de tema hasCompletedOnboarding em .claude.jsonAvança para o diálogo de confiança + hasTrustDialogAccepted no caminho resolvidoAvança ao prompt com "Not logged in" + ANTHROPIC_API_KEY no ambienteBloqueado em "Deseja usar esta chave?" + customApiKeyResponses.approvedPronto para operação O problema do caminho real A permissão em ~/.claude.json exige caminhos canônicos resolvidos, sem links simbólicos. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }Aprovação da chave A confirmação da chave tem como padrão 2. No (recommended). A CLI armazena apenas os 20 caracteres finais como token de aprovação. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }Atalhos ineficazes O parâmetro --permission-mode bypassPermissions não ignora a confirmação de confiança do diretório. Um tema é apenas estética. Apagar um arquivo é uma decisão crítica. Liberamos a inicialização do ambiente mas preservamos a segurança em comandos destrutivos. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };A execução na nuvem é explicada em rodar Claude Code na nuvem, e a gestão de conexão em observar um terminal remoto. --- ## Los 3 problemas al iniciar Claude Code por primera vez en un contenedor Docker Source: https://murmell.com/es/blog/claude-code-first-launch Un agente que muestra un banner y se queda esperando sigue generando bytes, lo que en los registros parece un éxito. En un contenedor nuevo, Claude Code se detiene tres veces antes de realizar cualquier trabajo útil. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerEl orden es estricto. Haber respondido a las dos primeras preguntas no evita el bloqueo en la tercera. Las tres paradas en orden de aparición ParadaPregunta formulada Asistente de primer inicioSelección de estilo de texto y tema Comprobación de confianza¿Es este un proyecto en el que confías? Validación de clave de API¿Deseas utilizar esta clave de API? Resolver solo una o dos de estas paradas permite avanzar al agente pero sigue impidiendo la ejecución del trabajo. Matriz de mediciones reales Comportamiento medido con claude 2.1.220 en un entorno HOME limpio: Configuración inyectadaComportamiento del agente NingunaBloqueado en el selector de tema Solo theme en settings.jsonAún bloqueado en el selector de tema hasCompletedOnboarding en .claude.jsonAlcanza el diálogo de confianza + hasTrustDialogAccepted en la ruta resueltaLlega al prompt con "Not logged in" + ANTHROPIC_API_KEY en el entornoBloqueado en "¿Deseas utilizar esta clave de API?" + customApiKeyResponses.approvedAlcanza el prompt listo para operar La trampa de la ruta resuelta La confianza se almacena bajo projects[ruta] y la ruta debe estar completamente resuelta (canonical). En macOS, las carpetas temporales requieren resolver los enlaces simbólicos para que la CLI reconozca la autorización. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }La aprobación de la clave La confirmación de la clave de API es peligrosa porque su opción por defecto es 2. No (recommended). La CLI almacena únicamente los últimos veinte caracteres como token de aprobación. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }Dos atajos que no funcionan El modificador --permission-mode bypassPermissions no salta el diálogo de confianza del directorio. Un tema visual es una preferencia. Borrar un archivo es una decisión crítica. Preconfiguramos la confianza del entorno pero mantenemos intactas las protecciones sobre herramientas sensibles. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };El funcionamiento en la nube se detalla en ejecutar Claude Code en la nube, y el control de conexión en observar un terminal remoto. --- ## I 3 ostacoli al primo avvio di Claude Code in un container Docker Source: https://murmell.com/it/blog/claude-code-first-launch Un agente che stampa un banner e si ferma continua a emettere byte. In un container nuovo, Claude Code si arresta tre volte prima di compiere qualsiasi operazione. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerL’ordine è rigido. Risolvere le prime due non evita il blocco sulla terza. I tre blocchi in ordine cronologico PassaggioRichiesta Assistente inizialeScelta del tema grafico Fiducia nel workspaceConferma attendibilità cartella Conferma chiave APIAutorizzazione utilizzo chiave API Risolvere solo parte dei requisiti lascia l’agente bloccato al passaggio successivo. Matrice delle misurazioni reali Dati verificati con claude 2.1.220 in ambiente pulito: Configurazione iniettataComportamento agente NessunaBlocco sul selettore tema Solo theme in settings.jsonAncora blocco sul selettore tema hasCompletedOnboarding in .claude.jsonAvanza alla conferma cartella + hasTrustDialogAccepted sul percorso risoltoRaggiunge prompt ("Not logged in") + ANTHROPIC_API_KEY nell’ambienteBlocco su autorizzazione chiave + customApiKeyResponses.approvedPronto all’uso Il problema dei percorsi reali I percorsi in ~/.claude.json devono essere canonici e risolti, senza symlink. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }La conferma della chiave La conferma della chiave usa come default 2. No (recommended). Il CLI memorizza gli ultimi 20 caratteri come token di approvazione. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }Scorciatoie inefficaci Il flag --permission-mode bypassPermissions non scavalca la conferma di fiducia della cartella. Un tema è estetica. Cancellare un file è una decisione critica. Automatizziamo l’avvio ma preserviamo le protezioni sulle operazioni distruttive. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };L’esecuzione nel cloud è spiegata in eseguire Claude Code nel cloud, e la gestione della connessione in osservare un terminale remoto. --- ## Reserva de arquivos: Como evitar conflitos entre múltiplos agentes de IA no mesmo repositório Source: https://murmell.com/pt/blog/reserving-a-file Coloque três agentes no mesmo repositório sem controle e eles se sobrescreverão em menos de um minuto. A divisão em branches isoladas prejudica o desenvolvimento colaborativo de novas aplicações. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedUm titular por arquivo. Conflitos são barrados no quadro de reservas antes de tocarem o disco. O custo de branches isoladas Ambientes isolados impedem que agentes vejam tipos recém-criados uns pelos outros. Arquivos comuns sofrem conflitos de merge insolúveis de forma automática. A visualização em tempo real torna-se incompleta. A reconciliação manual consome tempo e tokens desnecessários. Por isso, os agentes compartilham o mesmo diretório. Concessão temporária sem travamento A reserva define caminhos, agente, modo e tempo de expiração. Modos exclusivo (escrita) e compartilhado (leitura com notificações de alteração). export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }Pedidos negados retornam instantaneamente dados do titular para que o agente possa redirecionar suas tarefas. As concessões são renovadas a cada gravação e liberadas automaticamente ao encerrar o processo. A disciplina do modelo é otimização; a garantia do servidor é a segurança real. Monitoramento ativo do sistema de arquivos O servidor valida todas as gravações no disco e bloqueia alterações não autorizadas. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationEm caso de violação, um snapshot de segurança é criado antes de o arquivo ser alterado. O agente infrator é alertado para reverter e o titular legítimo é notificado. Rastreabilidade total Cada commit no Git é atribuído automaticamente ao agente responsável pela modificação. A arquitetura completa é detalhada em vários agentes de IA num repositório, e o fluxo de terminal em observar um terminal remoto. --- ## Reserva de archivos: cómo evitar que múltiples agentes de IA se sobreescriban en un repositorio Source: https://murmell.com/es/blog/reserving-a-file Pon a tres agentes en el mismo repositorio sin reglas y se sobrescribirán en un minuto. La última escritura gana en silencio hasta que fallan las pruebas. La solución habitual de aislarlos en ramas independientes resulta contraproducente para construir una aplicación colaborativa. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedUn titular por ruta. La escritura en conflicto se bloquea en el tablero antes de llegar al disco. El verdadero coste de las copias aisladas Tener ramas independientes impide que el segundo agente vea el código que el primero acaba de generar, forzándole a reinventar tipos ya existentes. En proyectos nuevos, los archivos comunes (package.json, configuraciones) sufren colisiones máximas imposibles de fusionar de forma automática. La vista previa en vivo queda fragmentada. Resolver los conflictos finales genera un coste elevado en tiempo humano o consumo de tokens. Por ello los agentes comparten un único directorio. Arrendamiento temporal sin bloqueos muertos La reserva define rutas, titular, modo y tiempo de expiración. Existen dos modos: exclusivo (para modificar) y compartido (para declarar dependencias de lectura). export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }Una petición denegada responde al instante con los datos del titular actual, permitiendo al agente reorientar su trabajo de inmediato. El arrendamiento se renueva automáticamente con cada escritura real y se libera al salir el proceso. El cumplimiento voluntario es una optimización; la validación por servidor es la garantía de corrección. El servidor juzga y vigila el sistema de archivos Un monitor en el servidor vigila cada modificación en el disco y verifica su autorización legítima. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationAnte una escritura no autorizada, se genera un snapshot de seguridad antes de reflejar el cambio en pantalla. El agente infractor es advertido para detenerse y revertir, garantizando la integridad del código. Atribución clara de autoría Cada commit en Git se asocia automáticamente con el agente específico que modificó el archivo, manteniendo un historial limpio sobre una única rama. La arquitectura completa se explica en múltiples agentes de IA en un repositorio, y la gestión de terminales remotos en observar un terminal remoto. --- ## Reserving a file before you write it Source: https://murmell.com/blog/reserving-a-file Give three agents the same repository and they overwrite each other inside a minute. Last write wins, silently, and nobody finds out until the tests do. The obvious fix is a checkout each, and for the case we care about it is the wrong one. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedOne holder per path. The write that would have collided is stopped at the board rather than on disk. What a checkout each actually costs A worktree per agent is the right model for three unrelated bugs in a mature codebase. It is not the model for the thing people actually ask us for, which is several agents building one application, split up to go faster. On that case it breaks in four places. The second agent cannot see the first agent’s code. The one writing the API needs a type the one writing the schema finished a minute ago, in another worktree on another branch. It does not see the type, so it declares the type again. You end with three divergent definitions of one thing, and the merge does not reconcile them: it produces a conflict on a file nobody owns. Composing in the open is the whole benefit of working in parallel, and separate checkouts forbid it by construction. On a new project the conflict is maximal rather than minimal. Three agents starting from an empty repository each create a package manifest, a TypeScript config, a bundler config, an entry point and a lockfile. Those are add and add conflicts on generated files, which is the worst case a merge has, and a lockfile does not merge at all. It regenerates. The preview lies. A preview has to serve one tree. Either it serves the integration branch, which is minutes behind the work the person is watching happen, or it serves one worktree, which is a third of the application. And somebody pays for the merge. Either a human in a conflict resolution interface, or a fourth agent burning tokens to repair a fragmentation we created ourselves. A lease, not a mutex So the agents share one directory, and a reservation is what makes that survivable. A claim is a set of paths, an agent, a mode and an expiry. It prevents nothing physically. It declares an intention, and it gives the system the right to judge a write. There are two modes. An exclusive claim has one holder. A shared claim announces a read, which is how an agent says it depends on a file and gets told when the owner of that file changes it. A claim never blocks. A refusal comes back immediately, and it carries everything the refused agent needs to do something else instead. export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }The holder, what the holder is working on, how many seconds are left, and what to do now. An agent that queued on a lock would burn tokens sitting still, so the refusal tells it to take other work in its own scope, or to message the holder, or to post itself as blocked so the orchestrator can re-plan. Expiry is a lease and not a deadline. Any board call by an agent, and any write the watcher observes on a path it holds, pushes its expiry out by a full term. An agent that is working never silently loses its lease. The default term is fifteen minutes, the ceiling is an hour, and one claim covers at most fifty paths. Death needs no heartbeat, because the server owns the pty. When the process exits, every lease of that session is released at once, the roster marks it as gone, and the orchestrator is told which paths it was holding and which task is unfinished. The expiry only ever covers the agent that is alive but stuck. A person can break a lease from the canvas. The orchestrator deliberately cannot. Breaking the lease of a live agent that is genuinely writing is the most reliable way to manufacture the collision the whole mechanism exists to avoid. There is also a ceiling on how often an agent may ask. Past thirty board calls in a rolling minute the answer is an explicit refusal carrying a retry time, returned as a value the agent can read rather than thrown as an error, because an agent cannot act on an exception. Compliance is an optimisation, never a condition of correctness. The rule is judged, not trusted The server owns the filesystem, so it does not have to believe an agent that says it claimed something. A watcher sees every write and asks who it belongs to. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationThe order is fixed. The agent’s own hook report first, which is ground truth wherever the CLI supports hooks. Then the live claim on that path. Then the single agent whose declared scope matches it. Then nobody, honestly recorded as nobody. A scope match is used only when exactly one agent claims that territory, because two overlapping scopes is an invalid plan and guessing between them would put a lie on the canvas. That is the whole reason this works with models that do not cooperate perfectly. An agent that forgets to claim still gets its writes attributed and still gets caught writing into somebody else’s path. When a write lands on somebody else’s path The snapshot is committed before the collision reaches the screen, so the revert the canvas offers is always real. Ordering it the other way round would give people a button that sometimes has nothing behind it. Then both sides are told. The offender is told to stop and to revert if it can, so it does not keep going. The holder is told that its file moved underneath it and that it should re-read the file before trusting it, which is the message that stops a good agent building on a corrupted assumption. The third violation by the same agent stops being a message and becomes a question to the human: pause it, re-scope it, or let it continue. An agent that has broken the same rule three times is not going to be fixed by a fourth notification, and the loop diverges if nobody interrupts it. Attribution comes free Because the server knows who held which path at the moment it changed, every write is attributed. The commit message names the agent alongside the file. A human reviews one diff that can be colored by author, and gets blame per agent with no branch per agent, which was the main thing a worktree each would have bought. What the agents did with it Measured on our own two-agent runs: 1.8 board calls per turn, two writes out of two covered by a claim, and two refusals to overwrite a peer. It is a small sample and our own observation rather than a benchmark, and it is stated as such. The interesting figure is the first one. Nobody polled. Agents used the board roughly twice a turn, which is what a mechanism looks like when it is cheaper to use than to work around. The two refusals took insisting: we had to push before an agent would overwrite a peer at all. If you are building the same thing Put the enforcement where the filesystem is. A protocol the model is asked to follow is a suggestion. A watcher that attributes writes is a fact, and the difference shows up the first time a model is having a bad afternoon. Make refusal cheaper than waiting. A refusal that arrives instantly with the holder, the remaining time and an alternative is something an agent can act on. A blocking lock is an invoice. Snapshot before you notify, not after. The order is the difference between a revert button and a lie. The broader product architecture is covered in multiple AI agents on one repo, and how we connect browsers to remote sessions is in watching a terminal you do not host. --- ## Réserver un fichier avant de l’écrire Source: https://murmell.com/fr/blog/reserving-a-file Donnez à trois agents le même dépôt sans coordination et ils s’écraseront mutuellement en moins d’une minute. La dernière écriture prévaut silencieusement jusqu’à ce que les tests échouent. La réponse habituelle consiste à isoler chaque agent dans son propre worktree, mais cette solution s’avère inadaptée pour construire une application à plusieurs. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedUn détenteur par chemin. L’écriture en conflit est stoppée au niveau du tableau de réservation avant d’atteindre le disque. Le coût réel de l’isolation par branches Un worktree par agent fonctionne pour traiter des bugs indépendants sur une base de code mature. Pour créer une application complète en parallèle, l’isolation échoue sur quatre aspects majeurs : Le deuxième agent ne voit pas le code du premier. L’agent écrivant l’API a besoin d’un type créé une minute plus tôt par l’agent en charge du schéma dans une autre branche. Ne le voyant pas, il le redéfinit, créant des divergences insolubles lors de la fusion. Sur un projet neuf, les conflits sont maximaux sur les fichiers de configuration partagés (package.json, tsconfig, lockfile). L’aperçu en direct devient fragmenté : il ne peut afficher qu’un tiers de l’application ou une branche d’intégration en retard. Enfin, la résolution des conflits nécessite l’intervention humaine ou un modèle supplémentaire consommant inutilement des jetons. Un bail temporaire plutôt qu’un verrou bloquant Les agents partagent donc un dossier unique, sécurisé par un système de réservation. Une demande de réservation comprend une liste de chemins, un identifiant d’agent et une durée de validité. Deux modes existent : exclusif (un seul détenteur pour écriture) et partagé (déclaration de lecture et notification en cas de modification). export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }Une demande refusée ne bloque jamais le processus. Elle renvoie immédiatement les informations sur le détenteur actuel et sa tâche, permettant à l’agent de se réorienter ou de patienter intelligemment sans gaspiller de jetons. Le bail (15 minutes par défaut) se renouvelle automatiquement à chaque écriture effective de l’agent. En cas d’arrêt du processus, tous ses baux sont instantanément libérés par le serveur. La conformité est une optimisation, jamais une condition de validité. Le serveur arbitre et surveille le système de fichiers Le serveur contrôle directement le système de fichiers. Un observateur analyse chaque écriture sur le disque et vérifie son appartenance : classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationSi une écriture non autorisée survient, un instantané (snapshot) est enregistré avant que la modification n’apparaisse à l’écran, garantissant la possibilité d’un retour en arrière fiable. L’agent fautif est immédiatement sommé de s’arrêter et le détenteur légitime est invité à recharger son fichier. Au troisième avertissement, l’arbitrage est soumis à l’utilisateur humain. Attribution automatique des modifications Grâce au suivi précis des baux au moment de chaque écriture, les messages de commit git associent automatiquement chaque modification à l’agent responsable, offrant un historique clair et détaillé sur une branche unique. L’architecture globale est détaillée dans plusieurs agents IA sur un même dépôt, et la gestion des terminaux distants dans observer un terminal distant. --- ## Ce que nous avons appris en déployant des agents sur une sandbox cloud Source: https://murmell.com/fr/blog/cloud-sandbox-findings Le plan initial prévoyait une machine exécutant les agents avec réseau sortant totalement coupé. Les bancs d’essai réels ont révélé des contraintes différentes, conduisant à adapter l’architecture aux réalités du terrain. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneUn canal unique à travers la frontière, transportant les trames dans les deux sens, strictement subordonné à un jeton d’accès valide. Le rôle central du WebSocket Les agents s’exécutent dans des terminaux interactifs, qui constituent des flux continus. La plateforme supporte parfaitement l’upgrade de protocole et le passage bidirectionnel des trames : GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverSans jeton, la requête est rejetée en 403 Unauthenticated, garantissant que la machine d’exécution ne présente aucune surface publique non filtrée. L’impossibilité de couper le réseau sortant Couper les accès réseau sortants empêche l’agent d’interroger les API des modèles (Anthropic, OpenAI), d’accéder au dépôt Git et de communiquer avec notre plan de contrôle. L’isolation ne peut donc pas reposer sur une coupure réseau brutale. Elle repose sur la séparation des responsabilités : retirer la base de données et les clés maîtresses de la machine d’exécution. La plateforme dicte l’architecture plus que les diagrammes théoriques. Enseignements opérationnels Mesurez toujours les caractéristiques réelles de votre infrastructure avant de figer vos choix d’architecture. Conservez les protocoles de communication indépendants du sens d’établissement de la connexion pour préserver votre liberté de déploiement. Les conséquences architecturales de ces tests sont détaillées dans la machine qui exécute les agents ne détient aucun secret, et la gestion du flux dans observer un terminal distant. --- ## Cosa abbiamo imparato eseguendo agenti IA in sandbox cloud: Risultati e benchmark Source: https://murmell.com/it/blog/cloud-sandbox-findings Il piano iniziale prevedeva di bloccare tutte le connessioni in uscita delle sandbox. I test hanno dimostrato che gli agenti necessitano di contattare le API dei modelli e i repository. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneUn solo canale bidirezionale protetto da token di autenticazione. Il ruolo cruciale dei WebSocket I terminali interattivi richiedono flussi continui supportati tramite HTTP Upgrade. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverRichieste non autenticate vengono respinte con 403 Unauthenticated. La rete in uscita non può essere disattivata Senza accesso a Internet l’agente non può contattare le API di Anthropic, OpenAI o Git. La sicurezza deve risiedere nei dati custoditi. I vincoli dell’infrastruttura plasmano l’architettura più dei diagrammi teorici. Conclusioni pratiche Verifica sempre l’infrastruttura con test reali e mantieni i protocolli applicativi indipendenti dal trasporto. Le scelte architetturali sono approfondite in la macchina che esegue gli agenti non custodisce segreti, e il flusso in osservare un terminale remoto. --- ## Qué aprendimos al ejecutar agentes de IA en sandboxes en la nube: hallazgos y rendimiento Source: https://murmell.com/es/blog/cloud-sandbox-findings El plan inicial asumía que la máquina de ejecución mantendría su red de salida apagada. Las pruebas reales demostraron la necesidad de permitir el acceso a las API de modelos y repositorios. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneUn canal único bidireccional estrictamente condicionado a un token de autenticación válido. La importancia crítica del WebSocket Los terminales de los agentes requieren canales continuos bidireccionales, soportados de forma nativa por la plataforma mediante HTTP Upgrade. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverLas peticiones sin token se rechazan con 403 Unauthenticated, protegiendo la superficie de la máquina. La salida a Internet no se puede apagar Cortar el tráfico saliente impide al agente comunicarse con las API de Anthropic y OpenAI o sincronizar con Git. La seguridad debe residir en lo que la máquina contiene. Las restricciones de la plataforma determinan la arquitectura más que los diseños teóricos. Conclusiones prácticas Valida siempre tu infraestructura con pruebas reales antes de cerrar el diseño y mantén el transporte desacoplado de los protocolos de aplicación. Las decisiones de diseño se detallan en la máquina que ejecuta los agentes no guarda secretos, y los terminales en observar un terminal remoto. --- ## O que aprendemos ao rodar agentes de IA em sandboxes na nuvem: Resultados e benchmarks Source: https://murmell.com/pt/blog/cloud-sandbox-findings O plano original previa cortar todo o tráfego de saída das máquinas dos agentes. Os testes provaram que os agentes precisam acessar APIs de modelos e repositórios remotos. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneUm único canal bidirecional protegido por tokens de acesso. A importância central do WebSocket Terminais exigem fluxos contínuos de dados, suportados nativamente via HTTP Upgrade. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverRequisições sem credenciais são rejeitadas com 403 Unauthenticated. A rede de saída não pode ser desligada Sem internet de saída o agente não consegue consultar LLMs nem o Git. A segurança deve estar nos dados que a máquina armazena. As restrições da infraestrutura moldam a arquitetura mais do que os diagramas conceituais. Conclusões práticas Valide sempre a infraestrutura com testes reais antes de definir a arquitetura e mantenha os protocolos desacoplados do transporte de rede. O impacto arquitetural é detalhado em a máquina que executa os agentes não guarda segredos, e os terminais em observar um terminal remoto. --- ## Arquitetura Zero-Trust: A máquina na nuvem que executa os agentes não guarda credenciais Source: https://murmell.com/pt/blog/machine-with-no-secrets Um agente que escape de seu contêiner não deve encontrar nada de valor. Dividimos a arquitetura para que o executor não tenha acesso a dados confidenciais. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceTudo o que descriptografa dados fica de um lado. Do outro, apenas os agentes e o código. Dois papéis para isolamento seguro A autenticação acessa o banco em rede interna privada. O executor roda código não confiável em ambiente isolado. Verificações de acesso utilizam funções puras e determinísticas. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckMinimização de privilégios nas interfaces Métodos expostos ao executor fornecem apenas o estritamente necessário (nome e e-mail, sem hashes de senha). Tokens de acesso a repositórios são consultados sob demanda e descartados após o uso. A restrição de dados é uma propriedade de segurança fundamental. Arquitetura baseada em papéis O papel sandbox opera sem banco de dados e recusa conexões externas diretas, aceitando apenas conexões encaminhadas. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Essa separação garante a proteção contínua dos dados dos usuários. O isolamento seguro é coberto em uma sandbox na nuvem para agentes, e os resultados em descobertas em sandbox na nuvem. --- ## Arquitectura Zero-Trust: la máquina en la nube que ejecuta los agentes no guarda credenciales Source: https://murmell.com/es/blog/machine-with-no-secrets Un agente que logre escapar de su contenedor no debe encontrar nada que merezca la pena robar. Por ello, dividimos el sistema en dos: la mitad que ejecuta los agentes carece de conexión a la base de datos y de claves de descifrado. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceTodo lo que puede descifrar datos reside en un lado. En el otro solo están los agentes y el código del proyecto. Dos roles independientes para un aislamiento estricto La parte de autenticación gestiona la base de datos en una red privada sin puertos públicos. La parte de ejecución hace correr código de modelos en un entorno aislado. Las comprobaciones de autorización son funciones puras sin accesos a base de datos ni reloj. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckReducción de datos en los límites del sistema Los métodos expuestos al ejecutor están estrictamente minimizados: no se transmiten hashes de contraseñas ni tokens persistentes. Las credenciales para sincronizar con Git se solicitan bajo demanda y se eliminan de la memoria de inmediato. La restricción estricta de datos es una propiedad de seguridad fundamental. Arquitectura basada en roles sobre un único binario El rol sandbox opera sin base de datos y rechaza conexiones web directas, aceptando únicamente tráfico reenviado por el plano de control. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Esta separación impide fugas de credenciales en caso de anomalías en el agente. El aislamiento de seguridad se analiza en un sandbox en la nube para agentes, y los hallazgos en hallazgos en sandbox en la nube. --- ## Архитектура Zero-Trust: Облачные машины с агентами не содержат ключей и секретов Source: https://murmell.com/ru/blog/machine-with-no-secrets Агент, покинувший пределы контейнера, не должен найти ничего ценного. Мы разделили систему так, чтобы среда исполнения не имела доступа к конфиденциальным данным. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceВсе криптографические операции сосредоточены на одной стороне. На другой — только агенты и код. Две роли для надежной изоляции Аутентификация работает с базой в закрытой сети. Исполнение кода моделей происходит изолированно. Проверки прав реализованы в виде чистых детерминированных функций. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckМинимизация данных на интерфейсах Методы исполнителя возвращают только имя и email, без парольных хешей. Токены доступа к репозиториям запрашиваются по требованию и стираются после пуша. Минимизация передаваемых данных — фундаментальное свойство безопасности. Ролевая модель в едином бинарном файле Роль sandbox работает без базы данных и отклоняет прямые веб-соединения. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }Такое разделение надежно защищает пользовательские данные. Изоляция среды исполнения рассмотрена в облачная песочница для ИИ-агентов, а замеры — в результаты тестов в облачных песочницах. --- ## Опыт запуска ИИ-агентов в облачных песочницах: Замеры и результаты тестирования Source: https://murmell.com/ru/blog/cloud-sandbox-findings Первоначальный план предполагал полное отключение исходящей сети для агентов. Тесты доказали необходимость доступа к API моделей и Git. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneЕдиный защищенный двунаправленный канал передачи данных. Ключевая роль WebSocket Интерактивные терминалы требуют непрерывных потоков данных через HTTP Upgrade. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverНеавторизованные запросы блокируются с кодом 403 Unauthenticated. Исходящий трафик необходим Без доступа в интернет агент не может связаться с Anthropic, OpenAI или Git. Защита должна быть внутри машины. Ограничения платформы определяют архитектуру сильнее теоретических схем. Практические выводы Всегда проверяйте инфраструктуру тестами и отделяйте сетевой транспорт от бизнес-логики. Архитектурные выводы изложены в машина с агентами не хранит секретов, а работа сокетов — в наблюдение за удаленным терминалом. --- ## 3 проблемы при первом запуске Claude Code в Docker-контейнере Source: https://murmell.com/ru/blog/claude-code-first-launch Агент, выводящий баннер и ожидающий ввода, генерирует байты, создавая иллюзию активности в логах. В новом контейнере Claude Code останавливается трижды. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerПорядок строгий. Прохождение первых двух шагов не спасает от остановки на третьем. Три барьера в хронологическом порядке ШагЗапрос Мастер первого запускаВыбор цветовой темы Проверка доверия к директорииДоверяете ли вы этой папке проекта? Подтверждение API-ключаХотите ли вы использовать данный API-ключ? Частичная настройка оставляет процесс заблокированным на следующем этапе. Таблица практических измерений Замеры для claude 2.1.220 в чистом HOME-окружении: Внесенная конфигурацияПоведение агента Без конфигурацииБлокировка на выборе темы Только theme в settings.jsonВсе еще блокировка на выборе темы hasCompletedOnboarding в .claude.jsonПереход к диалогу доверия + hasTrustDialogAccepted для канонического путиВыход в командную строку ("Not logged in") + ANTHROPIC_API_KEY в окруженииБлокировка на подтверждении ключа + customApiKeyResponses.approvedПолная готовность к работе Ловушка канонических путей Пути в ~/.claude.json должны быть строго каноническими, без символических ссылок. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }Подтверждение ключа По умолчанию диалог ключа выбирает 2. No (recommended). CLI сохраняет последние 20 символов как токен одобрения. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }Неработающие решения Флаг --permission-mode bypassPermissions не отключает проверку доверия к директории. Тема — это оформление. Удаление файла — ответственное решение. Мы автоматизируем старт окружения, но сохраняем защиту на потенциально опасных операциях. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };О запуске в облачной среде читайте в запуск Claude Code в облаке, а о контроле соединений — в наблюдение за удаленным терминалом. --- ## Резервирование файлов: Защита от конфликтов при работе нескольких ИИ-агентов в одном репо Source: https://murmell.com/ru/blog/reserving-a-file Запуск трех агентов в одном репозитории без правил приводит к перезаписи правок за считанные минуты. Изоляция по отдельным веткам не подходит для совместного создания новых приложений. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedОдин владелец на путь. Конфликтные записи блокируются на доске до попадания на диск. Недостатки работы в изолированных ветках В отдельных ветках агенты не видят создаваемые коллегами типы данных и функции. Конфигурационные файлы проекта получают неразрешимые конфликты слияния. Живой предпросмотр отображает лишь часть создаваемого сервиса. Слияние веток отнимает время разработчиков или сжигает токены. Поэтому все агенты делят одну рабочую директорию. Временная аренда без взаимоблокировок Запрос на аренду содержит пути, ID агента, режим и срок действия. Поддерживаются эксклюзивный режим (для записи) и совместный (для чтения с уведомлениями). export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }Отказ моментально возвращает данные текущего владельца для переключения на другие задачи. Аренда продлевается при реальных записях и освобождается при завершении процесса. Дисциплина модели — это оптимизация; контроль сервера — гарантия безопасности. Серверный мониторинг файловой системы Сервер отслеживает каждую запись на диск и пресекает несанкционированные правки. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationПри нарушении создается снимок состояния до применения изменений. Агент-нарушитель останавливается, а законный владелец получает уведомление. Точное авторство Каждый Git-коммит автоматически привязывается к конкретному агенту, создавшему изменение. Архитектура подробно описана в несколько ИИ-агентов в одном репозитории, а управление удаленными терминалами — в наблюдение за удаленным терминалом. --- ## Cloud Sandbox में AI Agents चलाने के प्रैक्टिकल अनुभव और Benchmark Findings Source: https://murmell.com/hi/blog/cloud-sandbox-findings शुरुआती योजना आउटबाउंड नेटवर्क बंद करने की थी, लेकिन परीक्षणों ने साबित किया कि मॉडल API और Git का उपयोग आवश्यक है। A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without oneटोकन द्वारा सुरक्षित एकल द्विदिशी संचार चैनल। WebSocket की मुख्य भूमिका टर्मिनल इंटरैक्शन के लिए HTTP Upgrade द्वारा निरंतर डेटा प्रवाह आवश्यक है। GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to serverअमान्य अनुरोध तुरंत 403 Unauthenticated पर रोक दिए जाते हैं। आउटबाउंड नेटवर्क बंद नहीं किया जा सकता इंटरनेट के बिना एजेंट Anthropic या OpenAI API से संपर्क नहीं कर सकते, इसलिए सुरक्षा डेटा अलगाव में होनी चाहिए। कागज़ी योजनाओं से अधिक इंफ्रास्ट्रक्चर की वास्तविक सीमाएं डिज़ाइन तय करती हैं। व्यावहारिक निष्कर्ष हमेशा वास्तविक परीक्षण करें और नेटवर्क लेयर को एप्लिकेशन लॉजिक से अलग रखें। सुरक्षा आर्किटेक्चर एजेंट चलाने वाली मशीन में कोई सीक्रेट नहीं होता में और टर्मिनल स्ट्रीम रिमोट टर्मिनल की निगरानी में विस्तृत है। --- ## Docker Container में Claude Code पहली बार रन करने की 3 मुख्य चुनौतियां Source: https://murmell.com/hi/blog/claude-code-first-launch बैनर दिखाकर रुका हुआ एजेंट भी बाइट्स भेजता है जो लॉग में चालू जैसा दिखता है, लेकिन वास्तव में इनपुट का इंतज़ार कर रहा होता है। Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh containerक्रम निश्चित है। पहले दो को हल करने के बाद भी तीसरे पर रुकावट आती है। क्रमवार 3 रुकावटें चरणसवाल प्रारंभिक विज़ार्डटेक्स्ट थीम का चयन फ़ोल्डर ट्रस्ट जाँचक्या आप इस प्रोजेक्ट डायरेक्टरी पर भरोसा करते हैं? API की पुष्टिक्या आप इस API की का उपयोग करना चाहते हैं? अधूरे समाधान से एजेंट अगली रुकावट पर रुक जाता है। परीक्षण तुलना तालिका स्वच्छ वातावरण में claude 2.1.220 पर किए गए परीक्षण: दी गई कॉन्फ़िगरेशनएजेंट का व्यवहार कोई नहींथीम चयन पर रुका केवल settings.json में themeफिर भी थीम चयन पर रुका .claude.json में hasCompletedOnboardingट्रस्ट संवाद पर पहुँचा + सुलझाए गए पाथ पर hasTrustDialogAcceptedप्रॉम्प्ट तक पहुँचा ("Not logged in") + एनवायरनमेंट में ANTHROPIC_API_KEYAPI की पुष्टि पर रुका + customApiKeyResponses.approvedपूरी तरह काम करने के लिए तैयार सुलझे हुए पाथ का जाल ~/.claude.json में पाथ पूरी तरह वास्तविक और सुलझा हुआ होना चाहिए। export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }API की की पुष्टि API की संवाद डिफ़ॉल्ट रूप से 2. No (recommended) चुनता है। CLI अंतिम 20 अक्षरों को अप्रूवल टोकन के रूप में रखता है। export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }अप्रभावी शॉर्टकट --permission-mode bypassPermissions फ़ोल्डर ट्रस्ट संवाद को बायपास नहीं करता। थीम चुनना पसंद है। फ़ाइल डिलीट करना एक गंभीर निर्णय है। हम सेटअप को स्वचालित करते हैं लेकिन संवेदनशील टूल की सुरक्षा बनाए रखते हैं। const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };क्लाउड वातावरण में चलाने की प्रक्रिया क्लाउड में Claude Code चलाना और कनेक्शन सुरक्षा रिमोट टर्मिनल की निगरानी में दी गई है। --- ## File Reservation सिस्टम: एक ही Repo में कई AI Agents के बीच Conflicts कैसे रोकें Source: https://murmell.com/hi/blog/reserving-a-file बिना नियमों के एक ही रिपॉजिटरी में कई एजेंट चलाने से काम नष्ट हो जाता है। ब्रांच में अलगाव नए प्रोजेक्ट्स के लिए सही नहीं है। Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedप्रति पाथ एक होल्डर। टकराव वाला बदलाव डिस्क पर पहुँचने से पहले बोर्ड द्वारा रोक दिया जाता है। ब्रांच अलगाव की असली लागत अलग ब्रांच में एजेंट एक-दूसरे द्वारा बनाए गए नए टाइप और फ़ंक्शन नहीं देख पाते। साझा प्रोजेक्ट फ़ाइलों में मर्ज टकराव होते हैं। लाइव प्रीव्यू अधूरा रहता है। मर्ज करने में इंसानी समय और टोकन नष्ट होते हैं। इसलिए सभी एजेंट एक ही डायरेक्टरी साझा करते हैं। बिना डेडलॉक वाली अस्थायी लीज रिज़र्वेशन में पाथ सूची, एजेंट आईडी, मोड और समय सीमा होती है। एक्सक्लूसिव मोड (लिखने के लिए) और शेयर्ड मोड (पढ़ने के लिए)। export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }इनकार होने पर तुरंत वर्तमान होल्डर की जानकारी मिलती है ताकि एजेंट दूसरा काम कर सके। वास्तविक बदलाव पर लीज अपने आप बढ़ती है और प्रोसेस बंद होने पर तुरंत छूट जाती है। मॉडल का सहयोग अनुकूलन है; सर्वर का नियंत्रण वास्तविक सुरक्षा है। सर्वर द्वारा फ़ाइल सिस्टम की निगरानी फ़ाइल सिस्टम वॉचर हर बदलाव की जाँच करता है और अनधिकृत बदलाव रोकता है। classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassificationउल्लंघन होने पर स्क्रीन पर दिखने से पहले स्नैपशॉट लिया जाता है। गलती करने वाले एजेंट को रोका जाता है और असली होल्डर को सूचित किया जाता है। स्पष्ट योगदान ट्रैकिंग प्रत्येक Git कमिट उस विशिष्ट एजेंट से जुड़ता है जिसने बदलाव किया था। विस्तृत आर्किटेक्चर एक ही रेपो में कई AI एजेंट में और रिमोट टर्मिनल प्रबंधन रिमोट टर्मिनल की निगरानी में समझाया गया है। --- ## Stateless Cloud Sandbox: AI Agent चलाने वाली मशीन में कोई Credentials नहीं होते Source: https://murmell.com/hi/blog/machine-with-no-secrets कंटेनर से बाहर निकलने वाले किसी एजेंट को कोई गोपनीय चीज़ नहीं मिलनी चाहिए। इसलिए एक्ज़ीक्यूटर से DB कनेक्शन और की हटा दी गई हैं। A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspaceडेटा डिक्रिप्ट करने वाले सभी घटक एक तरफ हैं और दूसरी तरफ केवल एजेंट और कोड हैं। दो भूमिकाओं द्वारा सख्त अलगाव प्रमाणीकरण प्राइवेट नेटवर्क में DB संभालता है और एक्ज़ीक्यूशन अलग रहकर मॉडल कोड चलाता है। अधिकार जाँच बिना I/O वाले शुद्ध फ़ंक्शन के रूप में बनाई गई है। export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckइंटरफ़ेस पर न्यूनतम डेटा शेयरिंग एक्ज़ीक्यूटर को केवल नाम और ईमेल दिया जाता है, पासवर्ड हैश कभी नहीं भेजा जाता। Git टोकन केवल ज़रूरत के समय मंगाया जाता है और पुश के तुरंत बाद मेमोरी से हटा दिया जाता है। न्यूनतम डेटा प्रदर्शन मौलिक सुरक्षा का आधार है। एकल बाइनरी में रोल आर्किटेक्चर sandbox रोल बिना DB के चलता है और सीधे वेब कनेक्शन अस्वीकार करता है। export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }यह उपयोगकर्ताओं के डेटा को हमेशा सुरक्षित रखता है। सैंडबॉक्स आइसोलेशन AI एजेंटों के लिए क्लाउड सैंडबॉक्स में और व्यावहारिक निष्कर्ष क्लाउड सैंडबॉक्स परीक्षण अनुभव में उपलब्ध हैं। --- ## 제로 트러스트 클라우드 샌드박스: 에이전트 실행 머신에 자격 증명을 두지 않는 보안 설계 Source: https://murmell.com/ko/blog/machine-with-no-secrets 컨테이너를 탈출한 에이전트가 탈취할 가치 있는 정보를 찾지 못하도록 실행 환경에서 DB 연결과 복호화 키를 완전히 제거했습니다. A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace데이터를 복호화할 수 있는 모든 구성 요소는 한쪽에 격리되고 실행 측에는 코드만 존재합니다. 두 가지 역할로 엄격한 격리 인증 시스템은 비공개 네트워크에서 DB를 관리하고 실행 시스템은 격리 환경에서 모델 코드를 구동합니다. 접근 검증 로직은 I/O가 없는 순수 함수로 구현되었습니다. export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheck인터페이스 최소 권한 원칙 실행 측에 전달되는 데이터는 이름과 이메일로 최소화되며 비밀번호 해시는 절대 전달되지 않습니다. Git 토큰은 필요한 순간에만 임시 호출되고 푸시 직후 메모리에서 제거됩니다. 데이터 노출 최소화는 가장 본질적인 보안 속성입니다. 단일 바이너리 역할 아키텍처 sandbox 역할은 DB 없이 실행되며 직접적인 외부 웹 요청을 거부합니다. export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }이를 통해 사용자 데이터를 안전하게 보호합니다. 샌드박스 보안 격리는 AI 에이전트를 위한 클라우드 샌드박스, 실측 분석은 클라우드 샌드박스 실측 결과에서 다룹니다. --- ## Docker 컨테이너 환경에서 Claude Code 첫 실행 시 발생하는 3가지 문제와 해결책 Source: https://murmell.com/ko/blog/claude-code-first-launch 배너를 출력하고 대기 중인 에이전트도 바이트를 방출하므로 로그상 정상처럼 보이지만 실제로는 입력을 기다리며 멈춰 있습니다. Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container순서는 고정되어 있습니다. 앞의 두 개를 통과해도 세 번째에서 멈춥니다. 순서대로 마주치는 3가지 관문 단계질문 내용 초기 설정 마법사텍스트 테마 선택 워크스페이스 신뢰 확인이 프로젝트를 신뢰합니까? API 키 확인이 API 키를 사용하시겠습니까? 일부만 해결하면 다음 관문에서 멈추게 됩니다. 실측 비교 매트릭스 깨끗한 HOME 환경에서 claude 2.1.220으로 측정한 결과: 사전 설정에이전트 동작 설정 없음테마 선택에서 멈춤 settings.json에 theme만 설정여전히 테마 선택에서 멈춤 .claude.json에 hasCompletedOnboarding 설정신뢰 확인 대화상자로 진행 + 확인된 경로에 hasTrustDialogAccepted 설정프롬프트 진입 ("Not logged in") + 환경 변수 ANTHROPIC_API_KEY 설정API 키 확인에서 멈춤 + customApiKeyResponses.approved 설정즉시 작업 가능 상태 진입 심볼릭 링크 해결의 함정 ~/.claude.json의 경로는 반드시 실제 정규화된 경로(canonical)여야 합니다. export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }API 키 승인의 복병 API 키 확인은 기본값이 2. No (recommended)로 지정되어 있습니다. CLI는 키의 마지막 20자를 승인 토큰으로 저장합니다. export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }작동하지 않는 우회책 --permission-mode bypassPermissions 옵션은 디렉터리 신뢰 대화상자를 건너뛰지 못합니다. 테마 선택은 단순 취향이지만 파일 삭제는 중대한 결정입니다. 환경 초기화는 자동화하되 위험 도구 실행 권한 확인은 엄격히 유지합니다. const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };클라우드 환경 구동은 클라우드에서 Claude Code 실행, 연결 안정성은 직접 호스팅하지 않는 터미널 관찰에서 확인하실 수 있습니다. --- ## 클라우드 샌드박스에서 AI 에이전트를 구동하며 얻은 실측 결과와 벤치마크 분석 Source: https://murmell.com/ko/blog/cloud-sandbox-findings 초기 계획은 에이전트 머신의 아웃바운드 네트워크를 차단하는 것이었으나 실측 결과 모델 API 및 Git 접근이 필수적임을 확인했습니다. A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one인증 토큰으로 보호되는 단일 양방향 통신 채널. WebSocket의 핵심 역할 터미널 인터랙션에는 HTTP Upgrade 기반의 지속적 스트림 통신이 필수적입니다. GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to server미인증 요청은 403 Unauthenticated로 즉시 차단됩니다. 아웃바운드 네트워크 차단 불가 인터넷 차단 시 Anthropic 및 OpenAI API를 호출할 수 없으므로 보안은 데이터 보관 수준에서 확보해야 합니다. 이론적 청사진보다 인프라의 물리적 실측 데이터가 아키텍처를 결정합니다. 실무적 결론 인프라 동작을 사전에 실측 검증하고 통신 계층과 애플리케이션 로직을 분리해야 합니다. 보안 아키텍처는 에이전트를 실행하는 머신은 비밀을 보관하지 않는다, 스트리밍 제어는 직접 호스팅하지 않는 터미널 관찰에서 확인하실 수 있습니다. --- ## 파일 사전 예약 시스템: 단일 저장소 내 다중 AI 에이전트 간 코드 충돌 방지 Source: https://murmell.com/ko/blog/reserving-a-file 같은 저장소에서 규칙 없이 에이전트를 실행하면 1분 안에 상호 덮어쓰기가 일어납니다. 브랜치 격리는 협업 개발에 적합하지 않습니다. Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused경로당 단일 점유자. 충돌을 유발하는 쓰기는 디스크에 닿기 전에 보드에서 차단됩니다. 브랜치 격리의 실제 비용 격리된 환경에서는 다른 에이전트가 방금 생성한 타입 정의를 즉시 활용할 수 없습니다. 공통 설정 파일에서 자동 병합이 불가능한 충돌이 발생합니다. 실시간 프리뷰가 온전한 상태를 반영하지 못합니다. 사후 충돌 해결에 불필요한 인력과 토큰이 소모됩니다. 따라서 모든 에이전트가 단일 디렉터리를 공유합니다. 교착 상태 없는 임시 임대 예약은 경로 목록, 에이전트 ID, 모드, 만료 시간으로 구성됩니다. 독점 모드(쓰기)와 공유 모드(읽기 의존성 추적)를 지원합니다. export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }거부 시 현재 점유자의 작업 정보가 즉시 반환되어 다른 작업으로 신속히 전환할 수 있습니다. 실제 쓰기 시 임대가 자동 연장되며 프로세스 종료 시 자동 해제됩니다. 모델의 자율 준수는 최적화일 뿐이며 서버 통제가 무결성의 보증입니다. 서버 기반 파일 시스템 감시 파일 시스템 감시자가 미승인 쓰기를 즉각 감지하고 차단합니다. classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassification무단 변경 발생 시 화면에 반영되기 전에 스냅샷을 생성합니다. 위반 에이전트에게 롤백을 지시하고 정당한 점유자에게 변경 사항을 알립니다. 명확한 커밋 기여도 모든 Git 커밋은 변경을 수행한 특정 에이전트와 자동으로 연결됩니다. 전체 아키텍처는 단일 저장소에서의 다중 AI 에이전트 운용, 원격 터미널 연결은 직접 호스팅하지 않는 터미널 관찰에서 확인하실 수 있습니다. --- ## クラウドサンドボックスでAIエージェントを動かした実測結果とパフォーマンス検証 Source: https://murmell.com/ja/blog/cloud-sandbox-findings 当初は外向き通信を完全遮断する計画でしたが、実機テストによりモデルAPIやGitへのアクセスが必要不可欠であることが明らかになりました。 A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one認証トークンで保護された単一の双方向通信チャネル。 WebSocket の重要性 ターミナル操作には HTTP Upgrade による持続的なストリーム通信が必須です。 GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to server未認証リクエストは 403 Unauthenticated で即時遮断されます。 外向き通信遮断の不可能性 ネット遮断では Anthropic や OpenAI の API を呼べないため、セキュリティは保持データ側の隔離で実現します。 机上の設計図よりもプラットフォームの実測制約がアーキテクチャを決定します。 運用のまとめ 早期の実機検証を行い、通信プロトコルとアプリロジックを疎結合に保つことが重要です。 設計への反映は エージェントを実行するマシンは秘密を持たない、ターミナル接続は 自分がホストしていないターミナルを見守る技術 をご覧ください。 --- ## ファイル事前予約システム：同一リポジトリでの複数AIエージェントのコード衝突を防ぐ Source: https://murmell.com/ja/blog/reserving-a-file 同一リポジトリで複数エージェントを無秩序に動かすと1分以内に上書きが発生します。個別ブランチへの隔離は共同開発において逆効果となります。 Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefusedパスごとに1人の保持者。衝突する書き込みはディスク到達前にボードで遮断されます。 ブランチ隔離の弊害 隔離された環境では、他方が直前に作成した型定義を即座に利用できません。 共通設定ファイルで自動マージ不能な競合が発生します。 リアルタイムプレビューが断片化します。 事後マージに多大な人的労力やトークンを消費します。 そのため全エージェントが同一ディレクトリを共有します。 デッドロックのない一時リース 予約は対象パス、エージェントID、モード、有効期限で構成されます。 排他モード（書き込み）と共有モード（読み込み追跡）が存在します。 export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }拒否時は即座に現保持者のタスク情報が返され、エージェントは他タスクへ切り替えられます。 実際の書き込みで自動延長され、プロセス終了時に自動解放されます。 モデルの自律性は最適化であり、サーバー制御こそが正しさの担保です。 サーバーによるファイル監視 ファイルシステムウォッチャーが未承認の書き込みを検知・遮断します。 classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassification不正な書き込み発生時は変更適用前にスナップショットを保存します。 違反エージェントには巻き戻しを指示し、正当な保持者には通知を送ります。 正確なコミット帰属 Git コミットは変更を行った特定エージェントへ自動的に帰属付けられます。 製品アーキテクチャの詳細は 同一リポジトリでの複数AIエージェント実行、リモートターミナル制御は 自分がホストしていないターミナルを見守る技術 をご覧ください。 --- ## AI 代理在云端沙箱运行的实测发现与工程踩坑记录 Source: https://murmell.com/zh/blog/cloud-sandbox-findings 最初的设想曾认为运行代理的机器可以完全切断外网出站连接。真实的探针集群给出了截然不同的答案，驱动整个系统架构做出了务实的演进。 A sealed machine with one channel through its wall, carrying frames both ways, and a second attempt refused for want of a token.controlsandboxwith a token403without one跨越边界的单一通道，承载双向数据帧传输，无有效 Token 时完全不可访问。 一切依托于 WebSocket 长连接 代理运行在交互式终端中，终端本质上是双向流。托管平台完美支持 HTTP 协议升级并在双向持续传递数据帧。 GET /?identifier=&api-version=2024-02-02-preview Authorization: Bearer 101 Switching Protocols frames server to client, and client to server未携带合法凭证的请求会直接被拦截为 403 Unauthenticated，确保执行机本身不存在未受保护的公开攻击面。 出站流量不可被硬性切断 切断出站网络会导致代理无法调用大模型 API、无法连接代码托管仓库，也无法与控制端通信。因此系统隔离必须来自机器内部持有的数据剥离，而非粗暴的网络切断。 云平台的物理约束比主观的架构设计更能决定系统的最终形态。 工程实测总结 在确立技术方案前必须先行验证基础设施的真实行为，将网络传输细节与上层应用协议解耦，以获得最大的架构灵活性。 相关架构设计请参阅 运行代理的机器不保留秘密，终端连接管理请参阅 观察不属于你的终端。 --- ## DockerコンテナでClaude Code初回起動時に直面する3つの技術課題 Source: https://murmell.com/ja/blog/claude-code-first-launch 起動してバナーを表示したまま待機しているエージェントもバイト列を出力するためログ上は動いているように見えますが、実際には3つのプロンプトで入力を待っています。 Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container順序は厳格です。前の2つを解決しても3つ目で確実に止まります。 出現順の3つの関門 関門質問内容 初期設定ウィザードテキストテーマの選択 ワークスペース信頼確認このプロジェクトを信頼しますか？ APIキー利用確認この API キーを使用しますか？ 一部のみの解決では次の関門で停止してしまいます。 実測データ対照表 新規 HOME 環境下における claude 2.1.220 の実測値： 事前設定エージェントの挙動 設定なしテーマ選択で停止 settings.json に theme のみ設定依然としてテーマ選択で停止 .claude.json に hasCompletedOnboarding 設定信頼確認ダイアログへ進む + 解決済みパスの hasTrustDialogAcceptedプロンプト到達 ("Not logged in") + 環境変数 ANTHROPIC_API_KEYAPIキー確認で停止 + customApiKeyResponses.approved即座に稼働開始可能 シンボリックリンク解決の罠 ~/.claude.json に記録するパスは完全に解決された正規パスである必要があります。 export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }APIキー確認の落とし穴 APIキー確認はデフォルトで 2. No (recommended) が選択されています。末尾20文字が承認トークンとして保存されます。 export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }無効な回避策 --permission-mode bypassPermissions ではディレクトリ信頼ダイアログをスキップできません。 テーマ設定は外観の好みに過ぎませんが、ファイル削除は重大な判断です。 起動の自動化は行いますが、危険なツール実行の確認は保持します。 const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };クラウド環境での実行仕様は クラウドでの Claude Code 実行、接続制御は 自分がホストしていないターミナルを見守る技術 をご覧ください。 --- ## 写入前预留文件：解决多 AI 代理在同一仓库的代码冲突 Source: https://murmell.com/zh/blog/reserving-a-file 让三个代理在同一个仓库中无约束运行，它们在不到一分钟内就会互相覆盖。最后写入者悄无声息地覆盖前者，直到测试失败才暴露问题。显而易见的解决办法是各给一份分支检出，但对于协作开发而言，这种做法完全适得其反。 Two agents reach for the same file. One reservation is granted; the other is refused at the board.the boardclaude-1codex-2src/types/order.tsrefused每个路径仅限单一持有者。即将发生冲突的写入会在看板层直接被阻断，而不是落到磁盘上。 各自分支检出的真实代价 每个代理独占一个 worktree 适合在成熟代码库中分别修复三个无关的 Bug。但在协同构建同一个新应用的场景下，这种模式会在四个关键点崩溃： 第二个代理无法读取第一个代理的代码。编写 API 的代理需要数据模型代理一分钟前在另一个分支刚写好的类型，由于看不见，它会重新声明一套。最终导致同一个概念出现多套不同定义，并在合并时产生无法调和的冲突。 在全新项目中，各个代理会同时创建 package.json、tsconfig 和 lockfile 等公共配置文件，产生最大化的合并冲突。 实时预览变得残缺不全：它要么落后于最新进展，要么只能展示三分之一的应用。 最终合并冲突的解决成本高昂，无论是由人类手动解决，还是由额外的大模型消耗 Token 尝试修复。 租约，而非阻塞锁 因此所有代理共享一个目录，通过路径占用机制确保协同安全。占用请求包含路径集合、代理标识、模式和租期。 占用包含两种模式：排他模式（独占写权限）与共享模式（声明只读依赖，在文件发生变更时接收通知）。 export interface ClaimDenial { path: string; holder: string; holderTask: string; expiresInS: number; hint: string; }占用请求绝不阻塞进程。被拒绝的请求会立刻返回持有者信息、当前任务、剩余租期以及下一步建议，代理可以立刻转向其他任务，避免停滞空转浪费 Token。 租约（默认 15 分钟）会在代理每次实际写入时自动顺延。进程退出时，其名下所有租约会立即被服务器自动释放。 自觉遵循只是性能优化手段，服务器强制校验才是正确性的底线保障。 规则由服务器裁决，而非盲目信任 服务器完全掌控文件系统，不会盲信代理的声明。底层文件监视器会捕获每一次写入并严格核验其归属。 classifyWrite(rawPath: string, hintedAgentId?: string): WriteClassification如果发生越权写入，系统会在冲突变更渲染到屏幕之前自动创建 Git 快照，确保画布提供的回滚功能绝对真实可靠。 系统会立即警告越权代理停止写入并回滚，同时通知原持有者重新读取已被修改的文件。若同一代理违规达三次，系统将暂停代理并由人工介入决策。 天然精准的代码归属记录 由于服务器明确掌握每次写入时的路径持有者，所有的 Git 提交都会自动精确关联到具体负责的代理，无需分叉分支即可在单一主线上获得清晰的责任追踪。 更多架构细节请参阅 多个 AI 代理共用同一个仓库，以及关于远程终端连接的 观察不属于你的终端。 --- ## 零信任云沙箱架构：运行 AI 代理的机器不持有凭据与敏感信息 Source: https://murmell.com/zh/blog/machine-with-no-secrets 一个逃逸出容器的代理不应在机器中找到任何有价值的机密。这一安全属性取决于机器本身持有什么，而不仅仅取决于容器加固得有多严密。因此我们将系统一分为二：运行代理的一半完全不配置数据库连接，也不持有任何解密密钥。 A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace所有能够解密机密数据的组件位于一侧，另一侧只有代理和纯粹的项目代码树。 一个进程无法同时兼顾两个物理位置 负责认证的一端需要访问数据库（账户、画布、加密的代码仓库凭据），数据库运行在无公网端口的内网中。负责运行代理的一端执行模型编写的代码，必须与内网核心设施彻底隔离。 权限判断逻辑被设计为纯函数，不执行任何 I/O 操作，也不读取数据库或系统时钟，确保双端逻辑完全一致。 export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheck接口层面的最小化权限裁剪 向执行端暴露的方法经过了极度严苛的数据精简： 身份获取方法只返回姓名与邮箱，绝不传递包含 Argon2id 密码哈希的完整用户行。 凭据获取严格限定于当前画布上下文，并在 Git 推送完成后立即从内存中抹除。 最小化暴露是安全基石，而非仅仅为了编码方便。 通过单一二进制的 Role 架构实现解耦 系统采用统一的二进制文件，通过严格受检的 Role 标识进行行为控制： export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }sandbox 角色运行在无数据库模式下，并且直接拒绝对外提供 Web 服务，仅接受来自控制平面的中继连接。 关于沙箱隔离的机制请参阅 面向 AI 代理的云沙箱，实测数据请参阅 云沙箱实测发现。 --- ## ゼロトラスト・クラウドサンドボックス：エージェント実行マシンに機密を置かない安全設計 Source: https://murmell.com/ja/blog/machine-with-no-secrets コンテナから脱出したエージェントが盗むべき価値のあるものを一切見つけられないようにするため、実行環境からDB接続と復号キーを完全に排除しました。 A locked boundary. The database and the key stand on the control side; the sandbox holds only agents and a working tree.controlsandboxdatabasekeynever crosses/workspace暗号復号可能な要素はすべて一箇所に集約され、実行側にはコードのみが存在します。 2つの役割による厳格な隔離 認証系は内部ネットワークでDBを管理し、実行系は隔離環境でモデルコードを動かします。 権限判定は I/O を行わない純粋関数として実装されています。 export function checkFrame(access: ConnectionAccess, frame: ClientMsg["type"]): AccessCheckインターフェースでのデータ最小化 実行側に渡すデータは名前とメールのみに限定し、パスワードハッシュ等は一切渡しません。 Git トークンは必要な瞬間にのみ一時取得され、プッシュ完了後即座に破棄されます。 データの最小化こそが根本的なセキュリティ特性です。 単一バイナリでのロール設計 sandbox ロールはDBなしで動作し、直接の外部Web接続を拒否します。 export const ROLES = ["all", "control", "sandbox"] as const; export function needsDatabase(role: Role): boolean { return role !== "sandbox"; } export function servesBrowsers(role: Role): boolean { return role !== "sandbox"; }これにより安全なマルチテナント運用を実現しています。 サンドボックスの隔離構造は AIエージェント向けクラウドサンドボックス、実測データは クラウドサンドボックス実測結果 をご覧ください。 --- ## 容器中首次启动 Claude Code 的三个阻碍与解决方案 Source: https://murmell.com/zh/blog/claude-code-first-launch 一个启动后输出横幅然后静止不动的代理依然在产生字节。在日志中，产生字节看起来就像正常运行。在全新容器中，Claude Code 在开始任何实际工作前会停顿三次，每一次都是在向一个空无一人的终端发问。 Three gates in a row. An agent passes the first two and stops at the third.onboardingtrustapi keya fresh container顺序至关重要。一个已经回答了前两个问题的代理依然会阻塞在第三个问题上。 代理按序遇到的三道关卡 关卡提示内容 首次启动引导助手选择视觉效果最佳的文本主题 工作区信任检查这是你创建或信任的项目目录吗？ 服务商密钥确认你是否要使用此 API Key？ 第一道和第三道关卡是机器全局性的。第二道关卡按目录记录。只解决其中一两道关卡只会让代理前进相应步数，依然无法真正开始工作。 实测对比矩阵 下表每行数据均基于 claude 2.1.220 在真实 pty 和全新 HOME 目录下实测得出： 预置配置代理实际行为 无任何预置阻塞在主题选择器 仅在 settings.json 中配置 theme依然阻塞在主题选择器 在 .claude.json 中预置 hasCompletedOnboarding进入目录信任确认对话框 额外预置 resolved 路径的 hasTrustDialogAccepted进入提示符，显示 "Not logged in" 额外在环境变量中注入 ANTHROPIC_API_KEY阻塞在 "Do you want to use this API key?" 额外预置 customApiKeyResponses.approved成功进入工作状态，显示 "API Usage Billing" 目录信任路径中的解析陷阱 信任记录保存在 ~/.claude.json 的 projects[path] 下，且路径必须为符号链接解析后的真实路径。在 macOS 上 mkdtempSync 返回 /var/folders/…，而真实路径为 /private/var/folders/…。写入未解析的路径会导致配置失效，提示框依然弹出。 export function trustKeyFor(root: string): string { try { return realpathSync(root); } catch { return root; } }密钥确认中的暗坑 API Key 确认提示最容易出错，因为其默认选项是 2. No (recommended)。CLI 记录的并不是完整密钥，而是密钥后 20 个字符的批准令牌。 export function approvalTokenFor(apiKey: string): string { return apiKey.slice(-20); }两条无效的捷径 命令行参数 --permission-mode bypassPermissions 无法跳过目录信任对话框，它只影响工具执行权限。预置未解析路径同样无效。 主题只是外观偏好，删除文件则是严肃决策。 预置配置消除了环境启动的冗余交互，但绝不能破坏关键的安全判断。我们不会跳过敏感工具调用时的必要确认。 const trust: ProjectTrust = { hasTrustDialogAccepted: true, hasCompletedProjectOnboarding: true, projectOnboardingSeenCount: 0, allowedTools: [], };关于云端运行环境的解析请参阅 在云端运行 Claude Code，连接控制细节请参阅 观察不属于你的终端。 --- ## Qui construit Murmell Source: https://murmell.com/fr/a-propos/fondateurs Les deux fondateurs Moss'Ab Mirande-Ney, cofondateur, business. mossabmirandeney.fr Omar Farouk Lasfar, cofondateur, développeur principal. oflasfar.netlify.app Ce qu’ils tiennent par ailleurs BrainSec (brainsec.fr). Le studio qu'ils ont fondé, à Paris et à Troyes. Web, audits de sécurité et intégration IA pour des PME. Hanta Tracker (hanta-tracker.app). Une carte en direct des cas d'hantavirus. Canal 32 y a compté 1,5 million de vues. IntrudR (intrudr.io). Un agent qui mène un test d'intrusion de bout en bout et rédige le rapport. Altavora (altavora.com). Une boutique de compléments sportifs, avec sa propre vitrine par-dessus un catalogue Shopify. DabaDeal (dabadeal.com). Une marketplace de seconde main au Maroc, entre particuliers. Ce que la presse en a écrit Hanta Tracker est sorti pendant l’épidémie d’hantavirus de 2026 et trois rédactions l’ont couvert : L’Est Éclair, Pokaa et Canal 32. Les joindre Tout ce qui concerne Murmell passe par la page contact et arrive dans la boîte que les deux fondateurs lisent. Tout ce qui concerne le studio passe par brainsec.fr. --- ## Who builds Murmell Source: https://murmell.com/about/founders The two founders Moss'Ab Mirande-Ney, co-founder, business. mossabmirandeney.fr Omar Farouk Lasfar, co-founder, lead developer. oflasfar.netlify.app What else they run BrainSec (brainsec.fr). The studio the two of them founded, in Paris and Troyes. Web, security audits and AI work for small companies. Hanta Tracker (hanta-tracker.app). A live map of hantavirus cases. Canal 32 counted 1.5 million views on it. IntrudR (intrudr.io). An agent that runs a penetration test end to end and writes the report. Altavora (altavora.com). A sports supplement shop, with its own storefront over a Shopify catalogue. DabaDeal (dabadeal.com). A second-hand marketplace for Morocco, between private sellers and buyers. Where the press wrote about them Hanta Tracker went up during the 2026 hantavirus outbreak and three newsrooms covered it: L’Est Éclair, Pokaa and Canal 32. Reaching them Anything about Murmell goes to the contact page and lands in the same mailbox both founders read. Anything about the studio goes to brainsec.fr. --- ## Nutzungsbedingungen Source: https://murmell.com/de/legal/terms Was Murmell bereitstellt Ein Canvas im Browser, Cloud-Ausführungsumgebungen und private Git-Repositories pro Projekt. Wir verkaufen keine Modell-Tokens weiter. Was Ihr Eigentum bleibt Ihr Code. Murmell beansprucht keinerlei Eigentums- oder Lizenzrechte an von Ihnen oder Agenten erstelltem Code. Ihre Agenten-Accounts und API-Schlüssel. Was von Ihnen erwartet wird Sie besitzen die erforderlichen Rechte am bearbeiteten Code. Sie tragen die Verantwortung für die Handlungen Ihrer Agenten. Keine Nutzung der Maschinen für Mining, Angriffe oder missbräuchliche Zwecke. Einhaltung der Nutzungsbedingungen angebundener KI-Dienste. Verfügbarkeit Frühe Produktphase ohne feste Verfügbarkeitszusagen; Code wird kontinuierlich im privaten Git-Repository gesichert. Beendigung Sie können Ihr Konto jederzeit löschen. Bei Regelverstößen behält sich Murmell Kontosperrungen vor. Fragen an hello@murmell.com. --- ## Conditions de service et de vente Source: https://murmell.com/fr/legal/terms Service et acceptation Ces conditions constituent le contrat entre vous et Intrudr, Paris, France, pour Murmell. Elles concernent les particuliers et les entreprises. Les droits impératifs des consommateurs restent applicables. Starter, essai et paiement Starter comprend un quota Murmell Cloud limité à 30 minutes par jour. Go comprend 10x Murmell Cloud, soit 5 heures par jour. Pro comprend Murmell Cloud illimité et 7 jours d’essai pour les nouveaux abonnements éligibles. Les quotas Murmell Cloud et de stockage sont partagés entre tous les Canvas d’un même abonnement. Le quota Murmell Cloud est consommé tant qu’au moins un Canvas ou agent de code est actif ; le chevauchement de Canvas dupliqués ne multiplie pas la consommation. Les Canvas en veille ne consomment pas de Murmell Cloud. Le stockage comprend les fichiers, les dépendances et le dossier personnel persistant : 1 Go pour Starter, 5 Go pour Go et 20 Go pour Pro. Un seul Canvas peut fonctionner à la fois. Lorsque le quota Murmell Cloud quotidien est épuisé, Murmell affiche un avertissement de 60 secondes, bloque les nouveaux travaux, gèle les espaces actifs puis les arrête. Le même Canvas peut rouvrir après le renouvellement quotidien ou un changement d’offre suffisant. Une limite de stockage atteinte bloque les nouveaux usages de stockage jusqu’à la libération d’espace ou au changement d’offre. Une baisse d’offre ne supprime pas les fichiers existants. Go est facturé immédiatement. Une carte bancaire est demandée au début d’un essai Pro. Sauf résiliation avant sa fin, le prix mensuel ou annuel affiché, taxes affichées incluses, est prélevé automatiquement à la fin de l’essai. Les abonnements annuels sont facturés pour une année complète à l’avance. Chaque abonnement est ensuite renouvelé automatiquement selon la périodicité choisie jusqu’à sa résiliation. Vous pouvez résilier dans les paramètres avant le prochain prélèvement. Pour exercer un droit de rétractation, écrivez à hello@murmell.com. Le démarrage immédiat ne supprime aucun droit sans réunion des conditions légales. Vos travaux et services connectés Votre code et vos résultats restent les vôtres. Vous accordez seulement l’autorisation limitée nécessaire au fonctionnement du service. Les fournisseurs connectés conservent leurs conditions et facturations. Usage acceptable Vous devez avoir les droits sur le code et les identifiants utilisés. Sont interdits les attaques, logiciels malveillants, minage, accès illicites, hébergement public et contournement des limites de tiers. Disponibilité, suspension et responsabilité Murmell est un service récent sans garantie de disponibilité. Intrudr peut suspendre un usage dangereux, illicite, abusif ou impayé. Les responsabilités et recours légalement impératifs restent applicables. Fin du service Vous pouvez résilier ou supprimer votre compte dans ses paramètres. Des preuves minimales peuvent être conservées pour les obligations légales et comptables. Consultez la Politique de confidentialité et les Mentions légales. --- ## Politique de confidentialité chez Murmell Source: https://murmell.com/fr/legal/privacy Ce qui est stocké Votre compte : une adresse email, un hachage de mot de passe si vous en avez défini un, et l’identité du fournisseur d’authentification utilisé. Vos canvas : leurs noms, leurs contenus, la disposition des fenêtres et les deux jetons de partage associés. Un jeton d’hébergeur de code, si connecté. Il est chiffré en AES-256-GCM sous une clé résidant dans l’environnement serveur et jamais en base de données. La transcription d’une session pendant la durée de vie du canvas pour retrouver l’historique à votre retour. Ce qui n’est jamais stocké Votre mot de passe en clair. Il est haché avec Argon2 lors de sa définition. Où réside chaque secret Murmell fonctionne en deux parties distinctes : l’une gère les comptes et les clés chiffrées sans jamais exécuter de code agent, l’autre fait tourner les agents sans accès à la base de données ni aux clés de déchiffrement. Autres intervenants tiers Un cookie de préférence mémorise votre choix. Le consentement est demandé pendant l’onboarding et dans les menus de l’application tant que vous n’avez pas choisi. La landing n’envoie aucun événement analytique. PostHog, uniquement après votre accord pour mesurer l’onboarding. Les champs et les textes sont masqués. Les terminaux, cadres intégrés, images, vidéos et pixels des canvas sont exclus du replay. Les paramètres et fragments des URL sont supprimés. L’identifiant local de parcours expire après 24 heures. Le replay s’arrête après cinq minutes ou dès que le premier agent est prêt. L’agent utilisé (Claude Code, Codex) qui communique directement avec son fournisseur selon ses propres conditions. Email : l’envoi des notifications et réinitialisations via un prestataire de messagerie. Dictée vocale, si utilisée, transmise via une autorisation éphémère. Votre hébergeur de code pour la synchronisation de vos dépôts privés. Finalités, bases légales et durées Intrudr, Paris, France, est responsable du traitement. Les données de compte et de projet servent à exécuter le contrat. Les journaux de sécurité relèvent de l’intérêt légitime. Les pièces de facturation répondent aux obligations légales. Compte, canvas, identifiants et projets actifs : jusqu’à la suppression du compte. Copies de récupération Azure supprimées : au plus tard sous 30 jours. Journaux techniques et de sécurité : 90 jours, sauf incident en cours. Échanges d’assistance : 24 mois après le dernier échange. Preuves d’acceptation : 5 ans. Factures et pièces comptables : 10 ans. Destinataires et transferts Les données sont transmises selon les besoins à Microsoft Azure, Stripe, aux prestataires d’email et de voix optionnelle, ainsi qu’aux hébergeurs de code et fournisseurs d’agents choisis. Certains peuvent traiter des données hors de l’Espace économique européen avec leurs garanties de transfert applicables. Vos droits Vous pouvez demander accès, rectification, export, limitation, opposition ou suppression dans les paramètres ou à hello@murmell.com. Vous pouvez également saisir la CNIL. Un lien de lecture partagé rend votre canvas accessible à toute personne le détenant, sous votre propre contrôle. --- ## Murmell Claude credits draw rules Source: https://murmell.com/legal/product-hunt-contest Organizer and dates The draw is organized by Intrudr, based in Paris, France. It opens when this page is published and closes on September 8, 2026 at 23:59:59 Europe/Paris. The random draw will take place on or after September 9, 2026. Who can enter Entry is free and open worldwide to people aged 18 or older, except where prohibited by local law. Employees, officers, contractors, and immediate family members of Intrudr may not enter. One entry is allowed per person and per Murmell account. How to enter Create or use a verified Murmell account, enter the exact campaign code PHMurmell, create at least one Murmell canvas, and submit a public link to an original social post that genuinely mentions Murmell. The post must clearly disclose that it is an entry in Murmell's $1,000 Claude credits draw and remain publicly accessible until the draw. No purchase is required. No Product Hunt vote is required or rewarded. Posts asking others to vote for Murmell on Product Hunt are not eligible. Automated, duplicate, fraudulent, unlawful, impersonating, or misleading entries may be removed. Review and selection Intrudr checks only that the submitted link is public, belongs to an eligible post, and mentions Murmell. A complete entry requires an approved post and a first canvas. One winner is then selected at random from all complete entries. The organizer may request reasonable proof of eligibility before awarding the prize. Prize The prize is one transferable award of $1,000 in Claude credits. No cash alternative is offered. Delivery remains subject to account eligibility, availability, geographic restrictions, and the provider's applicable terms. If delivery becomes impossible for reasons outside Intrudr's control, Intrudr may provide a reasonably equivalent prize where permitted by law. Winner contact The winner will be contacted through the verified email on the Murmell account and must reply within seven days. If the winner is ineligible, cannot receive the prize, or does not reply in time, another eligible entry may be selected at random. Data and platform notice Intrudr processes the account identifier, verified email, canvas completion status, social URL, review decision, and timestamps to administer the draw, prevent abuse, contact the winner, and keep necessary legal evidence. Unsuccessful entry data will be deleted or anonymized within 90 days after the prize is awarded, unless law requires longer retention. Privacy requests can be sent to hello@murmell.com. See the privacy notice. This promotion is not sponsored, endorsed, administered by, or associated with Anthropic or Product Hunt. Product Hunt votes have no effect on eligibility or the draw. --- ## Datenschutz bei Murmell Source: https://murmell.com/de/legal/privacy Was gespeichert wird Ihr Benutzerkonto: E-Mail-Adresse, Passwort-Hash (Argon2) und Login-Anbieter. Ihre Canvases: Namen, Fensteranordnungen und Freigabe-Tokens. Code-Host-Tokens, verschlüsselt mit AES-256-GCM über Server-Umgebungsschlüssel. Sitzungstranskripte während der aktiven Laufzeit des Canvas. Was niemals gespeichert wird Ihr Passwort im Klartext. Wo Geheimnisse verwahrt werden Die Architektur trennt strikt die Steuerungsebene (mit Datenbank und Schlüsseln) von der Ausführungsebene (auf der Agenten ohne Datenbankzugriff laufen). Beteiligte Dritte KI-Modellanbieter gemäß deren eigenen Nutzungsbedingungen. E-Mail-Dienstleister für Systembenachrichtigungen. Transkriptionsdienste für Spracheingaben. Ihr Git-Host zur Synchronisation privater Repositories. Ihre Rechte Sie können jederzeit Datenauskunft oder Kontolöschung über Ihre Einstellungen oder via hello@murmell.com verlangen. Freigegebene Lese-Links unterliegen Ihrer eigenen Verantwortung bei der Weitergabe. --- ## Legal notice Source: https://murmell.com/legal/notice Publisher Murmell is published by Intrudr, based in Paris, France. Publication, legal, privacy, and abuse requests: hello@murmell.com. Hosting The service is hosted by Microsoft Azure in the France Central region. Documents Read the Terms and Privacy notice. --- ## Mentions légales Source: https://murmell.com/fr/legal/notice Éditeur Murmell est édité par Intrudr, établi à Paris, France. Publication, demandes légales, vie privée et signalements : hello@murmell.com. Hébergement Le service est hébergé par Microsoft Azure dans la région France Central. Documents Consultez les Conditions et la Politique de confidentialité. --- ## Privacidad en Murmell Source: https://murmell.com/es/legal/privacy Qué se almacena Tu cuenta: dirección de correo, hash de contraseña y proveedor de inicio de sesión. Tus lienzos: nombres, disposición y tokens de acceso compartido. Tokens de repositorios, cifrados con AES-256-GCM bajo claves de entorno seguras. Transcripciones de sesión activas mientras el lienzo permanezca abierto. Qué nunca se almacena Tu contraseña en texto plano (se procesa exclusivamente con Argon2). Dónde residen los secretos Murmell divide su arquitectura en dos mitades aisladas: la parte de control gestiona cuentas sin ejecutar código de modelos, y la parte de ejecución corre agentes sin acceso a la base de datos. Terceros involucrados Proveedores de modelos de IA sujetos a sus propios términos. Proveedores de correo para notificaciones de seguridad. Servicios de transcripción de voz temporales. Tu proveedor de Git para sincronizar repositorios. Tus derechos Puedes solicitar una copia de tus datos o la baja definitiva desde tus ajustes o en hello@murmell.com. Los enlaces de lectura compartidos son responsabilidad de quien los distribuye. --- ## Privacidade no Murmell Source: https://murmell.com/pt/legal/privacy O que é armazenado Sua conta: e-mail, hash de senha e autenticação de terceiros. Seus canvas: nomes, layouts e tokens de compartilhamento. Tokens de repositórios, criptografados com AES-256-GCM. Histórico de transcrição ativo durante a sessão. O que nunca é armazenado Sua senha em texto legível (processada via Argon2). Onde residem os segredos A arquitetura divide o controle (com chaves e autenticação) do ambiente de execução (que apenas roda agentes sem acesso ao banco de dados). Terceiros envolvidos Provedores de modelos de IA sob seus próprios termos de serviço. Provedores de e-mail transacional. Serviços de áudio temporários. Seu provedor Git para sincronização de repositórios privados. Seus direitos Você pode solicitar a exportação ou exclusão dos seus dados a qualquer momento via painel ou por hello@murmell.com. Links de visualização compartilhados estão sob seu exclusivo controle de distribuição. --- ## Informativa sulla privacy di Murmell Source: https://murmell.com/it/legal/privacy Cosa viene memorizzato Il tuo account: email, hash della password (Argon2) e provider di accesso. I tuoi canvas: nomi, configurazione finestre e token di condivisione. Token di accesso a GitHub crittografati con AES-256-GCM. Trascrizioni di sessione attive durante la vita del canvas. Cosa non viene mai memorizzato La tua password in chiaro. Dove risiedono i segreti La piattaforma separa nettamente il piano di controllo (con database e chiavi) dall’ambiente di esecuzione (che esegue codice senza database). Terze parti coinvolte I provider di modelli IA secondo i loro rispettivi termini di servizio. Fornitori di servizi email transazionali. Servizi di trascrizione vocale effimeri. Il tuo provider Git per la sincronizzazione dei repository privati. I tuoi diritti Puoi richiedere la copia o l’eliminazione dei tuoi dati dalle impostazioni o scrivendo a hello@murmell.com. La diffusione dei link di lettura condivisi rimane sotto il tuo esclusivo controllo. --- ## Privacy at Murmell Source: https://murmell.com/legal/privacy What is stored Your account: an email address, a password hash if you set a password, and the identity of the provider you signed in with if you used one. Your canvases: their names, what is on them, the arrangement of the windows, and the two share tokens each one carries. A code host token, if you connect one. It is encrypted with AES-256-GCM before it is written, under a key that lives in the environment of the server and never in the database, so a database dump on its own yields nothing usable. The transcript of a session while the canvas is alive, so that closing a tab and coming back shows you what arrived while you were away. What is never stored Your password in readable form. It is hashed with Argon2 when you set it, and the hash is what is compared when you sign in. Where each secret lives Murmell runs in two halves and the split is a privacy property rather than a deployment detail. One half holds the accounts, the canvases, the tokens and the encryption key, and it never executes agent code. The other half runs the agents, and it holds no database, no decryption key and no stored credential. An agent that gets out of what it was asked to do finds a project directory and nothing worth taking. Who else is involved PostHog, only after you accept onboarding measurement. It receives journey milestones and a masked replay. Inputs and text are masked; terminal contents, embedded frames, images, video and canvas pixels are blocked. Query strings and URL fragments are removed. The local journey identifier expires after 24 hours. The replay ends after five minutes or when the first agent is ready, whichever comes first. A preference cookie remembers your choice. Consent is requested during onboarding and in application menus until you choose. The landing does not send analytics events. The agent you bring. Claude Code, Codex and the rest talk to their own vendor with your own account, exactly as they would on your laptop. What you send an agent is covered by that vendor terms. Email. Password resets, security notices and account deletion confirmations are sent through a delivery provider, which receives your email address and the message. Dictation, if you use it. The audio goes to a transcription service under a short-lived grant the server mints. The page that records you never holds the key that pays for it, and the grant expires on its own. Your code host, if you connect one. Murmell pushes your project to a repository you own, authenticating with the token you connected. Your side of it Ask for a copy of what is stored about you, or for the account to be deleted, from your account settings or by writing to hello@murmell.com. Deletion removes the account, its canvases and its stored credentials. A deletion request is confirmed by a one-time link sent to your address, because an action that cannot be undone should not be startable by somebody who is merely signed in on your machine. Purposes, legal bases, and retention Intrudr, Paris, France, is the controller. Account and project data is processed to perform the service contract. Security logs are processed for legitimate interests. Billing and accounting records are processed to meet legal obligations. Optional communications use consent where required. Account, canvas, credential, and active project data: until account deletion. Deleted Azure recovery material: removed within 30 days. Security and service logs: 90 days, longer only for an investigated incident. Support conversations: 24 months after the last exchange. Checkout acceptance evidence: 5 years. Invoices and accounting records: 10 years. Recipients and transfers Data is shared only as needed with Microsoft Azure, Stripe, email delivery and optional voice providers, and the code hosts and agent vendors you select. Some providers may process data outside the European Economic Area under their applicable transfer safeguards. Your rights You may request access, correction, export, restriction, objection, or deletion at hello@murmell.com. You may also complain to the CNIL. A read link you have handed out shows your canvas to anybody holding it. Sharing is what the link is for, and it is the one place where what happens next is yours to control. --- ## Termini di servizio Source: https://murmell.com/it/legal/terms Cosa fornisce Murmell Un canvas nel browser, macchine cloud di esecuzione e repository Git privati per ogni progetto. Non rivendiamo token di modelli. Cosa rimane di tua proprietà Il tuo codice. Murmell non rivendica alcuna proprietà o licenza sul codice scritto da te o dai tuoi agenti. I tuoi account e abbonamenti presso i fornitori di agenti IA. Cosa ci aspettiamo da te Possedere i diritti necessari sul codice elaborato. Assumerti la responsabilità delle azioni svolte dai tuoi agenti. Non utilizzare le macchine per mining, attacchi informatici o abusi. Rispettare le condizioni d’uso dei provider di modelli collegati. Disponibilità del servizio Prodotto in fase iniziale senza garanzie formali di uptime; il codice viene continuamente salvato sui repository Git privati. Risoluzione Puoi chiudere il tuo account in qualsiasi momento. Violazioni gravi possono comportare la sospensione dell’accesso. Contatto: hello@murmell.com. --- ## Términos de uso Source: https://murmell.com/es/legal/terms Qué proporciona Murmell Un lienzo en el navegador, máquinas en la nube y repositorios privados por proyecto. No revendemos tokens de modelos. Qué permanece bajo tu propiedad Tu código. Murmell no reclama derechos sobre lo que tú o tus agentes escribáis. Tus cuentas de agentes y claves de API, gestionadas directamente por sus proveedores. Qué se espera de ti Disponer de los derechos sobre el código procesado. Responsabilizarte de las acciones ordenadas a tus agentes. No utilizar las máquinas para minería, ataques o actividades ilícitas. Cumplir los términos de los proveedores de IA conectados. Disponibilidad Servicio en fase inicial sin compromiso formal de uptime; el código se guarda continuamente en repositorios privados. Cancelación Puedes eliminar tu cuenta en cualquier momento. Cualquier infracción puede derivar en la suspensión de la cuenta. Dudas en hello@murmell.com. --- ## Termos de uso Source: https://murmell.com/pt/legal/terms O que o Murmell fornece Um canvas no navegador, máquinas em nuvem e repositórios privados por projeto. Não revendemos tokens de modelos. O que permanece sob sua propriedade Seu código. O Murmell não reivindica direitos autorais sobre o que você ou seus agentes escrevem. Suas contas e chaves de API nos provedores de IA. O que é esperado de você Ter direitos legítimos sobre o código manipulado. Responsabilizar-se pelas ações executadas pelos seus agentes. Não utilizar as máquinas para mineração de criptomoedas, ataques ou fraudes. Respeitar as políticas dos provedores de IA conectados. Disponibilidade Serviço em fase inicial sem garantias estritas de uptime; backups de código são realizados continuamente no repositório Git. Encerramento Você pode cancelar e excluir sua conta a qualquer momento nas configurações. Violações podem gerar suspensão do serviço. Contato: hello@murmell.com. --- ## Terms of service and sale Source: https://murmell.com/legal/terms Service and acceptance These terms form the agreement between you and Intrudr, Paris, France, for Murmell. They apply to consumers and businesses. Mandatory consumer rights remain applicable. Starter and payment Starter is a monthly subscription of $0.99, and includes Limited Murmell Cloud, equal to 30 minutes per day. Go includes 10x Murmell Cloud, equal to 5 hours per day. Pro includes Unlimited Murmell Cloud. Murmell Cloud and storage allowances are shared across all Canvases in one subscription. Murmell Cloud usage runs while at least one Canvas or coding agent is active; overlapping duplicate Canvases do not multiply usage. Sleeping Canvases consume no Murmell Cloud. Storage allowances are 1 GB for Starter, 5 GB for Go and 20 GB for Pro, including workspace files, dependencies and the persistent home. One Canvas can run at a time. When a daily Murmell Cloud quota is used, Murmell gives a 60-second warning, blocks new work, freezes active workspaces and stops them. The same Canvas can reopen after the daily reset or a qualifying upgrade. Reaching a storage limit blocks new storage use until space is freed or the plan is upgraded. Existing files are not deleted by a downgrade. Starter, Go and Pro are charged immediately at the displayed monthly or annual price, including displayed taxes. No plan includes a free trial. Annual subscriptions are charged for a full year in advance. Each subscription then renews automatically at its selected monthly or annual interval until cancelled. You can cancel from account settings before the next charge. For a withdrawal request, contact hello@murmell.com. Starting the service immediately does not remove mandatory rights unless the legal conditions are met. Your work and connected services Your code and output remain yours. You grant Intrudr only the limited permission needed to store, process, back up, and transmit them to operate Murmell. Connected agent vendors and code hosts keep their own terms and billing. Acceptable use You must have rights to the code and credentials you use. Do not use Murmell for attacks, malware, mining, unlawful access, public hosting, or evading third-party limits. You are responsible for agent instructions and invited collaborators. Availability, suspension, and liability Murmell is an early service without an uptime guarantee. Intrudr may suspend unsafe, unlawful, abusive, or unpaid use. To the extent allowed by law, Intrudr is not liable for indirect loss, lost profits, or failures of third-party services. Nothing excludes mandatory liability or remedies. Ending the service You can cancel or delete your account in account settings. Minimal billing and acceptance records may be retained as legal or accounting evidence. See the Privacy notice and Legal notice. --- ## Политика конфиденциальности Murmell Source: https://murmell.com/ru/legal/privacy Что сохраняется Данные аккаунта: адрес электронной почты, хеш пароля (Argon2), данные провайдера входа. Данные холстов: названия, расположение окон и токены общего доступа. Токены хостинга кода, зашифрованные по алгоритму AES-256-GCM. Транскрипты активных сессий на время жизни холста. Что никогда не сохраняется Ваш пароль в открытом виде. Где хранятся секреты Архитектура физически разделена на панель управления (с базой и ключами) и изолированную среду исполнения (где работают агенты без базы данных). Сторонние сервисы Провайдеры моделей ИИ в соответствии с их собственными правилами. Сервисы доставки служебных электронных писем. Службы временной транскрипции голосового ввода. Ваш Git-хостинг для синхронизации приватных репозиториев. Ваши права Вы можете запросить выгрузку данных или удаление аккаунта в настройках или написав на hello@murmell.com. Распространение ссылок на просмотр холста находится под вашим личным контролем. --- ## Условия использования Source: https://murmell.com/ru/legal/terms Что предоставляет Murmell Браузерный холст, облачные виртуальные машины и приватные Git-репозитории. Мы не перепродаем токены моделей ИИ. Что остается вашей собственностью Ваш код. Murmell не претендует на права на код, созданный вами или вашими агентами. Ваши аккаунты и ключи у поставщиков моделей ИИ. Что требуется от пользователя Обладать законными правами на обрабатываемый код. Нести полную ответственность за действия, поручаемые агентам. Не использовать ресурсы для майнинга, кибератак или противоправных действий. Соблюдать правила подключенных сервисов ИИ. Доступность сервиса Продукт находится на ранней стадии; код непрерывно синхронизируется с приватным Git-репозиторием проекта. Прекращение обслуживания Вы можете удалить аккаунт в любой момент. В случае нарушений доступ к сервису может быть заблокирован. Вопросы: hello@murmell.com. --- ## Murmell गोपनीयता नीति Source: https://murmell.com/hi/legal/privacy क्या संग्रहीत किया जाता है खाता विवरण: ईमेल पता, पासवर्ड हैश (Argon2), और लॉगिन प्रदाता आईडी। कैनवस डेटा: नाम, विंडो लेआउट और शेयर टोकन। कोड होस्ट टोकन, AES-256-GCM द्वारा एन्क्रिप्टेड। सक्रिय सेशन ट्रांसक्रिप्ट। क्या कभी संग्रहीत नहीं होता आपका पासवर्ड सादे टेक्स्ट में। सीक्रेट कहाँ रहते हैं कंट्रोल प्लेन (डेटाबेस और की) और एक्ज़ीक्यूशन प्लेन (एजेंट मशीन) पूरी तरह अलग हैं। तृतीय-पक्ष सेवाएं AI मॉडल प्रदाता उनकी शर्तों के अनुसार। ईमेल सूचना प्रदाता। अस्थायी वॉयस ट्रांसक्रिप्शन सेवा। प्राइवेट रिपॉजिटरी सिंक के लिए Git होस्ट। आपके अधिकार आप सेटिंग से डेटा कॉपी या खाता हटाने का अनुरोध कर सकते हैं या hello@murmell.com पर लिख सकते हैं। साझा किए गए रीड-ओनली लिंक आपके नियंत्रण में रहते हैं। --- ## सेवा की शर्तें Source: https://murmell.com/hi/legal/terms Murmell क्या प्रदान करता है ब्राउज़र कैनवस, क्लाउड मशीनें और प्रोजेक्ट के लिए निजी Git रिपॉजिटरी। हम मॉडल टोकन का पुनर्विक्रय नहीं करते। आपका स्वामित्व क्या रहता है आपका कोड। Murmell आपके कोड पर किसी स्वामित्व या लाइसेंस का दावा नहीं करता। आपके एजेंट खाते और आधिकारिक API की। आपसे क्या अपेक्षाएं हैं कोड पर आवश्यक कानूनी अधिकार होना। एजेंट द्वारा किए गए कार्यों की जिम्मेदारी लेना। माइनिंग या साइबर हमलों के लिए मशीनों का उपयोग न करना। कनेक्टेड AI सेवाओं की शर्तों का पालन करना। सेवा की उपलब्धता प्रारंभिक चरण की सेवा; काम लगातार प्राइवेट Git रिपॉजिटरी में सुरक्षित किया जाता है। समाप्ति आप कभी भी खाता हटा सकते हैं। नियमों का उल्लंघन होने पर खाता निलंबित किया जा सकता है। संपर्क: hello@murmell.com. --- ## Murmell 개인정보 처리방침 Source: https://murmell.com/ko/legal/privacy 수집 및 저장 항목 계정 정보: 이메일 주소, 비밀번호 해시(Argon2), 로그인 제공자 식별자. 캔버스 정보: 이름, 창 배치 상태, 공유 토큰. 코드 호스트 토큰(연결 시): AES-256-GCM으로 암호화 보관. 세션 트랜스크립트: 캔버스 활성 기간 중 작업 연속성 유지 목적. 절대 저장하지 않는 항목 평문 형태의 비밀번호. 보안 데이터 보관 위치 제어 시스템(인증 및 키 관리)과 실행 시스템(에이전트 구동)을 물리적으로 분리하여 실행 환경에서의 기밀 유출 가능성을 원천 차단합니다. 제3자 서비스 연동 사용자가 연동한 AI 모델 제공업체(해당 업체의 약관 적용). 보안 안내 메일 발송 서비스. 임시 음성 인식 받아쓰기 서비스. 비공개 저장소 동기화를 위한 Git 호스팅 서비스. 이용자의 권리 계정 설정 또는 hello@murmell.com을 통해 데이터 사본 요청 및 계정 영구 삭제를 신청할 수 있습니다. 공유된 읽기 전용 링크의 배포 및 관리는 전적으로 공유자의 책임입니다. --- ## 서비스 이용약관 Source: https://murmell.com/ko/legal/terms Murmell이 제공하는 서비스 브라우저 협업 캔버스, 클라우드 실행 머신, 프로젝트별 전용 비공개 Git 리포지토리. 모델 토큰을 재판매하지 않습니다. 이용자의 소유권 코드 소유권. Murmell은 이용자나 에이전트가 작성한 코드에 대해 어떠한 소유권이나 라이선스도 주장하지 않습니다. 이용자의 AI 에이전트 계정 및 API 키. 이용자의 준수 사항 작업 대상 코드에 대한 정당한 권한을 보유할 것. 에이전트에 지시한 작업 내용 및 결과에 대해 책임을 다할 것. 머신을 가상화폐 채굴, 사이버 공격, 비정상적 트래픽 유발에 사용하지 않을 것. 연동된 AI 서비스 제공업체의 이용약관을 준수할 것. 서비스 가용성 초기 개발 단계 서비스로 무중단 운영을 보증하지 않으나 작업물은 전용 비공개 Git 리포지토리에 실시간 안전하게 동기화됩니다. 이용 계약 해지 이용자는 언제든 계정을 해지할 수 있으며, 부정 이용 시 서비스 이용이 제한될 수 있습니다. 문의: hello@murmell.com. --- ## Murmell プライバシーポリシー Source: https://murmell.com/ja/legal/privacy 保存される情報 アカウント情報：メールアドレス、パスワードハッシュ（Argon2）、ログインプロバイダ識別子。 キャンバス情報：名称、ウィンドウ配置、共有トークン。 コードホストのアクセスキー（接続時）：サーバー環境変数内の鍵を用いて AES-256-GCM で暗号化。 セッションログ：キャンバス稼働中の作業継続用。 保存されない情報 平文のパスワード。 機密情報の分離管理 制御系（認証・暗号鍵管理）と実行系（エージェント実行）を物理的に分離し、実行マシンからの情報漏洩リスクを排除しています。 連携する第三者サービス 利用するAIモデルプロバイダ（各自の規約に準拠）。 システム通知用メール配信サービス。 一時的な音声入力文字起こしサービス。 プライベートリポジトリ同期用の Git ホスティングサービス。 お客様の権利 設定画面または hello@murmell.com 宛てのメールにて、データの開示請求およびアカウント削除が可能です。 共有した閲覧リンクの管理はお客様自身の責任において行われます。 --- ## 利用規約 Source: https://murmell.com/ja/legal/terms Murmell が提供するもの ブラウザ上の協調キャンバス、クラウド実行環境、プロジェクトごとのプライベート Git リポジトリ。モデル利用料の再販は行いません。 お客様に帰属するもの ソースコードの著作権。当社はお客様やエージェントが作成したコードに対していかなる権利も主張しません。 AI エージェントのアカウントおよび API 契約。 お客様への要請事項 処理対象のコードに対する正当な利用権を保持していること。 エージェントに指示した動作および結果に対して責任を負うこと。 マシンをマイニング、サイバー攻撃、不正アクセス等に利用しないこと。 接続する各 AI サービスの利用規約を遵守すること。 サービス品質 初期段階のサービスであり稼働率の完全保証はありませんが、コードは常に専用のプライベート Git リポジトリへ継続同期されます。 契約の終了 いつでもアカウントを削除できます。不正利用が確認された場合、アカウントを停止することがあります。 お問い合わせ：hello@murmell.com。 --- ## 服务条款 Source: https://murmell.com/zh/legal/terms Murmell 提供的服务 浏览器中的协作画布、运行代理的云端机器以及每个项目的私有 Git 仓库。Murmell 仅启动您已付费的官方 CLI，不转售模型 Token。 归您所有的权益 您的代码所有权。Murmell 对您或您的代理编写的任何内容不主张任何所有权，仅保留维持服务运转所必需的临时处理权限。 您的代理账户。您绑定的订阅或 API 密钥归您所有，由对应厂商直接计费，可随时解绑。 对您的使用要求 您对指示代理处理的代码拥有合法的知识产权或使用权。 您对代理执行的操作及其后果承担完全责任。 机器仅用于合法的代码开发项目，严禁用于挖矿、网络攻击或规避第三方限制。 遵守所接入代理服务商的相应服务条款。 服务可用性 Murmell 处于早期发展阶段，不提供绝对的正常运行时间保证。机器属于临时资源，但项目代码会在每次变更及关机前实时推送到私有仓库。 终止服务 您可以随时在设置中删除账户。如存在违反上述规则的行为，Murmell 有权暂停违规账户。 任何疑问请联系 hello@murmell.com。 --- ## Murmell 隐私政策 Source: https://murmell.com/zh/legal/privacy 存储的内容 您的账户信息：电子邮箱、密码哈希（若设置了密码）以及第三方登录身份。 您的画布数据：名称、内容布局、窗口排列及两组共享令牌。 代码托管平台令牌（若连接）：在写入前使用 AES-256-GCM 加密，密钥仅保存在服务端环境变量中。 会话转录记录：在画布活跃期间保留，以便您在重新打开标签页时恢复上下文。 绝不存储的内容 明文形式的密码。密码在设置时即通过 Argon2 进行哈希处理。 各类机密的存放位置 Murmell 采用严格的双半区物理隔离：控制端负责账户、令牌与加密密钥，绝不执行代理代码；执行端负责运行代理，绝不配置数据库连接与解密密钥。 涉及的第三方服务 您使用的代理工具（Claude Code、Codex 等），它们遵循各自服务商的条款。 电子邮件服务商，用于发送安全通知与密码重置邮件。 语音转录服务（若使用），通过服务端签发的短期授权调用。 您连接的代码托管平台，用于推送项目代码到您的私有仓库。 您的权利 您可以随时在账户设置中导出存储的数据或申请删除账户，或发送邮件至 hello@murmell.com。 您分享的只读链接可供任何持有者查看画布，分享范围完全由您自主控制。 --- ## Agents IA de code dans le cloud Source: https://murmell.com/fr Le problème que ça règle Un agent IA de code sur un portable occupe un terminal et une machine. Le deuxième attend, ou bien il travaille sur une copie du dépôt et quelqu'un fusionne le soir. C'est la raison pour laquelle la plupart des gens qui utilisent Claude Code ou Codex en lancent un seul à la fois : la coordination coûte plus cher que le travail gagné. Murmell enlève les copies. Les agents tournent sur une machine cloud, partagent un dossier, et réservent un chemin avant d'y écrire. Rien ne fusionne à la fin parce que rien n'a divergé au début. La réservation de fichiers Avant d'écrire, un agent annonce les chemins qu'il va toucher. Le tableau tient le registre et refuse ce chemin à tous les autres tant que le détenteur ne l'a pas rendu. Un seul détenteur par fichier, appliqué par le serveur. Quand une écriture arrive quand même sur un fichier tenu par quelqu'un d'autre, elle est photographiée avant d'atterrir. Vous récupérez les deux versions au lieu d'en perdre une. Les agents, sur vos comptes Claude Code, Codex, Kimi et OpenCode s'ouvrent chacun dans une fenêtre du canvas, avec un vrai terminal derrière. Vous vous connectez avec l'abonnement ou la clé que vous avez déjà. Murmell facture la machine et la salle, jamais les jetons du modèle. Les sessions vivent sur la machine, pas dans l'onglet. Fermez le navigateur, reprenez une heure plus tard, les agents ont continué. C'est la différence pratique entre une IA dans le cloud et une IA sur votre bureau. La salle, et qui regarde Un canvas se partage par un lien. Les invités voient les fenêtres, lisent les terminaux qui défilent et voient les curseurs des autres, avec un nom et une couleur sur chacun. Regarder ne coûte rien et ne demande pas de compte. Ce que ça coûte Starter coûte 0,99 $ par mois, avec un quota Murmell Cloud limité à 30 minutes par jour et 1 Go de stockage partagé. Go coûte 9 $ par mois avec 10x Murmell Cloud, soit 5 heures par jour, et 5 Go. Pro coûte 39 $ par mois avec Murmell Cloud illimité et 20 Go. Le stockage est partagé entre tous les Canvas de l’abonnement. Chaque offre comprend un Canvas actif et 20 fenêtres d’agents. Le paiement annuel offre 20 % de réduction. Les fournisseurs d’agents sont facturés séparément. Teams et Enterprise sont disponibles sur demande. Ouvrir un canvas Pour aller plus loin Ce que veut dire IA cloud reprend le terme depuis le début. Plusieurs agents IA sur un même dépôt explique le mécanisme de réservation en détail, et les comparatifs placent Murmell face à Cursor, Devin, Copilot et les agents cloud de Codex. --- ## Agenti IA di coding nel cloud Source: https://murmell.com/it Il problema che risolve Un agente IA di coding su un portatile occupa un terminale e una macchina. Il secondo aspetta, oppure lavora su una copia del repository e qualcuno la unisce la sera. Per questo la maggior parte di chi usa Claude Code o Codex ne lancia uno solo alla volta: coordinare costa più del lavoro guadagnato. Murmell elimina le copie. Gli agenti girano su una macchina cloud, condividono una cartella, e riservano un percorso prima di scriverci. Alla fine non c'è niente da unire perché all'inizio niente si è separato. La prenotazione dei file Prima di scrivere, un agente annuncia i percorsi che toccherà. La bacheca tiene il registro e li nega a tutti gli altri finché il titolare non li rilascia. Un solo titolare per file, applicato dal server. Se comunque arriva una scrittura su un file che un altro agente tiene, viene fotografata prima di atterrare. Recuperi entrambe le versioni invece di perderne una. Gli agenti, sui tuoi account Claude Code, Codex, Kimi e OpenCode si aprono ciascuno in una finestra del canvas, con un vero terminale dietro. Ti colleghi con l'abbonamento o la chiave che hai già. Murmell fa pagare la macchina e la stanza, mai i token del modello. Le sessioni vivono sulla macchina, non nella scheda del browser. Chiudi il browser, torna un'ora dopo, gli agenti hanno continuato a lavorare. È la differenza pratica tra un'IA nel cloud e un'IA sul tuo computer. La stanza, e chi guarda Un canvas si condivide con un link. Gli ospiti vedono le finestre, leggono i terminali che scorrono e vedono i cursori degli altri, ciascuno con un nome e un colore. Guardare non costa nulla e non richiede un account. Cosa costa Starter costa 0,99 $ al mese, con Limited Murmell Cloud, 30 minuti al giorno, e 1 GB condiviso. Go costa 9 $ al mese con 10x Murmell Cloud, 5 ore al giorno, e 5 GB. Pro costa 39 $ al mese con Unlimited Murmell Cloud e 20 GB. Lo spazio è condiviso tra tutti i Canvas dell’abbonamento. Un Canvas attivo e 20 finestre agente per piano. Pagamento annuale con sconto del 20%. Fornitori fatturati separatamente. Teams ed Enterprise su richiesta. Apri un canvas Per saperne di più Cosa vuol dire IA cloud riprende il termine dall'inizio. Più agenti IA su un solo repository spiega il meccanismo di prenotazione nel dettaglio, e i confronti mettono Murmell a confronto con Cursor, Devin, Copilot e gli agenti cloud di Codex. --- ## Agentes de IA de código en la nube Source: https://murmell.com/es El problema que resuelve Un agente de IA de código en un portátil ocupa una terminal y una máquina. El segundo espera, o trabaja sobre una copia del repositorio y alguien fusiona por la noche. Por eso la mayoría de la gente que usa Claude Code o Codex lanza solo uno a la vez: coordinar cuesta más que el trabajo que se gana. Murmell elimina las copias. Los agentes corren en una máquina en la nube, comparten un directorio, y reservan una ruta antes de escribir en ella. Al final no hay nada que fusionar porque nunca hubo nada que divergiera. La reserva de archivos Antes de escribir, un agente anuncia las rutas que va a tocar. El panel guarda el registro y se las niega a todos los demás hasta que el titular las libera. Un solo titular por archivo, aplicado por el servidor. Si de todos modos llega una escritura sobre un archivo que otro tiene reservado, se fotografía antes de aterrizar. Recuperas las dos versiones en vez de perder una. Los agentes, con tus cuentas Claude Code, Codex, Kimi y OpenCode se abren cada uno en una ventana del canvas, con una terminal real detrás. Te conectas con la suscripción o la clave que ya tienes. Murmell cobra la máquina y la sala, nunca los tokens del modelo. Las sesiones viven en la máquina, no en la pestaña. Cierra el navegador, vuelve una hora después, los agentes han seguido trabajando. Esa es la diferencia práctica entre una IA en la nube y una IA en tu escritorio. La sala, y quién mira Un canvas se comparte con un enlace. Los invitados ven las ventanas, leen las terminales que se desplazan y ven los cursores de los demás, cada uno con su nombre y su color. Mirar no cuesta nada y no requiere cuenta. Lo que cuesta Starter cuesta 0,99 $ al mes, con Limited Murmell Cloud, 30 minutos al día, y 1 GB compartido. Go cuesta 9 $ al mes con 10x Murmell Cloud, 5 horas al día, y 5 GB. Pro cuesta 39 $ al mes con Unlimited Murmell Cloud y 20 GB. El almacenamiento se comparte entre todos los Canvas de la suscripción. Un Canvas activo y 20 ventanas de agentes por plan. Pago anual con 20 % de descuento. Proveedores facturados aparte. Teams y Enterprise bajo consulta. Abrir un canvas Para seguir leyendo Qué significa IA en la nube retoma el término desde el principio. Varios agentes de IA en un mismo repositorio explica el mecanismo de reserva en detalle, y las comparativas ponen a Murmell frente a Cursor, Devin, Copilot y los agentes en la nube de Codex. --- ## Agentes de IA de código na nuvem Source: https://murmell.com/pt O problema que isso resolve Um agente de IA de código em um notebook ocupa um terminal e uma máquina. O segundo espera, ou trabalha em uma cópia do repositório e alguém funde as mudanças à noite. É por isso que a maioria das pessoas que usa Claude Code ou Codex lança apenas um agente por vez: coordenar custa mais caro do que o trabalho que se ganha. Murmell elimina as cópias. Os agentes rodam em uma máquina na nuvem, compartilham um diretório, e reservam um caminho antes de escrever nele. No final não há nada para fundir porque nunca houve nada que divergisse. A reserva de arquivos Antes de escrever, um agente anuncia os caminhos que vai tocar. O painel guarda o registro e nega esse caminho a todos os outros até que o titular o libere. Um único titular por arquivo, aplicado pelo servidor. Se mesmo assim chega uma escrita em um arquivo que outro agente detém, ela é fotografada antes de ser gravada. Você recupera as duas versões em vez de perder uma. Os agentes, com suas contas Claude Code, Codex, Kimi e OpenCode abrem cada um em uma janela do canvas, com um terminal de verdade por trás. Você se conecta com a assinatura ou a chave que já tem. Murmell cobra pela máquina e pela sala, nunca pelos tokens do modelo. As sessões vivem na máquina, não na aba. Feche o navegador, volte uma hora depois, os agentes continuaram trabalhando. Essa é a diferença prática entre uma IA na nuvem e uma IA no seu computador. A sala, e quem assiste Um canvas se compartilha por um link. Os convidados veem as janelas, leem os terminais rolando e veem os cursores dos outros, cada um com um nome e uma cor. Assistir não custa nada e não exige conta. Quanto custa Starter custa US$ 0,99 por mês, com Limited Murmell Cloud, 30 minutos por dia, e 1 GB compartilhado. Go custa US$ 9 por mês com 10x Murmell Cloud, 5 horas por dia, e 5 GB. Pro custa US$ 39 por mês com Unlimited Murmell Cloud e 20 GB. O armazenamento é compartilhado entre todos os Canvas da assinatura. Um Canvas ativo e 20 janelas de agentes por plano. Pagamento anual com 20% de desconto. Provedores cobrados à parte. Teams e Enterprise sob consulta. Abrir um canvas Para saber mais O que significa IA na nuvem retoma o termo desde o início. Vários agentes de IA em um mesmo repositório explica o mecanismo de reserva em detalhe, e as comparações colocam o Murmell frente a Cursor, Devin, Copilot e os agentes na nuvem do Codex. --- ## KI-Coding-Agenten in der Cloud Source: https://murmell.com/de Das Problem, das es löst Ein KI-Coding-Agent auf einem Laptop belegt ein Terminal und eine Maschine. Der zweite wartet, oder er arbeitet an einer Kopie des Repositorys, und abends führt jemand die Änderungen zusammen. Deshalb starten die meisten Leute, die Claude Code oder Codex nutzen, immer nur einen Agenten gleichzeitig: Koordination kostet mehr, als die zusätzliche Arbeit einbringt. Murmell entfernt die Kopien. Die Agenten laufen auf einer Cloud-Maschine, teilen sich ein Verzeichnis und beanspruchen einen Pfad, bevor sie hineinschreiben. Am Ende gibt es nichts zusammenzuführen, weil am Anfang nichts auseinandergelaufen ist. Die Dateireservierung Bevor ein Agent schreibt, kündigt er die Pfade an, die er anfassen wird. Das Board führt das Register und verweigert diesen Pfad allen anderen, bis der Inhaber ihn freigibt. Ein einziger Inhaber pro Datei, durchgesetzt vom Server. Kommt trotzdem eine Schreibaktion auf eine Datei an, die ein anderer Agent hält, wird sie fotografiert, bevor sie ankommt. Sie erhalten beide Versionen zurück, statt eine zu verlieren. Die Agenten, mit Ihren Konten Claude Code, Codex, Kimi und OpenCode öffnen sich jeweils in einem Fenster der Canvas, mit einem echten Terminal dahinter. Sie melden sich mit dem Abo oder dem Schlüssel an, den Sie bereits haben. Murmell berechnet die Maschine und den Raum, niemals die Tokens des Modells. Die Sitzungen leben auf der Maschine, nicht im Tab. Schließen Sie den Browser, kommen Sie eine Stunde später zurück, haben die Agenten weitergearbeitet. Das ist der praktische Unterschied zwischen einer KI in der Cloud und einer KI auf Ihrem Rechner. Der Raum, und wer zusieht Eine Canvas wird über einen Link geteilt. Gäste sehen die Fenster, lesen die durchlaufenden Terminals und sehen die Cursor der anderen, jeder mit einem Namen und einer Farbe. Zusehen kostet nichts und erfordert kein Konto. Was es kostet Starter kostet 0,99 $ monatlich, mit Limited Murmell Cloud, 30 Minuten pro Tag, und 1 GB gemeinsamem Speicher. Go kostet 9 $ monatlich mit 10x Murmell Cloud, 5 Stunden pro Tag, und 5 GB. Pro kostet 39 $ monatlich mit Unlimited Murmell Cloud und 20 GB. Der Speicher wird von allen Canvas des Abonnements geteilt. Ein aktives Canvas und 20 Agentenfenster pro Tarif. Jährliche Zahlung spart 20 %. Agentenanbieter werden separat abgerechnet. Teams und Enterprise auf Anfrage. Canvas öffnen Um mehr zu erfahren Was Cloud-KI wirklich bedeutet nimmt den Begriff von vorn auf. Mehrere KI-Agenten in einem Repository erklärt den Reservierungsmechanismus im Detail, und die Vergleiche stellen Murmell neben Cursor, Devin, Copilot und die Cloud-Agenten von Codex. --- ## ИИ-агенты для кода, работающие в облаке Source: https://murmell.com/ru Проблема, которую это решает ИИ-агент для кода на ноутбуке занимает терминал и целую машину. Второй агент либо ждёт, либо работает с копией репозитория, и кто-то вечером сливает изменения вручную. Именно поэтому большинство людей, использующих Claude Code или Codex, запускают только одного агента за раз: координация стоит дороже, чем выигрыш в работе. Murmell убирает копии. Агенты работают на облачной машине, используют общий каталог и занимают путь перед тем, как в него писать. В конце ничего не нужно сливать, потому что вначале ничего не разошлось. Резервирование файлов Перед тем как писать, агент объявляет пути, которые собирается затронуть. Доска ведёт учёт и отказывает в этом пути всем остальным, пока владелец его не отпустит. У файла только один владелец, и это применяет сервер. Если запись всё же приходит на файл, которым владеет кто-то другой, она снимается снимком до того, как попадает на диск. Вы получаете обе версии вместо того, чтобы потерять одну. Агенты на ваших аккаунтах Claude Code, Codex, Kimi и OpenCode открываются каждый в своём окне канваса, а за ним настоящий терминал. Вы подключаетесь через подписку или ключ, который у вас уже есть. Murmell берёт плату за машину и комнату, но никогда за токены модели. Сессии живут на машине, а не во вкладке. Закройте браузер, вернитесь через час, и агенты будут продолжать работу. Это и есть практическая разница между ИИ в облаке и ИИ на вашем компьютере. Комната, и кто наблюдает Канвас открывается по ссылке. Приглашённые видят окна, читают терминалы в реальном времени и видят курсоры друг друга, у каждого своё имя и цвет. Смотреть бесплатно и не требует аккаунта. Сколько это стоит Starter стоит 0,99 $ в месяц и включает Limited Murmell Cloud, 30 минут в день, и 1 ГБ общего хранилища. Go стоит 9 $ в месяц и включает 10x Murmell Cloud, 5 часов в день, и 5 ГБ. Pro стоит 39 $ в месяц и включает Unlimited Murmell Cloud и 20 ГБ. Хранилище общее для всех Canvas подписки. Один активный Canvas и 20 окон агентов в каждом плане. Годовая оплата со скидкой 20 %. Поставщики агентов оплачиваются отдельно. Teams и Enterprise по запросу. Открыть канвас Что читать дальше Что означает облачный ИИ раскрывает термин с самого начала. Несколько ИИ-агентов в одном репозитории подробно объясняет механизм резервирования, а сравнения ставят Murmell рядом с Cursor, Devin, Copilot и облачными агентами Codex. --- ## क्लाउड में कोड लिखने वाले AI एजेंट Source: https://murmell.com/hi यह किस समस्या को हल करता है लैपटॉप पर चलने वाला कोड एजेंट एक टर्मिनल और पूरी मशीन घेर लेता है। दूसरा एजेंट या तो इंतज़ार करता है, या रिपॉज़िटरी की एक कॉपी पर काम करता है और कोई शाम को बदलाव मिलाता है। यही वजह है कि Claude Code या Codex इस्तेमाल करने वाले ज़्यादातर लोग एक बार में सिर्फ़ एक ही एजेंट चलाते हैं: समन्वय की कीमत काम के फ़ायदे से ज़्यादा पड़ती है। Murmell कॉपियां हटा देता है। एजेंट क्लाउड मशीन पर चलते हैं, एक फ़ोल्डर साझा करते हैं, और लिखने से पहले रास्ता आरक्षित करते हैं। आख़िर में कुछ मिलाना नहीं पड़ता क्योंकि शुरुआत में कुछ अलग हुआ ही नहीं। फ़ाइल आरक्षण लिखने से पहले, एजेंट उन रास्तों की घोषणा करता है जिन्हें वह छूने वाला है। बोर्ड इसका हिसाब रखता है और जब तक मालिक इसे छोड़ नहीं देता, बाकी सभी को यह रास्ता नहीं मिलता। एक फ़ाइल का एक ही मालिक होता है, और इसे सर्वर लागू करता है। अगर फिर भी किसी और की फ़ाइल पर लेखन पहुंचता है, तो डिस्क पर उतरने से पहले उसका स्नैपशॉट ले लिया जाता है। आप एक वर्ज़न खोने की बजाय दोनों वर्ज़न पाते हैं। आपके अकाउंट पर एजेंट Claude Code, Codex, Kimi और OpenCode कैनवस की अपनी-अपनी विंडो में खुलते हैं, हर एक के पीछे एक असली टर्मिनल। आप अपनी मौजूदा सब्सक्रिप्शन या कुंजी से जुड़ते हैं। Murmell मशीन और कमरे का शुल्क लेता है, मॉडल के टोकन का कभी नहीं। सेशन टैब में नहीं, मशीन पर रहते हैं। ब्राउज़र बंद करें, एक घंटे बाद वापस आएं, एजेंट काम करते रहे होंगे। क्लाउड में AI और आपके कंप्यूटर पर चलने वाले AI के बीच यही असली फ़र्क़ है। कमरा, और कौन देख रहा है कैनवस एक लिंक से साझा होता है। आमंत्रित लोग विंडो देखते हैं, टर्मिनल को लाइव पढ़ते हैं, और एक-दूसरे के कर्सर देखते हैं, हर एक का अपना नाम और रंग। देखना मुफ़्त है और किसी अकाउंट की ज़रूरत नहीं। इसकी कीमत क्या है Starter 0.99 डॉलर प्रति माह है और इसमें Limited Murmell Cloud, रोज़ 30 मिनट, और 1 GB साझा स्टोरेज मिलता है। Go 9 डॉलर प्रति माह है और इसमें 10x Murmell Cloud, रोज़ 5 घंटे, और 5 GB मिलता है। Pro 39 डॉलर प्रति माह है और इसमें Unlimited Murmell Cloud और 20 GB मिलता है। स्टोरेज सदस्यता के सभी Canvas में साझा है। हर प्लान में एक सक्रिय Canvas और 20 एजेंट विंडो। वार्षिक भुगतान पर 20% छूट। एजेंट प्रदाताओं का शुल्क अलग है। Teams और Enterprise के लिए संपर्क करें। कैनवस खोलें आगे क्या पढ़ें क्लाउड AI का मतलब यह शब्द शुरू से समझाता है। एक रिपॉज़िटरी में कई AI एजेंट आरक्षण के तरीके को विस्तार से बताता है, और तुलनाएं Murmell को Cursor, Devin, Copilot और Codex के क्लाउड एजेंट के सामने रखती हैं। --- ## 클라우드에서 실행되는 AI 코딩 에이전트 Source: https://murmell.com/ko 해결하는 문제 노트북에서 실행되는 AI 코딩 에이전트는 터미널과 머신을 하나씩 차지합니다. 두 번째 에이전트는 기다리거나, 저장소의 복사본에서 작업하다가 밤에 누군가가 병합해야 합니다. Claude Code나 Codex를 쓰는 대부분의 사람이 한 번에 하나만 실행하는 이유가 여기 있습니다. 조율 비용이 얻는 작업보다 크기 때문입니다. Murmell은 복사본을 없앱니다. 에이전트는 클라우드 머신에서 실행되며 디렉터리를 공유하고, 쓰기 전에 경로를 점유합니다. 처음부터 아무것도 갈라지지 않았으니, 마지막에 병합할 것도 없습니다. 파일 점유 쓰기 전에 에이전트는 건드릴 경로를 선언합니다. 보드가 그 기록을 보관하고, 소유자가 놓아줄 때까지 다른 모든 에이전트에게 그 경로를 거부합니다. 파일 하나에 소유자는 한 명뿐이며, 이는 서버가 강제합니다. 그래도 다른 에이전트가 점유한 파일에 쓰기가 발생하면, 반영되기 전에 스냅샷됩니다. 하나를 잃는 대신 두 버전을 모두 되찾을 수 있습니다. 여러분의 계정으로 실행되는 에이전트 Claude Code, Codex, Kimi, OpenCode는 각각 캔버스의 창 안에서 열리고, 그 뒤에는 진짜 터미널이 있습니다. 이미 가지고 있는 구독이나 키로 연결합니다. Murmell이 청구하는 것은 머신과 방이며, 모델 토큰은 절대 청구하지 않습니다. 세션은 브라우저 탭이 아니라 머신 위에서 살아 있습니다. 브라우저를 닫고 한 시간 뒤에 돌아와도 에이전트는 작업을 계속하고 있습니다. 이것이 클라우드 AI와 여러분의 컴퓨터 위 AI의 실질적인 차이입니다. 방, 그리고 지켜보는 사람들 캔버스는 링크로 공유됩니다. 초대받은 사람은 창을 보고, 흘러가는 터미널을 읽고, 이름과 색이 붙은 다른 사람들의 커서를 볼 수 있습니다. 보는 것은 비용이 들지 않고 계정도 필요 없습니다. 요금 Starter는 월 0.99달러이며 Limited Murmell Cloud, 하루 30분, 1 GB 공유 저장 공간을 제공합니다. Go는 월 9달러이며 10x Murmell Cloud, 하루 5시간, 5 GB를 제공합니다. Pro는 월 39달러이며 Unlimited Murmell Cloud와 20 GB를 제공합니다. 저장 공간은 구독의 모든 Canvas가 공유합니다. 각 요금제는 활성 Canvas 1개와 에이전트 창 20개를 제공합니다. 연간 결제 20% 할인. 에이전트 제공업체 요금은 별도입니다. Teams와 Enterprise는 문의해 주세요. 캔버스 열기 더 읽어보기 클라우드 AI가 무엇을 뜻하는지는 이 용어를 처음부터 설명합니다. 하나의 저장소에서 여러 AI 에이전트를 실행하기 는 점유 메커니즘을 자세히 설명하고, 비교 페이지에서는 Murmell을 Cursor, Devin, Copilot, Codex의 클라우드 에이전트와 비교합니다. --- ## クラウドで動くAIコーディングエージェント Source: https://murmell.com/ja 解決する問題 ノートパソコン上のAIコーディングエージェントは、ターミナルとマシンを1つ占有します。2つ目は待つか、 リポジトリのコピー上で作業して誰かが夜にマージすることになります。Claude CodeやCodexを使うほとんどの 人が一度に1つしか起動しないのはこのためです。調整のコストが、得られる作業を上回るからです。 Murmellはコピーをなくします。エージェントはクラウドマシン上で動作し、ディレクトリを共有し、書き込む 前にパスを確保します。最初に何も分岐しなかったので、最後に何もマージする必要がありません。 ファイルの確保 書き込む前に、エージェントは触れるパスを宣言します。ボードがその記録を保持し、所有者が解放するまで 他のすべてのエージェントに対してそのパスを拒否します。1つのファイルにつき所有者は1人だけで、これは サーバーが強制します。 それでも他のエージェントが保持しているファイルへの書き込みが発生した場合、それは反映される前に スナップショットされます。1つを失う代わりに、両方のバージョンを取り戻せます。 あなたのアカウントで動くエージェント Claude Code、Codex、Kimi、OpenCodeは、それぞれキャンバスのウィンドウの中で開き、その裏には本物の ターミナルがあります。すでに持っているサブスクリプションやキーで接続します。Murmellが課金するのは マシンと部屋であり、モデルのトークンでは決してありません。 セッションはブラウザのタブではなく、マシン上で生きています。ブラウザを閉じて1時間後に戻っても、 エージェントは作業を続けています。これがクラウドのAIと自分のコンピューター上のAIの実際の違いです。 部屋と、それを見ている人 キャンバスはリンクで共有されます。招待された人はウィンドウを見て、流れるターミナルを読み、それぞれ 名前と色のついた他の人のカーソルを見られます。見るだけなら何も費用がかからず、アカウントも不要です。 料金 Starter は月額0.99ドルで、Limited Murmell Cloud、毎日30分、1 GBを利用できます。Go は月額9ドルで、10x Murmell Cloud、毎日5時間、5 GBです。Pro は月額39ドルで、Unlimited Murmell Cloud と20 GBです。ストレージは契約内の全 Canvas で共有します。各プランは同時に1つの Canvas と20のエージェントウィンドウを利用できます。年払いは20%割引。エージェント提供元の料金は別途。Teams と Enterprise はお問い合わせください。 キャンバスを開く さらに読む クラウドAIの意味はこの言葉を最初から説明します。 1つのリポジトリで複数のAIエージェントを動かす は確保の仕組みを詳しく説明し、比較ページではMurmellをCursor、Devin、Copilot、 Codexのクラウドエージェントと比較しています。 --- ## 云端 AI 编程代理 Source: https://murmell.com/zh 要解决的问题 一个跑在笔记本电脑上的 AI 编程代理占用一个终端、一台机器。第二个代理只能等着,或者在仓库的另一份拷贝上工作,晚上再由人手动合并。这就是为什么大多数用 Claude Code 或 Codex 的人一次只敢开一个:协调的成本比多干的活还贵。 Murmell 去掉了拷贝这一步。代理运行在云端机器上,共用一个目录,写入前先占用要改的路径。结尾不需要合并,因为一开始就没有分叉。 文件占用机制 写入之前,代理先声明自己要动的路径。看板保存这份记录,在持有者释放之前拒绝所有其他代理碰这个路径。每个文件只有一个持有者,由服务器强制执行。 如果一次写入还是落在了别人占用的文件上,它会在落地前被拍下快照。你拿到的是两个版本,而不是丢失其中一个。 代理,用你自己的账号 Claude Code、Codex、Kimi 和 OpenCode 各自在画布的一个窗口里打开,背后是真正的终端。你用自己已经有的订阅或密钥登录。Murmell 只为机器和房间收费,从不为模型的 token 收费。 会话运行在机器上,而不是标签页里。关掉浏览器,一小时后回来,代理仍然在继续工作。这就是云端 AI 和桌面 AI 之间实际的区别。 房间,以及谁在看 一块画布通过一个链接分享出去。访客能看到所有窗口,实时滚动阅读终端输出,也能看到彼此的光标,每个光标都有自己的名字和颜色。旁观不花一分钱,也不需要账号。 费用 Starter 每月 0.99 美元，包含 Limited Murmell Cloud，每天 30 分钟和 1 GB 共享存储。Go 每月 9 美元，包含 10x Murmell Cloud，即每天 5 小时和 5 GB。Pro 每月 39 美元，包含 Unlimited Murmell Cloud 和 20 GB。存储空间由订阅中的所有 Canvas 共享。每个套餐同时运行一个 Canvas，支持 20 个智能体窗口。年付优惠 20%。智能体供应商单独计费。Teams 和 Enterprise 请联系我们。 打开一块画布 继续阅读 云端 AI 到底是什么 从头讲起这个术语。多个 AI 代理共用一个仓库 详细说明了占用机制,对比页面 把 Murmell 和 Cursor、Devin、Copilot 以及 Codex 的云端代理放在一起比较。