Cloud Agents у Cursor: як задача перетворюється на pull request

Ідея звучить фантастично: ви формулюєте задачу, закриваєте ноутбук — а за пів години в репозиторії на вас чекає готовий pull request. Це і є Cloud Agents у Cursor: агент працює не на вашій машині, а в хмарі, сам пише код в окремій гілці та відкриває PR, який лишається тільки перевірити й змержити. Можна запустити кілька таких агентів одразу на різні незалежні задачі, не займаючи власну машину.

Але в цієї автономності є два зворотні боки, про які маркетингові огляди мовчать: хмарний агент виконує команди без вашого підтвердження, а платите ви за нього за зовсім іншим лічильником, ніж за звичайний чат. Розберемо все по черзі: чим Cloud Agents відрізняються від локального агента, як їх налаштувати, що ви отримуєте на виході, скільки це реально коштує та як не відкрити агенту зайвого. Звірено з документацією Cursor і незалежними розборами на липень 2026.

Background чи Cloud Agents — це одне й те саме

Перше, що плутає навіть авторів статей: Background Agents і Cloud Agents — це одна й та сама функція. Її просто перейменували наприкінці жовтня 2025 року разом із виходом Cursor 2.0 (блог датований 30 жовтня, changelog версії — 29-м). Тому в пошуку ви натрапите на обидві назви — і обидві про одне й те саме. Якщо гайд каже «Background Agent», подумки читайте «Cloud Agent». В російськомовних і україномовних матеріалах цю функцію за старою пам’яттю іноді називають «фоновий агент» Cursor — це прямий переклад колишньої назви Background Agent, і йдеться все про ту саму хмарну фічу.

Друге, що важливо не сплутати: локальний Agent Mode і хмарний агент — різні речі. Локальні паралельні агенти використовують git worktree просто на вашій машині, а хмарні крутяться в ізольованих віртуалках Cursor, не прив’язаних до вашого комп’ютера, — можна закрити ноутбук, і робота триватиме. І третє: Cloud Agent — не те саме, що Bugbot. Bugbot — окремий продукт, який ревʼю́ить чужі PR; Cloud Agent — агент, який сам ці PR створює.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Як запустити: точки входу та підключення репозиторію

Запустити хмарного агента можна з багатьох місць: iOS-застосунок, вебверсія cursor.com/agents (та Android як PWA), сам десктопний Cursor (пункт Cloud у дропдауні), Slack за згадкою @cursor, коментар @cursor під issue чи PR на GitHub і Bitbucket, Linear та API. Ідея в тому, щоб поставити задачу звідти, де ви її побачили, — хоч із телефона.

Claude Code 2.1.224 звʼязав сесії: SendMessage і ListAgents на macOS та Linux

Claude у браузері: повний розбір Claude for Chrome — Teach Mode, дозволи та безпека

Керування Claude Code із Telegram: офіційний шлях і де він ламається

Як підключити Claude Code до GitHub: @claude, авторев’ю PR і GitHub Actions

Як змусити Claude Code працювати без вас: /loop, Routines і фонові агенти

Але перед першим запуском є обов’язковий крок: адміністратор акаунта Cursor має підключити систему контролю версій на рівні організації — GitHub (Cloud або Enterprise Server), GitLab, Bitbucket Cloud чи Azure DevOps. Без цього агенту немає куди відкривати PR. Гарна новина щодо грошей за доступ: Cloud Agents увімкнені в усі індивідуальні тарифи — Pro за $20/міс, Pro Plus за $60/міс та Ultra за $200/міс, — окремо докуповувати функцію не потрібно (але за самі прогони платити доведеться, про це нижче).

Якщо ви ще не користуєтеся Cursor і хочете спробувати все це на своєму проєкті, поставити редактор можна за цим посиланням — а далі налаштуємо оточення, без якого хмарний агент не збере ваш проєкт.

Налаштування оточення: environment.json

Щоб агент у хмарі зміг встановити залежності та запустити ваш код, йому потрібне оточення. Налаштувати його можна двома шляхами:

1. Агент сам налаштовує середовище через дашборд Cloud Agents — ви відповідаєте на його запитання, а готову конфігурацію можна зберегти як снапшот і перевикористати.
2. Вручну через Dockerfile, указаний у файлі .cursor/environment.json у репозиторії.

Порядок, у якому Cursor обирає конфігурацію, такий: спершу .cursor/environment.json у репозиторії, потім ваше персональне збережене оточення, потім командне. Найпростіший перевикористовуваний варіант через снапшот виглядає так:

{
  "snapshot": "snapshot-xxxx",
  "install": "npm install"
}

Важлива деталь про зберігання: сама переписка з агентом зберігається безстроково, а от снапшоти оточення видаляються автоматично після 90 днів неактивності (таймер скидається за кожного нового запуску з цього снапшота). Тобто занедбане оточення за три місяці доведеться збирати заново.

Задача → pull request: що ви отримуєте

Коли агент закінчив, задача перетворюється на готовий до злиття pull request. До нього можна додати артефакти — скриншоти, відео, логи — і за бажанням вбудувати їх прямо в опис PR на GitHub. Кожен коміт при цьому автоматично підписується ключем Ed25519 на базі HSM і отримує бейдж Verified — це знімає головний біль із branch protection, де правила вимагають підписані коміти.

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

Три можливості, які роблять хмарних агентів по-справжньому потужними:

• Паралельність. За офіційним changelog Cursor 2.0 можна запустити до восьми агентів одночасно за одним промптом (частина сторонніх агрегаторів називає 10–20 — але спиратися варто на офіційну цифру 8).
• Multi-repo. Один агент може працювати одразу з кількома репозиторіями — наприклад, змінювати фронтенд, бекенд та інфраструктуру — і відкрити PR у кожному зміненому репо.
• Автолагодження CI. Агент сам намагається полагодити провалені перевірки в створених ним PR — щоправда, лише для GitHub Actions, не більше ніж 10 спроб на один PR і тільки на тарифі Teams.

На практиці повний цикл виглядає так: ви пишете задачу («додай пагінацію в список замовлень і покрий тестами»), обираєте репозиторій і гілку, запускаєте агента й ідете. Агент піднімає хмарну віртуалку з вашого снапшота оточення, ставить залежності, пише код, ганяє тести, за потреби лагодить провалений CI і відкриває pull request з описом та артефактами. Вам приходить сповіщення — лишається відкрити PR, прочитати дифф, залишити коментарі (на них агент теж може відповісти правкою) і змержити. Ключова відмінність від локальної роботи: усе це відбувається без вашої участі та з закритим ноутбуком, а кілька таких задач можуть виконуватися паралельно.

Як ця механіка вписується в решту Cursor і його тарифи — розбирали в огляді Cursor і його тарифів. А якщо ви тільки знайомитеся із самим підходом «поставив задачу — отримав код», почніть із вайб-кодингу на простому проєкті, перш ніж довіряти агенту цілі PR.

Коли хмарний агент виправданий, а коли ні

Cloud Agents — не заміна локальній роботі, а інструмент під конкретний клас задач. Вони добре заходять там, де задача зрозуміла й добре формулюється словами: рутинний рефакторинг, покриття тестами, оновлення залежностей, однотипні правки в кількох репозиторіях, багфікси з чітким відтворенням. Їхня сильна сторона — паралельність: поки ви зайняті одним, три-чотири агенти розгрібають беклог дрібних задач і приносять готові PR.

А от де хмарний агент програє локальному: дослідницька робота, де потрібно «помацати» код і часто змінювати напрямок; задачі з нечіткими вимогами, які простіше доуточнювати в діалозі; і все, що потребує запусків із секретами продакшену, — тут автономність і авто-запуск команд стають ризиком, а не зручністю. Просте правило: чим чіткіше ТЗ і чим безпечніші наслідки, тим краще підходить хмарний агент. Для тонкої роботи з непередбачуваним ходом лишайтеся в локальному Agent Mode, де кожен крок під вашим контролем.

Ціна Cloud Agents: завжди Max Mode і оплата за API-тарифом

Тут криється головний сюрприз. Cloud Agents завжди працюють у Max Mode — розширеному режимі контексту, — і перемикача, щоб його вимкнути, для них немає. А оплата йде не зі звичайного ліміту підписки, а за API-тарифом обраної моделі. За першого запуску Cursor змушує встановити ліміт витрат (spend limit) — і це не формальність, а захист від несподіваного рахунку.

Чому це важливо розуміти заздалегідь: у 2025 році Cursor перейшов із пакетної моделі «за кількістю запитів» на метраж за API-тарифами провайдера. Для частини користувачів це обернулося непередбачуваними витратами: за незалежними звітами переплати понад підписку у важких користувачів сягали 15–30%, а в задокументованих випадках річна підписка згорала за один день. Відтоді ситуація стабілізувалася, але принцип лишився: хмарний агент за визначенням дорожчий за звичайний чат, бо завжди в Max Mode. Ставте spend limit і стежте за витратами, особливо перший час.

Локальний агент проти хмарного: у чому різниця

Ключова відмінність — не «де крутиться», а хто підтверджує команди. Звів у таблицю:

Саме рядок про підтвердження команд — те, що варто усвідомити до першого запуску. Локальний агент запитає дозвіл, перш ніж щось запустити в терміналі. Хмарний — не запитає.

Безпека та ризики

Автономність хмарного агента — це і його сила, і його головний ризик. Слабкі місця:

• Авто-запуск усіх команд без підтвердження. На відміну від локального агента, хмарний виконує будь-які термінальні команди сам. Cursor прямо попереджає в документації: це створює ризик витоку даних через prompt injection — агента можна обманом змусити відправити код на сторонній сайт. Звідси — режими мережевого доступу: дозволити весь вихідний трафік, дефолтні домени плюс свій список, або лише явний allowlist. Для чутливих репозиторіїв обирайте останній.
• Тільки звичайний Privacy Mode. Cloud Agents працюють лише в стандартному Privacy Mode; застарілий Legacy Privacy Mode не підтримується, бо агенту треба тимчасово зберігати код і оточення в хмарі. Нюанс: якщо вимкнути Privacy Mode на старті, а потім увімкнути в процесі — агент допрацює поточний запуск із вимкненим режимом.
• Секрети трьох типів. Cursor розрізняє Environment Variable (видимий агенту), Runtime Secret (підставлений в оточення, але замаскований у логах як [REDACTED]) та Build Secret (доступний лише на етапі Docker-збірки). Паролі й токени має сенс заводити як Runtime або Build, а не як звичайну змінну.
• Прогалини в enterprise-контролі. У Cloud Agents немає незмінного аудит-логу, ролей рівня проєкту (лише workspace-рівень admin/member), а секрети зберігаються простими парами ключ-значення без інтеграції з HashiCorp Vault чи AWS Secrets Manager. Для суворого governance це варто враховувати.
• Немає повного «своєї хмари». Навіть self-hosted-варіанти (особиста машина чи керований флот воркерів) лишають «мозок» агента в хмарі Cursor — на своє залізо переноситься лише виконання інструментів. За оцінкою самого Cursor, керованої хмари вистачає понад 80% клієнтів, але якщо у вас вимоги до периметра — повного BYOC тут немає.
• Налаштування буває болісним. На папері все просто, на практиці — не завжди: в одному незалежному розборі на Docker-in-Docker пішло 15 годин за три вихідні, а на форумі Cursor скаржаться, що секрети не підтягуються в не-Docker сценаріях, а install-команда з environment.json іноді мовчки не спрацьовує. Один користувач через це пішов на Windsurf. Закладайте час на перше налаштування.

Для балансу — що зроблено добре: підписані коміти з бейджем Verified з коробки, перевикористовувані снапшоти оточення (не треба щоразу перезбирати залежності) та multi-repo-координація, якої немає в локального агента.

Поширені запитання

Чим Cloud Agent відрізняється від звичайного агента в Cursor?

Локальний (foreground) Agent Mode працює на вашій машині й за замовчуванням запитує підтвердження перед кожною командою в терміналі. Хмарний агент крутиться в ізольованій віртуалці Cursor, працює навіть із закритим ноутбуком і виконує всі команди сам, без підтверджень, а результат віддає готовим pull request. Платите за хмарного за API-тарифом (завжди Max Mode), а не зі звичайного ліміту підписки.

Скільки коштує запуск хмарного агента?

Доступ до функції входить у Pro ($20/міс), Pro Plus ($60/міс) та Ultra ($200/міс), але самі прогони тарифікуються окремо — за API-тарифом обраної моделі, і завжди в Max Mode, тобто дорожче за звичайний чат. За першого запуску Cursor попросить установити ліміт витрат — не пропускайте цей крок: після переходу на usage-білінг у 2025 році були випадки, коли за день згорало набагато більше, ніж очікували. Стежте за витратами, особливо на довгих агентних задачах.

Як налаштувати оточення для хмарного агента?

Два шляхи. Перший — дати агенту налаштувати середовище самому через дашборд Cloud Agents і зберегти результат снапшотом. Другий — прописати Dockerfile у файлі .cursor/environment.json у репозиторії. Cursor застосовує конфігурацію в порядку «репозиторій → персональне оточення → командне». Пам’ятайте, що снапшот видаляється після 90 днів без використання, тож занедбане оточення доведеться збирати заново.

Скільки хмарних агентів можна запустити одночасно?

За офіційним changelog Cursor 2.0 — до восьми агентів паралельно за одним промптом (частина сторонніх оглядів називає 10–20, але це не підтверджена цифра, орієнтуйтеся на вісім). Плюс ви можете запускати незалежних агентів на різні задачі з різних місць — із десктопного Cursor, вебу, iOS-застосунку, Slack, коментаря @cursor під PR на GitHub, із Linear чи через API. Саме паралельність — головна практична перевага: кілька рутинних задач розгрібаються одночасно, поки ви зайняті чимось одним.

Чи безпечно пускати хмарного агента в робочий репозиторій?

Із застереженнями. Агент виконує команди без підтвердження, тому Cursor сам попереджає про ризик витоку через prompt injection. Мінімізуйте його: увімкніть суворий режим мережевого доступу (allowlist), заводьте паролі як Runtime або Build Secret, а не звичайною змінною, і не давайте агенту доступ до репозиторіїв та ключів, без яких задача не розв’язується. Для проєктів зі суворим комплаєнсом урахуйте: незмінного аудит-логу та повного «своєї хмари» у функції поки немає, а ролі доступу задані лише на рівні всього робочого простору, без гранулярності за окремими репозиторіями.