Как экономить токены при работе с AI: rtk, CodeGraph и точный контекст

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

Хорошая стратегия — не просить модель «прочитать всё», а давать ей ровно тот контекст, который нужен для текущего шага. Для этого полезны rtk, CodeGraph и похожие инструменты индексации и навигации по проекту.

Главный принцип: меньше текста, больше сигнала

Экономия токенов — это не механическое сокращение каждого ответа. Нужно убрать из контекста шум:

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

При этом нельзя жертвовать информацией, необходимой для корректного решения. Слишком короткий контекст приводит к ошибкам, а исправление ошибок часто стоит дороже первоначального чтения.

Используйте rtk для компактного вывода команд

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

Например:

rtk git status --short
rtk git diff --check
rtk npm run build

Это особенно полезно при работе с Git, тестами и сборкой. Модели обычно не нужны все строки установки зависимостей или полный успешный лог компилятора. Важнее понять:

1. завершилась ли команда успешно;
2. какие ошибки требуют внимания;
3. какие файлы изменились;
4. есть ли предупреждения, влияющие на задачу.

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

Используйте CodeGraph вместо чтения репозитория целиком

CodeGraph строит индекс символов и связей между ними. Поэтому вместо последовательного поиска по десяткам файлов можно спросить:

• где объявлена функция;
• кто её вызывает;
• какой путь проходит запрос от UI до API;
• какие файлы зависят от изменяемого символа;
• где находятся связанные типы и обработчики.

Пример полезного запроса:

Как createPayment проходит от BuyModal до webhook? Покажи связанные символы и файлы.

Или перед правкой:

Покажи исходный код SUPPORTED_MODELS и все места, которые используют этот список.

Такой подход даёт модели локальный фрагмент кода вместе с call path и blast radius. Не приходится отдельно читать grep, затем открывать весь файл, а потом вручную восстанавливать связи.

Когда CodeGraph особенно полезен

• при изменении функции, которую вызывают из нескольких мест;
• при поиске обработчика API-запроса;
• при работе с React-компонентом и его родителями;
• при добавлении модели, endpoint или маршрута;
• при рефакторинге типов и интерфейсов;
• при расследовании бага по цепочке вызовов.

Для конфигураций, Markdown и файлов, которые не индексируются CodeGraph, используйте точечное чтение обычными инструментами.

Не смешивайте исследование и редактирование

Токены расходуются быстрее, когда в одном большом запросе объединены поиск архитектуры, проектирование, реализация и тестирование. Лучше разбить работу на короткие этапы:

1. определить затронутые символы;
2. изучить call path и ограничения;
3. сформулировать небольшой план;
4. внести минимальное изменение;
5. проверить только связанные сценарии.

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

Читайте только нужный диапазон строк

Полный файл часто содержит много контекста, который не нужен для задачи. Если известны символ или участок, используйте targeted read:

• начало файла — для импортов и типов;
• тело нужной функции — для логики;
• место вызова — для понимания контракта;
• тесты — только связанные с изменением.

Для Markdown-статьи обычно достаточно прочитать заголовок, структуру и несколько соседних разделов. Не нужно каждый раз загружать весь блог или все локализации.

Не передавайте повторно уже известные данные

Повторная передача одинакового контекста — один из самых дорогих сценариев. Старайтесь:

• ссылаться на уже найденный файл и символ;
• не копировать один и тот же лог в несколько сообщений;
• хранить решения в кратком ADR или заметке проекта;
• после редактирования передавать только актуальный diff;
• отделять факты от гипотез.

Инструментальная память и проектные заметки особенно полезны для архитектурных решений: модель не обязана каждый раз заново выяснять, почему в проекте два роутера, где хранится список моделей или как устроена оплата.

Выбирайте модель под задачу

Экономия зависит не только от количества текста, но и от выбранной модели:

• быстрая модель подходит для классификации, простого поиска и небольших механических правок;
• Sonnet — для большинства задач разработки и анализа;
• Opus — для сложной архитектуры, трудного отладки и больших изменений, где ошибка обходится дорого.

Не используйте самую мощную модель для форматирования или переименования. Но и не поручайте сложный рефакторинг модели, которая не удерживает нужный контекст: повторные исправления могут потратить больше токенов.

Практический workflow

Для типичной задачи в существующем проекте удобно работать так:

1. CodeGraph: найди символ и путь вызовов.
2. rtk: получи компактный git status и связанные проверки.
3. Точечно прочитай только нужные участки файлов.
4. Измени минимальный набор строк.
5. rtk git diff --check.
6. Запусти узкий тест или сборку.
7. При ошибке передай модели только ошибку и relevant diff.

Пример запроса к агенту:

Исправь валидацию email в createPayment.
Сначала покажи call path и связанные типы.
Не читай весь репозиторий. После правки запусти только связанные проверки.

Такой запрос задаёт не только цель, но и бюджет исследования.

Что обычно не помогает

«Прочитай весь проект»

Это создаёт большой шум и не гарантирует, что модель найдёт важную связь. Лучше начать с символа, endpoint или сообщения об ошибке.

Полный вывод grep и логов

Большие результаты трудно анализировать и дорого передавать. Ограничивайте поиск по файлам и ключевым словам, а успешные логи сокращайте через rtk.

Повторное чтение после каждой мелкой правки

Если изменение локальное, достаточно проверить diff и выполнить связанную команду. Повторный полный обзор проекта редко добавляет ценность.

Слишком большой универсальный prompt

Длинные инструкции, не относящиеся к задаче, конкурируют с кодом за контекст. Сохраняйте общие правила в конфигурации проекта, а в запросе оставляйте конкретную цель и критерии готовности.

Итог

Чтобы тратить меньше токенов и получать более стабильный результат:

1. давайте модели точный контекст, а не весь репозиторий;
2. используйте CodeGraph для символов, связей и call path;
3. используйте rtk для компактного вывода команд и проверок;
4. разделяйте исследование, изменение и валидацию;
5. после правки передавайте diff, а не повторный полный файл;
6. выбирайте модель под сложность задачи;
7. фиксируйте архитектурные решения в памяти проекта.

Меньше контекста не означает меньше качества. Правильный контекст — это небольшой, актуальный и связанный набор фактов, который позволяет модели принять решение без лишнего чтения.