Cursor, у которого есть платный бета-сервис Origin для работы с Git-репозиториями, рассказал, как обошел старую проблему: чем больше быстрых реплик хранишь, тем больнее и медленнее становится синхронизация. Для тех, кто строит внутренние платформы разработки, CI/CD и инструменты для AI-агентов, это не абстрактная архитектурная дискуссия, а вполне земной вопрос стоимости, задержек и отказоустойчивости.
23 августа 2026 года, как пишет The Register, principal systems engineer Cursor Висент Марти описал архитектуру сервиса Origin, работающего на внутреннем движке Continuity. Идея проста на словах и неприятно нетривиальна в реализации: source of truth для репозитория хранится не в наборе синхронных локальных копий, а в объектном хранилище S3, тогда как локальные репозитории на NVMe берут на себя чувствительные к задержкам операции. Бета Origin уже доступна в платных планах Cursor.
Почему это вообще важно? Потому что Git отлично чувствует себя как инструмент для разработчика на ноутбуке, но начинает капризничать, когда его пытаются превратить в глобальный сервис для миллионов и сотен миллионов репозиториев. Git хранит объекты по хэшу и видит историю как направленный ациклический граф. Если сервер знает нужный SHA, задача простая. Если нет, ему приходится обходить граф шаг за шагом, даже если клиенту на самом деле нужен всего лишь packfile для clone, fetch или список последних изменений. На малых объемах это инженерная рутина, на больших превращается в постоянный спор между диском, сетью и временем ответа.
Марти хорошо знает эту территорию: раньше он работал в GitHub и застал период, когда компания выстраивала собственную архитектуру масштабирования Git. В статье напоминают, что GitHub в итоге пришел к модели Spokes: у каждого репозитория есть как минимум три тесно синхронизируемые копии на быстрых NVMe-дисках. Подход стал почти отраслевым стандартом, потому что он дает предсказуемую производительность. Проблема в том, что за эту предсказуемость приходится платить все более дорогой синхронизацией. Чем больше реплик, тем длиннее путь до консистентного состояния. А Git, мягко говоря, не любит eventual consistency.
Что именно меняет Cursor
В Origin push сначала попадает в write-ahead log в S3. Иначе говоря, все изменения фиксируются как неизменяемые объекты в объектном хранилище; где возможно, они еще и пакуются вместе ради лучшей пропускной способности. Параллельно тот же push записывается в локальную «эталонную» копию репозитория, обычно лежащую на NVMe. Когда обе операции завершены, остальные реплики могут подтянуть изменения по мере необходимости.
В этом месте и появляется главное инженерное преимущество. Вместо синхронизации транзакции с кворумом из нескольких быстрых реплик система должна согласовать запись только с одной локальной reference-copy и журналом изменений в S3. По сути, Cursor выносит постоянную правду о репозитории в дешевое и почти бесконечно масштабируемое объектное хранилище, а локальный диск превращает в теплый кэш для операций, где важны миллисекунды. Для операций, требующих обхода DAG, это тоже выглядит логично: если Git все равно должен пройтись по графу, лучше делать это локально на NVMe, а не через сеть.
Здесь есть и второй слой смысла, уже напрямую связанный с AI. По словам Марти, агенты меняют профиль нагрузки на системы контроля версий: становится больше кода, больше pull request, больше прогонов CI. И это еще не все. Если раньше многие компании пытались укрупнять код в монорепозитории, то агентные сценарии, наоборот, часто плодят огромные количества маленьких, краткоживущих репозиториев, многие из которых почти не используются. Такая нагрузка плохо сочетается с моделью, где каждый репозиторий нужно немедленно размножить по нескольким дорогим и строго синхронным копиям.
Что это значит для платформенных команд
Для российских и русскоязычных платформенных команд здесь важен не сам бренд Cursor, а архитектурный сдвиг. Если у вас есть внутренний Git-сервис, self-hosted forge, корпоративная developer platform или интенсивные AI-воркфлоу вокруг кода, кейс Cursor подсказывает: возможно, пора перестать относиться к локальному диску как к единственному месту истины. Объектное хранилище уже давно перестало быть просто «местом, куда складывают бэкапы». Его используют как фундамент для баз данных, контейнерных реестров и брокеров сообщений. Теперь тот же подход все увереннее заходит и в инфраструктуру исходного кода.
Это не значит, что классическая схема с несколькими NVMe-репликами завтра исчезнет. У нее понятный профиль производительности, она проверена боем, а у многих команд уже обросла мониторингом, алертами и операционными привычками. Но рост нагрузки от AI-агентов меняет экономику. Если репозиториев становится больше, если значительная их часть эфемерна, а требования к скорости push и clone не уменьшаются, то хранить все как набор идеально синхронных локальных копий становится слишком дорогим удовольствием. В таком контексте масштабирование Git через объектное хранилище выглядит не экзотикой, а попыткой снять старое противоречие между скоростью, ценой и надежностью.
У Origin пока только бета-статус, так что самый интересный вопрос не в том, красиво ли звучит схема на диаграмме, а выдержит ли она реальную нагрузку без серии неприятных инцидентов. Если выдержит, у команд, которые отвечают за Git на уровне платформы, появится еще один серьезный аргумент в пользу S3-подобных хранилищ как базового слоя для систем разработки, а не только для архивов и логов.