Portal от Spotify режет токены нейросети Claude на 90% - работает ли трюк на моём пайплайне?

Клод - нейросеть, которая последние недели гонит мой конвейер статей раз в пару часов, и я привык, что расход токенов - это просто цифра, на которую жалуешься в конце недели. 3 сентября 2026 инженер Spotify Дмитрий Мазманов выкатил пост о плагине shunt: тот же Claude Code, но с хуками, которые не дают агенту читать большие файлы напрямую, и экономией токенов в 90% на некоторых задачах. Разобрал, как это устроено, и прогнал через свой конвейер - совпадает трюк с моей экономикой лимитов или нет.

Что такое Portal и плагин shunt от Spotify?

Portal - внутренняя платформа Spotify для запуска AI-агентов: декларативные "AiKA-режимы" поднимаются на эфемерном рантайме, как AWS Lambda, только для агентов, без своих серверов и долгоживущих ключей. Shunt - опенсорсный плагин Claude Code поверх Portal: он перехватывает дорогие операции агента и отправляет их в дешёвую модель вместо Клода.

Работает шунт не через MCP, а через три слоя прямо в Claude Code: hooks (перехватчики системных вызовов), scripts (bash-обёртки над Portal CLI) и skills (markdown с инструкцией, когда что вызывать). Схема простая - агент упирается в хук, хук вместо ошибки предлагает делегировать задачу, скрипт оборачивает файлы и стучится в Portal API.

Как shunt срезает токены Claude Code на 90%?

Хук check-file-size блокирует Read на файлах длиннее SHUNT_MIN_LINES (по умолчанию 350 строк), хук check-bash-read ловит cat/head/tail на тех же больших файлах через bash. Вместо чтения агент вызывает скрипт bulk-read, тот оборачивает нужные файлы в XML-теги и стучится в режим bulk-reader на Gemini 2.5 Flash с температурой 0.2 и инструкцией "точный аналитик кода, структурированный ответ, без воды".

На Java-монорепо это дало экономию токенов в среднем 90%, по сценариям - от 82 до 94%. Логика в том, что Клод часто читает файл целиком, чтобы ответить на один узкий вопрос по нему - а дешёвая модель с длинным контекстом справляется с "прочитай и перескажи" не хуже, просто в 10-30 раз дешевле по токену. Второй режим, code-writer, генерирует тесты и конфиги, а ещё заглушки типов по спецификации и файлу-эталону - тоже рутина, тоже не требует дорогой модели.

Настройки живут в .claude/settings.json проекта: SHUNT_MIN_LINES=350 - порог блокировки, SHUNT_MAX_PAYLOAD_BYTES=400000 - потолок размера запроса в Portal, плюс SHUNT_BULK_READER_MODE_ID и SHUNT_CODE_WRITER_MODE_ID - жёсткая привязка к конкретным AiKA-режимам, чтобы агент не выбирал модель сам. Ставится плагин командой claude plugin install shunt@portal из репозитория spotify/portal-ai-plugins (ветка add-shunt-claude, папка plugins/shunt) - то есть это не концепт из блога, а рабочий код с тестами в папке evals/.

Это разовый трюк Spotify или общий тренд для Claude Code в 2026 году?

Общий тренд, и Spotify тут не первые. С конца 2025 по начало 2026 у Anthropic вышел Tool Search Tool - механизм, который не грузит описания всех подключённых MCP-инструментов в контекст сразу, а подгружает по запросу. По разбору на Medium это срезало общий расход токенов агента на 46,9% - с 51 тысячи до 8,5 тысячи токенов на сессию.

Причина, по которой это вообще стало проблемой - у семи одновременно подключённых MCP-серверов, по замерам блога async-let.com, суммарный вес схем инструментов сжигает 67 300 токенов ещё до того, как пользователь набрал первый символ. Портал и шунт решают ту же боль с другой стороны: не тулы раздувают контекст, а результаты их работы - полные тексты файлов и логов, которые Клод получает и держит в памяти сессии до конца разговора.

Индустриальный фон в посте Spotify такой: типичные расходы на ИИ-разработку сегодня - 200-500 долларов на разработчика в месяц, у части компаний - от 2000$. Прогноз автора - к 2028 году траты на ИИ-кодинг обгонят среднюю зарплату разработчика, если экономить на токене никто не будет.

Что shunt не умеет делать?

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

Плюс к этому - задержка. Каждое делегирование - это 10-30 секунд на сетевой round-trip до Portal и обратно, так что шунт выгоден там, где агент и так ждёт (массовый анализ), но проигрывает в интерактивной правке кода, где секунды считает человек, а не бенчмарк.

Работает ли похожий трюк в моём агентском пайплайне?

Нет, впрямую не переносится - у меня конвейер статей, а не монорепа на Java, и рутины типа "прочитай 40 файлов и перескажи" там почти нет. Но принцип "хук дороже промпта" я себе выписал отдельно: инструкция агенту "экономь токены" в CLAUDE.md игнорируется в первую же напряжённую сессию, а хук, который физически блокирует операцию, - нет.

Раздавать рутину дешёвым моделям я уже пробовал на своих субагентах - Haiku и Sonnet вместо Opus там, где не нужны рассуждения, разница в цене похожая, 10 с лишним раз. А вот хуков, которые бы блокировали дорогие операции до того, как агент успеет их сделать, у меня в конвейере нет - только инструкции в скиллах, которые агент читает и иногда правда следует им.

Заглянул в свои же логи: cron/generate.log показывает, что headless-прогоны blog-draft run (topic=auto) идут с интервалом около 2 часов - 4 и 5 сентября 2026 это 12:22:56, 14:26:20, 16:07:42, 18:33:54, 20:39:46, 22:42:07 и дальше по кругу. И в каждом таком прогоне первая строчка после git-пула - Установлено скиллов: 12. То есть кеша скиллов между прогонами нет вообще: 12 markdown-файлов перечитываются заново каждые два часа, хотя между прогонами они не менялись ни разу. Деталь бесполезная как совет - её нельзя было получить, не залезав в свои же логи, но она ровно показывает то место, где принцип шунта ("не грузи то, что не изменилось") у меня самого не реализован.

Скиллы уже один раз сжирали мой недельный лимит за 4 дня, и я тогда решал это на уровне промптов, а не хуков - похоже, зря: промпт "не перечитывай то, что не менялось" в скилле никто не писал, потому что до этой статьи мне казалось, что 12 markdown-файлов - не та величина, ради которой стоит городить кеш.

Стоит ли ставить shunt на прод-пайплайн статей?

Нет - не в текущем виде. Bulk-read и code-writer заточены под код: тесты, конфиги, а ещё разбор чужой монорепы по вопросу. У меня агент почти всегда что-то придумывает или пишет живым голосом - а это ровно то, что авторы shunt прямо помечают как "не делегируется" (рассуждение, а не пересказ). Ставить чужой плагин ради задачи, которой у меня нет, - плодить зависимость без выгоды: ещё один API-ключ, ещё один пункт в мониторинге, ещё один способ конвейеру упасть в 4 утра, когда я сплю.

Из полезного - сама идея хука-цензора выглядит переносимой без установки чужого кода: у Claude Code давно есть PreToolUse-хуки, и заблокировать по имени операции что-то дорогое можно своими руками, без Portal и без чужой инфраструктуры. Разница только в том, что у меня блокировать пока особо нечего - конвейер статей не читает по 40 файлов на вопрос, он держит в контексте пачку скиллов и факт-лист на один черновик.

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

Актуальность у темы, кстати, не абстрактная: с 14 сентября 2026 Anthropic и так режет лимиты Claude Code на 17% - значит любая экономия токена, которая раньше была "приятным бонусом", с середины сентября станет вопросом, влезает пайплайн в неделю или нет.

Что в итоге

Правда ли Portal от Spotify срезал токены Claude Code на 90%? Да, но именно на задачах "прочитать много и пересказать" - экономия 82-94% (в среднем 90%) достигается за счёт хуков, которые физически не дают агенту прочитать большой файл напрямую, и делегирования дешёвой модели вместо Клода. На редактирование и рассуждение трюк не переносится - авторы сами это признают.

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

Забавно, что этот же критерий сработал прямо во время написания этой статьи: часть исследования - поиск по вебу и разбор страницы Spotify - конвейер делает инструментами, схемы которых подгружаются по запросу, а не висят в контексте с самого начала сессии. То есть тот же принцип "не грузи описание того, чем не пользуешься сейчас", про который пишет Anthropic в Tool Search Tool, уже часть моей собственной обвязки - я просто не называл это так, пока не прочитал пост Spotify. И вот это уже не история Spotify, а моя собственная - и её ещё предстоит докрутить.