Cursor на монорепо: порог 50 000 файлов и как его обойти

На маленьком проекте Cursor выглядит как магия: агент видит весь код, держит контекст, правит уверенно. Переносите тот же Cursor на монорепо в десятки тысяч файлов — и магия ломается. Индексация тянется, агент «забывает», что делал два шага назад, правки становятся неточными, а иногда индекс вообще не собирается. Это не поломка редактора — это предсказуемые ограничения, у каждого из которых есть конкретный обход.

Ниже — разбор по фактам: как Cursor на самом деле «видит» код, где именно он упирается на масштабе (с цифрами), и что настроить, чтобы большой проект снова стал управляемым. Всё сверено с документацией Cursor и независимыми техническими разборами на июль 2026.

Индексация Cursor — не то, что вы думаете

Первое распространённое заблуждение: «индексация полностью локальная, код никуда не уходит». Это не так. Cursor разбивает код на чанки, считает по ним эмбеддинги (векторные представления) и хранит их в облачной векторной базе — Turbopuffer поверх AWS S3. Сам код в открытом виде на сервере не хранится: он обрабатывается в памяти и отбрасывается, пути файлов обфусцируются, а индекс удаляется после 6 недель бездействия. Синхронизация идёт примерно раз в 5 минут.

Чтобы не гонять всё заново, Cursor считает локально дерево Меркла (хэши всех файлов и папок) и досылает на сервер только изменившиеся куски — на 50 000 файлов это всего около 3,2 МБ имён и хэшей. Механика умная, но вывод для вас практический: индексация — процесс гибридный, и на монорепо в чувствительной области (финансы, здоровье) режим приватности стоит оценивать отдельно, а не считать, что «код остаётся на машине».

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Если вы только присматриваетесь к Cursor и хотите проверить всё это на своём проекте, поставить редактор можно по этой ссылке — дальше по тексту разберём, что настроить сразу, чтобы на большом репозитории не упереться в потолок.

Bugbot в Cursor: сколько теперь стоит ИИ-ревьюер pull request и что он реально ловит

Cloud Agents в Cursor: как задача превращается в pull request

MCP в Cursor: как подключить базу данных, Figma и свои инструменты

Один продукт на Codex: как довести идею до живого URL, не утонув в коде

AGENTS.md: инструкция, которую агент Codex действительно читает перед работой

Порог 50 000 файлов: где авто-индексация просто не запускается

Самое жёсткое ограничение почти не обсуждают в русскоязычных гайдах: авто-индексация папки не запускается, если файлов в ней слишком много. Порог называют независимые тесты (bitpeak и techjacksolutions сходятся на ~50 000 файлов; часть источников приводит и более консервативную оценку около 10 000), а в официальной документации Cursor конкретной цифры по числу файлов нет вовсе — так что это ориентир из практики, а не жёсткая константа из доков. Но вывод для большого монорепо от этого не меняется: без ручной настройки исключений семантический поиск по коду у вас просто не заработает.

Насколько «тяжело» индексируется масштаб, показывает независимый бенчмарк (bitpeak на публичном репозитории ~79 600 файлов): полная индексация заняла около 38 минут против ~6,5 минут на один модуль в ~15 000 файлов; время ответа агента — 55 секунд против 30. Цифры единичного теста, но порядок понятен: чем шире индекс, тем медленнее и дороже каждый шаг.

Важная оговорка про время: по разным источникам оно разлетается от пары минут до многих часов на схожих объёмах — всё зависит от железа, сети и того, настроен ли .cursorignore. Поэтому воспринимайте это как диапазон «сильно зависит от конфигурации», а не как единую константу. И ещё про ресурсы: по независимой оценке на монорепо около миллиона строк индексатор и файловый watcher могут занимать диск на 5–15 минут после каждого открытия проекта и держать 4–8 ГБ RAM — под такое на Apple Silicon рекомендуют от 32 ГБ памяти.

Почему агент «забывает»: 200K обещанных против 40–60K реальных

Вторая частая жалоба — «агент теряет нить». У этого есть измеримая причина. Заявленное окно контекста модели — 200K токенов, но реально «полезного» пространства под ваш код и переписку по независимой оценке заметно меньше — порядка 40–60K токенов. Остальное съедают системные инструкции, описания инструментов, подгруженные правила и история диалога.

Отсюда характерный симптом: в многошаговом рефакторинге, который задевает несколько файлов, агент начинает терять точность уже к 3–4 шагу — контекст заполняется быстрее, чем при правке одного файла, и модель «забывает», что делала в начале. Community на Reddit фиксирует то же самое: связи между файлами теряются после примерно 20–30 тысяч токенов диалога.

Есть и денежный аспект. Max Mode расширяет окно, но если вход превышает 200K токенов (актуально для моделей с большим контекстом вроде Claude Sonnet), стоимость запроса удваивается. То есть «затолкать в контекст весь монорепо» — не только не помогает точности, но и прямо бьёт по кошельку. Как устроены тарифы и кредиты Cursor в целом — разбирали в обзоре Cursor и его тарифов; здесь важно одно: экономия контекста — это одновременно экономия денег.

BYBITВсё ещё смотришь со стороны?Рынок работает без выходных. Счёт на Bybit открывается за 2 минуты.Начать сейчас

Симптом → причина → обход

Свёл разрозненные советы в одну таблицу — такой сводки нет ни у одного конкурента целиком:

Дальше — как выполнить эти обходы по порядку.

Настройка за 15 минут: .cursorignore и правила по подпапкам

Первый инструмент — файлы исключений, и их важно не путать:

• .cursorignore — полный блок доступа ИИ к файлам: агент, Tab, Inline Edit и @-упоминания их не увидят.
• .cursorindexingignore — исключает файлы только из индекса и поиска, но оставляет их доступными через явное @-упоминание.

Cursor и так по умолчанию не индексирует лок-файлы, бинарники, медиа, node_modules/, .venv/, .next/ и ещё под сотню паттернов. Ваша задача на монорепо — добавить в .cursorignore сгенерированный код, дампы данных, снапшоты, крупные фикстуры и пакеты, с которыми вы сейчас не работаете. На практике именно .cursorignore закрывает больше половины жалоб на «Cursor тормозит» и сокращает индексацию примерно вчетверо (в одном разборе — с ~12 минут до менее чем 3).

Для монорепо включите Hierarchical Cursor Ignore (Settings → Indexing → Ignore Files) — тогда Cursor будет искать .cursorignore не только в корне, но и во всех родительских папках, и у каждого под-пакета может быть свой файл поверх общего. Одна ловушка: переисключить вложенный файл через !-паттерн не получится, если родительская директория уже закрыта через * — исключайте конкретные подпапки, а не всю директорию целиком.

Готовый скелет .cursorignore под монорепо, от которого удобно отталкиваться, — исключаем сгенерированное и тяжёлое, оставляем исходники:

# сборки и артефакты
**/dist/
**/build/
**/.next/
**/coverage/
# данные и снапшоты
**/fixtures/**/*.json
**/*.snap
**/*.dump
# пакеты, которыми сейчас не занимаемся
packages/legacy-*/
apps/admin-old/

Логика простая: чем меньше «мусора» в индексе, тем ниже шанс упереться в порог 50 000 файлов и тем быстрее и точнее работает поиск. Начните с широких исключений, а по мере надобности точечно открывайте нужные подпапки в их собственных .cursorignore.

Второй инструмент — правила проекта, и здесь есть устаревшая информация, которую до сих пор тиражируют. Единый корневой файл .cursorrules — легаси, в актуальной документации Cursor его больше нет. Сейчас правила задаются файлами .cursor/rules/*.mdc с YAML-заголовком (description, globs, alwaysApply), а для монорепо поддерживаются вложенные AGENTS.md в любой поддиректории — то есть у каждого под-пакета могут быть свои правила. Ключевой приём для экономии контекста: вместо always apply используйте Auto Attached с glob-паттернами, чтобы правила модуля подгружались только при работе с его файлами — по независимому опыту это срезало расход токенов на правила в монорепо примерно на 70%.

Приёмы: как держать контекст узким

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

1. Узкие «вертикальные» задачи. Одна законченная функциональная единица за раз, а не правки по файлам вразброс. Так контекст не расплывается.
2. План до кода. Plan Mode заставляет агента сначала исследовать и составить план, а не хвататься за правки — на большом проекте это резко снижает случайные изменения не туда.
3. Точные @-ссылки. @Files на конкретные файлы и @Code на конкретную функцию вместо @Codebase по всему монорепо. Для @Folders держите в папке не больше ~10 файлов, иначе агент увидит только часть.

Ещё один приём для совсем крупных монорепо — разбить работу на отдельные окна. Вместо того чтобы держать весь репозиторий в одном проекте Cursor, откройте нужный под-пакет как отдельный воркспейс: индекс собирается только по нему, порог 50 000 файлов перестаёт быть проблемой, а агент не отвлекается на чужой код. Это ровно тот случай, когда бенчмарк показывал разницу «38 минут на весь репозиторий против 6,5 минут на один модуль» — работая по модулю, вы получаете и быструю индексацию, и точность. Минус — теряется сквозной семантический поиск между пакетами, поэтому окна имеет смысл держать по границам, где код и так связан слабо (отдельный сервис, отдельное приложение, отдельная библиотека).

Отдельно работает явное ограничение границ прямо в промпте. По независимому опыту фраза вроде «меняй только этот модуль, остального не касайся» снизила долю случайных и лишних правок агента с ~30% до менее 5%. Это самый дешёвый приём из всех — просто слова в запросе.

И трезвое напоминание: даже при аккуратной настройке по независимой оценке около 15–20% кода, который правит агент, содержит проблемы (примерно 5% — настоящие баги, 10% — вопросы качества, 5% — несоответствие конвенциям проекта). На масштабном проекте ревью после агента — обязательный шаг, а не опциональный. Если вы только осваиваете такой стиль работы, начните с более простого формата — вайб-кодинга на небольшом проекте, а к монорепо переходите, когда набьёте руку на управлении контекстом.

Слабые места Cursor на монорепо: эмбеддинги уходят в облако

Где Cursor на монорепо объективно слаб — честно:

• Приватность индекса. Эмбеддинги уходят в облако (Turbopuffer/S3). Сырой код там не хранится, но для строгого compliance это повод отдельно оценить режим приватности, а не полагаться на «всё локально».
• Жёсткий порог 50 000 файлов. Это не «медленно», а «вообще не проиндексируется» без ручной настройки исключений.
• Зависания на очень больших репозиториях. Агент может застревать в статусе «Planning…» на 5+ минут и падать с серверной ошибкой NGHTTP2_ENHANCE_YOUR_CALM (это rate limit со стороны сервиса).
• Правила, взрывающие контекст. В баг-репорте на форуме Cursor описан случай, когда в монорепо с множеством AGENTS.md агент подгрузил правила из всех папок разом и мгновенно исчерпал окно контекста. Лечится переходом на Auto Attached с globs.

Для баланса — что на монорепо работает хорошо:

• .cursorignore реально спасает — вчетверо более быстрая индексация подтверждена на двух независимых крупных репозиториях.
• Переиспользование индекса в команде. По данным самого Cursor, клоны одного репозитория у коллег совпадают в среднем на 92%, и редактор умеет переиспользовать готовый индекс: медианное подключение нового участника упало с 7,87 секунды до полусекунды (это собственная метрика вендора, но механика правдоподобна).
• Правила и исключения по подпакетам дают монорепо то, чего раньше не хватало — разные настройки для каждого под-пакета без единого свалочного конфига в корне.

Частые вопросы

Почему Cursor не индексирует мой монорепо?

Скорее всего, в папке больше 50 000 файлов — при таком объёме авто-индексация не запускается. Решение — настроить .cursorignore: исключить билды, сгенерированный код, крупные данные и пакеты, с которыми вы сейчас не работаете, чтобы индексируемое дерево опустилось ниже порога. Для монорепо дополнительно включите иерархический ignore, чтобы у каждого под-пакета был свой файл исключений.

Правда ли, что код уходит на сервер Cursor?

Частично. Cursor считает по коду эмбеддинги и хранит их в облачной векторной базе, но сам код в открытом виде на сервере не сохраняется — он обрабатывается в памяти и отбрасывается, а пути файлов обфусцируются. Индекс удаляется после 6 недель простоя. Для чувствительных проектов это всё равно повод оценить режим приватности отдельно, а не считать индексацию чисто локальной.

Работает ли ещё файл .cursorrules?

Единый корневой .cursorrules — легаси, в актуальной документации Cursor его уже нет, хотя часть гайдов по инерции его советует. Актуальный способ — файлы .cursor/rules/*.mdc с заголовком (description, globs, alwaysApply), а для правил по подпапкам монорепо — вложенные AGENTS.md. Для экономии контекста подключайте правила через Auto Attached с glob-паттернами, а не always apply.

Почему агент «забывает» на середине задачи?

Из заявленных 200K токенов контекста реально полезными оказываются лишь около 40–60K — остальное занимают инструкции, описания инструментов и правила. На многофайловой задаче это пространство переполняется к 3–4 шагу, и агент теряет то, что делал в начале. Обход — дробить работу на узкие задачи, использовать Plan Mode и давать точные @-ссылки вместо поиска по всему монорепо.

Сколько нужно оперативной памяти под большой проект?

На монорепо примерно в миллион строк индексатор, файловый watcher и селектор контекста Cursor в устойчивом режиме держат 4–8 ГБ RAM, а после каждого открытия проекта нагружают диск на 5–15 минут, пока идёт синхронизация индекса. Для комфортной работы с такими объёмами на Apple Silicon рекомендуют машину от 32 ГБ памяти. Если у вас меньше — тем важнее агрессивный .cursorignore и разбивка на отдельные окна по под-пакетам, чтобы не индексировать весь монорепо разом.