Тюнинг Cursor: как я укротил AI-ассистента и радикально снизил счета за токены с помощью MCP-серверов

Cursor или его аналоги, здорово облегчают написание кода, когда речь идет о каких-то не очень больших проектах. Но стоит попробовать применить их к серьезному, сложному проекту, состоящему из нескольких репозиториев, и тут же сталкиваешься с тем, что эти “чудеса” оборачиваются просто огромными счетами за токены. Я в этой статье поделюсь, как мне удалось перестать впустую сжигать миллионы токенов. Для этого пришлось собрать и запустить три MCP-сервера по протоколу Model Context Protocol, что позволило сэкономить до 90% бюджета, при этом совершенно не потеряв в эффективности модели при работе с кодом.

В прошлом году я использовал Cursor «из коробки» и не делал никаких дополнительных настроек, кроме выбора моделей. Я сидел на минимальном тарифе и мог позволить себе использовать абсолютно любые модели. Всё работало идеально.

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

Я решил глубоко разобраться с этим вопросом, чтобы уменьшить возросшие траты. Первое, что я сделал – перешел на более дешевые модели. Качество кода упало и все равно в финале надо было “дошлифовывать” код с помощью более дорогих моделей. В итоге такой подход ничего не дал в плане экономии.

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

В итоге решил обратиться к помощи передовых инструментов в виде MCP-серверов. Этот подход и позволил мне достичь моих целей. Заодно и пригодился полученный ранее навык работы с настроечными файлами Cursor.

Анатомия затрат: куда утекают токены?

В личном кабинете Cursor в дашборде можно увидеть логи использования инструмента. При наведении указателя мыши на количество потраченных токенов в любой строке появляются четыре поля: Cache Read, Cache Write, Input, Output.

Что это за поля и откуда берутся их значения?

Важный момент: Если вы видите огромные цифры в поле Cache Read — это не баг и не проблема. Наоборот, это признак эффективной работы механизма Prompt Caching. Это значит, что модель переиспользует контекст вашего проекта за копейки, а не загружает его с нуля за полную стоимость при каждом сообщении.

А вот большие значения в полях Input и Cache Write при каждом запросе — это прямой путь к разорению.

В среднем на один рабочий запрос у меня тратилось от 100 тыс. до 1,5 миллионов токенов. Но в глаза бросились аномалии: несколько запросов сожгли от 6 до 10 миллионов токенов каждый! В таких случаях поля Cache Write и Cache Read были равны нулю, а вся масса падала в дорогой Input. Обычно это происходит, когда модель начинает циклично ходить по коду, раз за разом читая одни и те же огромные файлы. От коллег я слышал о случаях, когда один такой запрос обходился по стоимости больше 100 долларов.

Первые попытки – AGENTS.md

У меня сложный проект, состоящий из нескольких тысяч строк кода на Golang. Часто бывает, что одна фича требует параллельного внесения изменений сразу в несколько репозиториев. Поэтому в Cursor я открываю workspace-папку, объединяющую несколько репозиториев.

Сначала я попытался решить проблему директивно — через файл AGENTS.md в корне папки, содержащей мои репозитории с кодом. В нем можно задать базовые инструкции для агента: например, запретить ему самостоятельно делать коммиты или запускать тесты. Там же я описал в минимальном виде архитектуру.

Выяснилось, что модель лучше воспринимает документ, поделенный на четкие разделы. Это позволило мне сократить текст самих ежедневных промптов. Теперь мне уже не нужно было каждый раз объяснять, как устроен проект. Но, к моему сожалению, агент всё так же жадно читал файлы целиком.

Открытие Model Context Protocol (MCP)

И тогда я вспомнил MCP-серверах.

MCP — это открытый стандарт, который позволяет моделям безопасно взаимодействовать с локальными инструментами, базами данных, файловыми системами, различными сервисами и т.д. Количество таких серверов стремительно растет. По информации Anthropic, в феврале 2024 их было около 2000, а в декабре 2025 — уже около 10 000.

Отличный агрегатор, который мне помог: PulseMCP.

Сообщество видит в MCP огромный потенциал, но сейчас экосистема находится в стадии «строителей больше, чем пользователей». Основные боли этого замечательного инструмента:
– Сложная настройка взаимодействия серверов.
– Проблемы безопасности (MCP-серверы имеют широкие права, есть риск утечки данных или деструктивных действий в системе).

Потратив некоторое количество времени на ресерч, я остановился на связке из трех MCP-серверов: RagCode MCP, Context Intelligence Engine (lean-ctx) и mcp-on-demand.

Ниже я расскажу, как установил и заставил их работать в единой связке на моей WSL с Ubuntu-24.04. На момент написания статьи я использую Cursor версии 3.1.14.

1. rag-code-mcp: Наделяем AI семантическим зрением

rag-code-mcp – это сервер, который позволяет построить векторный индекс кода на основе AST (абстрактного синтаксического дерева). При запросе моделью делается точечный семантический запрос и получается ровно те данные, которые сейчас нужны. Всё работает локально и код никуда “не утекает”.

Под капотом 3 компонента:

1. Сам сервер RagCode (предоставляет 9 инструментов, включая search_code, get_function_details).

2. Ollama (для запуска локальных легковесных моделей под эмбеддинги и логику).

3. Qdrant (векторная БД для хранения индексов).

Установка

Требования: минимум 16 ГБ RAM, 4 ядра CPU, установленные Docker и Docker Compose.

curl -fsSL https://github.com/doITmagic/rag-code-mcp/releases/latest/download/rag-code-mcp\_linux\_amd64.tar.gz | tar xz && ./ragcode-installer -ollama=docker -qdrant=docker

Скрипт сам поднимет контейнеры, скачает нужные модели (около 8 ГБ) и настроит окружение.

Интеграция с Cursor:

Добавьте в /user/.cursor/mcp.json (или через UI Cursor):

  "mcpServers": {
    "rag-code": {
      "command": "rag-code-mcp",
      "args": [],
      "env": {
        "OLLAMA_BASE_URL": "http://localhost:11434",
        "OLLAMA_EMBED": "nomic-embed-text",
        "OLLAMA_MODEL": "phi3:medium",
        "QDRANT_URL": "http://localhost:6333"
      }
    }
  }	

2. lean-ctx: Безжалостный компрессор токенов

Это универсальный оптимизатор, написанный на Rust. Его задача — сокращать потребление токенов на 89-99% за счет умного сжатия вывода терминала и кэширования чтения файлов. Он фильтрует «воду» из логов и файлов, отдавая AI только суть. Идеально работает в паре с любыми другими инструментами.

Установка

Rust и Cargo:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.bashrc

Установка lean-ctx:

cargo install lean-ctx

Настройка shell hook (для автосжатия команд в терминале):

lean-ctx init --global
exec bash

Теперь команды вроде git status или cargo build будут прозрачно сжиматься перед отправкой в контекст AI. Можете проверить статистику командой lean-ctx gain.

Интеграция с Cursor: Добавляем в /user/.cursor/mcp.json:

    "lean-ctx": {
      "command": "/root/.cargo/bin/lean-ctx",
      "args": []
    }

3. mcp-on-demand: Умный прокси для экономии контекста

Каждый MCP-сервер, добавленный в Cursor, по умолчанию работает постоянно и каждый раз отправляет описания всех своих инструментов в системный промпт модели. Если у вас много серверов с десятками функций, описания этих функций съедят 30–50% доступного контекста (ваших денег).

mcp-on-demand решает эту проблему. Это прокси-сервер, который прячет за собой все остальные MCP-сервера. Вместо десятков инструментов от каждого сервера он показывает Cursor всего два: search_tools (найти нужный инструмент) и use_tool (выполнить его). В то же время сами MCP-сервера запускаются только в момент их вызова (Lazy load), экономя гигабайты оперативки и тысячи токенов при каждом запросе.

Установка

Добавляем в /user/.cursor/mcp.json:

    "mcp-on-demand": {
      "command": "npx",
      "args": ["-y", "@soflution/mcp-on-demand"]
    }

При перезапуске Cursor прокси проанализирует соседние серверы в mcp.json, закэширует их схемы и выставит наружу только два мета-инструмента.

Проверить статус можно командой: npx @soflution/mcp-on-demand status. Вы увидите нечто подобное:

  Cache: 9 tools cached
  Tool Search: 9 tools -> 2 meta-tools exposed
  Token savings: ~2K tokens saved per message
  Estimated RAM savings: ~0.8 GB at startup

Связываем всё воедино: Правила и Промпты

Установить MCP-серверы — половина дела. Важно их заставить работать вместе при каждом запросе. Предполагается, что модель сама выбирает нужный сервер. Но на практике это не так. При каждом запросе выбор интсрументов делается хаотично.

Важно понимать логику, которую мы хотим привить агенту:

1. Этап A (Разведка): Если код незнаком, агент использует rag-code (через прокси mcp-on-demand), чтобы семантически найти нужные файлы.

2. Этап B (Работа): Когда пути к файлам известны, агент использует lean-ctx, чтобы читать и редактировать их с максимальным сжатием токенов.

Примечание: чтобы .mdc файл гарантированно применялся, он должен содержать YAML-блок с description, globs и обязательным alwaysApply: true.

Вот моя выстраданная конфигурация.

/project/AGENTS.md:

## Core Rules
- Не делай коммиты без спроса.
- Тесты не запускай сам; только дай команду пользователю.
- Код всегда должен быть SOLID и без гонок данных.

## Project Context (Architecture)
В проекте 3 сервиса: 
<Далее краткое описание работы ваших сервисов>

## Жёсткие лимиты

### 1. Максимум токенов за запрос: 50 000

Если lean-ctx или нативные инструменты показывают, что контекст превысит 50K — **НЕ ВЫПОЛНЯЙ запрос**.

Выведи сообщение:
Лимит 50K токенов. Уточни файлы и строки.


### 2. Максимум токенов за сессию: 200 000

Суммарно за все запросы в текущей сессии.

## Запрещённые паттерны

| ❌ | Описание |
|----|----------|
| Читать файл повторно | Не читай один файл дважды (даже с разными offset), если содержимое не изменилось |
| `ctx_tree` без пути | Не выполняй `ctx_tree` без явного пути от пользователя |
| `hybrid_search` при известном пути | Не используй `hybrid_search`, если уже знаешь точный путь к файлу |
| Длинные тесты/логи | Не загружай результаты тестов или логов длиннее 100 строк |

## Аварийная остановка

Если в текущей сессии уже использовано **> 200K токенов** (суммарно)

1. **НЕМЕДЛЕННО остановись**
2. Выведи:
⛔ ПРЕВЫШЕНИЕ ЛИМИТА ТОКЕНОВ (X токенов)
Действие: создай новую сессию Cursor
Причина: [кратко, например: "прочитано 15 файлов по 300 строк"]

/project/.cursorrules:

<instructions>
Совместная работа трёх MCP: **rag-code**, **mcp-on-demand** (мост к rag-code), **lean-ctx** (экономия токенов после того, как известны файлы).

**Если rag-code недоступен: допускается встроенный codebase search; полный ripgrep по монорепо без цели — нет.**

**Этап A — смысл и навигация по незнакомому коду**  
Используй **rag-code** `search_code` (аргументы строго по JSON-дескриптору инструмента). При отсутствии индекса — `index_workspace` с корнем нужного репозитория. Если rag-code недоступен напрямую — **mcp-on-demand**: `search_tools`, затем `use_tool` для инструмента rag-code. Точные имена/строки — `hybrid_search`; с якорем (файл, символ) — `get_code_context`, `get_function_details`, `find_implementations`, `find_type_definition`.  
Не подменяй этот этап слепым grep, если цель — понять поведение по описанию.
На этапе A не использовать широкий текстовый поиск по всему workspace вместо search_code.

**Этап B — чтение, обход дерева, shell, текстовый поиск по уже известным путям**  
Максимально используй **lean-ctx**: `ctx_read` вместо Read, `ctx_search` вместо Grep, `ctx_shell` вместо Shell, `ctx_tree` вместо ls/find. Правки: нативный Edit/StrReplace; если Read недоступен — сразу `ctx_edit`. Write, Delete, Glob — нативно.  
Не вызывай rag-code вместо `ctx_read`/`ctx_search`, если путь уже известен или нужна только точная строка.

**Сразу без rag-code** допустимо: известен точный путь к файлу или есть уникальная строка для поиска — тогда Этап B (lean-ctx или нативные инструменты по ситуации).

**index_workspace:** для задачи внутри одного сервиса индексируй корень соответствующего каталога (`service_1`, `service_2` или `service_3`); для сквозной задачи по нескольким сервисам — корень workspace-монорепозитория (`dual`).
</instructions>

/project/.cursor/rules/lean-ctx.mdc:

---
description: "lean-ctx — экономия токенов"
alwaysApply: true
---

# lean-ctx
ctx_read > Read (cached)
ctx_search > Grep (limit:20)
ctx_shell > Shell
ctx_tree > ls

Modes: full, map, signatures, diff, lines:N-M

/project/.cursor/rules/mcp-workflow.mdc:

---
description: Детальный workflow для MCP (не заменяет .cursorrules)
globs: 
alwaysApply: true
---

# Подробности вызова MCP

## rag-code параметры
- `search_code`: строго по JSON-схеме дескриптора
- `hybrid_search`: только для точных совпадений имён/строк
- `get_code_context`: когда есть якорь (файл, символ)

## lean-ctx
См. `.cursor/rules/lean-ctx.mdc`.

## Исключения для Этапа A
Не подменяй rag-code слепым grep, если цель — понять поведение по описанию.

/project/.cursor/rules/token-economy.mdc:

---
description: Жёсткая экономия токенов для MCP-инструментов
globs: 
alwaysApply: true
priority: 1
---

# Правила вызова MCP

## lean-ctx
Инструменты, лимиты и режимы — в `.cursor/rules/lean-ctx.mdc` (не дублировать здесь).

## rag-code (только для этапа A)
- `search_code`: максимум 10 результатов.
- `hybrid_search`: запрещён, если у тебя уже есть точный путь к файлу.
- После того как нашёл нужный файл через RAG — сразу переходи к `ctx_read`, не вызывай RAG повторно.

## Мониторинг
Перед каждым вызовом инструмента оценивай:
- Сколько токенов уже в контексте?
- Сколько токенов добавит этот вызов?

Если сумма > 50K — отмени операцию.


## Cache Read ограничения
- Если Cache Read токены > 10% от общего контекста — остановись
- После 3 повторных чтений одного файла — остановись

Также я создал вспомогательный файл-карту: /project/.cursor/project-source-index.txt

# Карта исходников (кратко). Полный список файлов не хранить здесь — слишком много токенов при подключении к контексту.
# Workspace: монорепозиторий <название папки>

## Сервисы (корни для index_workspace / навигации)
- service_1/ —  <краткое описание самого сервиса>
- service_2/ — <краткое описание самого сервиса>
- service_3/ — <краткое описание самого сервиса>
- notes/ — заметки и планы (не прод-код)

## Go-модули (имена из go.mod)
- 
- 
- 

Этот файл — мини-карта проекта для модели. Он помогает агенту быстро понять структуру проекта, не сканируя директории впустую.

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

Результаты

В результате внедрения этой архитектуры типичный запрос в моем логе теперь выглядит примерно так:

• Cache Read – 727 456

• Cache Write – 0

• Input – 39 488

• Output – 7 233

Как видите, дорогой Input минимизирован, а основная масса контекста берется из дешевого Cache Read. Экономия получилась колоссальной. В то же время и скорость ответов заметно возросла, так как модель теперь читает только нужные для работы файлы.

Выводы

1. Экономия токенов — это отдельная задача, которую приходится решать вручную. Если не смотреть в дашборд и не анализировать структуру контекста, очень легко сжигать огромные суммы даже на обычных задачах. Особенно это важно для больших проектов.

2. Правила и конфиги Cursor полезны, но сами по себе проблему не закрывают. Ценность настроечных файлов вроде .cursorrules, AGENTS.md и .mdc раскрывается тогда, когда они становятся частью общего workflow.

3. Сам по себе MCP ничего не экономит, если не задать правила его использования. Нужны четко понимать когда и для чего применять каждый сервер MCP.

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

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

Надеюсь, что в этой статье вы найдете что-то интересное для себя, что поможет вам сохранить нервы и бюджет. Буду рад обсудить в комментариях, какие MCP-серверы и трюки для экономии токенов используете вы!