Оптимизация контекста для Claude Code на большом проекте (иногда и 50% экономия токенов)

Работаю над большим C++ проектом - реализация сетевого протокола. Использую Claude Code как основной инструмент. Со временем заметил: каждый новый чат начинается с того, что агент долго читает README.md, который разросся до 1000+ строк и 60 КБ.

Проблема

В CLAUDE.md была прописана команда читать README.md в начале каждого диалога, агенту нужно дать контекст проекта. Пока проект был небольшим это работало нормально. Но README рос вместе с проектом и в итоге стал содержать всё: архитектуру, логику DTLS, настройки веб-интерфейса, описание протокола, инструкции по сборке.

И как результат:

• Агент тратит тысячи токенов на анализ файла до начала работы

• Если задача касается только фронтенда, модель всё равно загружает детали реализации ядра протокола. Лишний контекст снижает точность ответов.

Решение

Вместо одного большого файла использовать иерархию маленьких, в отдельной папке claude-context/:

claude-context/
├── context-claude.md       # общая архитектура и навигация (~90 строк)
├── context-AC-claude.md    # Access Controller
├── context-WTP-claude.md   # WTP Agent
├── context-WEB-claude.md   # Web Interface
└── context-TESTS-claude.md # тесты

Главный файл context-claude.md содержит краткое описание проекта и таблицу-навигатор: какой файл читать для какой области. В дочерних файлах описана детализация по модулям, каждый 100-130 строк.

Инструкция в CLAUDE.md теперь выглядит так:

“Start each new conversation by reading claude-context/context-claude.md. For deeper context on specific areas, read the relevant file from that directory.”

Агент читает главный файл (90 строк), понимает область задачи, подгружает только нужный дочерний контекст.

Замер

Чтобы проверить эффект, я поставил Claude одну и ту же задачу в двух разных конфигурациях:

“Добавь тесты для WtpConfigController и WtpRadioController, проверь что если WTP address не строка, то возникает исключение std::runtime_error”

| Параметр             | README.md (60 КБ) | Иерархический контекст | Разница  |
| :------------------- | :---------------- | :--------------------- | :------- |
| Токены на сообщения  | 36.8k             | 17.6k                  | -53%     |
| Всего токенов        | 56.7k             | 37.6k                  | -34%     |
| Рост usage за задачу | +11%              | +6%                    | В 2 раза |
| Скорость анализа     | Заметная пауза    | Почти мгновенный старт |          |

Важный момент

README.md остался нетронутым - это документация для людей. Файлы в claude-context/ - отдельный артефакт, написанный под AI: плотно, без лирики, с ASCII-схемами и таблицами. Я старался не смешивать два разных назначения в одном файле.

При небольшом проекте в этом подходе смысла нет, накладные расходы на поддержку двух наборов документации не оправдаются.

Надоело искать парные вкладки (.h/.cpp) в VS Code? Я навайбкодил расширение, которое их магнитит.

Привет! Меня всегда немного раздражала одна мелочь в VS Code.

Открываешь Source.cpp, хочешь посмотреть заголовок, а Source.h открыт где-то в конце списка вкладок или вообще затерялся среди десятка других файлов. Приходится глазами искать его или тянуться к дереву проекта.

Стандартные методы сортировки тут не помогают, поэтому я написал Tab Magnet.

Как это работает:
Вы просто кликаете на файл в Explorer-е. Tab Magnet проверяет, открыта ли его "пара" (например, .h для .c или .html для .component.ts), и если да - автоматически переносит её поближе, чтобы они стояли бок о бок.

Функционал:

• Знает, что заголовки лучше держать справа, а тесты — рядом с кодом.

• Поддерживает из коробки C/C++, C#, Web (JS/TS/HTML/CSS) и Angular.

• Можно настроить свои правила (например, для Go тестов или специфичных структур папок).

vscode marketplace: Tab Magnet

GitHub: tab-magnet

Linux под Hyper-V, overhead со знаком минус?

Неоднократно приходилось переходить с Linux на самой машине к той же версии и на той же машине, но развернутой в виртуалке в Windows. И часто замечал, что Linux в Hyper-V работает более “отзывчиво” по части GUI (vscode, chrome, firefox и т.п.). Но это были именно субъективные ощущения, особо не заострял на этом внимание предполагая, что улучшения происходят из-за каких-либо аппаратных интерфейсов, для которых Hyper-V предоставляет стандартные реализации. 

Недавно решил обновить рабочий компьютер, и перед тем как выбрать какая ОСь будет основной, провел небольшой тест на сколько “тормозней” Linux в Hyperv-V. 

Список оборудования и ПО:

• Ноутбук Acer Aspire 7, Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz, RAM 20.0 GB

• ОС Linux Mint 21.3 Virginia 64-bit, Kernel Linux 5.15.0-130-generic x86_64

• ОС Windows 10 Enterprise LTSC 21H2 (build 19044.5247)

• В качестве теста выбрана сборка проекта OpenWrt.

Сценарий теста:

1. Linux на ноутбуке:

   1. Устанавливаем Linux на ноутбук.

   2. Клонируем OpenWrt и запускаем последовательно команды:

      1. git clone -b openwrt-23.05 https://github.com/openwrt/openwrt.git

      2. cd openwrt/

      3. ./scripts/feeds update -a

      4. ./scripts/feeds install -a

      5. make menuconfig #выбираем Target System (Qualcomm Atheros IPQ807x)

      6. make -j8 download #download отдельной командой, чтобы не зависеть от сети при тесте.

      7. time make -j8

2. Linux в Hyper-V:

   1. Устанавливаем Windows 10 LTSC на ноут. 

   2. Включаем поддержку Hyper-V.

   3. Устанавливаем Linux под Hyper-V.

   4. В настройках виртуалки, установить кол-во CPU равным 8, выделить RAM 8-18 GB.

   5. Далее выполняем те же действия, что и в пп. 1.2.

Вывод time после сборки OpenWrt:

• Linux на ноутбуке:

  • попытка №1

    • real    30m37,765s

  • попытка №2

    • real    29m18,569s

• Linux в Hyper-V:

  • попытка №1

    • real    27m12,136s

  • попытка №2

    • real    27m36,395s

Получается, что Linux в Hyper-V работает немного быстрей? Странно это, и по хорошему нужно проверять еще. Но на данном этапе меня устраивает, что могу две ОСи одновременно использовать и есть уверенность что нет дополнительных проседаний в производительности.

Так же попробовал в виртуалке установить Ubuntu 24.04 и Linux Mint 22 Cinnamon, их время было такое,real  30m59,630s и 30m37,765s соответственно.