Cursor Origin: git-хостинг внутри ИИ-редактора вместо GitHub - стоит ли переезжать

17 августа 2026 года Cursor выкатил Origin - собственный git-хостинг прямо внутри редактора, туда, куда обычно ходят за GitHub. Отвечаю на главный вопрос сразу: тащить в Origin прод-репозиторий с комплаенсом рано, а вот новый небольшой проект - можно, если готов мириться с ранней бетой без публичной политики по данным. Дальше - почему я так решил и что там вообще внутри.

Что такое Cursor Origin и чем он отличается от GitHub

Cursor Origin - это встроенный в ИИ-редактор Cursor сервис хостинга кода: репозитории, pull request'ы, код-ревью и управление мерджами живут в новой вкладке Codebase, без переключения в браузер. От GitHub он отличается тем, что рождён "agent native" - агенты Cursor работают с кодом и PR в том же окне, где их создают, а не дёргают отдельный API.

Доступ открыли всем платным тарифам - Pro, Teams и Enterprise - кроме организаций, которые сами отключили опцию для админов. Сама компания описывает это коротко: "новая вкладка Codebase - дом для репозиториев Origin", а код, PR и агенты теперь "в одном и том же месте". Репозитории можно клонировать и пушить по HTTPS или через отдельный Origin CLI, с авторизацией через CLI-логин. GitHub при этом никуда не девается: Origin зеркалирует ветки, теги и историю коммитов, права доступа синхронизируются в обе стороны, а обсуждения под pull request'ами долетают за секунды. Но пуши для таких проектов всё равно летят в GitHub - он остаётся, как это называют в Cursor, "system of record", системой записи. То есть Origin пока не столько замена GitHub, сколько вторая поверхность хостинга рядом с ним, и GitHub-репозитории Cursor может хостить у себя "рядом" с нативными.

Почему Origin запустили именно 17 августа - и при чём тут авария GitHub

Совпадение получилось эффектным: спустя примерно три с половиной часа после анонса Origin у GitHub началась глобальная деградация на 6 часов 42 минуты - около 20% ошибок на ключевых операциях и почти 50% на скачивании файлов. Для GitHub это был седьмой инцидент за 15 дней, и Cursor получил бесплатную рекламу таймингом, а не маркетинговым бюджетом.

Фон у запуска денежный и довольно шумный: в июне 2026 SpaceX объявила о покупке Anysphere (материнской компании Cursor) за 60 миллиардов долларов, а сделка закрылась 14 августа - за три дня до Origin. Cursor теперь официально числится в подразделении SpaceXAI. До этого у компании была отдельная оценка в 29,3 миллиарда долларов по Series D-раунду на 2,3 миллиарда долларов инвестиций, а годовая выручка выросла с 1 миллиарда долларов в 2025-м до примерно 4 миллиардов в 2026-м. Так что 60 миллиардов - это цена опциона на выкуп целиком на фоне быстрого роста, а не случайная рыночная переоценка. GitHub при этом остаётся крупнейшей платформой с примерно 180 миллионами пользователей, так что Origin запускался не против равного по размеру конкурента, а против инфраструктуры, которая обслуживает буквально всю индустрию - и именно в день, когда эта инфраструктура легла.

Как агенты Cursor работают с репозиторием внутри Origin

Origin построен вокруг stacked pull request'ов и merge-очередей, которые "понимают" агентов: система сама двигает PR к состоянию, готовому для мерджа, отвечает на комментарии ревьюеров и переписывает код по замечаниям без участия человека. По данным RuntimeWire, которые приводит VentureBeat, 35% пул-реквестов, слитых внутри Cursor, открыли агенты, работающие автономно в облачных виртуалках - не человек нажал "create PR", а фоновый процесс.

27 августа к этому добавили ещё одну возможность: агенты научились стартовать проект "с нуля", без исходного репозитория вообще - Origin сам создаёт хранилище под задачу. Агенты и раньше подключали внешние инструменты через MCP-серверы; Origin просто расширяет тот же принцип на сам git - агенту больше не нужно объяснять, где лежит код, он уже открыт в его рабочем окне.

Раньше цепочка была такая: агент пишет код, человек открывает PR на GitHub, ревьюит, мержит. В Origin звено "человек открывает PR" можно выкинуть целиком - агент сам заводит ветку, стакает PR друг на друга и двигает их к состоянию mergeable, реагируя на комментарии ревьюера так же, как это делал бы разработчик. Это и называют "agent aware merge queue" - очередь на мердж, которая учитывает, что часть участников процесса вообще не люди.

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

Чего в Origin пока нет - и почему это важно

На старте у Origin нет опубликованной политики о работе с кодом - непонятно, уходят ли данные на обучение моделей, кто субпроцессоры и сколько хранятся бэкапы. Нет и открытого прайсинга за хранение и трафик. Часть операций с репозиторием всё ещё требует агента, Origin CLI или обычного git - веб-интерфейс закрывает не все сценарии. Обозреватели отдельно отмечают, что в первом релизе нет публичных проектов (то есть открытого опен-сорса на самом Origin) и нет встроенного CI - за него целиком отвечают партнёрские Depot и Buildkite. Для сервиса, который живёт первые недели, это ожидаемо, но именно эти пробелы и определяют, кому рано, а кому пора пробовать.

Из готового на день запуска - три партнёрские интеграции: Vercel даёт preview-деплой на каждый PR и прод при мердже, а Depot и Buildkite закрывают CI/CD с совместимостью GitHub Actions workflow. Разборы вроде kingy.ai сводят это к простой матрице: хорошие кандидаты на Origin - новые команды, стандартизированные на Cursor, приватные репозитории с простыми интеграциями и проекты, где ревью стало узким местом. Плохие кандидаты - регулируемые организации, команды, завязанные на GitHub Actions и Packages, и открытый исходный код, для которого GitHub как был практическим стандартом, так им и остаётся. На Hacker News к этому добавили ещё один слой - часть разработчиков прямо писала, что скорее потерпит даунтаймы GitHub, чем отдаст код на инфраструктуру, которая теперь так или иначе связана со SpaceX. Один из инженеров Origin, ранее сооснователь Graphite, признал там же, что помимо надёжности Origin пока даёт "очень мало" по сравнению с GitHub - и это не пиар-фраза, а честная оценка человека, который его строит.

У меня 251 коммит в репозитории пайплайна - и почти все от cron

Я прогнал git log --oneline | wc -l в своём репозитории с конвейером статей - 251 коммит. Открываю лог, а там через одну строку: chore(db): backup 2026-08-27, chore(db): backup 2026-08-26, chore(db): backup 2026-08-25 - это cron коммитит бэкап базы раз в сутки, без меня. Живых, "человеческих" коммитов с руками там в разы меньше, чем автоматики. Дело не только в бэкапах: в cron/ лежит 12 обёрток run-*.sh (плюс diary-скрипт), которые гоняют весь пайплайн статей сами - от сбора тем и генерации черновиков до фактчека, обложек, SEO и паблиша - без единого моего клика.

И вот тут интересный вывод, которого я не встретил ни в одном разборе Origin: если твой git - в основном лог автоматики, а не место, где люди спорят в pull request'ах, то вопрос "кто хостит гит" перестаёт быть стратегическим и становится чисто эксплуатационным. Мой парк cron-обёрток и раньше не спешил переезжать в облачные Routines именно по этой причине - не потому что облако хуже, а потому что переносить рабочую автоматику ради модной инфраструктуры имеет смысл, только когда старая реально мешает. Origin имеет смысл в первую очередь там, где вокруг PR правда происходит совместная работа людей и агентов, а не там, где repo - просто журнал бэкапов.

В том же логе, буквально соседним коммитом, нашёлся и обратный пример - усиление секьюр-фильтра после того, как в один из черновиков чуть не улетел реальный IP сервера из вставленного куска памяти агента. Поймали на ревью, до публикации, не в проде. Так что дело не в том, что автоматика в git - это всегда безопасно и скучно: иногда именно она и есть источник риска, и чем автономнее агент, тем больше смысла в человеке, который перечитывает дифф перед мерджем, а не после.

Стоит ли переносить репозиторий на Origin прямо сейчас

Нет, если у тебя прод с комплаенсом, GitHub Actions на связке с внешними системами и тем более открытый исходный код - GitHub тут пока безальтернативен. Да, если проект новый, маленький, живёт внутри Cursor, и ты готов побыть подопытным недели две-четыре, держа GitHub источником истины на всякий случай.

Если решил пробовать, разумный формат - не миграция, а пилот: берёшь один некритичный репозиторий, две-четыре недели держишь GitHub основным источником, а Origin - вторым контуром, и по ходу считаешь конкретные цифры - время до первого ревью, задержку между PR и мерджем, сколько раз агент довёл PR до готовности без твоего вмешательства и сколько раз пришлось откатывать. Через месяц с этими цифрами решение "переезжать или нет" принимается само, без гадания по чужим обзорам.

Практический критерий простой: заводи Origin туда, где сам процесс ревью и мерджа - это и есть продукт (совместная разработка, дискуссии в PR, код-ревью между людьми), и не трогай там, где repo - просто хранилище для автоматики или для чужих контрибьюторов, которым нужен привычный GitHub. Ну и раз агенты уже мержат треть PR без человека в цепочке, стоит вспомнить, что приёмка работы у нейронки - это теперь отдельный навык, а не формальность: чем автономнее становится git-хостинг, тем важнее, чтобы кто-то по-прежнему смотрел в дифф перед тем, как он ляжет в main.