Экономия токенов в AI-разработке начинается не с просьбы к модели «отвечай короче». Модель может писать меньше, но при этом всё равно получать на вход огромный шумный контекст, каждый раз заново читать одни и те же правила, рассуждать там, где достаточно простого скрипта, и несколько раз переделывать работу из-за неточной постановки задачи.
Я смотрю на токены как на инженерный ресурс. Их нужно тратить там, где они покупают качество: понимание сложной задачи, архитектурное решение, разбор противоречий, проверку риска. Всё остальное лучше отдавать более дешёвым маршрутам, обычному коду, подготовленным артефактам и валидаторам.
В моей практике главный вывод такой: сильную reasoning-модель нельзя делать дефолтным исполнителем для всего подряд. Её место - архитектор, ревьюер или оркестратор. А рутину должны делать более дешёвые модели, инструменты и скрипты. Это хорошо сочетается с тем, как я проектирую маршрутизацию LLM и AI-контуры для реальных задач.
Где токены обычно сгорают впустую
Первая утечка - слишком широкий контекст. В AI-разработке легко закинуть модели весь репозиторий, историю обсуждения, длинную системную инструкцию, несколько логов и ещё пару файлов «на всякий случай». Модель всё это прочитает, но не факт, что станет полезнее. Иногда наоборот: важный сигнал утонет в шуме.
Вторая утечка - неправильная модель на простую работу. Если нужно переименовать поле, поправить формат, пройтись по списку файлов, собрать таблицу ссылок или проверить наличие frontmatter, дорогая reasoning-модель не нужна. Это зона обычного кода, shell-команд, статических проверок или более дешёвого исполнителя.
Третья утечка - повторение неизменной информации. Правила проекта, стиль ответа, формат артефакта, описание ролей и ограничения безопасности часто одинаковые от запуска к запуску. Если каждый раз собирать их заново в произвольном виде, кэширование хуже работает, а поведение системы становится менее стабильным.
Четвёртая утечка - отсутствие промежуточной проверки. Модель делает большой кусок работы, ошибается в исходном допущении, а потом приходится перегенерировать всё. Дешевле остановиться раньше: проверить план, список файлов, формат результата, источники и критерии готовности.
Пятая утечка - агент там, где нужен скрипт. Я уже отдельно разбирал, когда выбирать ИИ-агента или обычный скрипт. Для токенов это особенно важно: агентная самодеятельность дорого стоит, если задача на самом деле детерминированная.
Сначала сужаю задачу, потом выбираю модель
Мой базовый порядок такой: сначала понять форму задачи, потом подготовить контекст, потом выбрать модель. Не наоборот.
Если начать с вопроса «какую модель взять», легко переплатить. Сильная модель может закрыть почти всё, но это не значит, что её нужно ставить в начало каждой цепочки. В рабочем процессе я сначала спрашиваю:
- что именно должно измениться;
- какие файлы или данные реально нужны;
- какой результат будет считаться готовым;
- какие действия запрещены;
- что можно проверить программно;
- где цена ошибки выше цены токенов.
Чем точнее сценарий, тем меньше модель тратит токены на угадывание. И тем проще отправить разные части работы в разные места: поиск файлов - инструментам, черновую сборку - недорогому исполнителю, спорные решения - сильной модели.
Дорогая модель не должна быть рабочей лошадкой
Архитектор, ревьюер, оркестратор
Архитектор получает ограничения, цели, риски, интерфейсы и критерии готовности до реализации. Он не должен переписывать файлы руками, его задача - разложить работу и выбрать маршрут. Это похоже на этап проектирования AI-архитектуры: сначала компоненты и границы, потом код.
Ревьюер смотрит на уже готовый план, diff, тесты или артефакт и ищет неверные допущения, риск регрессии, неполную проверку, конфликт требований. Оркестратор держит цель, раздаёт ограниченные поручения и останавливает процесс, если качество не подтверждено.
В таком режиме дорогая модель тратит токены на решения, а не на механическую ходьбу по файловой системе.
Контекст должен быть коротким, но достаточным
Экономия токенов не означает «дать модели меньше, чем нужно». Плохой короткий контекст приводит к переделкам, а переделки съедают больше токенов, чем аккуратная подготовка.
Я делю контекст на три части.
Постоянные правила
Это роль, стиль, ограничения, формат результата, правила безопасности. Они должны быть стабильными. Если система каждый раз формулирует их по-новому, модель получает вроде бы похожие, но технически разные запросы. Это мешает и кэшу, и предсказуемости.
У Anthropic в официальной документации для разработчиков есть раздел про кэширование запросов: смысл в том, что повторяемые части запроса можно использовать эффективнее, если они стабильно передаются как кэшируемый префикс. Я не закладываю в рабочие статьи точные цены или лимиты, потому что они меняются, но сам принцип для длинных процессов устойчивый: неизменяемое держать неизменяемым.
Динамические данные
Это файлы, источники, выдержки из базы знаний, результаты команд, список существующих страниц. Их нужно не «побольше», а ровно столько, сколько нужно для текущего решения.
Текущая задача
Это конкретное действие: что создать, где сохранить, что проверить, чего не делать. Чем меньше текущая задача смешана с постоянными правилами и сырой базой знаний, тем легче её менять без пересборки всего контекста.
Effort - отдельный бюджет, а не настроение модели
В современных reasoning-моделях важно управлять не только выбором модели, но и глубиной рассуждения. В документации Anthropic по thinking и context windows прямо описано, что thinking-токены входят в общий бюджет контекста и лимитов. Значит, «пусть думает максимально» - это не бесплатная настройка качества.
Я бы не ставил высокий режим рассуждения по умолчанию. Практичнее завести уровни:
- low - короткая классификация, первичное решение, ограниченный review;
- medium - проектирование небольшого изменения, разбор понятной ошибки, редактура;
- high - архитектура, конфликтующие требования, опасные правки, сложная отладка.
Главное - не путать экономию с жадностью. Если задача действительно сложная, низкий effort может привести к поверхностному решению. Но если задача простая, высокий effort превращается в платное топтание на месте.
Субагенты экономят только при жёстких границах
Идея «дорогая модель ставит задачу, дешёвые исполнители делают работу» хорошая, но она ломается без дисциплины. Если каждому исполнителю дать расплывчатое поручение, система просто размножит шум.
Я стараюсь формулировать поручение субагенту как маленький контракт: цель, входные файлы, запреты, формат результата, критерий готовности и поведение при блокере.
Например, один исполнитель может собрать список внутренних ссылок, второй - проверить официальные источники, третий - прогнать build. Дорогой оркестратор не должен перечитывать всё заново. Он должен получить проверяемые артефакты: найдено, подтверждено, не найдено, сборка прошла или упала с такой-то причиной.
В бизнесовых AI-системах это тот же принцип, что и при проектировании ИИ-агентов для бизнеса: агент не ценен сам по себе. Ценен контур, где понятны права, входы, выходы и контроль качества.
Как я собираю экономный AI-coding процесс
Рабочий сценарий у меня обычно выглядит так.
1. Зафиксировать результат
Не «улучши проект», а «создай один файл», «измени один компонент», «подготовь PR-описание», «найди причину падения сборки». Чем конкретнее финиш, тем меньше лишних ходов.
2. Собрать минимальный контекст
Я читаю только те файлы, без которых нельзя безопасно работать: правила, профиль проекта, целевой источник, соседние примеры, схемы данных. Если контекста не хватает, добираю точечно.
3. Выбрать маршрут
Простые операции идут инструментам: поиск файлов, подсчёт символов, проверка ссылок, frontmatter, formatter, build. Рутинный черновик - дешёвому исполнителю. Архитектура, риск и финальная оценка - сильной модели. Если задача маленькая, вся агентная «бригада» не нужна.
4. Стабилизировать префикс
Повторяемые инструкции должны жить отдельно от текущей задачи: правила проекта, стиль, запреты, формат результата. Это уменьшает хаос и помогает кэшированию там, где платформа его поддерживает.
5. Делать короткие циклы
Большая генерация без промежуточной проверки дорогая. Я предпочитаю маленькие циклы: план - проверка; черновик - проверка; файл - build; замечания - точечная правка.
6. Проверять результат не той же эмоцией
Если модель написала код, нужны тесты или build. Если модель написала статью, нужны frontmatter, реальные ссылки, отсутствие технического мусора, соответствие источникам. Если модель приняла решение, нужен артефакт с причиной.
Практический чек-лист
Перед дорогим AI-запросом я прохожу такой список:
- можно ли решить задачу скриптом без LLM;
- нужна ли здесь сильная reasoning-модель или хватит простой;
- есть ли один понятный критерий готовности;
- удалён ли лишний контекст;
- вынесены ли постоянные правила в стабильный префикс;
- выбран ли effort под сложность, а не «на максимум»;
- можно ли часть работы отдать инструментам;
- есть ли проверяемый output у каждого субагента;
- заложен ли fallback при лимите, таймауте или слабом результате;
- проверяется ли финальный результат программно или отдельным review.
Этот чек-лист не делает AI-разработку бесплатной. Но он убирает самую неприятную статью расходов - токены, которые тратятся не на качество, а на неопределённость. Хорошая экономия выглядит не как урезание модели до бедного ответа, а как нормальная инженерия: меньше шума, точнее маршрут, жёстче границы, больше проверяемых артефактов.