87% времени AI-агента — простой. А самая большая оптимизация убирает ноль токенов

Команда Acefleet пять недель подряд перехватывала каждый запрос одного разработчика к Claude Code через локальный reverse proxy. Результат: 4,2 млрд промпт-токенов, $3 035 по прайсу, 90,5% — контент, который уже отправлялся ранее. Это не баг, а архитектура: cache reads составляют ~98% объёма промпта, и провайдер уже зачислил экономию 6,1× от кэширования. Но за этими числами скрывается куда менее очевидная картина — и она переворачивает почти все предположения о том, что оптимизировать в AI-агентах.

Главный враг — не токены, а вы сами

87,7% wall-clock времени сессий — это idle. Из них 233,8 часа (204 случая, по 69 минут каждый) агент провёл, удерживая pending tool call и ожидая одобрения, которое никто не давал. Ни один инструмент в стеке не скажет вам, что агент ждёт вас уже час. ACE Sidecar поднимает это как live-alarm, и для этого не нужен классификатор — факт простоя детерминирован. Разработчики маркируют это как ceiling, а не как saving, и это принципиально: транскрипт не отличит «человек вернулся бы раньше» от «ушёл надолго».

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

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

• Дедупликация повторных чтений файлов. Выглядела как очевидная цель. Оказалась стоит $0,33 за 36 дней, потому что 97,6% «повторных чтений» запрашивают другой диапазон строк и не являются дубликатами вообще. Оптимизацию выкинули.
• ttl_keepalive — крупнейший левер по стоимости (6,4%). Но он убирает ноль токенов. Это учётная мера, которая ничего не меняет в том, что видит модель.
• Триггер контекстного истощения. Команда предполагала, что проблема — rate-limit exhaustion. За 162 сессии произошло 3 ошибки rate-limit. Реальное событие — context exhaustion, и auto-compaction уже обрабатывает его в-band. Настоящий пробел — durability: compaction создаёт lossy summary, который умирает вместе с сессией. Resume brief на диске — вот чего не хватает.

Единственный левер, который команда готова включить в продакшен — Bash truncation с сохранением head+tail. Он был сначала понижен в приоритете (высокий риск: output — это сигнал, stack traces, test failures), а потом повышен. Анализ показал: 90% bash-вывода — это sed/cat-дампы, grep-сводки и git diff, которые агент просмотрел один раз и больше не открывал. Keep head+tail, exempt diagnostics — и почти всё значение сохраняется при околонулевом риске.

Почему метрика должна быть раньше оптимизатора

ACE Sidecar — это Phase 0: только наблюдение, ноль изменений трафика. Прокси релеит запросы как есть, пишет локальный SQLite, не загружает ничего наружу, не держит credentials, не авто-аппрувит tool calls (структурно не может — permission decisions не проходят через API). Dashboard читает существующие транскрипты с диска, так что вы получаете метрику по уже накопленным сессиям до первого релеинга.

День-за-днем медиана изменения объёма — −12,2% с IQR от −48% до +76%. Объём routinely halves or doubles. Это убивает целый класс алертов: любой budget, построенный на rate of change, будет срабатывать постоянно и ничего не значить. Выживает только кумулятивный cap против период-бюджета.

Вывод

Все находки — один разработчик, одна машина, 36 дней. Структура стоимости должна обобщаться, но magnitudes — конкретно этого флота. Команда явно просит второй корпус для валидации. Главный же тезис шире: инструмент измерения должен существовать раньше оптимизатора. Без него вы будете оптимизировать дедупликацию за $0,33 и пропускать 233 часа простоя, которые не видит ни один инструмент в стеке.

Источник: Hacker News - Newest: ""AI" "LLM""