Code-memory: MCP-сервер, который понимает ваш код лучше, чем вы сами (и не сожрет всю VRAM)

Проблема: ваш код не помещается в голову модели (и это нормально)

Вы когда-нибудь пытались объяснить Claude или локальной Llama 3.2 90B всю архитектуру вашего проекта? Сначала модель кивает, делает вид, что понимает, а потом предлагает добавить console.log в середину production-кода. Знакомо?

Проблема не в моделях (хотя иногда и в них). Проблема в том, что 128K токенов контекста — это примерно 300 страниц текста. Ваш кодовая база на 500 файлов? Прощай, контекст. Здравствуй, галлюцинации.

Code-memory: что это и зачем он вам нужен

Code-memory — это MCP-сервер, который делает простую вещь: превращает ваш код в поисковую базу. Не просто текстовый поиск «найди функцию login». А семантический: «покажи мне все места, где обрабатывается JWT-токен» или «найди все компоненты, которые используют хук useAuth».

Вместо того чтобы пихать весь проект в промпт, вы спрашиваете code-memory: «Эй, а где у нас валидация форм?» Сервер находит релевантные фрагменты через векторный поиск, парсит AST через tree-sitter, и возвращает только то, что нужно. Экономия контекста — до 90%.

Чем code-memory отличается от других решений

Вы наверняка видели другие инструменты. Ragex работает с графами зависимостей. SRAG — это больше для документов. Code-memory — специалист по коду, и делает три вещи лучше всех:

• Локальные эмбеддинги: не нужен OpenAI, не нужен даже интернет. Использует модели типа all-MiniLM-L6-v2 (25MB), которые грузятся в оперативку и работают оффлайн.
• AST-парсинг через tree-sitter: понимает структуру кода, а не просто текст. Знает разницу между объявлением функции и её вызовом.
• Sqlite-vec: векторная БД в одном файле. Никаких отдельно стоящих PostgreSQL с pgvector.

Как это работает изнутри (без скучных диаграмм)

Представьте, что code-memory — это очень педантичный библиотекарь для вашего кода. Вот что он делает, когда вы ему говорите «индексируй этот проект»:

1 Парсинг через tree-sitter

Tree-sitter — это парсер, который понимает синтаксис десятков языков. Он не просто разбивает код на строки. Он строит дерево (AST), где видно: вот функция, вот её параметры, вот тело, вот вызов другой функции внутри.

Code-memory использует это, чтобы разбивать код осмысленно. Не просто «каждые 1000 символов», а «каждая функция — отдельный чанк, каждый класс — отдельный чанк».

2 Создание эмбеддингов локально

Здесь магия. Каждый чанк кода превращается в вектор (список из 384 чисел) с помощью локальной модели. На 22.02.2026 самые популярные варианты:

• all-MiniLM-L6-v2: 25MB, быстро, хорошо для английского
• multilingual-e5-small: 134MB, поддерживает русский
• BAAI/bge-small-en-v1.5: 33MB, современнее MiniLM

Модель грузится один раз и живёт в оперативке. Никаких запросов в облако.

3 Сохранение в sqlite-vec

Sqlite-vec — это расширение для SQLite, которое умеет хранить векторы и искать по ним. Всё в одном .db файле. Переносите проект на другой компьютер — копируете файл базы. Всё.

Когда вы спрашиваете «где обработка ошибок», ваш запрос тоже превращается в вектор, ищутся похожие векторы в базе, возвращаются соответствующие фрагменты кода.

Настройка: от нуля до работающего сервера за 15 минут

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

1 Установка

Убедитесь, что у вас Python 3.10+. Потом:

pip install code-memory-mcp

Да, есть готовый пакет на PyPI. Не нужно клонировать репозитории.

2 Запуск сервера

code-memory serve --port 8000 --embedding-model all-MiniLM-L6-v2

Сервер запустится на порту 8000. По умолчанию использует лёгкую модель. Если нужна поддержка русского в запросах, замените на multilingual-e5-small.

3 Индексация проекта

Отправьте POST-запрос (или используйте готовый UI, если он есть в вашем MCP-клиенте):

curl -X POST http://localhost:8000/index \
  -H "Content-Type: application/json" \
  -d '{"project_path": "/путь/к/вашему/проекту", "patterns": ["**/*.py", "**/*.js", "**/*.ts"]}'

Сервер пройдётся по файлам, распарсит их, создаст эмбеддинги. Для проекта на 10K строк это займёт 2-3 минуты.

4 Подключение к MCP-клиенту

В Claude Code или Cursor зайдите в настройки MCP, добавьте сервер:

{
  "mcpServers": {
    "code-memory": {
      "command": "python",
      "args": ["-m", "code_memory", "serve", "--port", "8000"],
      "env": {}
    }
  }
}

Перезапустите IDE. Теперь в чате с моделью можно писать: @code-memory найди все компоненты с модальными окнами.

Примеры использования, которые реально работают

Не просто «поиск кода». Конкретные сценарии:

Миграция легаси-кода: «Покажи все места, где используется устаревший API v1». Модель получает конкретные файлы и строки, предлагает замену на v2.

Поиск багов: «Найди все try-catch блоки, где ошибка логируется, но не пробрасывается дальше». Code-memory найдёт, модель проанализирует.

Онбординг нового разработчика: «Объясни архитектуру аутентификации в проекте». Сервер найдёт все связанные файлы (контроллеры, мидлвари, конфиги), модель синтезирует объяснение.

Рефакторинг: «Где у нас дублирование логики валидации email?» Вместо ручного grep — семантический поиск.

Подводные камни (они есть всегда)

Не всё идеально. Вот что может пойти не так:

• Tree-sitter не всегда идеально парсит: особенно экзотические синтаксические конструкции. Для большинства языков работает отлично, для JSX/TSX — хорошо, для шаблонных строк с вложенным кодом — иногда спотыкается.
• Локальные эмбеддинги хуже облачных: модель all-MiniLM-L6-v2 создана в 2020 году. Современные текстовые эмбеддинги от OpenAI или Cohere лучше понимают нюансы. Но они требуют API-ключи и интернет.
• Первая индексация медленная: особенно на больших проектах. Зато потом поиск — миллисекунды.
• Нужно обновлять индекс: добавили новый файл? Переиндексируйте или настройте вотчер.

Кому это нужно (спойлер: почти всем)

Разработчики на локальных моделях: если у вас RTX 5090 и локальная Llama 3.2 90B, но контекста всё равно не хватает — code-memory расширит «память» модели без апгрейда железа.

Команды с закрытым кодом: нельзя отправлять код в облачные эмбеддинги? Локальное решение решает проблему.

Те, кто ненавидит платить за OpenAI: каждый запрос к эмбеддингам OpenAI — деньги. Локальные модели — одноразовая загрузка в память.

Разработчики легаси-проектов: когда кодовая база старше некоторых членов команды, и никто не помнит, как всё устроено.

А что насчёт альтернатив?

Code-memory — не единственный игрок. SRAG больше заточен под документы, но может работать и с кодом. Ragex сложнее в настройке, зато умеет строить графы зависимостей.

Выбор зависит от задачи:

• Нужно просто и быстро → code-memory
• Нужен анализ зависимостей между файлами → Ragex
• Работаете в основном с документацией → SRAG
• Не боитесь облачных API и есть бюджет → OpenAI embeddings + векторная БД

Главное преимущество code-memory — минимализм. Один файл БД, одна модель эмбеддингов, tree-sitter. Ничего лишнего.

Будущее (куда это всё движется)

На 22.02.2026 MCP становится стандартом де-факто для расширения контекста моделей. В ближайшем будущем ждём:

• Встроенную поддержку code-memory в популярные IDE без ручной настройки
• Более умные модели эмбеддингов, специально обученные на коде
• Интеграцию с системами контроля версий (поиск по истории изменений)
• Автоматическое обновление индекса при коммитах

Уже сейчас code-memory решает проблему, которая сводит с ума всех, кто работает с большими кодовыми базами. Модели перестают «забывать» ранние инструкции, потому что контекст не раздувается мегабайтами кода.

И самое приятное: вам не нужна RTX 5090 за $3000 или ежемесячная подписка на OpenAI. Достаточно обычного компьютера и 15 минут на настройку.

Попробуйте. Ваша модель скажет спасибо. (Ну, или хотя бы перестанет предлагать странные решения из-за нехватки контекста.)