Разработчик, работающий с 20+ проектами на нескольких VPS, замерил реальный расход контекста Claude Code на простом сценарии: вопрос о платёжных методах одного из Telegram-ботов. Агент сделал 15 вызовов инструментов, потратил больше 80 000 токенов и занял 8 минут. Сам ответ уложился в 800 токенов. Остальное — навигация: grep по домашней директории, чтение шести файлов-кандидатов из разных проектов, повторный поиск после промаха, SSH-подключение к серверу.
Это не специфика Claude Code. Cursor, Codex и Gemini CLI устроены так же: у них нет карты рабочего пространства пользователя, поэтому каждая сессия начинается с разведки. При работе с одним проектом это терпимо. При пятнадцати — часы контекста в день уходят только на ориентирование.
| Слепой агент | С иерархией | |
|---|---|---|
| Tool calls | 12 | 1 |
| Поведение | Grep → читает 4 файла → собирает ответ | Читает CLAUDE.md → отвечает |
| Точность | Корректно | Корректно |
Очевидное решение — RAG с векторным поиском — закрывает не ту проблему. Embeddings ловят семантическое сходство: запрос «как работает аутентификация» вернёт 15 фрагментов, упоминающих auth, login, token. Но они не покажут, что middleware.ts вызывает refresh.ts, который зависит от jwt-config.ts. Цепочка вызовов — реальная архитектура — невидима для векторного поиска. Плюс RAG добавляет инфраструктуру: embedding-сервер, индекс, ре-ранкинг, 200–500 мс задержки на каждый запрос.
Cursor, Codex и Gemini CLI ведут себя так же: у них нет карты рабочего пространства, каждая сессия начинается с разведки.
Альтернатива — иерархия из трёх уровней, реализованная обычными markdown-файлами. Верхний уровень — глобальная карта проектов объёмом около 2 КБ, которая прописывается в ~/.claude/CLAUDE.md (для Claude Code) или .cursorrules (для Cursor) и загружается автоматически в каждой сессии. В ней — таблица проектов с путями, серверами и статусами, список серверов с IP-адресами и назначением, и одно правило: прежде чем читать исходный код, прочитай CLAUDE.md проекта.
Второй уровень — CLAUDE.md в корне каждого проекта, около 5 КБ. Там стек, ключевые файлы с пояснениями, команды деплоя, имя systemd-сервиса, путь к логам. Агент читает его, когда пользователь упоминает конкретный проект, и сразу получает всю архитектуру без единого grep. Третий уровень — исходный код, к которому агент обращается только когда иерархия уже указала нужный файл.
Результаты замеров на одной модели (Haiku) и одной машине показывают кратную разницу. Вопрос об архитектуре проекта: 12 вызовов инструментов у слепого агента против 1 у агента с иерархией. Вопрос «какие из моих проектов используют библиотеку X»: 44 вызова против 2, и при этом слепой агент пропустил один из трёх проектов — больше вызовов не означает более точный ответ. Вопрос о деплое и логах конкретного проекта: 9 вызовов и SSH-подключение против 0 вызовов — агент ответил из контекста.
Преимущество подхода — в детерминированности. Разработчик сам пишет, что агент должен знать. С RAG приходится надеяться, что ре-ранкер выбрал правильные фрагменты. Обновление тоже проще: изменился деплой-конфиг — правится одна строка в CLAUDE.md, а не переиндексируется база. Наконец, markdown читают все агенты — Claude Code, Cursor, Codex, Gemini CLI — без дополнительных интеграций.
Для 15 проектов суммарный объём структурированного контекста составит около 77 КБ против 500 КБ–1 МБ сырых файлов при слепом поиске. Опционально между вторым и третьим уровнями можно добавить граф кода через инструмент Graphify — он строит граф зависимостей из AST и, по оценке автора, экономит ещё 30–50% вызовов для крупных проектов. Но и без него три markdown-файла меняют соотношение «навигация / полезная работа» с 99/1 до примерно равного.
