Введение

17 августа стал необычно драматичным днём для разработческой инфраструктуры.

GitHub пережил крупный глобальный инцидент, который продолжался 7 часов 47 минут с момента первого зафиксированного воздействия до окончательного устранения. Во время инцидента разработчики наблюдали проблемы в основных сервисах GitHub.com, API, pull request'ах, содержимом репозиториев, системах аутентификации и GitHub Copilot.

Почти в то же самое время Cursor начал развёртывание Origin — собственной платформы хостинга Git.

Время было почти идеальным для социальных сетей.

Одна сторона мира разработчиков обновляла страницу статуса GitHub. Другая делилась скриншотами новой вкладки Codebase от Cursor и шутила, что пора переносить репозитории.

В исходной статье этот момент описывается как «снос GitHub за одну ночь» силами Cursor. Это эффектный заголовок, но его не следует понимать буквально.

Origin не стал причиной сбоя, и ранний бета-продукт для хостинга не стёр огромную экосистему GitHub за один день.

Что произошло на самом деле, гораздо интереснее: Cursor перешёл из статуса преимущественно среды ИИ-разработки в инфраструктурный слой управления исходным кодом.

Origin теперь может самостоятельно размещать репозитории. Это означает, что компания больше не удовлетворена тем, что агенты пишут код, пока GitHub остаётся местом по умолчанию, где этот код в итоге хранится.

Cursor теперь хочет, чтобы репозиторий, pull request, агент и процесс разработки существовали в одной системе.

Приобретение Cursor компанией SpaceX уже завершилось 14 августа. Три дня спустя Origin перешёл в раннюю бета-версию для платных пользователей.

Версия GitHub от Cursor теперь доступна

Origin — это не просто кэшированная копия репозитория GitHub внутри Cursor.

Cursor описывает его так:

git-кузница для хранения и обмена кодом

В текущей ранней бета-версии Origin может:

• Создавать и размещать репозитории.
• Клонировать репозитории с помощью стандартного Git.
• Выполнять push и pull с помощью стандартного Git.
• Зеркалировать репозитории с GitHub.
• Просматривать и искать код в браузере.
• Изучать историю коммитов.
• Открывать pull request'ы.
• Просматривать pull request'ы.
• Комментировать pull request'ы и отдельные строки.
• Сливать pull request'ы.
• Управлять доступом к репозиториям.
• Подключать сторонние приложения.
• Прикреплять Cursor Cloud Agents и Automations.
• Использовать CLI, специфичный для Origin.

Этого достаточно, чтобы сделать Origin настоящим продуктом для хостинга Git, а не просто

визуализационный слой.

Продукт по-прежнему явно помечен как Early Beta. В анонсе Cursor говорится, что они начинают с основ и планируют позже добавить больше функций, ориентированных на агентов.

Эта граница важна при сравнении бета-версии с более амбициозным видением Origin, которое Cursor продемонстрировал ранее в этом году.

Кто может использовать Origin?

В текущей документации Cursor указано хранение кода Origin для:

Поскольку внедрение происходит постепенно, платная учетная запись может не увидеть Origin сразу. Организации Enterprise также могут отказаться.

Origin наследует режим конфиденциальности владельца пространства имен, что означает, что команды должны проверить свою конфигурацию конфиденциальности и доступа к репозиториям Cursor перед размещением чувствительного кода в сервисе.

Создание репозитория

Базовая настройка намеренно знакома.

Шаг 1: Откройте Codebase

Перейдите в рабочую область Codebase в Cursor:

cursor.com/codebase

Шаг 2: Создайте репозиторий

Выберите:

+ New

Введите имя репозитория.

Затем Cursor покажет команды, необходимые для установки CLI Origin, клонирования репозитория или отправки существующего локального проекта.

Шаг 3: Внимательно выберите пространство имен Codebase

Когда пользователь или команда создает первый репозиторий Origin, выбранное имя codebase становится частью URL репозитория.

URL следует общей схеме:

https://cursor.com/codebase/{owner}/{repo}

Например:

https://cursor.com/codebase/acme-corp/example-repo

В текущей бета-документации Cursor предупреждается, что пространство имен нельзя переименовать во время бета-версии. Выбирайте его осознанно.

Origin работает со стандартным Git

Одно из самых важных решений при внедрении заключается в том, что Origin не требует от разработчиков отказываться от самого Git.

Репозиторий может использовать знакомые операции, такие как:

git clone 
git pull
git push

Чтобы открыть pull request из новой ветки, документация Cursor предлагает стандартный流程:

git checkout -b my-change
git push -u origin my-change

Как только ветка окажется в Origin, pull request можно создать через веб-интерфейс.

Cursor Cloud Agents также могут создавать ветки, коммиты, пуши и pull request для репозиториев Origin.

Это важно, потому что Git-совместимую платформу можно внедрить, не заменяя сразу все локальные инструменты разработчика.

Pull Requests переходят в Cursor

Каждый репозиторий Origin включает pull requests.

Текущий интерфейс PR предоставляет четыре основных представления:

• Activity.
• Commits.
• Checks.
• Files Changed.

Ревьюеры могут просматривать изменения (diffs), комментировать строки, оставлять отзывы и запрашивать

рецензенты, и объединение после удовлетворения требований рецензирования и CI.

Более общая идея продукта заключается в том, что разработчику не нужно переключаться между:

Редактором Cursor
→ веб-сайтом размещения Git
→ ИИ-ассистентом
→ панелью CI
→ обратно в редактор

для каждого изменения.

Origin переносит просмотр репозиториев и работу с PR в ту же среду Cursor, в которой уже действуют агенты.

О заявлениях о «Стековых PR, очереди слияния и ИИ-автослиянии»

В исходной статье представлены три особенно амбициозные функции Origin:

1. Стековые pull request'ы.
2. Очередь слияния, ориентированная на агентов.
3. Автоматическое разрешение конфликтов слияния с помощью ИИ.

Эти идеи соответствуют более широкому видению Cursor о масштабировании агентов.

Однако их следует отделять от того, что на самом деле обещает текущая документация Early Beta.

Что точно доступно сегодня

Cursor в настоящее время документирует:

Репозитории
Стандартный Git clone/push/pull
Зеркалирование GitHub
Просмотр и поиск кода
Pull request'ы
Рецензирование/комментарии
Проверки
Ручное слияние
Отображение конфликтов
Разрешения
Приложения
Автоматизации
Облачные агенты
Origin CLI

Что ещё не описано как текущая функция Origin Beta

Текущие официальные документы Origin не перечисляют следующее как общедоступное:

Встроенный рабочий процесс со стековыми PR
Очередь слияния Origin
Автоматическое разрешение конфликтов слияния с помощью ИИ
Специализированный структурированный API состояния рецензирования Origin
Origin как MCP-сервер

В анонсе Cursor прямо указано, что дополнительные нативные для агентов функции появятся позже.

Поэтому к этому следует относиться как к более ранним демонстрационным концепциям, направлениям развития или функциям, ожидающим более чёткой документации по выпуску, а не как к возможностям, на которые может рассчитывать каждый платный пользователь Origin сегодня.

GitHub уже имеет стековые PR и очереди слияния

Сравнение также нуждается в исправлении в части GitHub.

GitHub не ограничивается одним огромным читаемым списком PR.

GitHub в настоящее время документирует:

• Стековые pull request'ы.
• REST API для создания и управления стеками.
• GraphQL-запросы для стеков.
• Очереди слияния.
• События рабочего процесса merge_group.
• Автослияние.
• Структурированные решения по рецензированию pull request'ов через GraphQL.

Это не делает GitHub «нативным для агентов» в том же смысле продукта, к которому стремится Cursor.

Но это означает, что техническое различие заключается не в следующем:

У GitHub нет ни одного из этих примитивов
против
У Origin есть все они

Более убедительное различие — это философия продукта.

Cursor хочет, чтобы инфраструктура репозиториев была напрямую встроена в среду, где флоты агентов кодирования уже являются субъектами первого класса.

Зеркалирование GitHub делает первый шаг малобюджетным

Самая практичная функция миграции Origin — это не драматическая замена. Это зеркалирование.

Команда может подключить

GitHub в Cursor: выберите организацию и репозиторий, создайте зеркало Origin

Документированная синхронизация включает:

Для зеркального репозитория GitHub изначально остаётся источником истины.

Загрузки через удалённый репозиторий Origin продолжают поступать в GitHub. Запросы на включение можно просматривать в Origin, пока активность синхронизируется обратно в GitHub.

Это упрощает тестирование Origin, поскольку командам не нужно отказываться от контроля над репозиторием с первого дня.

Запросы на включение синхронизируются в обе стороны

В анонсе Cursor говорится, что запросы на включение в зеркальных репозиториях синхронизируются двунаправленно.

Предполагаемое поведение:

Комментарий в Cursor
→ отображается на GitHub

Ответ или реакция на GitHub
→ отображаются в Cursor

Ревью, назначенное на GitHub
→ можно обработать из Cursor

Cursor утверждает, что эти обновления появляются в течение нескольких секунд.

Это позволяет разработчикам оценить работу Origin, пока существующие коллеги по GitHub продолжают использовать GitHub.

Вероятно, это более реалистичная стратегия миграции, чем немедленный перенос критического монорепозитория на нового бета-хоста.

Одна кнопка может сделать Origin источником истины

Самый решительный шаг миграции — Отключение от GitHub.

Когда зеркальный репозиторий создаётся впервые, отношение выглядит так:

GitHub
= источник истины

Origin
= синхронизированное зеркало

В настройках репозитория Cursor есть действие в зоне риска:

Отключить от GitHub

После отключения:

Origin
= автономный размещённый репозиторий
= источник истины

Загрузки в удалённый репозиторий Origin больше не поступают в GitHub.

Исходный репозиторий GitHub не удаляется и не изменяется действием отключения.

Это различие важно.

Отключение изменяет поведение синхронизации; оно не стирает копию GitHub.

Что означает «источник истины» здесь

Кодовая база может иметь несколько клонов и зеркал, но процессам разработки обычно нужен один авторитетный репозиторий.

Эта авторитетность определяет такие вопросы, как:

• Какой удалённый репозиторий получает новые коммиты?
• Какая ветка является канонической main?
• Где объединяются запросы на включение?
• Из какого репозитория развёртывание должно загружать код?
• Какая история считается авторитетной после расхождения?

Для зеркальных репозиториев Origin эта авторитетность изначально находится на GitHub.

После отключения Cursor документирует Origin как источник истины для репозитория, размещённого в Origin.

Это точка, в которой Origin перестаёт быть вспомогательным интерфейсом и становится основным Git-хостом для этого проекта.

Экосистема приложений Origin начинается с Vercel, Depot и Buildkite

У Cursor также

началось подключение Origin к экосистеме развертывания и CI.

Текущие официальные интеграции включают:

Vercel

Подключите Vercel через вкладку Apps в репозитории.

Cursor отмечает, что каждый pull request может получать предварительное развертывание, что позволяет командам тестировать и комментировать до слияния.

Depot

Depot может запускать CI для репозиториев Origin и повторно использовать существующие рабочие процессы GitHub Actions.

Buildkite

Buildkite также может запускать существующие рабочие процессы GitHub Actions в дополнение к своей собственной системе конвейеров.

Это помогает снизить одну из самых сложных затрат на миграцию.

Даже когда хранилище репозитория перемещается, команды не хотят одновременно переписывать весь свой CI/CD стек.

Файлы GitHub Actions не становятся автоматически CI Origin

Здесь есть важный нюанс.

Документация зеркалирования GitHub от Cursor говорит, что рабочие процессы и секреты GitHub Actions сами по себе не зеркалируются в Origin как конфигурация платформы GitHub.

Однако сторонние интеграции Origin, такие как Depot и Buildkite, могут выполнять существующие определения рабочих процессов GitHub Actions.

Эти утверждения могут сосуществовать:

Состояние платформы GitHub Actions
→ не переносится зеркалированием репозитория

Файлы рабочих процессов в репозитории
→ могут интерпретироваться поддерживаемыми CI-интеграциями

Команды должны протестировать секреты, разрешения, триггеры событий, кэширование, учетные данные для развертывания и защиту веток перед отсоединением производственного репозитория.

Origin разработан для работы под Cursor Agents

Более крупный стратегический аргумент для Origin — это интеграция агентов.

Cloud Agents от Cursor работают в изолированных облачных виртуальных машинах с полными средами разработки.

Они могут:

• Клонировать репозитории.
• Создавать ветки.
• Изменять код.
• Запускать сборки и тесты.
• Фиксировать изменения.
• Отправлять ветки.
• Открывать pull request.
• Продолжать работу, пока ноутбук разработчика офлайн.

С Origin эти агенты могут работать напрямую с репозиториями, размещенными на той же платформе.

Цикл становится таким:

Цель
→ агент Cursor
→ репозиторий Origin
→ ветка
→ изменения кода
→ тесты
→ pull request
→ ревью
→ слияние

Репозиторий больше не должен быть внешним сервисом в центре рабочего процесса агента.

Автоматизации делают репозиторий управляемым событиями

Origin также интегрируется с Cursor Automations.

Текущая документация перечисляет события репозитория, такие как:

• Отправка в ветку.
• Открытие pull request.
• Отправка в pull request.
• Связанные события PR.

Автоматизация может активировать облачного агента в ответ на одно из этих событий.

Например:

Новый PR открыт
→ запустить агента проверки безопасности

Отправка в main
→ обобщить изменения

PR обновлен
→ проверить новые коммиты

Это конкретная часть истории «агент-нативного» подхода, которая уже задокументирована сегодня.

Обновление агентов от 19 августа от Cursor идет дальше, позволяя Cloud Agents подписываться на события и продолжать вести работу, такую как исправления CI и обратная связь ботов, до завершения цели.

Что насчет MCP?

В исходной статье говорится, что Origin «нативно поддерживает MCP», поэтому агенты могут управлять forge так же легко, как API.

Cursor как более широкий продукт абсолютно поддерживает MCP для подключения агентов к внешним инструментам и данным.

Однако я не нашел текущей страницы документации Origin, которая раскрывала бы сам Origin как

MCP-сервер** для операций с репозиториями.

В текущей документации Origin по интеграции особое внимание уделяется:

Origin CLI
Cloud Agents
Automations
Сторонние приложения

Таким образом, безопасная формулировка такова:

Экосистема агентов Cursor поддерживает MCP, тогда как текущая документация Origin в статусе Early Beta пока не рекламирует явно выделенный интерфейс Origin MCP.

Это может измениться по мере того, как Cursor выпустит дополнительные нативные функции для агентов, которые он обещал.

Заявления о производительности ориентированы на масштаб агентов

Более ранние демонстрации Origin от Cursor подчеркивали показатели пропускной способности, которые звучат чрезмерно для команды разработчиков-людей.

Заявленные демонстрационные показатели включали:

Исходная статья использует эти цифры, чтобы сделать простой вывод:

Разработчикам-людям не нужно делать десятки коммитов в секунду. Флотилии агентов — возможно.

Эти цифры следует воспринимать как заявления вендора на демонстрациях.

Текущая документация Cursor по Origin не публикует полную методологию бенчмарков, производственное SLA, распределение нагрузки, таблицу процентильной задержки или независимую валидацию этих показателей.

Производственная команда должна тестировать свои собственные нагрузки, прежде чем рассматривать пропускную способность сценарной демонстрации как гарантированную емкость сервиса.

Агенты уже создают значительную долю PR внутри Cursor

Аргумент в пользу Git-инфраструктуры масштаба агентов не является чисто гипотетическим.

Cursor заявил в феврале, что более 30% объединенных внутренних pull request были созданы агентами, работающими автономно в облачных песочницах.

К июню инженерный пост самого Cursor сообщил:

более 40% наших PR поступают от облачных агентов

Исходная статья ссылается на промежуточный показатель 35%–40%.

Точный процент менялся со временем по мере роста внедрения агентов.

Более важная тенденция очевидна:

Февраль 2026:
>30%

Июнь 2026:
>40%

Внутренний процесс разработки ПО в Cursor уже производит достаточно PR, созданных агентами, чтобы координация репозиториев стала серьезной инфраструктурной проблемой.

Почему PR от агентов меняют рабочий процесс

Традиционные рабочие процессы с репозиториями предполагают человеческий темп.

Разработчик может:

1. Создать одну ветку.
2. Работать часами.
3. Запушить несколько коммитов.
4. Открыть PR.
5. Ждать ревью.
6. Устранять замечания.
7. Слить изменения.

Флотилия агентов может работать иначе.

Десять или сто агентов могут одновременно:

• Клонировать один и тот же репозиторий.
• Создавать ветки.
• Изменять пересекающиеся файлы.
• Запускать CI.
• Пушить коммиты.
• Открывать pull request.
• Отвечать на комментарии к ревью.
• Исправлять ошибки.

Узкое место смещается.

Написание первого черновика кода может стать дешевым.

Координация, валидация, ревью и безопасное слияние множества одновременных изменений становится сложнее.

Именно эту инфраструктурную проблему и решает Origin.

GitHub был создан для людей — но он тоже адаптируется

Исходная статья противопоставляет «рабочий процесс GitHub 2008 года» и агентно-нативный Origin.

Историческая рамка полезна, но текущее сравнение продуктов более нюансировано.

GitHub продолжает добавлять

автоматизации, включая:

- Очереди слияния.
- Стеки пулл-реквестов.
- Кодинг-агенты Copilot.
- GraphQL и REST API.
- Вебхуки.
- GitHub Actions.
- Наборы правил.
- Автоматизированные проверки и функции слияния.

Поэтому вопрос не в том, может ли GitHub автоматизировать разработку.

Очевидно, может.

Стратегический вопрос в том, сможет ли платформа, построенная вокруг репозиториев и человеческого сотрудничества, адаптироваться так же быстро, как платформа, чья основная продуктовая идентичность теперь — **ИИ-агенты, выполняющие программную работу**.

Origin — это ставка Cursor на то, что в ответе остаётся место для новой кузницы кода.

## Сбой GitHub сделал запуск более драматичным, чем он был на самом деле

Сбой GitHub 17 августа был реальным и серьёзным.

Официальный инцидент длился с:

```Plaintext
13:28 UTC
до
21:15 UTC

в общей сложности:

7 часов 47 минут

Во время события в статусных отчётах сообщалось о существенных ошибках в веб/API-трафике и доступе к содержимому репозиториев, а Copilot также был деградирован.

Совпадение с запуском создало неотразимый нарратив:

GitHub падает
+
Cursor запускает хостинг Git
=
Cursor заменяет GitHub

Это не то, что произошло на операционном уровне.

Фактически, собственный путь зеркалирования GitHub в Origin по-прежнему зависит от GitHub, пока GitHub остаётся источником истины.

А более широкие агенты Cursor также могут зависеть от внешних провайдеров систем контроля версий.

Таким образом, сбой GitHub автоматически не демонстрирует, что все рабочие процессы Cursor продолжают работать без сбоев.

Настоящий урок касается концентрационного риска: когда одна платформа контроля версий глубоко встроена в разработку, длительный сбой затрагивает гораздо больше, чем просто просмотр репозиториев.

Скриншот акций Microsoft не доказывает причинно-следственную связь

Исходная статья также размещает скриншот акций Microsoft рядом с историей Origin, показывая падение акций примерно на 3,2% за день.

Это привлекающее внимание сопоставление.

Но его недостаточно, чтобы сделать вывод:

Origin запущен
→ Microsoft потеряла более 100 миллиардов долларов

Крупные технологические акции движутся по многим причинам.

Без доказательств, изолирующих причину, движение акций следует рассматривать как рыночный контекст того же дня, а не как прямую реакцию на Origin.

Поэтому эта статья не приписывает изменение рыночной капитализации Microsoft запуску Cursor.

Стоит ли переносить производственный репозиторий сегодня?

Для большинства команд ответ:

Не всё сразу.

Origin всё ещё находится на стадии ранней беты.

Более безопасный путь — оценивать его постепенно.

Шаг 1: Начните с некритичного репозитория

Выберите:

• Внутренний инструмент.
• Прототип.
• Небольшой сервис.
• Библиотеку с низким риском.

Не начинайте с репозитория, который разворачивает всю вашу производственную платформу.

Шаг 2: Сначала зеркалируйте с GitHub

Сохраните GitHub как источник истины.

Оцените:

• Свежесть синхронизации.
• Поведение PR.
• Поиск по коду.
• Контроль доступа.
• Рабочие процессы агентов Cursor.
• Интеграции CI.

Это даёт вам путь отката.

Шаг 3: Протестируйте синхронизацию пулл-реквестов

Создавайте комментарии и ревью с обеих сторон.

Убедитесь, что:

• Синхронизация Cursor → GitHub работает.
• Синхронизация GitHub → Cursor работает.
• Назначения ревьюеров остаются корректными.
• Проверки отображаются правильно.

Шаг 4: Осознанно перестройте CI

Если вы используете Vercel, Depot,

Для Buildkite подключите их и проверьте:

- Секреты.
- Обязательные проверки.
- Предпросмотр развёртываний.
- Правила веток.
- Шлюзы развёртывания.

Не предполагайте, что состояние платформы GitHub Actions перенесётся автоматически.

## Шаг 5: Тестирование агентов против Origin

Запустите Cloud Agents на зеркальном репозитории.

Оцените:

- Надёжность клонирования.
- Надёжность отправки изменений.
- Создание PR.
- Циклы исправления CI.
- Поведение разрешений.
- Завершение длительных задач.

## Шаг 6: Проверка конфиденциальности и доступа

Проверьте:

- Видимость репозитория.
- Разрешения команд.
- Cursor Privacy Mode.
- Контроль администратора организации.
- Доступ внешних приложений.

Хост репозитория становится частью вашего периметра безопасности.

## Шаг 7: Отключение только после подтверждения работоспособности процесса

Используйте:

```Plaintext
Settings
→ General
→ Danger Zone
→ Detach from GitHub

только когда команда осознанно решила, что Origin должен стать авторитетным источником.

После отключения отправки изменений в Origin больше не передаются обратно в GitHub.

Когда Origin стоит протестировать уже сейчас

Origin особенно интересен, если ваша команда уже активно использует Cursor.

Хорошими кандидатами являются команды, которые:

• Запускают множество Cursor Cloud Agents.
• Создают большое количество PR, написанных агентами.
• Хотят просматривать репозитории и работать с агентами в одном интерфейсе.
• Хотят экспериментировать с событийно-ориентированными рабочими процессами агентов.
• Уже используют Vercel, Depot или Buildkite.
• Хотят создать низкобарьерное зеркало GitHub перед рассмотрением миграции.

Преимущество интеграции максимально, когда Cursor уже находится в центре инженерного процесса.

Когда GitHub остаётся более безопасным выбором по умолчанию

GitHub остаётся более консервативным выбором для команд, которые зависят от:

• Зрелой публичной экосистемы с открытым исходным кодом.
• GitHub Issues.
• Инфраструктуры GitHub Actions.
• Интеграций Marketplace.
• Существующего корпоративного управления.
• Сложных наборов правил.
• Устоявшихся процессов аудита.
• Широкой знакомости внешних контрибьюторов.
• Большого количества интеграций, ещё недоступных в Origin.

Хост кода — это не просто хранилище Git-объектов. Это экосистема.

Origin ещё не является полной заменой GitHub

На сегодняшний день наиболее точное описание такое:

Origin — это настоящий Git-хост
+
зеркало GitHub
+
поверхность для PR/ревью
+
интегрированный с агентами слой репозитория

Но это ещё не:

готовая замена всех функций GitHub

Это различие важно для планирования миграции.

Команда уже может полностью размещать код в Origin.

Это не означает, что все её GitHub Issues, конфигурация Actions, секреты, приложения Marketplace, политики, публичные процессы сообщества и корпоративные процедуры автоматически переносятся вместе с ним.

Более важная конкуренция — за систему записи

Финальный аргумент исходной статьи сильнее, чем её заголовок.

Cursor конкурирует с GitHub не просто за хранение репозиториев.

Он борется за место, где программная работа становится авторитетной.

В старой архитектуре:

Разработчик
→ IDE
→ GitHub
→ CI
→ развёртывание

В новой архитектуре Cursor:

Цель человека
→ агент Cursor
→ Origin
→ PR
→ автоматические проверки
→ интеграция развёртывания

Если

агенты становятся основными производителями изменений, и платформа-репозиторий, которая координирует этих агентов, может стать не менее стратегически важной, чем редактор.

Вот почему отключение от GitHub имеет большее значение, чем шутки в день запуска.

Зеркало — это удобно.

Новый источник истины — это смена платформы.

Часто задаваемые вопросы

Что такое Cursor Origin?

Origin — это платформа Cursor для хостинга Git и обмена кодом. В ранней бете она может размещать репозитории, использовать стандартные команды Git clone/push/pull, зеркалировать репозитории GitHub, просматривать и искать код, открывать и объединять пул-реквесты, а также подключать агентов Cursor и выбранные сторонние приложения.

Доступен ли Cursor Origin бесплатным пользователям?

Нет. В текущей документации Cursor указано, что хранение кода Origin доступно в тарифах Pro, Teams и Enterprise и недоступно в бесплатных планах. Развертывание происходит поэтапно, поэтому некоторые подходящие пользователи могут получить доступ позже других.

Может ли Origin полностью заменить GitHub?

Origin может стать источником истины для репозитория после его отключения от GitHub, но в настоящее время это не замена GitHub на 100% по функциональности. Проблемы GitHub (Issues), конфигурация платформы GitHub Actions, секреты и многие интеграции экосистемы не мигрируют автоматически.

Поддерживает ли Cursor Origin синхронизацию с GitHub?

Да. Origin может зеркалировать репозитории GitHub, включая историю Git, ветки, теги, просматриваемый код и пул-реквесты с двусторонней синхронизацией. Пока репозиторий остается зеркальным, GitHub остается источником истины, а пуши через Origin передаются обратно в GitHub.

Что делает функция «Отключить от GitHub»?

Она прекращает синхронизацию с GitHub и превращает зеркало Origin в автономный репозиторий, размещенный на Origin. Origin становится источником истины, и будущие пуши в удаленный репозиторий Origin больше не передаются в GitHub; существующий репозиторий GitHub остается нетронутым.

Поддерживает ли Origin уже стековые PR и очередь слияния на основе ИИ?

В текущей документации ранней беты Cursor не указаны нативные стековые PR-процессы или очередь слияния Origin как общедоступные функции. В запуске сказано, что дополнительные функции, ориентированные на агентов, появятся скоро, поэтому более ранние демо или дорожные карты не следует путать с текущей документированной бетой.

Автоматически ли Origin разрешает конфликты слияния с помощью ИИ?

В текущей документации по пул-реквестам Origin указано, что Origin отображает конфликты слияния, чтобы пользователи могли разрешить их перед объединением. Более ранние публикации о демонстрации Cursor Compile описывали идеи разрешения конфликтов на основе ИИ, но это не следует рассматривать как документированную гарантию ранней беты.

Запустила ли Cursor Origin потому, что GitHub был недоступен?

Нет доказательств этого. Cursor начал развертывание Origin 17 августа, в тот же день, когда GitHub пережил крупный сбой, что стало заметным совпадением. Origin был анонсирован и продемонстрирован ранее, поэтому сбой не создал продукт за одну ночь.

Связанные инструменты

• Cursor Origin: официальная документация Cursor по Git-хостингу, репозиториям, PR, зеркалированию GitHub и интеграции агентов.
• Origin CLI: интерфейс командной строки Cursor для рабочих процессов с репозиториями Origin.
• [Cursor

Облачные агенты](https://cursor.com/docs/cloud-agent) — размещённые в облаке программирующие агенты, которые могут работать напрямую с репозиториями Origin.

• Автоматизации Cursor — управляемые событиями и по расписанию рабочие процессы агентов, которые могут реагировать на активность в репозиториях Origin.
• Git — распределённая система контроля версий, используемая как GitHub, так и Origin.
• GitHub — устоявшаяся платформа для хостинга Git и совместной работы, с которой Origin может синхронизироваться и создавать зеркала.
• Vercel — платформа развёртывания, к которой Origin может подключаться для предварительного просмотра развёртываний pull request.
• Buildkite — платформа CI/CD, интегрированная с Origin и способная запускать существующие рабочие процессы GitHub Actions.

Связанные ссылки

• Cursor: Origin Code Hosting — официальное объявление о запуске от 17 августа и текущие рамки ранней бета-версии.
• Mirror a GitHub Repository — официальная документация по синхронизации с GitHub, что синхронизируется и что нет, а также по отсоединению.
• Origin Pull Requests — официальная документация по рабочим процессам PR, рецензиям, проверкам, конфликтам и поведению зеркальных PR GitHub.
• Origin Integrations — официальная документация по автоматизациям, облачным агентам, Vercel, Depot и Buildkite.
• Cursor: Cloud Agents Lessons — собственный отчёт Cursor о том, что к июню 2026 года более 40% внутренних PR создавались облачными агентами.
• GitHub Merge Queue Documentation — официальная документация GitHub, показывающая, что очереди слияния уже поддерживаются.
• GitHub Stacked Pull Requests — официальная документация GitHub по стековым PR и их интеграции с очередями слияния.

Резюме

Cursor Origin — это теперь настоящая платформа хостинга Git, а не просто браузер GitHub внутри Cursor. Её ранняя бета-версия может размещать репозитории, использовать стандартный Git, создавать зеркала GitHub, синхронизировать pull request в обоих направлениях, просматривать код, управлять рецензиями, подключать приложения CI/CD и позволять агентам Cursor работать с репозиториями, размещёнными на Origin.

В исходной статье некоторые функции, ориентированные на агентов, преувеличены как уже развёрнутые. В текущей собственной документации пока не указаны нативные стековые PR, очередь слияния Origin, автоматическое разрешение конфликтов с помощью ИИ или MCP-сервер Origin как общедоступные функции ранней бета-версии. Сам Cursor заявляет, что дополнительная функциональность, ориентированная на агентов, ещё впереди.

Сбой GitHub 17 августа дал Origin необычайно драматичный момент запуска, но это не означало, что GitHub был заменён за одну ночь. Для большинства команд разумный путь — сначала создать зеркало некритичного репозитория, протестировать синхронизацию и CI, и только после того, как Origin докажет, что может безопасно стать источником истины, отсоединиться.

Реальный конкурентный сдвиг заключается не в том, что Cursor «убил GitHub»; а в том, что Cursor теперь хочет владеть всем циклом разработки — от первого коммита до продакшена.

уровень репозитория, где AI-агенты создают, проверяют и выпускают программное обеспечение.**