benjamin-plus — скилл экономии токенов для AI-агентов от JetBrains

Стоимость работы кодинг-агента почти никогда не определяется тем, сколько он реально «думает». Основной источник расходов — то, как много шагов он делает и какого размера куски контекста после каждого шага перечитывает вся сессия. Каждый запрос к модели отправляет ей весь диалог целиком: счёт идёт в формулу «шаги × контекст», а не в число слов. JetBrains выпустил скилл benjamin-plus, который атакует именно эту формулу.

Это однофайловый ruleset для кодинг-агентов, который меняет как агент смотрит на код и как ждёт, но никогда не меняет то, что он строит. Результаты заявлены измеримыми: до −18% стоимости и −22% токенов на задачу при неизменном качестве — причём цифры получены не «на глазок», а парным A/B-экспериментом (Wilcoxon на парных дельтах, 80 парных задач SkillsBench). Главный сюрприз: скилл экономит только в режиме инъекции в промпт, а в виде «устанавливаемого» skills-каталога не экономит ничего. Лицензия — MIT. Репозиторий: github.com/JetBrains/benjamin-plus-skill.

Откуда взялся скилл

Название отсылает к Бенджамину Франклину и его цитате с маскота-белки Бенджи: «Beware of little expenses; a small leak will sink a great ship» — «Остерегайся малых расходов: маленькая течь потопит большой корабль». Течь в контексте агентов — это 20 лишних токенов на незаметный шаг, которые потом многократно умножаются на каждое перечитывание разросшегося диалога.

Скилл создан не «один раз написали и выложили», а через auto research: агент в цикле гонялся против бенчмарка. Авторы выделили из ~1 200 старых агентских трейсов, куда реально уходят деньги, сформулировали правила, прогнали парный A/B, разобрали провальные траектории, переписали и прогнали снова. Всего шесть версий; остались только те правила, которые пережили проверку данными. Всё, что торговало качеством ради экономии, было удалено — а таких «умных» идей оказалось большинство.

Пять правил скилла

Агент платит за каждый неуклюжий поиск дважды: один раз за сам шаг и второй — когда весь выросший диалог перечитывается моделью. Правила нацелены именно на это.

1. Разведка за один проход (Recon in one pass)

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

echo == layout ==; ls -la; echo == deps ==; head -30 requirements.txt

или несколько tool-call'ов в одном сообщении. Второй раунд поиска допустим только для вопросов, которые породили ответы первого. А перед копированием формата или конвенции (DSL, схема, формат файла) — смотреть два реальных примера, а не один.

2. Keyhole-чтения (Look through a keyhole)

Когда агенту нужно что-то лишь увидеть — он читает 50 строк, а не весь файл. Ограничители команд: | head -50, | tail -20, grep -m 20, wc -l перед чтением содержимого, Read с offset/limit. Если размер неизвестен — сначала мерить, потом читать нужный срез.

Принципиальная оговорка: атрибуты keyhole применяются только к инспекции, никогда к загрузке данных. Файл читается целиком только когда его собираешься редактировать или копировать из него дословно — обрезать данные, которые будешь трансформировать, нельзя, это испортит результат. Если заглянул слишком узко — делаешь ровно один более широкий просмотр.

3. Одна проверка окружения (Probe the environment once)

Перед запуском кода с несколькими зависимостями — проверить их одним зондом, а не открывать по одному трейсбеку на каждую:

python3 -c "import x, y, z"
command -v tool1 tool2

и установить всё недостающее одной командой.

4. Зелёный = проверка задачи (Green means the task's own check)

Если в задаче названы команды верификации — это и есть определение «готово». Запускать их максимально дословно, а зелёный означает exit status ноль. Провал, который агент считает «экологическим» (нет пакета, компилятора или утилиты) — всё равно его провал: починить окружение и перезапустить; фраза «не связано с моим изменением» — это не зелёный чек.

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

5. Поллинг — это шаг (Polling is a step)

Запущенная команда, которая ещё не завершилась, — это не новая информация, но каждая проверка статуса перечитывает весь диалог. Если харнесс возвращает управление, пока команда ещё работает — ждать крупными интервалами: 30+ секунд, а для сборок и тестовых прогонов — минуты, прежде чем проверять снова. Никаких реполлингов раз в секунду, никакого пустого ввода «просто посмотреть». Там, где выполнение блокируется до завершения (стандартное поведение), правило не стоит ничего.

Что важно, но не входит в пять правил

Скилл явно запрещает строить то, что задача не просила:

Never build a verification harness, test suite, or checker the task didn't ask for — verify stated properties with the shortest command that measures them.

То есть не придумывать себе полигон для проверок, если его не было в задании; проверять заявленные свойства самой короткой командой, которая их измеряет, а сэкономленные шаги тратить на саму задачу. И главный предохранитель: если экономия шага рискует привести к неверному результату — шаг тратится, потому что эффективность никогда не главнее корректности, проваленного чека или того, что задача явно просит произвести.

Как экономия измерялась

Это парный A/B, а не «посмотрите на косметическую метрику». Одна и та же модель, одни и те же задачи, одни и те же container-образы; единственная разница между рукавами — инъецированный текст скилла. Методика:

• 80 парных задач SkillsBench (Claude Code 2.1.201 в Docker-песочницах, Sonnet 5, low effort);
• Wilcoxon по парным дельтам стоимости, знаковый тест на наградах верификатора;
• контроль доставки: инъекция дошла до модели в 80 из 80 обработанных прогонов и в 0 из 80 контрольных;
• прогоны, упавшие только с одной стороны, перезапускались до подсчёта.

Каждая цифра и каждая оговорка задокументированы в EXPECTED-RESULTS.md в репозитории. Все версии правил, которые торговали качеством ради цифр, были отсеяны в процессе — авторы прямо пишут, что «большинство умных идей» на это и пошли.

Чего ожидать по цифрам

• Качество неизменно. 7 лучше / 5 хуже / 68 ничьих (знаковый тест p = 0.77); средняя награда верификатора 0.362 → 0.392. Эксперимент не был заточен под проверку эквивалентности как таковой: крупные эффекты исключены, малые не исключены.
• Экономия масштабируется от «раздутости» базлайна. Идентичный прогон днём раньше показал −10.0% медианной стоимости против более «стройного» базового прогона; обработанная группа оставалась плоской оба дня, пока контроль дрейфовал на +10.5%. Реалистичный ожидаемый диапазон — примерно −10%…−18% стоимости в зависимости от того, насколько раздуты у вас сессии.
• Кросс-платформенность. На Java SWE-bench (Codex CLI, gpt-5.6-luna, 675 парных реплик) тот же скилл, инъецированный через хук, дал −4.4% стоимости [−7.5, −1.5], p = 0.003, при неизменной solve rate (p = 0.22) и −20% tool-call'ов.
• Медианы — честная единица измерения: пара тяжелых хвостовых задач может отдать часть агрегированного эффекта обратно.

Инъецировать, а не «устанавливать»

Ключевой практический вывод исследования: один и тот же скилл, доставленный двумя способами, даёт разные результаты. В режиме инъекции — экономит (−17.9% медианной стоимости на графиках выше; −4.4% даже на более сложной Java/Codex-схеме). В виде discoverable skills-папки — не экономит ничего (−0.5%, статистически незначимо): агенты сжигали шаги просто на то, чтобы найти SKILL.md. Вывод авторов: инъецировать, не устанавливать.

Клонирование:

git clone https://github.com/JetBrains/benjamin-plus-skill ~/.benjamin-plus

Интеграция — три коротких рецепта.

Claude Code — добавить в ~/.claude/settings.json (проверить через /hooks):

{ "hooks": { "SessionStart": [ { "matcher": "startup|resume|clear|compact",
  "hooks": [ { "type": "command", "command": "cat ~/.benjamin-plus/injected-instruction.md" } ] } ] } }

или по-проектно, без конфигурации: cat ~/.benjamin-plus/injected-instruction.md >> CLAUDE.md.

Codex CLI — AGENTS.md грузится в каждую сессию, хук не нужен:

cat ~/.benjamin-plus/injected-instruction.md >> ~/.codex/AGENTS.md   # или >> AGENTS.md в репозитории

Любой другой агент — дописать injected-instruction.md к системному промпту. Это вся интеграция — около 3 КБ. Для сравнения, полный текст скилла в RULESET.md — около 745 токенов на инъекцию.

Практические выводы

benjamin-plus интересен сразу по нескольким причинам. Во-первых, это редкий пример скилла, который прошёл настоящую экспериментальную валидацию: два независимых бенчмарка, парный дизайн, контроль доставки текста до модели, честные оговорки о границах (знаковый тест не эквивалентен тесту эквивалентности). Во-вторых, он руками JetBrains подтверждает общий для экосистемы вывод: агентные скиллы экономят, когда попадают в системный промпт, и теряются, когда их надо искать. В-третьих, сами правила легко переносимы в любой проект — их можно применять вручную через CLAUDE.md / AGENTS.md без установки чего-либо.

Пять привычек — разведка за один проход, keyhole-чтения для инспекции, единый зонд окружения, «зелёный = свой чек задачи» и редкий поллинг — это не магия, а дисциплина измерения. Экономия в −10…−18% стоимости при неизменном качестве выглядит как разумный ориентир для тех, кто уже платит за длинные агентные сессии и хочет контролировать, куда уходят токены. Главное — не забыть, что эффективность правил живёт в инъекции, а не в каталоге навыков.