Смотрящий за ИИ: как Codex заставил Гермеса меньше жрать токены

У меня есть ИИ-агент по имени Гермес.

Но сам по себе он никогда не жил. С самого начала за ним присматривает Codex.

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

Вот сервер. Подготовь его, поставь Docker, разверни Гермеса, настрой и доведи до рабочего состояния.

Codex установил нужное окружение, поднял Hermes в Docker, настроил конфиги и дальше остался его техническим смотрящим.

Схема получилась примерно такая:

Гермес занимается работой.

Codex обслуживает самого Гермеса.

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

В общем, смотрящий у Гермеса появился практически одновременно с самим Гермесом.

И недавно у него возникла новая задача.

Гермес стал слишком много есть.

Токенов.

Гермес работает автономно. Получает задания, читает файлы, запускает инструменты, обслуживает несколько процессов, выполняет cron-задачи.

Какое-то время значительная часть всего этого работала на GPT-5.5.

Потом я начал замечать, что расход токенов выглядит подозрительно бодро.

GPT-5.5, reasoning, история диалогов, skills, результаты инструментов, длинные агентные циклы. По отдельности ничего страшного. Но в сумме получался ИИ, который пошёл на кухню проверить молоко и заодно съел холодильник.

Я дал Codex задачу:

Посмотри, куда Hermes тратит токены. Не надо просто ставить более дешёвую модель. Сначала найди причины перерасхода, потом оптимизируй без заметной потери качества.

И хорошо, что задача была сформулирована именно так.

Потому что модель оказалась далеко не единственной проблемой.

Первым делом Codex посмотрел, что Гермес вообще таскает за собой в контексте.

Там быстро нашёлся хороший кандидат.

У одного проекта был большой рабочий skill с инструкциями, правилами и накопленной документацией.

Размер:

84 190 байт.

Большой файл сам по себе не проблема. Проблема в том, что большая часть его содержимого не нужна при каждом действии.

Но если агент читает skill целиком, модель получает всё.

Codex переработал рабочую инструкцию.

Было:

84 190 байт

Стало:

11 089 байт

Сокращение примерно на 87%.

Старую версию никто не удалял, она осталась в архиве. В рабочем контексте теперь лежит только то, что действительно нужно постоянно.

Мне понравилась эта идея. Гермесу не запретили пользоваться библиотекой. Просто перестали заставлять его каждый раз приносить библиотеку с собой.

Следующая находка была ещё веселее.

У одного из процессов есть очередь заданий. Состояние хранится в JSON.

Размер файла около 108 224 символов.

Гермес периодически читал его целиком.

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

Получалась примерно такая архитектура:

Есть JSON на 108 тысяч символов. Нужно получить из него четыре значения. Отправляем весь JSON нейросети.

Работает? Да.

Разумно? Не очень.

Codex написал небольшой helper, который сам читает файл и отдаёт Гермесу короткую сводку.

Было около 108 КБ.

Стало 339 байт.

Разница более чем в 300 раз.

Причём здесь вообще нет компромисса по качеству. LLM просто перестала выполнять работу, с которой обычный Python справляется лучше.

Наверное, это один из самых простых способов сэкономить токены в агентной системе: сначала проверить, не используется ли нейросеть вместо json.loads().

Потом Codex добрался до выбора моделей.

Часть рутинных задач работала на:

GPT-5.5 reasoning = medium

Для сложной задачи это нормально.

Но у Гермеса хватает работы уровня:

Проверь очередь.

Посмотри состояние процесса.

Убедись, что операция закончилась.

Выполни стандартную процедуру.

Использовать для этого GPT-5.5 можно. Она точно справится.

Но это примерно как вызвать старшего инженера, чтобы узнать, горит ли зелёная лампочка.

Codex настроил маршрутизацию.

Для обычной рутины теперь используется:

GPT-5.4-mini reasoning = low

GPT-5.5 осталась для задач, где действительно нужны сложное рассуждение или более высокое качество результата.

Это, кстати, важный момент.

Можно было просто перевести всего Гермеса на mini и объявить победу над расходами. Но тогда через пару дней вполне мог появиться другой материал:

«Как я сэкономил на токенах и сломал себе агента».

Поэтому сейчас логика простая:

Ничего революционного. Просто не каждая задача должна попадать к самому дорогому специалисту.

Самая интересная часть началась с агентных циклов.

В старых логах нашлись задания, которые доходили до 80-130 API-вызовов.

Это уже особая черта автономных агентов.

Он может выполнить задачу, получить нормальный результат, а потом решить:

Надо проверить.

Проверяет.

Потом:

Неплохо. Но неплохо бы проверить ещё одним способом.

Проверяет.

Потом:

Теперь стоит убедиться, что вторая проверка не противоречит первой.

И где-то рядом тихо заканчиваются лимиты.

Codex добавил ограничения:

Сейчас общий max turns установлен в 40.

Не потому, что хорошая задача должна делать 40 шагов.

Скорее наоборот. Если агент дошёл до сорокового, пора задуматься, не занимается ли он уже исследованием самого себя.

У обычного чат-бота всё довольно понятно:

У агента цепочка длиннее:

И вот здесь легко спрятать ещё один большой расход.

Инструмент может вернуть HTML, большой JSON, длинный лог или содержимое файла. Потом всё это снова попадает в модель.

Даже если ей нужны три строки из пятидесяти тысяч символов.

Поэтому Codex ограничил размер чтения файлов и tool output.

Тут важно не переборщить. Просто отрезать всё после условных 20 КБ тоже плохая идея. Нужная строка вполне может оказаться чуть дальше.

Нормальная схема выглядит примерно так:

Задача не в том, чтобы Гермес видел как можно меньше.

Надо, чтобы он как можно реже видел то, что ему вообще не нужно.

После изменений Codex не ограничился сообщением «оптимизация выполнена».

Он мягко перезапустил gateway и проверил систему.

Health check прошёл, подключения поднялись.

Потом была запущена небольшая read-only задача.

Результат:

API calls: 3 input: 22 726 tokens cache read: 38 400 output: 411 reasoning: 271 model: GPT-5.4-mini

Больше всего здесь мне понравились 3 API calls.

Раньше отдельные старые задания могли разрастаться до 80-130 вызовов.

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

Но по крайней мере понятно, в какую сторону всё поехало.

Во время этой истории обнаружилась ещё одна полезная вещь.

Для агента не очень интересно знать, сколько токенов ушло на один API-вызов.

Допустим, одна модель использует 10 тысяч токенов и решает задачу за три вызова.

Другая использует по 3 тысячи, но делает пятнадцать вызовов.

Если смотреть только на один запрос, вторая кажется экономнее.

Если посчитать всю задачу, уже не факт.

Поэтому правильная единица измерения для меня теперь такая:

одна законченная задача.

Для неё уже можно смотреть:

task model API calls input tokens cached tokens output tokens reasoning tokens total

Codex заодно добавил отдельный usage-report.

То есть теперь вместо:

Мне кажется, Гермес опять что-то много ест.

можно открыть отчёт и посмотреть.

Как в нормальной бухгалтерии.

Только вместо суточных и бензина там reasoning tokens.

Часть повторяющегося входного контекста API может кэшировать.

Это полезно, особенно для больших стабильных инструкций.

Но я бы не использовал caching как оправдание, чтобы продолжать отправлять всё подряд.

Логика сейчас у меня такая.

Сначала убрать лишнее.

Потом вынести простую обработку в обычный код.

Потом сократить большие tool results.

Потом научить агента сворачивать старую историю.

Потом подобрать модели под разные задачи.

И уже после этого смотреть, насколько хорошо кэшируется то, что осталось.

Потому что самый дешёвый лишний токен не тот, который попал в cache.

Самый дешёвый лишний токен тот, который вообще не отправили.

Самое интересное здесь, пожалуй, сама схема работы.

Codex с самого начала не использовался как чат, куда я копирую ошибку Гермеса и прошу написать пять строк Python.

Он получил в работу сам проект.

Надо было подготовить сервер, подготовил.

Надо было поставить Docker, поставил.

Надо было развернуть Hermes, развернул.

Появлялись проблемы, смотрел конфиги и логи.

Нужны были служебные скрипты, писал.

Теперь появилась проблема с расходом токенов, он прошёлся по архитектуре и нашёл, где агент расходует контекст впустую.

В итоге получилась довольно забавная иерархия:

Codex не занимается ежедневной работой Гермеса.

Гермес не администрирует собственный сервер.

У каждого своя роль.

Получился маленький отдел из двух ИИ-сотрудников.

Один работает.

Другой следит, чтобы первый нормально работал.

Пока профсоюза у них нет.

Из этой оптимизации я вынес несколько довольно простых вещей.

Дорогой агент не обязательно дорогой из-за модели. Можно поставить дешёвую модель и двадцать раз подряд кормить её огромным JSON.

LLM не обязательно должна делать всё. Если задачу можно решить пятью строками Python, скорее всего, лучше решить её пятью строками Python.

Большое контекстное окно не означает, что его надо обязательно заполнить.

Автономному агенту нужны ограничения. Иначе он иногда продолжает исследовать уже решённую задачу просто потому, что может.

И разные задачи действительно стоит отдавать разным моделям.

Но главный вывод для меня другой.

ИИ-агент довольно быстро превращается в обычный программный проект.

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

За всем этим приходится следить.

И теперь часть этой работы тоже можно отдать ИИ.

Недавно сама формулировка задачи ещё звучала бы довольно странно:

Codex, посмотри, почему Hermes слишком много тратит токенов, и оптимизируй его.

Но именно это и произошло.

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

Мне осталось сформулировать проблему и прочитать отчёт.

Похоже, агентные системы постепенно будут двигаться именно сюда.

Не один огромный универсальный ИИ, который пытается делать вообще всё.

Скорее несколько уровней:

Теперь осталось только следить, чтобы сам Codex не начал слишком много есть.

А то смотрящий тоже человек.

Ну, почти.