Token audit для Opus 4.7: как посчитать, что ты реально платишь

Anthropic выкатил Opus 4.7. В changelog, краткая строка: «Improved tokenization efficiency for system prompts». Читается как улучшение. На практике значит противоположное: ваши system prompts теперь занимают в среднем на 46% больше токенов, чем на Opus 4.6.

Коммерческая ставка 4.7 на выходе та же, что у 4.6 ($25 за миллион output токенов), но эффективно вы платите на 30-50% больше за каждый запрос, потому что на вход уходит больше токенов. Anthropic это не анонсировал как цену. Назвал это «efficiency improvement».

Я потратил день на замеры. Выкладываю, как посчитать свой рунрейт.

Tokenizer, это компонент модели, который разбивает текст на токены, атомарные единицы, которыми модель оперирует. Например, слово «tokenization» может быть одним токеном или разбиваться на «token» + «ization». Слово «эффективность» может быть одним токеном или двумя: «эффект» + «ивность».

Количество токенов в одинаковом тексте зависит от:

Anthropic в апреле обновил tokenizer для Opus 4.7. По их словам, это сделало модель точнее на ряде сложных reasoning-задач. По независимым замерам (Simon Willison, 22 апреля; opendatascience TG, 22 апреля; мой собственный замер), это также увеличило средний tokens-per-prompt примерно на 46% для прагматического набора запросов.

Anthropic, технически, не повысил цены. Но они повысили ВАШ runrate на 30-50%, не называя это повышением.

Проверим на конкретной системе. У меня системный промт для одного из проекта, 1850 слов русского текста плюс markdown-таблицы.

У меня вышло: Opus 4.6 даёт 3420 input токенов, Opus 4.7 даёт 4980. Δ: +45.6%. Близко к публично озвученным цифрам.

Откройте https://docs.anthropic.com/en/docs/build-with-claude/token-counting, вставьте ваш system prompt, выберите модель, получите число. Сравните две модели.

В Anthropic Console есть вкладка Usage по моделям. Если вы уже неделю работаете на 4.7, сравните среднее количество input токенов на запрос с той же неделей месяц назад на 4.6. Учитывайте, что профиль запросов мог поменяться, но для большого объёма (>500 запросов в неделю) это даёт достаточно точную оценку.

Я сравнил три типа запросов:

Тип A. Длинный системный промт + короткий вопрос пользователя.

Тип B. Короткий системный промт + длинная переписка.

Тип C. Code-assist с tool calls.

Итог. Если у вас много длинных system prompts, Opus 4.7 дорогой. Если у вас переписка и tool calls, Opus 4.7 заметно, но не драматично дороже. Мой общий runrate вырос на 27% с переходом на 4.7.

Для сравнения: это тихое повышение цен на 27% без публичного анонса. В любом SaaS-контракте это было бы основанием для ренегоциации. В AI это называется «improved efficiency».

Средний system prompt, который я вижу у коллег, раздут на 30-50%. Примеры типичного жира:

Избыточные инструкции. «Пожалуйста, будь аккуратен с форматированием», «если ты не уверен, спроси», «помни о контексте разговора», это токены, которые модель и так выполняет. Уберите.

Задублированные guidelines. Три раза повторённое «пиши по-русски», два раза «отвечай коротко». Один раз, максимум. Лучше, в специальном system-note блоке в начале.

Длинные примеры. Few-shot примеры в system prompt часто занимают 500-1500 токенов. Вопрос: работает ли модель хуже с 2 примерами вместо 5? По моему опыту, в 90% случаев нет. Проверьте на своих задачах.

Практика: берёте свой system prompt, запускаете через Claude с промтом «убери всё избыточное, сохрани точность», получаете сжатую версию. Прогоняете 10 типовых запросов через обе версии. Если качество совпадает, переходите на сжатую. Мне удалось сократить на 34% без потери качества.

Это то с чем я сегодня играюсь двухуровневая/трех уровневая маршрутизация. Но суть проста - сложные запросы в Opus, рутина в сетки по меньше, по проще.

Anthropic предлагает кеширование длинных system prompts. Если у вас одинаковый system prompt повторяется в большом количестве запросов (типично для production-сервисов), включите cache. Цена кешированных input токенов, примерно в 10 раз меньше обычных.

Практика: в SDK добавьте cache_control на блоки system prompt, которые не меняются. Документация: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching.

Token audit, это единовременная работа на час. Оптимизация промтов, разделение задач, включение cache, на каждое уходит от дня до недели.

И самое главное. Если Anthropic в следующий раз «улучшит эффективность» ещё на 46%, ваш runrate вырастет ещё на 30-50% без вашего участия. Это системная проблема, не ошибка команды Anthropic. Per-token pricing с меняющимся tokenizer, это архитектурная ловушка. Per-seat или per-outcome pricing был бы предсказуемее.

Но пока рынок на per-token, лучшее что мы можем, мерить свой собственный runrate каждый месяц и оптимизировать.

Попробуйте и поделитесь, какой результат у вас вышел. Мне интересно собрать стату по читателям.

Больше разборов AI для бизнеса - в Telegram: Telegram

Источники: