Databricks выложила свою математику расходов на кодинг-агентов: минус 50% токенов от тюнинга харнесса, а Opus 5 вышел дороже Opus 4.8

Патрик Вендел, соучредитель Databricks, вместе с четырьмя коллегами выложил 7 августа то, что обычно не выкладывают: внутреннюю математику расходов на агентный кодинг. Не «AI повышает продуктивность», а сколько это стоит, какие рычаги работают и на сколько процентов.

TL;DR: Databricks описала четыре рычага снижения расходов на кодинг-агентов. Тюнинг харнесса и кеша дал почти минус 50% сгенерированных токенов без потери качества, роутер между моделями срезает больше 30% средней стоимости задачи. Самый неприятный факт в статье: Stripe отказалась выдавать разработчикам Opus 4.7, потому что качество не выросло, а цена выросла, а сама Databricks увидела то же самое при сравнении Opus 5 с Opus 4.8.

Почему счёт за агентного кодера растёт быстрее пользы

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

Databricks формулирует это прямо: расходы определяются контекстом, который пользователь не просил. Отсюда и вывод, что «экспоненциально растущие косты» упёрлись почти во все компании, которые раскатали агентов на весь инженерный штат. Внутри Databricks агентный кодинг при этом улучшил все метрики скорости, которые они мерят, а у отдельных команд поднял выход на порядок. Так что это не история про «AI не работает». Это история про то, что счёт приходит отдельно от пользы.

Что даёт больше всего экономии

Переход на более эффективные модели по мере их выхода. Это, по Databricks, самый крупный рычаг, и он же самый неочевидный, потому что «дешёвая модель» и «модель, которая проходит твой порог качества» связаны нелинейно.

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

И теперь самое интересное: результаты часто отрицательные. Stripe проверила Opus 4.7 против Opus 4.6, не увидела значимого прироста качества, увидела рост цены и решила вообще не давать 4.7 разработчикам. Databricks пишет, что видела похожие регрессии по стоимости, сравнивая Opus 5 с Opus 4.8. Два разных инженерных отдела независимо пришли к тому, что новая версия флагмана обошлась дороже без выигрыша на их задачах.

Это ровно тот замер, которого не хватало после релиза Opus 5. Мы писали про независимые прогоны Opus 5 на Vending-Bench и про сравнение с Kimi K3, но там мерили интеллект. Databricks мерит счёт.

Отдельный вывод: если самый большой выигрыш в смене модели, то главным свойством инструмента становится независимость от модели. Харнесс обычно приколочен к одной модели, поэтому компании либо выдают разработчикам набор харнессов (Claude Code, Codex, Cursor) и просят переключаться, либо ставят мета-харнесс. У Databricks второй вариант, через открытый Omnigent.

Сколько экономит роутинг между моделями

По внутренним данным Databricks, Smart Router в их AI Gateway стабильно снижает среднюю стоимость задачи больше чем на 30%, примерно сохраняя качество самой дорогой модели в наборе. Другие компании, с которыми они говорили, называют похожие цифры.

Роутинг у них разложен на три уровня, и разница между ними практическая. Роутинг на уровне запроса ставит stateful-прокси между харнессом и моделями и отправляет каждый запрос в самую дешёвую модель, которая его вытянет: так работают Cursor Router, AutoRouter у OpenRouter, Router у Ramp и Smart Routing в Unity AI Gateway. Роутинг на уровне задачи живёт в клиенте: мета-харнесс смотрит на сложность задачи и целиком отдаёт её нужному уровню модели. Третий вариант, эскалация, держит внутри одного харнесса пару «дорогая умная плюс дешёвый работник».

Откуда берутся токены, которые ты не просил

Из болтливости харнесса и настроек кеша, и это единственный рычаг, который ничего не стоит включить. Databricks говорит, что относительно простой тюнинг харнесса и кеширования дал почти минус 50% сгенерированных токенов без замеченной деградации качества у разработчиков. В подписи к их графику формулировка ещё конкретнее: убрали лишние вызовы инференса и сократили запись в кеш.

Три подхода, которые они перечисляют: чаще принудительно компактить активный контекст, брать менее болтливые харнессы или подкручивать имеющиеся, и аудировать verbosity популярных тулов. Последнее очень созвучно тому, что мы разбирали на DeepSeek V4 Flash: дешёвый токен перестаёт быть дешёвым, если модель или тул генерит их в десять раз больше.

Как ограничивать расход, не отключая людей

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

Всё это Databricks сводит в один архитектурный шаблон, который называет AI Gateway: прокси и управление мощностями, учёт и принуждение бюджетов, управление конфигами конечных инструментов (allow-list моделей, настройки компакции) и логирование трейсов сессий для последующего анализа. Свою реализацию, Unity AI Gateway, они сделали общедоступной.

Подводные камни

Свой бенчмарк это проект, а не выходные. Databricks мерит на кодовой базе в миллионы строк, у Stripe вывод по Opus 4.7 отрицательный, и оба результата получены на своих задачах. Без такого замера ты покупаешь вендорскую табличку, а она про другое.

Минус 30% от роутера это средняя стоимость задачи на их трафике и их наборе моделей. Формулировка «примерно совпадает с качеством самой дорогой модели» гарантией не является. На небольшом трафике stateful-прокси добавит латентность и ещё одну точку отказа, а сэкономит меньше, чем стоит его поддержка.

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

Мета-харнесс лечит лок-ин на модель и добавляет лок-ин на диспетчер. Ты перестаёшь зависеть от того, кто держит веса, и начинаешь зависеть от того, кто держит маршрутизацию задач. Для Databricks это свой открытый Omnigent, для тебя это ещё один сервис в критическом пути.

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

Альтернативы

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

Cursor Router. Роутинг внутри одного продукта: настраивать нечего, но и выбор моделей не твой, а значит главный рычаг экономии остаётся у вендора.

Unity AI Gateway плюс Omnigent. То, что Databricks открыла: максимум контроля и единая точка учёта, но это инфраструктура, которую кто-то в компании должен держать и обновлять.

Лимиты на стороне вендора. Самый дешёвый вход: Claude Code с версии 2.1.225 умеет показывать лимит расхода, полученный от гейтвея, вместе с временем сброса. Работает без своей платформы, но и рычагов даёт ровно столько, сколько дал вендор.

Вердикт

Если у тебя меньше десяти разработчиков, начинай с четвёртого рычага. Аудит verbosity, настройки кеша и компакции ничего не стоят и дали Databricks почти половину токенов, а роутер с гейтвеем при таком масштабе съест на поддержку больше, чем сэкономит. Если счёт за агентов уже виден в отчёте о прибылях, тогда гейтвей и роутинг оправданы, но начинать всё равно стоит с замера на своей кодовой базе.

И перепроверь свою «самую умную» модель. Две компании из этой статьи независимо обнаружили, что новая версия флагмана обошлась им дороже старой без выигрыша в качестве. Дефолт «всегда бери свежий Opus» перестал быть бесплатным решением.

Как попробовать

1. Посмотри, сколько токенов твой харнесс генерит на типовую задачу. В Claude Code это /cost и /context, в Codex CLI расход видно в статусной строке сессии.
2. Проверь настройки кеша и компакции: у Databricks именно эта пара дала почти минус 50% токенов. Начни с того, чтобы не переписывать кеш на каждом ходу.
3. Прогони две модели на пяти реальных задачах из своего репозитория, а не на бенчмарке. Считай не только качество, но и токены на задачу.
4. Если моделей больше одной, попробуй роутинг: AutoRouter в OpenRouter заводится без инфраструктуры, а Unity AI Gateway и Omnigent дают полный контроль ценой поддержки.
5. Прочитай исходную статью Databricks целиком: там есть детали по спенд-гейтам и скриншот их дашборда расходов.