Claude Code урезал счёт за тикет примерно до пятой части

Как сообщается в блоге Claude, Anthropic дала Claude Code подбирать настройки приложения поддержки. В итоге расход упал с 4,6 цента примерно до цента за тикет, а точность на тикетах, которых оптимизатор не видел, выросла с 78,6% до 90,5%. Результат получила команда /claude-api hillclimb, а сам eval для неё собирает вторая команда, /claude-api build-eval.

Коротко

• В навыке claude-api появились две команды: /claude-api build-eval собирает eval прямо в вашей кодовой базе, а /claude-api hillclimb улучшает приложение по этому eval, внося одно изменение за раунд.
• От самообмана защищает отложенная выборка: патч остаётся, только если растут и обучающие, и тестовые примеры, а если растёт одна обучающая часть, Claude считает это переобучением и откатывает патч.
• Оба примера в статье получены на внутренних наборах Anthropic: бенчмарк поддержки насчитывает 44 тикета, из них отложено 14, а доверительные интервалы для итоговых цифр в тексте не приводятся.

Если вы не следили: по данным Flowtivity, навык claude-api распространяется как открытая установка из репозитория навыков Anthropic на GitHub. Explainx пишет, что уже рассказывал о hillclimb как об инструменте поиска дешёвой конфигурации в материале «Claude Platform cost and effort». По данным того же Explainx, новую статью написал Лэнс Мартин, а на claude.dev она вышла 28 сентября 2026 года.

Лучшая модель на максимальном effort должна набирать заметно меньше 100%

Первая половина статьи объясняет, каким должен быть eval, то есть набор задач с автоматической оценкой. Anthropic называет четыре признака. Во-первых, задачи повторяют реальное использование, а удобство генерации или проверки для отбора не годится. Во-вторых, более сильная модель и больший effort должны набирать больше, иначе виноваты двусмысленные задачи или сбитый грейдер.

Третий признак касается запаса: лучшая модель на максимальном effort должна набирать заметно меньше 100%, причём разрыв нельзя объяснять невыполнимыми задачами. Хорошая задача та, по которой два эксперта вынесут одинаковый вердикт. Четвёртый признак: низкий разброс между прогонами. Его портят и неоднозначные задачи, и окружение, где файл или git-история от прошлого прогона подсказывают агенту ответ.

Отдельно Anthropic предостерегает от отбора случаев только потому, что на них ошибается сегодняшняя модель. Такой eval начинает мерить провалы конкретной модели вместо того, что действительно трудно для вашего приложения. Трудный случай стоит брать, если человек может заранее объяснить, почему он трудный. Пользовательскому трафику тоже не стоит слепо доверять: люди пробуют то, что, по их ожиданиям, сработает.

build-eval начинает с продакшен-транскриптов и только потом берёт синтетику

Команда /claude-api build-eval сначала расспрашивает вас, затем собирает eval в кодовой базе и в нескольких точках ждёт одобрения. Примеры она берёт в таком порядке: продакшен-транскрипты (после вопросов о хранении и чувствительных данных), баг-репорты и тикеты, от пяти до десяти случаев, написанных вручную, и синтетика на основе кода. Все входы Claude показывает на простой странице.

Грейдер Claude предлагает самый дешёвый из подходящих. Для ограниченного вывода это проверка кодом: точное совпадение, метка из списка, JSON по схеме, тесты. Для открытого вывода по умолчанию берётся LLM-as-judge: вторая модель, отличная от тестируемой, сверяет ответ с рубрикой из проверяемых утверждений вместо шкалы от 1 до 5.

Затем Claude оценивает несколько случаев и спрашивает, поставили бы вы другую оценку. На базовом прогоне он дважды запускает грейдер на одном выводе, ищет таймауты и обрезанные ответы и предупреждает, если база уже около 95% или выше. На выходе остаются случаи, грейдер, раннер, транскрипты и страница с баллами.

Sonnet 5 на низком effort обошёл исходный Opus 4.8 примерно за пятую часть цены

Внутренний бенчмарк поддержки состоял из 44 тикетов: на 30 шёл поиск, 14 отложили. Старт: Opus 4.8 на высоком effort по умолчанию, 74,4% точности решений на поисковых тикетах и 4,6 цента за тикет. Сначала hillclimb почистил промпт от обязательных ритуальных вызовов инструментов, шага с черновиком и противоречивых правил. Opus 5.5 на низком effort дал 87,8% и 1,9 цента за тикет.

Часть экономии дала цена: у Opus 5.5 входные и выходные токены на 20% дешевле, чем у Opus 4.8, а чтение из кэша дешевле на 60%. Затем оптимизатор спустился на ступень ниже: Sonnet 5 на низком effort набрал 88,9% примерно за цент. Правила маршрутизации и перекрёстная ссылка на лимит возвратов подняли Sonnet 5 до 98,9% при той же цене.

Главная цифра получена на 14 отложенных тикетах, которых поиск ни разу не видел. Там итоговая настройка набрала 90,5% против 78,6% у исходной, примерно за пятую часть стоимости.

Навык claude-api поднялся с 66% примерно до 88%

Во втором примере улучшали сам навык claude-api на eval, собранном из документации Anthropic. Старт был 66%. С доступом к документации и SDK оптимизатор нашёл восемь неописанных функций, и разделы о них дали 74%. Исправленные таблицы типов для C# и Java подняли результат до 77%. По данным Explainx, всего прогон занял 24 раунда.

После двух раундов застоя Claude разложил оставшиеся провалы по причинам. Оказалось, что нужный текст в навыке есть, но Claude по памяти пишет устаревшие формы API, например extended thinking с фиксированным бюджетом токенов, который API отвергает на свежих моделях Opus. Таблица соответствия старых форм новым в начале навыка подняла результат до 80%.

Остальной прирост дали правки самого eval. Одна задача просила ловить один тип ошибки, а её грейдер требовал цепочку минимум из трёх, и Claude переписал задачу. Инструкции другого грейдера противоречили документации, и проверка на реальном API подтвердила документацию. Вместе с новыми правками навыка результат вырос примерно до 88%.

Как hillclimb решает, оставить патч или откатить

Перед стартом Claude спрашивает цель (качество или цену при сохранении качества) и что ему можно менять: системный промпт, навыки, описания инструментов, модель, effort, другие параметры API и код обвязки. Затем набор случайно делится на обучающую и тестовую части, и Claude проверяет, что шум eval меньше самого маленького улучшения, ради которого вы стали бы что-то менять.

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

Если балл не растёт два или три раунда, Claude разбирает оставшиеся провалы и отсеивает двусмысленные случаи, ошибки обвязки и случайный разброс. В конце код остаётся в версии, лучшей на тестовой части, а отчёт сравнивает её с базой с доверительными интервалами. Если прирост в пределах шума, Claude советует не мёржить.

Оба примера построены на внутренних наборах Anthropic, а отложенная часть бенчмарка поддержки насчитывает всего 14 тикетов, так что одна ошибка там заметно сдвигает процент. Сами доверительные интервалы для итоговых цифр в статье не приведены, есть только схемы отчётов. На наш взгляд, удачнее всего в дизайне правило откатывать патч, когда тестовая часть стоит на месте: оно дёшево и прямо целит в переобучение, которое статья называет частой проблемой.

Где в этих примерах Sonnet 5.5

По данным документации Claude Code, 28 сентября 2026 года вышла Claude Sonnet 5.5, новая модель Sonnet по умолчанию в API Anthropic. В примерах статьи её нет: подъём по стоимости заканчивается на Sonnet 5, и результат новой модели на том же бенчмарке не сообщается. Обе команды уже доступны в Claude Code, так что сравнить модели на собственном eval можно самостоятельно.