Хостинговый агент работает в облаке провайдера. Вы передаете ему копию своих репозиториев и набор учетных данных, и он выполняет задачи там. Local-first агент работает на вашей собственной машине, где уже есть runtime, подписка, файлы и ключи, а наружу уходит только сама переписка.
Оба подхода имеют право на жизнь. Они размещают ваш код, вашу цифровую идентичность и ваши расходы в разных местах, и эти различия становятся еще заметнее, когда вы начинаете делиться агентом с другими людьми.
В чем плюсы хостинга и какую цену за них платят
Наглядные примеры в 2026 году — это Claude Code в веб-интерфейсе и облачные задачи Codex от OpenAI. В обоих случаях агент запускается в изолированной песочнице провайдера на базе клона вашего репозитория и аутентифицируется в git через токены, выданные провайдеру с помощью OAuth-интеграции GitHub. Поэтому у агента никогда нет доступа к вашим локальным учетным данным, SSH-ключам или переменным окружения. Это реальное преимущество в безопасности: скомпрометированный ноутбук разработчика не может заразить окружение агента, а задача с неверно заданными границами не может затронуть файлы за пределами песочницы.
Хостинговый агент всегда онлайн. Вам не нужно следить, чтобы ноутбук не уходил в спящий режим, и не нужно ничего устанавливать. Для автономных круглосуточных пулов задач это решающий фактор.
Но эти преимущества влекут за собой структурные издержки, которые нельзя просто устранить исправлением кода.
- Вторая копия всего. Провайдер хранит ваши репозитории и зачастую ваше окружение, чтобы агент мог работать. У этой копии свои списки контроля доступа, правила хранения и поверхность для потенциальных утечек.
- Второй набор учетных данных. Токены для GitHub, облачных аккаунтов и внутренних API выдаются провайдеру. Их ротация означает необходимость обновлять их и на стороне провайдера.
- Второй счет на оплату. Вы платите за хостинговый runtime поверх или вместо подписки, которая у вас уже есть.
- Чужой выбор модели. Хостинг сам решает, какие модели доступны и когда они меняются.
В чем плюсы local-first и какую цену за них платят
Local-first агент использует то, что уже есть на вашей машине: подписку на Claude Code или Codex, за которую вы уже платите, локально склонированные репозитории и ключи, уже сохраненные в вашей связке ключей. Ничего никуда не копируется. Когда вы открываете доступ к агенту другим, второй человек лишь задает вопросы — всю работу по-прежнему выполняет ваша машина.
Цена этого подхода — доступность. Если машина уходит в спящий режим, агент тоже засыпает.
Способы решения здесь практические, а не архитектурные: зарегистрируйте daemon как службу, чтобы он запускался при входе в систему и перезапускался после сбоев, не давайте машине засыпать в рабочие часы и ставьте запросы в очередь во входящие, чтобы ничего не терялось, пока машина не в сети. Когда она вернется в сеть, запросы выполнятся по порядку.
Два варианта границы доверия: вокруг песочницы провайдера или вокруг собственной машины с комнатой снаружи.
Насколько тонким может быть облачный слой
muti построен по модели local-first, и главным вопросом архитектуры было: что именно разрешено хранить облаку? Ответ: комнату и ничего из того, что позволило бы комнате выдавать себя за машину.
Эту схему обеспечивают три механизма.
Только исходящие соединения. Daemon на вашей машине запрашивает задачи через исходящее соединение. Никаких открытых портов, туннелей и входящих маршрутов. Даже если бы облако muti было скомпрометировано, злоумышленник мог бы лишь поставить в очередь запросы, которые все равно подчиняются вашим правилам доступа и подтверждениям; добраться до ваших файлов он бы не смог.
События, а не файлы. Daemon публикует события таймлайна с описанием того, что произошло. Он не загружает рабочее дерево и никогда не читает переменные окружения или файлы ключей для отправки куда-либо.
Подтверждения в центре процесса. Поскольку машина принадлежит вам, четыре типа опасных действий ставятся на паузу и ждут вашего решения при каждом запросе от других участников. У хостингового агента с вашими учетными данными спросить разрешения просто не у кого.
Таблица для принятия решений
Почему muti не хостит runtime
Добавить кнопку «запустить это в нашем облаке» было бы элементарно. Мы этого не сделали, и это осознанная принципиальная позиция. Как только runtime перемещается в облако, следом уходят учетные данные и репозитории, а владелец перестает быть тем, кто подтверждает действия. Каждая гарантия из статьи четыре действия, перед которыми агент всегда должен спрашивать разрешения, держится на том, что машина принадлежит владельцу.
muti хостит комнаты. Ваш агент остается там, где он есть.
Часто задаваемые вопросы
«Local-first» означает то же самое, что и «офлайн»? Нет. Агенту нужна сеть для связи с провайдером модели, а muti — для доставки сообщений. Local-first описывает, где физически находятся рабочие данные и секреты, а не то, подключена ли машина к сети.
Могу ли я захостить облачную часть muti у себя? Self-hosting слоя комнат запланирован в дорожной карте как однопользовательский режим с поддержкой работы офлайн. Daemon и облако уже взаимодействуют через стандартный API.
Что если у меня несколько машин? Подключите каждую. Агенты привязаны к машине и рабочему каталогу, а различать свои машины вы можете по адресам, которые сообщает daemon.
Если вы уже платите за хорошего агента и хотите оставить его там, где он есть, создайте для него комнату.
Опубликовано · Обновлено