Я сократил счёт моего AI-агента за токены на 87% за 7 дней. Вот как

Источник: https://x.com/nothiingf4/status/2056381531648889007

Автор: Himanshu

Большинство разработчиков в этом квартале тихо перестали пользоваться своими AI-агентами, потому что счёт за API вышел из-под контроля. Бонус в конце этой статьи: три open source Claude skills.

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

Небольшое число команд поняло, что счёт никогда не был проблемой модели. Это была инженерная проблема.

Стоимость токенов в 2026 году — это не про то, какую модель вы выбрали. Это про то, инструментировали ли вы систему. Правильно ли включили кэширование. Направляете ли правильную модель на правильную задачу. Сжимаете ли контекст, который модели не нужен. Ограничили ли циклы повторных попыток. Проверили ли cache hit rate. Настроили ли алерты так, чтобы экономия не расползалась.

Я дам вам точный 7-дневный план, как сократить счёт вашего AI-агента за токены на 87% без потери качества.

Не теория. Не общие советы. Конкретные аудиты. Конкретные паттерны. Конкретные изменения в коде, которые за одну неделю переводят вас со счёта $4 800 в месяц на $620 в месяц.

Сохраните это :)

Погнали ⬇️

Прежде чем начать: реальная цена бездействия

Давайте покажу честные цифры.

Claude Code на тарифе Opus обходится разработчикам в $150–$200 в месяц за место при production-использовании. Pro-план упирается в лимиты примерно после 12 тяжёлых промптов. Активные пользователи натыкаются на rate limits в середине сессии и переключаются на альтернативы прямо посреди задачи. Харнесс отправляет 27 тысяч токенов накладных расходов ещё до того, как ваш промпт вообще начнут рассматривать. Эти накладные расходы отправляются на каждом отдельном ходе.

Умножьте это на десять разработчиков. Умножьте на 30 рабочих дней. Вы получаете $45 000 в год только за один инструмент для одной команды. У большинства команд три или четыре инструмента. Большинство команд не считали математику.

Счёт растёт быстрее, чем ценность. Именно по этой траектории сейчас движется большинство команд. Хорошая новость: счёт можно исправить. У каждой строки в вашем месячном инвойсе есть конкретная архитектурная причина. У каждой причины есть конкретное исправление. Семь дней достаточно, чтобы сделать всё.

Вам не нужно менять модели. Вам не нужно писать собственный runtime. Вам не нужно мигрировать фреймворки. Вам нужно просто применить семь конкретных изменений в правильном порядке.

Вот как выглядит порядок.

День 1: проведите аудит того, куда на самом деле уходят ваши токены

Большинство команд не может ответить на один вопрос. Какая функция в их кодовой базе самая дорогая? Какой пользователь отвечает за самую большую долю счёта? Какой маршрут сжигает больше всего токенов за сессию?

Если вы не можете ответить на эти вопросы, вы не можете оптимизировать. Это и есть день 1.

Вам нужна наблюдаемость до того, как вам понадобится оптимизация. Три инструмента, которые важны в 2026 году.

Helicone. Proxy gateway. Одна строка кода направляет ваши LLM-вызовы через их сервис. Захватывает каждый запрос, каждый ответ, каждый подсчёт токенов, каждый потраченный доллар. Бесплатный тариф покрывает 10K запросов в месяц. Платные планы начинаются с $20 за место. Сильный вариант для команд, которым нужна нулевая нагрузка на интеграцию SDK.

Langfuse — open source. Можно self-host под MIT-лицензией. В январе 2026 года был приобретён ClickHouse. До приобретения — 26 миллионов установок SDK в месяц. Лучший вариант для команд, которым нужно держать данные на собственной инфраструктуре. GitHub — https://github.com/langfuse/langfuse

Portkey — gateway, который маршрутизирует через 250+ провайдеров. Силен во fallback'ах, балансировке нагрузки и встроенных функциях оптимизации затрат. Выбирайте его, если маршрутизируете между несколькими провайдерами моделей и нужен автоматический failover. GitHub — https://github.com/Portkey-AI/gateway

lmnr — трассировка и оценка поведения агента в одном инструменте. Open source. Выбирайте его, если хотите наблюдаемость вместе с eval-харнессом; это полезно, когда на 4-й день вы маршрутизируете модели и хотите измерить, действительно ли качество вывода более дешёвой модели сохранилось. GitHub — https://github.com/lmnr-ai/lmnr

Выберите один. Подключите его. Интеграция Helicone самая быстрая: добавьте их proxy URL в существующий LLM-клиент, без других изменений. Данные начнут течь через несколько минут.

Теперь посмотрите на дашборд.

Вам нужны пять главных источников расходов. Отсортируйте по общей стоимости по убыванию. Посмотрите на функции, пользователей, маршруты, сессии. Паттерн, который проявляется почти в каждой команде: две функции съедают 60 процентов бюджета. Иногда это два пользователя. Иногда это один runaway cron job, о котором никто уже не помнит.

Когда вы впервые проделаете это упражнение, вам будет неловко. Там будет функция, которая потребляет $4 000 в месяц и делает что-то, что команда оценивает долларов в $40. Там будет пользовательский аккаунт, потративший $1 200, потому что кто-то три месяца назад оставил скрипт запущенным в терминале. Там будет двенадцать тысяч неудачных повторов tool call с прошлой недели, которые дали ноль полезного результата.

Это нормально. Для этого и нужен день 1. Найдите их. Запишите. Каждую категорию мы исправим в следующие шесть дней.

Конкретный пример, как это выглядит на практике. Команда, с которой я работал, в понедельник провела аудит своего стека и обнаружила, что 47 процентов их счёта приходилось на одну функцию, которую должны были вывести из эксплуатации ещё шесть месяцев назад. Никто не проверил. Функцию всё ещё вызывал legacy cron job, который запускался каждые пятнадцать минут. В тот же день после обеда они выключили cron, и счёт упал на 47 процентов ещё до каких-либо других действий.

Дисциплина, которую стоит сочетать с этой работой, — это то, что я называю скептической отладкой. Принцип такой: когда вы находите дорогую функцию, вы не просто удаляете вызовы и объявляете победу. Вы воспроизводите стоимость. Вы формулируете гипотезу о корневой причине. Исправляете её. Затем заново запускаете исходную, неизменённую нагрузку, чтобы подтвердить, что исправление действительно удержалось. Противоположность этому — то, что делает большинство команд. Они видят дорогую функцию. Накладывают на промпт 20-процентное сокращение. Стоимость падает в следующем инвойсе. Они идут дальше. Через три недели та же функция снова наверху счёта, потому что они исправили симптом, а не причину. Есть community skill под названием skeptical-debugger, который кодифицирует эту дисциплину. Установите его перед началом аудита, если есть время.

Метрика, которую я хочу, чтобы вы отслеживали с дня 1, — cost per session. Не общая месячная стоимость. Не cost per request. Cost per session. Потому что именно эта единица важна пользователю. Если сессия стоит вашему бизнесу $10 ценности и обходится в $0.50, вы здоровы. Если она стоит $4.20, нет. Это число показывает, по какую сторону линии вы находитесь.

К концу дня 1 у вас должны быть: общая месячная стоимость; пять самых дорогих функций; пять самых дорогих пользователей; средняя стоимость сессии; две или три очевидные аномалии, которые нужно расследовать.

Эти данные — фундамент. Без них следующие шесть дней будут догадками.

День 2: включите prompt caching везде, где оно работает

Это самый большой рычаг во всём 7-дневном курсе.

Anthropic даёт скидку 90 процентов на чтение из кэша. Это официальная цифра. Каждый кэшированный input token стоит 0.1 от базовой входной ставки. Читаете из кэша — экономите 90 центов с каждого доллара. Anthropic — https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

OpenAI даёт автоматическое кэширование. Без изменений в коде. Скидка применяется к повторяющемуся контенту, как только вы перестаёте его трогать. До 90 процентов скидки на кэшированные input tokens на последних моделях.

Подвох — стоимость записи. Anthropic берёт 1.25 от базовой ставки за первичную запись с TTL 5 минут. Или 2 от базовой ставки за TTL 1 час. То есть на первой записи вы платите больше, а на каждом последующем чтении — намного меньше.

Точка безубыточности наступает удивительно быстро. С 5-минутным кэшированием вы выходите в ноль уже после одного cache hit. Всё после первого hit — чистая экономия.

Что кэшировать.

System prompt. Определения инструментов. Большие reference documents, которые вы переиспользуете между вызовами. Few-shot examples. RAG retrieval results, которые стабильны в рамках сессии. Всё, что идентично на вызове N и вызове N+1.

Что не кэшировать.

Текущий ввод пользователя. Свежеполученные данные для конкретного запроса. Эволюционирующий scratchpad агента. Всё, что меняется между вызовами.

Реализация в коде.

Этот тег cache_control — вся интеграция. Добавьте его к content blocks, которые хотите кэшировать. Кэш остаётся тёплым 5 минут после каждого доступа. Каждый последующий вызов, попавший в тот же префикс, платит 0.1x за эту часть.

Для RAG-систем и code assistants экономия на кэшированной части входа составляет 85–95 процентов. Если ваш system prompt — 8000 токенов, а пользовательский ввод — 200 токенов, вы платили за 8200 input tokens на каждом вызове. После кэширования вы платите 8200 токенов один раз. Затем 0.1 × 8000 плюс 200 на каждом последующем вызове. Это сокращение input cost на 88 процентов.

Замечание по безопасности, пока вы это подключаете. Gateways и skills, которые вы устанавливаете в день 1 и день 2, работают с доступом к вашим API-ключам и промптам. Перед установкой любого стороннего skill, который обещает оптимизировать ваши затраты (а таких много), проведите аудит. Skill — это просто код. Community skill под названием skill-security-audit применяет каталог из 23 паттернов к любому skill package: опасные shell commands, обфусцированные payloads, credential exfiltration, подозрительные network calls, prompt injection, unicode tricks. Он выдаёт вердикт: safe, review needed или block. Запускайте его на каждом skill перед установкой. Смысл этого семидневного курса не в том, чтобы сэкономить $4 000 на API-счёте и одновременно устроить утечку credentials.

Команды, которые делают это правильно, видят, как месячный счёт режется пополам в первый день деплоя. Иногда сильнее.

Ошибка команд — кэшировать неправильные части. Закэшируете volatile bits — hit rate будет ноль. Кэш работает только на идентичных префиксах. Если в system prompt вверху интерполирована текущая дата или имя пользователя, вы сломали кэширование для каждого пользователя.

Переместите volatile content в конец. Держите invariant content в начале. Чем длиннее неизменный префикс, тем выше hit rate.

День 3: сожмите контекст

День 3 — о том, чтобы не отправлять модели то, что ей не нужно.

Это день, который будет неприятным. Вы посмотрите на свои промпты и поймёте, что они раздуты. В system prompt три абзаца там, где должно быть одно предложение. В retrieved context полные документы, когда нужны были только два абзаца. В истории результатов инструментов полный вывод каждого tool call, когда модели нужен только последний.

Математика, которая меня разбудила.

Типичный production-агент отправляет примерно:

200 токенов определений инструментов

300 токенов сводки телеметрии

150 токенов state memory

200 токенов сжатого retrieval context

Итого 850 токенов контекстных накладных расходов на ход.

Тот же агент до сжатия отправлял:

3 200 токенов определений инструментов (полные JSON schemas)

5 800 токенов телеметрии (сырые логи)

2 400 токенов state memory (каждый предыдущий tool call)

3 100 токенов retrieval context (сырые document chunks)

Итого 14 500 токенов.

Это сокращение на 94 процента. Тот же агент. Та же задача. Та же модель. Качество вывода, измеренное на eval set из 50 примеров, осталось в пределах 2 процентов от несжатого baseline.

Конкретные техники.

Усечение результатов инструментов со ссылками на файлы. Не возвращайте 50 KB лог-файл как tool result. Сохраните лог на диск. Верните путь и первые 500 символов. Модель прочитает путь, если ей понадобится больше.

Связанный трюк, который хорошо с этим сочетается. Когда агент создаёт артефакт со структурой (отчёт с разделами, сравнительная таблица, diff, небольшой dashboard), отдавайте его как HTML artifact, сохранённый на диск, а не как inline markdown в чате. Есть community skill под названием html-artifacts, который кодифицирует, когда HTML лучше markdown (порог длины, таблицы, diffs, diagrams, interactivity, sharing), и даёт starter skeleton. Почему это важно для стоимости: история чата перестаёт накапливать markdown-блоки на тысячи токенов. Агент создаёт HTML-файл на диске, возвращает однострочную ссылку на путь, и следующий ход не платит за этот артефакт в контексте.

Суммаризованное состояние scratchpad. Модели не нужно видеть каждый tool call за последние 30 ходов. Ей нужно видеть summary на 200 слов о том, что уже пробовали, и свежий взгляд на текущее состояние.

Microcompact. Запускайте на каждом ходе. Если один и тот же инструмент вызывался несколько раз с одинаковым вводом, замените все дублирующиеся результаты одной cached reference. Экономит тысячи токенов на агентах, которые многократно вызывают grep.

Snip compact. Удаляйте самые старые сообщения, сохраняя protected tail из недавних. Модель сохраняет полную точность по последним N ходам, даже когда более ранняя история сжата.

Auto compact. Запускайте суммаризацию, когда token usage пересекает порог. Заменяйте старые сообщения summary. Отслеживайте, что compaction уже произошёл, чтобы агент не суммаризировал summary на следующем ходе.

Паттерн, который связывает всё это вместе, — бюджет на ход. Большинство агентов отправляют в 10 раз больше, чем нужно, потому что никто не задал бюджет. Выберите число. 4 000 токенов контекстных накладных расходов на ход — разумно для большинства задач. 8 000 — щедро. Всё выше — у вас утечка.

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

День 4: маршрутизируйте модели по задачам

Не каждой задаче нужен Opus.

В этот день большинство команд обнаруживает, что тратило Opus-деньги на Haiku-задачи. Классификатор, который определяет intent пользователя, не нуждается в модели за $15 за миллион токенов. Transform, который превращает структурированный запрос в естественный язык, тоже. Шаг ranking для retrieval — тоже. Автор summary, вероятно, тоже.

Трёхуровневая стратегия маршрутизации, которая стабильно экономит командам 50–80 процентов в production.

Haiku 4.5 — для нижних 60 процентов задач. Classification, retrieval, simple transforms, JSON extraction, single shot lookups, basic question answering по предоставленному контексту. Стоимость на момент написания — около $1 за миллион input tokens. Быстрая, дешёвая, достаточно умная для узких задач.

Sonnet 4.6 — для средних 30 процентов. Рассуждение средней сложности, многошаговое использование инструментов, code generation не архитектурного уровня, document analysis, content drafting. Стоимость около $3 за миллион input tokens. Лучшее соотношение cost/performance для большинства production workloads.

Opus 4.6 — для верхних 10 процентов. Самые сложные проблемы. Архитектурные решения, новое reasoning, multi document synthesis, неоднозначные edge cases, требующие аккуратного judgement. Стоимость около $15 за миллион input tokens. Берегите её для работы, которой она действительно нужна.

Production case studies публичны.

KanseiLink провели mid-size enterprise scenario, где перевод routine high volume tasks с «всё на Sonnet» на Haiku плюс batch processing снизил счёт с $54 до $9 для той же нагрузки. Сокращение на 83 процента на маршрутизируемой части.

Команда в financial services сообщила об общем сокращении на 37 процентов. $1 001 экономии в день. $365 000 в год. Нулевая деградация качества, измеренная на внутренних evals.

Собственное тестирование Anthropic advisor pattern. Использовать Opus как senior reviewer, который периодически проверяет вывод Sonnet или Haiku. Сокращение стоимости на 11 процентов по сравнению с all Opus и улучшение качества на 2 процента на их benchmark.

Advisor pattern заслуживает большего внимания, потому что это routing pattern, который команды недоиспользуют чаще всего. Идея простая. На каждом ходе запускайте Sonnet или Haiku как worker. Раз в N ходов или при срабатывании конкретного условия (destructive action, final output, ambiguous tool result) поднимайте задачу до Opus для review. Opus читает, что сделал worker, предлагает исправления и передаёт обратно worker. Вы получаете большую часть judgement Opus на тех частях, где оно нужно. И платите по тарифам Haiku или Sonnet на тех частях, где оно не нужно. Опубликованные Anthropic цифры (11 процентов экономии против all Opus, 2 процента улучшения качества) занижают эффект паттерна, потому что измеряли узкий benchmark. Команды, с которыми я говорил, сообщают об экономии ближе к 30–50 процентам на workloads, где тяжёлое reasoning сосредоточено в нескольких ходах из многих.

Decision tree в коде.

Это примерно 12 строк, которые сэкономят вам 50 процентов счёта.

Ошибка людей на 4-й день — маршрутизировать по интуиции вместо измерений. Они предполагают, что задаче нужен Opus, потому что входы длинные или prompt подробный. Сначала запустите более дешёвую модель. Измерьте качество вывода на 50 примерах. Если проходит — всё. Если не проходит — поднимайтесь на следующий tier.

Более дешёвая модель проходит чаще, чем вы ожидаете.

День 5: остановите retry loops до того, как они сожгут токены

Регрессия Claude Code в апреле 2026 года — канонический case study для этого дня.

В апреле Anthropic выпустили три изменения харнесса, которые вместе подняли API retry rates в 80 раз. Median visible thinking length упала на 73 процента. Модели снова и снова говорили повторить попытку, не производя полезного результата. Пользователи почувствовали это раньше, чем мониторинг Anthropic. Сообщество подготовило анализ, который вскрыл паттерн. 6 852 сессии. 17 871 thinking blocks. 234 760 tool calls.

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

Симптомы.

Всплеск API calls per session. Сессия, которая обычно завершается за 8 вызовов, требует 23. Падение task completion rate. Сессии идут дольше, но дают меньше результатов. Рост average response latency. Cost per session растёт, пока value per session остаётся прежней или падает.

Причина почти всегда одна из четырёх.

Модель продолжает вызывать сломанный tool, а tool продолжает падать тем же способом. Модель интерпретирует failure как «мне нужно попробовать иначе» и повторяет с небольшими вариациями. В харнессе нет step limit, поэтому retry продолжается.

Харнесс проглатывает tool errors и возвращает generic строку «tool failed, please try again». У модели нет информации, на основании которой можно действовать, поэтому она повторяет тот же вызов.

Агент входит в loop, где продолжает производить вариации одного и того же output, не проверяя, что output уже существует.

Изменение upstream model behavior заставляет агента интерпретировать нормальный response как неполный и вызывать следующий tool, чтобы «завершить» работу.

Конкретная история. Мой друг управляет research agent в небольшой консалтинговой компании. Их счёт тихо утроился за три недели. Аудит в день 1 не показал ничего странного. Общее число запросов выглядело нормальным. Затем они инструментировали систему на уровне per turn и обнаружили, что одна из каждых девяти сессий делает 187 tool calls перед завершением. Агент застревал на вызове одного и того же web search с одним и тем же query, потому что search возвращал пустой результат, а агент интерпретировал это как «нужно попробовать ещё раз». Никакого ограничения retry. Один плохой query — и агент сжигал $14 в одной сессии. За три недели этот паттерн съел 38 процентов их счёта.

Ещё одна история с тем же паттерном, но в более крупной компании. Coding agent должен был запустить lint, затем format, затем commit. Шаг format иногда падал из-за upstream tool bug. Агент видел crash, решал «исследовать», открывал source упавшего tool, делал предположение, пытался пропатчить сам tool, запускал пропатченный tool, снова видел crash, делал ещё одно предположение, снова патчил. Шесть итераций на один failed format call. «Исследовательское» поведение агента было retry loop, переодетым в продуктивную работу. Двести десять долларов за вторник после обеда, прежде чем кто-то заметил.

Исправления.

MAX_STEPS bound в харнессе. У каждого цикла есть жёсткая верхняя граница. Когда агент её достигает, loop поднимает typed exception, который попадает в ваши логи. Число можно выбрать эмпирически, но 10 — хорошая стартовая точка для большинства агентов.

Structured error results. Когда tool падает, возвращайте structured result со status, error type и message. Модель может прочитать структурированный результат и рассуждать о нём, а не слепо повторять.

Idempotency keys на tool calls. Если агент собирается вызвать тот же tool с теми же arguments в третий раз, что-то не так. Харнесс может short circuit и вернуть cached result предыдущего вызова.

Abort on no progress. Отслеживайте, какие artifacts агент произвёл на этом ходе. Если проходит 3 хода без создания нового artifact, прерывайте session и логируйте trace для расследования.

Комбинация этих четырёх ловит большинство retry loops. Команды, которые внедрили их, сообщают о сокращении хвоста cost distribution на 30–60 процентов. Дорогие сессии перестают быть дорогими.

День 6: проверьте, что кэширование действительно работает

На день 2 вы включили caching. На день 6 вы проверяете, что оно работает.

Большинство команд пропускает этот шаг. Они включают caching, видят падение счёта, объявляют победу и идут дальше. Через три недели кто-то добавляет feature, которая помещает dynamic value ближе к началу system prompt, и cache hit rate тихо падает с 78 процентов до 12 процентов. Счёт снова ползёт вверх. Никто не связывает эти два события.

Метрика, которую нужно отслеживать, — cache hit rate by route. Не общий cache hit rate. По маршрутам. Потому что route, который должен быть на 90 процентов cached, выглядит нормально в среднем значении, даже если он рухнул до 30 процентов.

Цели. Для routes со стабильным invariant prefix (system prompt, tool definitions, persistent context) стремитесь к cache hit rate 70–90 процентов. Для routes с частично стабильными prefixes (user session state) стремитесь к 30–50 процентам. Если hit rate ниже 30 процентов на route, где вы должны кэшировать, структура кэша неправильная.

Это также день, когда дисциплина skeptical debugger, о которой я говорил на day 1, окупается сильнее всего. Искушение на day 6 — посмотреть на dashboard, увидеть cache hit rate и считать дело сделанным. Не поддавайтесь. Проверка — это не число на dashboard. Проверка — это когда вы можете выбрать три конкретных routes и объяснить, почему каждый попадает в свой target rate. Если не можете объяснить, вы не проверили. Вы просто посмотрели на график и почувствовали себя хорошо. Воспроизведите стоимость на одном route. Сформулируйте гипотезу о cache structure, которая дала бы наблюдаемый hit rate. Подтвердите, что structure соответствует тому, что вы задеплоили. Заново запустите исходную workload без изменений. Это и есть verification.

Как отлаживать низкий hit rate.

Проверьте длину префикса. Anthropic требует минимальное число токенов, прежде чем caching включится. Sonnet нужно 1 024 токена. Haiku нужно 2 048 токенов. Если ваш invariant prefix короче порога, caching не происходит.

Проверьте volatile fields near the start. Текущая дата. Имя пользователя. Текущее имя модели. Всё, что меняется между вызовами и находится перед cache_control marker, ломает cache для этого пользователя.

Проверьте TTL. 5-минутный TTL работает для hot routes. 1-часовой TTL работает для routes, которые вызываются эпизодически, но со стабильными prefixes. Если ваш traffic pattern означает, что большинство cache reads происходит через 8 минут после предыдущего read, 5-минутный cache истекает раньше повторного использования.

Проверьте placement cache_control. Cache control отмечает, где заканчивается invariant prefix. Если вы поставили его неправильно, cache короче, чем должен быть.

Запускайте аудит еженедельно. Cache hit rate — leading indicator. Если он падает, счёт идёт вверх.

День 7: настройте алерты и закрепите экономию

Вы сделали работу. Счёт снизился. Теперь нужно удержать его низким.

Без алертов экономия расползается. Каждая новая feature, которую выпускает команда, приносит новые prompts. Каждый новый code path — шанс, что кто-то copy-paste'нет 50 KB документ в system prompt. Каждый новый contractor — человек, который ещё не усвоил дисциплину. Счёт ползёт вверх, пока все заняты shipping.

Alerts — способ поймать этот creep до того, как он станет кризисом.

На что ставить alerts.

Total daily spend выше бюджета. Выберите threshold. Если обычно вы тратите $30 в день, поставьте alert на $50. Alert нужен для anomalies, не для обычной вариативности.

Cost per session выше threshold для конкретного workflow. Сессии в support agent должны в среднем стоить $0.40. Если одна session пересекает $5, что-то не так. Alert и расследование.

Cache hit rate падает ниже floor. Если route обычно работает на 80 процентах и падает до 50 процентов три часа подряд, что-то изменилось в prompt structure или traffic pattern.

Один пользователь отвечает более чем за N процентов общего daily spend. Обычно это означает runaway script. Или, в худшем случае, скомпрометированный API key.

Куда маршрутизировать alerts. Паттерн, который работает для большинства команд, — tiered routing. Slack channel для cost alerts, которые в 1x–2x выше нормального threshold; их расследуют в следующий рабочий час. PagerDuty для cost spikes, которые более чем в 5x выше нормы; они прерывают кого-то прямо сейчас. Email digest для weekly cost summaries, которые идут engineering manager и finance team. 5x spike прерывает человека. Weekly summary попадает в inbox, и вы просматриваете его в понедельник утром.

Инструменты поддерживают это из коробки. У Helicone есть alert configuration в dashboard. У Langfuse то же самое через их console. Portkey маршрутизирует alerts через gateway events.

Задайте thresholds. Задайте routing. Затем забудьте об этом, пока alert не сработает. Не смотрите постоянно на dashboard. Alert сработает тогда, когда должен.

Три skills, которые помогают закрепить эту дисциплину

Семь дней выше сократят ваш счёт. Но compounding случится только если дисциплина переживёт следующий квартал, когда вы не будете активно сфокусированы на cost. Три Claude skills (open source, MIT licensed), доступные по ссылке ниже, делают дисциплину структурной, а не зависящей от памяти.

GitHub — https://github.com/Himanshu040604/Claude-Skills

skill-security-audit. Первый, который стоит установить. Каждый observability gateway, каждый optimization skill, каждый third party token tracker, который вы подключаете к стеку, — это код, работающий с доступом к вашим API keys и prompt content. Большинство builders устанавливают community skills так же, как npm packages: читают README и вставляют install line. Это ошибка безопасности. Skill-security-audit применяет каталог из 23 паттернов к любому skill package перед установкой. Dangerous shell commands. Obfuscated payloads. Credential exfiltration. Suspicious network calls. Prompt injection. Unicode tricks. Он возвращает verdict: safe, review needed или block. В первый раз, когда вы запустите его на skill, который собирались установить, вы найдёте как минимум один network call, о котором не знали. Лучше найти его до установки, чем после.

skeptical-debugger. Принцип: reproduce, hypothesize, fix the root cause, затем re-run original unmodified workload, чтобы подтвердить, что fix удержался. Он подсвечивает дешёвые shortcuts, к которым большинство инженеров тянется под deadline pressure. Skip markers. Removed assertions. Swallowed errors. Deleted tests. В контексте работы над token cost эквивалентные gaming patterns встречаются так же часто. Сократить system prompt ради числа, не проверив eval. Кэшировать неправильный content, потому что cache hit rate выглядит лучше на dashboard. Маршрутизировать task в Haiku, потому что дешевле, не измерив, проходит ли output всё ещё. Установите skeptical-debugger и прогоняйте через него optimization changes. Это разница между реальным сокращением на 87 процентов и бумажным, которое вернётся через месяц.

html-artifacts. Самый маленький из трёх, но тот, который окупается на day 3 семидневного курса. Принцип простой. Когда агент создаёт multi-paragraph report, comparison table, diff, diagram или что-то interactive, правильный output — HTML-файл, сохранённый на диск, с path reference, возвращённым в chat. Не raw markdown inline. Skill поставляется с понятным тестом, когда HTML лучше markdown (length, tables, diffs, diagrams, interactivity, sharing), и пятью worked playbooks плюс starter skeleton. Cost angle прямой. Каждый markdown blob на тысячи токенов в chat history — это tokens, за которые вы продолжаете платить на каждом последующем ходе. Переместите artifact на диск, и chat history перестанет его накапливать.

Claude Code автоматически обнаруживает любой skill в этой директории при следующем запуске. Без registry, без config, без rebuild.

Это не единственные полезные skills в экосистеме. Это три, которые напрямую сочетаются с семидневной программой выше. Если хотите изучить дальше, canonical lists — официальный Anthropic skills repo: https://github.com/anthropics/skills и community-maintained каталог Awesome Claude Skills: https://github.com/travisvn/awesome-claude-skills. Аудируйте всё новое перед установкой. Для этого и нужен skill-security-audit.

Как это выглядит вместе

До этого курса у вас было.

$4 800 в месяц API spend.

27 процентов cache hit rate.

All Opus all the time.

Никакой model routing.

Retries silently eating budget.

Никаких alerts.

Cost growing 8 percent month over month.

После этого курса у вас:

$620 в месяц API spend (сокращение на 87 процентов).

78 процентов cache hit rate.

Haiku Sonnet Opus routed by task.

Bounded loops with structured errors.

Cost alerts wired to Slack.

Cost per session flat or shrinking as you ship features.

Годовая экономия где-то около $50 000. Для небольшой команды это значимые деньги. Для большой команды эквивалентное изменение в масштабе даёт кратно больший эффект. Та же команда, которая в прошлом году заплатила $50 000 неожиданных перерасходов, теперь платит $6 500 и выпускает больше features за тот же период.

Меняется ещё одна вещь: отношение вашей команды к счёту. До курса счёт был тем, что с вами случалось. После курса счёт — то, чем вы управляете. Люди в команде, которые внедрили оптимизацию, теперь имеют интуицию о том, какие features будут дорогими, а какие нет. Эти intuitions почти ничего не стоят при приобретении и окупаются всегда.

Паттерн compounding. Каждая новая feature, которую команда строит, наследует disciplines. Cost discipline становится частью того, как вы shipped, а не вещью, которую вы делаете один раз и забываете. Через шесть месяцев новый junior engineer спросит вас: «почему мы снова делаем эту caching thing», и вы расскажете ему историю семи дней. Он усвоит её за двадцать минут. Compounding продолжит compounding.

Распространённые ошибки, которые убивают эту экономию

1. Кэшировать volatile parts of the prompt. Кэш работает только на идентичных префиксах. Если в prompt вверху интерполирован timestamp или session ID, hit rate равен нулю. Переместите volatile content в конец. Держите invariant content в начале. Длинный invariant prefix означает высокий hit rate.
2. Маршрутизировать по названию модели, а не по сложности задачи. Команды говорят «мы используем Sonnet для всего» или «мы стандартизировались на Haiku», будто модель — свойство команды. Модель должна быть свойством задачи. Классифицируйте task, затем выберите model.
3. Оптимизировать до инструментирования. Нельзя оптимизировать то, что нельзя измерить. Команды, которые пытаются резать cost без instrumentation, всегда сокращают не то. Урезают Opus calls — и обнаруживают, что эти Opus calls были нужны. Урезают размер system prompt — и обнаруживают, что agent опирался на вырезанные части. Сначала instrumentation. Измерьте, куда уходят деньги. Потом optimizing.
4. Доверять free tier без limits. Free tiers не имеют hard caps. У них soft caps, которые говорят: «с вас спишут, если превысите». Поставьте собственные hard caps в коде или gateway. Если runaway script за ночь прожжёт ваш free tier, вы заплатите за этот сюрприз.
5. Сжимать context, который нужен модели. Можно over-compress. Если eval scores агента падают после compression, вы сжали слишком агрессивно. Отслеживайте output quality вместе с cost. Optimization — это Pareto frontier стоимости и качества. Не только cost.
6. Ставить MAX_STEPS слишком низко. Если ограничить loop на 3, вы получите agents, которые бросают работу до завершения реальных задач. Cap нужен для runaway loops, а не для normal work. 10 — разумная стартовая точка. 20 — щедро. Измерьте distribution перед выбором.
7. Устанавливать community skills без аудита. Каждый skill, который вы добавляете к agent, работает с тем же access, что и agent. Если вы не стали бы вставлять stranger's script в терминал, не прочитав его, не вставляйте их SKILL.md в skills directory без аудита. Запускайте skill-security-audit перед любой install. Всегда.

Честная правда

Большинство команд прочитает это и продолжит платить счёт.

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

Потом они потратят на API costs больше, чем заплатили бы инженеру за эту работу.

Команды, которые делают это один раз, получают compounding. Каждая новая feature, которую они ship, наследует optimization discipline. Senior engineers переносят patterns в следующую codebase. Junior engineers впитывают habits без необходимости отдельного обучения.

Те, кто этого не делает. Именно они запускают тот же workflow, который раньше стоил $20 в месяц, за $400 в месяц. Счёт растёт быстрее revenue команды. В какой-то момент математика перестаёт сходиться.

Окно, когда можно серьёзно заняться этим, — сейчас. Pricing wars замедляются. Anthropic и OpenAI обе выпустили pricing updates в начале 2026 года, и следующий раунд вряд ли принесёт 10x discounts. Команды, которые выстроили cost discipline в этом году, останутся прибыльными, когда API prices перестанут падать.

Ваш счёт за токены — не проблема модели. Это инженерная проблема. А инженерные проблемы решают люди, которые делают engineering.

Семь дней. Шесть images. Три skills. Один счёт, сокращённый на 87 процентов. Теперь идите и запускайте аудит.