Как срезать расход токенов на 90% методом Spotify в Claude Code

В начале сентября 2026 года главный продакт-менеджер Spotify Дмитрий Мазманов написал в блоге Spotify Engineering, что срезал расход токенов Claude Code на 90 процентов. За пару дней пост собрал под три сотни голосов и почти две сотни комментариев на Hacker News, и там же выяснилось, что часть цифры оказалась правдой, а часть - удобной для заголовка метрикой.

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

Если хотите получать такие разборы новых инструментов без пены и с готовыми решениями, у меня есть мой Telegram-канал «The Maslov», туда я выкладываю то, что реально проверил руками, а не пересказ чужих анонсов.

Что Spotify сделали с токенами Claude Code и почему об этом заговорил весь Hacker News

Инженер Spotify заставил Claude Code спрашивать краткий ответ у дешёвой быстрой модели вместо того, чтобы читать большие файлы целиком, и на этом сократил расход токенов на чтение. Метод оформлен как плагин Shunt и набор режимов AiKA, инфоповод вырос из поста в блоге Spotify Engineering и обсуждения на Hacker News в первых числах сентября 2026 года.

Отправная точка автора простая и знакомая каждому, кто платит за токены. Большая часть работы кодового агента - это ввод-вывод, а не рассуждение. Вот как он сам это описал.

За такое чтение и такую генерацию вы платите полными токенами дорогой модели, хотя работа там механическая. По оценкам самого автора, у четверти команд расход уже доходит до 200-500 долларов в месяц на разработчика, а у части перевалил за 2000, и к 2028 году такие расходы грозят перегнать среднюю зарплату разработчика. Отсюда и запрос снять с дорогой модели рутину, которую спокойно вытянет дешёвая.

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

Как устроен метод Shunt: хуки вместо промптов

Shunt перехватывает вызовы инструментов Claude Code раньше, чем они долетают до модели, и на больших файлах перенаправляет чтение дешёвой модели-исполнителю. Работает это через механизм хуков PreToolUse, а не через текстовую просьбу в файле проекта, и в этом вся разница.

Если написать в CLAUDE.md «читай большие файлы дешёвой моделью», в длинной сессии модель рано или поздно про это забудет или решит, что сейчас удобнее прочитать напрямую. Инструкция в промпте остаётся пожеланием. Хук ничего не просит, он механически встаёт на пути вызова и не пускает его дальше, пока условие не выполнено. Разработчики, которые сравнивали хуки с промпт-инструкциями, укладывают разницу в одну фразу.

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

Технически у Shunt два хука. Первый, check-file-size, висит на каждом вызове чтения, и если файл больше порога (по умолчанию 350 строк, порог меняется переменной окружения), хук блокирует прямое чтение и отправляет Claude за ответом к отдельному режиму-ридеру. Второй, check-bash-read, ловит попытки обойти ограничение через команды вроде cat, head и tail на тех же больших файлах. То есть лазейку «прочитаю в обход» тоже закрыли хуком, а не уговором.

Что такое режимы AiKA и почему рутину отдают Gemini Flash

AiKA - это декларативные агенты-режимы, которым задают системный промпт, модель и пару параметров, и они выполняют узкую задачу вместо дорогой модели. В демонстрации Spotify оба режима крутятся на Gemini 2.5 Flash как на дешёвой быстрой модели, но в документации прямо сказано, что модель можно поставить любую.

Режимов в связке два, и их системные промпты стоит прочитать целиком, потому что это готовый шаблон разделения труда. Режим bulk-reader отвечает за чтение и извлечение фактов.

Режим code-writer отвечает за генерацию по образцу.

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

Экономия 90 процентов - это честная цифра или маркетинг?

Цифра 90 процентов честная, но узкая. Это средняя экономия оценочных токенов чтения контекста в отдельных сценариях, а не 90 процентов от вашего итогового счёта. На реальных сессиях эффект выходит заметно скромнее, и сообщество это быстро подсветило.

Вот на чём Spotify мерил, бенчмарк гоняли на Java-монорепозитории по четырём сценариям.

Теперь возражения, ради которых пост и стоило читать. Один из участников обсуждения на Hacker News прогнал метод на своих прошлых сессиях Claude Code и получил оценочную экономию в 5-7 процентов вместо заявленных 90. Разрыв объясняется просто, потому что настоящие рабочие сессии редко состоят из чтения одного огромного файла, а Spotify тестировал сценарий, близкий к лучшему случаю для метода.

Второе возражение серьёзнее. Экономия считается на дешёвой части счёта. Входные токены (то, что модель читает) стоят примерно вчетверо дешевле выходных (то, что она генерирует), а основные деньги уходят как раз на генерацию. В обсуждении это сформулировали коротко, сэкономить 90 процентов входных токенов - это совсем не то же самое, что сэкономить 90 процентов денег. И режим-генератор code-writer, который как раз про дорогую сторону, вообще не измеряли толком, потому что сгенерированный код к дорогой модели не возвращается.

Вывод для нас простой. Цифру 90 процентов держите в голове как «лучший случай на чтении», а не как обещание счёту. Реальная экономия существует, но её размер зависит от того, сколько в вашей работе именно объёмного чтения, а не генерации.

Почему плагин Shunt нельзя просто установить

Скачать Shunt и включить у себя не получится. Плагин работает только поверх внутренней платформы Spotify (Portal на базе Backstage) и требует аутентификации к рабочему инстансу этой платформы. Репозиторий открытый, но сам инструмент рассчитан на команды, у которых корпоративная инфраструктура уже развёрнута.

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

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

Как повторить принцип без Spotify Portal в Claude Code и Cursor

Принцип воспроизводится тремя открытыми способами, это нативные субагенты Claude Code с указанием модели, прокси-роутер перед провайдерами моделей и свои хуки PreToolUse. Корпоративная платформа нужна была Spotify для их масштаба, а не самому методу.

Первый способ - нативные субагенты. В Claude Code можно завести под-агента отдельным файлом, задать ему свой системный промпт и прямо во фронтматтере указать поле модели, включая дешёвую. У Claude Code уже есть встроенный субагент-исследователь, который по умолчанию бегает на быстрой дешёвой модели для чтения и поиска. Это официальная функция, описанная в документации Anthropic, и никакой сторонней платформы для неё не требуется.

Второй способ - прокси-роутер. LiteLLM - это открытый прокси, который встаёт перед сотней провайдеров моделей и говорит с ними по единому протоколу, с учётом расходов и лимитов. Через его конфиг вы направляете конкретные типы вызовов на дешёвую модель, а важные оставляете дорогой. Есть и готовые обёртки поверх той же идеи, если не хотите поднимать прокси руками.

Третий способ - свои хуки. Механизм хуков PreToolUse в Claude Code открыт и документирован. Привязка именно к Portal CLI была решением Spotify под их хозяйство, но сам хук вы пишете как обычный скрипт. Он получает на вход описание вызова, проверяет своё условие (например, размер файла) и решает, пропустить или перенаправить. Вот минимальный каркас правила «большой файл - не читать напрямую».

На каждый вызов чтения.
  Узнать размер файла в строках.
  Если строк больше порога (скажем, 300):
     не пускать прямое чтение,
     вернуть агенту инструкцию спросить краткую выжимку у дешёвого режима-ридера.
  Иначе пропустить чтение как обычно.

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

Какие маркетинговые задачи стоит роутить на дешёвую модель

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

У меня для любого инструмента работает одно правило, и я его формулирую так, не всё на LLM, а ровно столько, сколько нужно. Где-то хватит обычного скрипта, где-то нужен классификатор, и только там, где начинается смысл, включается дорогая модель. Под это правило рутина маркетолога раскладывается почти как код у Spotify.

Что можно спокойно отдать дешёвой быстрой модели.

1. Черновая генерация по шаблону. Типовые объявления для Директа и VK по товарному фиду, первый черновик карточек для Авито, вариации заголовков для A/B по заданной формуле. Форма жёсткая, творчества ноль, идеальная работа для дешёвой модели.
2. Парсинг и классификация. Разметка входящих заявок по интенту, категоризация отзывов и комментариев, вытяжка структурированных данных из отчётов рекламных кабинетов, чистка и дедупликация списков ключевых слов.
3. Черновая обработка объёмных текстов. Суммаризация длинной переписки с клиентом, тезисы из транскрипта созвона, первичная разметка большого потока пользовательского контента перед ручной модерацией.
4. Форматирование и приведение к шаблону. Свести разнородные предложения к единому виду, разложить бриф в структуру технического задания. Это переупаковка готового, без сочинения с нуля.

Общий признак у всех четырёх пунктов один. Результат проверяем глазами за секунды, а ошибка дешёвой модели тут не стоит вам денег напрямую. Как только это перестаёт выполняться, задача уходит наверх, к дорогой модели.

Кстати, выбор модели под тексты влияет не только на кошелёк и качество. Если вы гоните контент через модели Claude для автоблога, стоит знать про встроенный водяной знак и то, как на него смотрит детектор ИИ-текста, я разбирал это в материале про водяные знаки Claude в автоблогах.

Сборка своих инструментов под задачи трафика и контента - это ровно та работа, которую я показываю в моём Telegram-канале «The Maslov». Там конкретные связки, где что подключить и как посчитать выгоду, без общих слов «попробуйте нейросети». Загляните, если хотите видеть такие сборки в деталях.

Что нельзя отдавать дешёвой модели - и почему

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

Автор Spotify сам поймал это на своём коде. Дешёвая модель-исполнитель нашла поверхностные паттерны, но пропустила тонкий баг с потокобезопасностью, который дорогая модель замечала сразу. Перенесите это на маркетинг, и картина та же, дешёвая модель пропустит тонкую смысловую или тональную ошибку в финальном тексте, которую поймает дорогая модель или живой редактор.

Вот что остаётся только на дорогой модели.

1. Стратегия и позиционирование. Здесь надо понять, почему просел CTR и что с этим делать, а не просто пересказать, что показывают цифры. Это работа на уровне интерпретации.
2. Финальная редактура и голос бренда. Дешёвая модель соберёт черновик, но последнюю правку и попадание в тон делает дорогая модель или человек.
3. Решения с деньгами. Бюджеты, ставки, отключение кампаний, здесь цена ошибки прямая, и её нельзя доверять модели, которую взяли ради дешевизны.
4. Творческие развилки. Выбор одного из трёх принципиально разных подходов к предложению - это рассуждение, ради которого дорогую модель и держат.

Если свести оба списка в одну таблицу, граница видна сразу.

Тут видна симметрия с кодом. У Spotify нельзя делегировать редактирование (у дешёвой модели нет надёжных номеров строк) и рассуждение (пропускает баги). У нас нельзя делегировать финальную правку и стратегию по тем же причинам. Граница проходит по одному вопросу, это следование паттерну или принятие решения.

Как собрать свой мини-роутер за один вечер

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

Порядок сборки такой.

1. Заведите под-агента для рутины. Отдельным файлом опишите под-агента с узким системным промптом (по образцу bulk-reader выше) и укажите ему дешёвую быструю модель. Один под-агент под чтение и извлечение, второй под генерацию по шаблону, большего на старте не нужно.
2. Напишите правило перехвата. Простой хук на операции чтения работает по логике из раздела выше. Если файл больше порога, отправляйте его под-агенту, а если меньше, читайте сами. Порог поставьте не слишком низким, иначе накладные расходы съедят экономию (об этом ниже).
3. Дайте дешёвой модели готовый промпт под вашу рутину. Промпт должен быть заточен под конкретную задачу, без абстракций. Вот рабочая заготовка под разметку входящих заявок.

Ты классификатор заявок. На вход - текст заявки с рекламы.
Определи по тексту три вещи.
1) Целевая заявка или мусор (мусор - пустой текст, набор цифр
   вместо вопроса, явный спам).
2) Если целевая - к какой услуге относится.
3) Есть ли контакт для связи.
Ответ выдай строго тремя строками (статус, услуга, контакт).
Без вступлений и пояснений.

4. Замерьте один рабочий день до и после. Возьмите типовой день работы и сравните расход и качество результата на дешёвой ветке с тем, что было на дорогой. Замеряйте конкретными числами, без оценок «вроде быстрее».

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

Какие риски и грабли ждут при роутинге моделей

Главные грабли три, это задержка на каждое делегирование, контрпродуктивность на мелких файлах и ложное чувство, что хук - это защита. Ни одна из них не отменяет метод, но каждую надо заложить в расчёт заранее.

Первое - задержка. Каждый уход к дешёвой модели стоит времени, у Spotify это 10-30 секунд на делегирование, и платформа обрывает вызов на 30 секундах сверху. Если таких уходов много и подряд, суммарное ожидание может перевесить удобство. Дешёвая модель экономит деньги, но не всегда экономит ваше время.

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

Третье - безопасность, и для нас это главное. Хук, который роутит вызовы ради экономии, не песочница и не система разрешений. Он решает, куда отправить операцию, а безопасность её не проверяет. Профильные агентства формулируют это прямо.

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

Чем это отличается от того, что Claude Code уже умеет из коробки

Сама идея «дешёвая модель на рутину, дорогая на рассуждение» не новая, и Claude Code часть этого уже умеет через встроенных субагентов с выбором модели. Новизна Shunt в принудительном хук-контроле, который нельзя обойти инструкцией, а идея роутинга сама по себе давно известна.

Сообщество на Reddit встретило новость с усмешкой, как «коллективное пожатие плечами». Многие сочли метод переупаковкой того, что агент и так делает встроенным субагентом-исследователем на дешёвой модели. В обсуждении на Hacker News сравнивали метод и со старыми инструментами, похожий подход с картой репозитория делали и раньше, а мультимодельные связки давно не редкость.

И это справедливая критика по существу. Но в ней же и польза для нас. Раз архитектурный принцип не нов и частично встроен в инструмент, значит, повторить его можно малой кровью, без корпоративной платформы. Ценность поста Spotify в том, что кто-то проговорил вслух и с цифрами то, что стоит настроить у себя, даже если само по себе это давно известный приём. Что мешает Claude Code из коробки, так это то, что встроенный выбор модели остаётся вашим решением в моменте, а хук делает его правилом.

Как понять, что экономия реальная, а не иллюзия

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

У меня для этого есть короткая рамка, я называю её «ROI, а не вау». Прежде чем оставить инструмент в работе, я прогоняю его через простую проверку. Если ваш рабочий час стоит, скажем, 2000 рублей, а сборка и наладка роутера заняли вечер, то это примерно 8000-10000 рублей вложений. Дальше считаем так. Если роутинг снимает с вас условный час рутины в неделю, то он окупится примерно за месяц-полтора, а если экономит десять минут раз в неделю, то не окупится никогда, и его место в архиве, а не в работе.

Ровно так же смотрите на токены. Возьмите свой недельный расход токенов до роутинга, включите роутинг на неделю на том же объёме задач и сравните два счёта по токенам. Если разница на вашем потоке работы - те самые 5-7 процентов, как у скептиков с Hacker News, а не 90, спокойно решите, стоит ли эта возня своих десяти минут задержки на каждом вызове.

Метод Spotify полезен даже не столько цифрой 90, сколько самой рамкой. Снимите с дорогой модели механическую рутину, закрепите это правилом вместо пожелания и оставьте дорогой модели только то, где нужен человеческий уровень рассуждения. Дальше - ваш замер и ваше решение.