Чому Cursor гальмує на монорепо: поріг 50 000 файлів, вузький контекст і як це обійти

На маленькому проєкті Cursor виглядає як магія: агент бачить увесь код, тримає контекст, впевнено вносить правки. Перенесіть той самий Cursor на монорепо в десятки тисяч файлів — і магія ламається. Індексація тягнеться, агент «забуває», що робив два кроки тому, правки стають неточними, а іноді індекс узагалі не збирається. Це не поломка редактора — це передбачувані обмеження, у кожного з яких є конкретний обхід.

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

Індексація Cursor — не те, що ви думаєте

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

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

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

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

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 і фонові агенти

Поріг 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 кроку — контекст заповнюється швидше, ніж при правці одного файла, і модель «забуває», що робила на початку. Спільнота на Reddit фіксує те саме: зв’язки між файлами губляться після приблизно 20–30 тисяч токенів діалогу.

Є й грошовий аспект. Max Mode розширює вікно, але якщо вхід перевищує 200K токенів (актуально для моделей із великим контекстом на кшталт Claude Sonnet), вартість запиту подвоюється. Тобто «заштовхати в контекст усе монорепо» — не лише не допомагає точності, а й прямо б’є по гаманцю. Як влаштовані тарифи й кредити Cursor загалом — розбирали в огляді Cursor і його тарифів; тут важливо одне: економія контексту — це водночас економія грошей.

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

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

Звів розрізнені поради в одну таблицю — такої зведеної немає в жодного конкурента цілком:

Далі — як виконати ці обходи по порядку.

Налаштування за 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 і розбивка на окремі вікна по під-пакетах, щоб не індексувати все монорепо разом.