Экономия токенов как транспортная задача

Считать нужно всю траекторию агента

Я бы считал не токены одного запроса, а ожидаемую стоимость всей траектории агента. В исходном обсуждении пользователь 1497575255 сравнил минимизацию токенов с транспортной задачей: результат должен попасть из точки А в точку Б при минимальном расходе ресурса. Это точнее, чем привычное «сделаем промпт покороче».

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

На уровне пайплайна переменных становится больше:

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

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

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

Точную длину входа обычно можно получить до отправки запроса. С выходом сложнее: нужен прогноз по классу задачи и модели, причем для агента надо учитывать вероятность дополнительных шагов. На 6 ноября 2026 года перед нами не новость о конкретном релизе, а полезная инженерная постановка проблемы.

Экономия начинается не с дешевой модели

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

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

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

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

Ранее мы разбирали, как конфигурации Claude Opus 4.6, расширенное рассуждение и длина контекста влияют на стоимость запросов. Это дополняет взгляд на токен-оптимизацию как на распределение ограниченного бюджета между частями контекста.