Anthropic тайно тестирует снижение усилий Claude Code в A/B-эксперименте

Всем привет, это Тарик из команды Claude Code. Я написал об этом в Twitter, но просто повторю здесь:

Мы иногда тестируем конфигурации обслуживания API в Claude Code перед их внедрением, и одна из текущих по-другому сопоставляет числовое значение усилий.

Вот почему Клод может говорить некоторым из вас, что он на «10» при высоком уровне. Шкала не от 0 до 100, число само по себе не имеет значения, и вы получаете те усилия, которые выбрали. Мы провели углубленные оценки, чтобы подтвердить, что это не влияет на производительность модели.

Это должно быть тот же опыт, но если вы заметите явную регрессию, пожалуйста, нажмите /feedback и отправьте мне ID. Начислю кредиты.

Не конкретно про Anthropic, но почему мы позволяем выставлять счета в токенах, которые туманны и полностью контролируются операторами, у которых нет согласованных стимулов?

Если у меня есть пользовательский ввод, и я санирую и вставляю его в промпт для выполнения какого-то действия, я понятия не имею, сколько это будет стоить, и у меня нет реального способа это нормально измерить. Параллельный пример — Digital Ocean или AWS: я могу пойти и измерить/ограничить свои вычисления, файловую систему, память, время запуска и т.д., и хотя может быть невозможно свести к последнему флопу выделенных денег, я могу работать с реальным бюджетом и реальными ограничениями, в отличие от LLM, где мне приходится... предварительно прогнать санированный пользовательский промпт через токенизатор, а затем попросить LLM угадать, что он может сделать, и дать оценки потребления токенов, а затем действовать на основе этого каким-либо разумным образом для пользователя?

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

*Чтобы уточнить мои бредни...

Нам должны выставлять счета и давать контроль на основе использования ресурсов, а не непрозрачной концепции токенов, и при этом мы не можем крутить никакие ручки, контролирующие использование ресурсов.

Обновление от Тарика в Twitter. https://x.com/trq212/status/2091247114869432543

«Мы иногда тестируем конфигурации обслуживания API в Claude Code перед их внедрением, и одна из текущих по-другому сопоставляет числовое значение усилий.

Вот почему Клод может говорить некоторым из вас, что он на "10" при высоком уровне. Шкала не от 0 до 100, число само по себе не имеет значения, и вы получаете те усилия, которые выбрали. Мы провели углубленные оценки, чтобы подтвердить, что это не влияет на производительность модели.

Это должно быть тот же опыт, но если вы заметите явную регрессию, пожалуйста, нажмите /feedback и отправьте мне ID. Начислю кредиты».

Это явление было настолько плохим и заметным с Fable, что я понизил свою подписку Max ($200) до Pro ($20). Это практически бесполезно. Codex 5.6 Sol на самом деле очень хорош, я просто создам еще один аккаунт, чтобы получить больше использования.

Пользователи LLM не хотят прилагать усилия, поэтому перекладывают задачи на LLM.

LLM, похоже, тоже не горит желанием прилагать усилия!

Это AGI?

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

Я использую Opus 5 почти исключительно с низким уровнем усилий и получаю хорошие результаты. Особенно на высоком уровне он, кажется, уходит в совершенно неожиданные отклонения. То же самое, похоже, верно и для Sonnet 5. Старые модели так себя не вели.

Смена настроения всего за шесть месяцев поразительна: в феврале этого года Claude был самым любимым LLM с большим отрывом.