Всем привет! Я Юля Гончарова — продакт, дизайнер и... «вайбкодер». Последний год я строю продукты в одиночку с помощью Claude Code — от идеи и UX до кода и запуска. В этой статье расскажу про один из таких проектов: стартап, который я уже третий месяц развиваю как solo founder. Здесь я поделюсь тем, как мне удалось снизить затраты на токены, оставшись на модели Claude Sonnet 4.6.

Для понимания контекста: продукт, о котором идет речь — это веб-приложение с мультиагентной системой. Один агент собирает данные о пользователе при регистрации, второй помогает ему подобрать и сформулирвоать цель (продуктом пользуются оснвоатели стартапов ранней стадии), третий ведет регулярный чек-ин (синк-сессии), четвертый — ежедневный чат-помощник, через которого пользователь может управлять любым функционалом, включая заполнения профиля-питч-дека или смены расписания синков. А еще есть индивидуальные агенты у инвесторов: те, которые настроены по параметрам конкретного фонда, такие агенты проводят интро-встречу с основателем (симуляцию питча инвестору). Агенты передают друг другу эстафету (например, после сбора данных передают управление агенту постановки цели) и координируются через общие данные, которые читают и пишут все вместе (профиль пользователя, цели, журнал событий) — а не общаются друг с другом напрямую.

Каждый раз, когда AI отвечает, агенту приходится заново «прочитать» весь предыдущий разговор, накопленный контекст по проекту и все свои инструкции — и это стоит денег на каждый ответ. Представьте, что перед каждой репликой в разговоре человек должен перечитывать всю переписку с начала. AI-провайдер (Anthropic) разрешает сказать: «вот этот кусок запомни, не заставляй меня платить за перечитывание». Но у этой «памяти» есть срок годности — и именно то, как мы её использовали, дало основную экономию.

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

Например, одна синк-сессия, которая в среднем длится 15–20 минут, обходилась примерно в $1.20. Даже обычная регистрация нового пользователя, в которой последовательно работают всего два AI-агента, стоила около $1.

Для MVP такие цифры еще можно пережить. Но если планировать массовое привлечение пользователей, стоимость каждого AI-сценария начинает напрямую влиять на CAC и экономику продукта. Стало очевидно, что сначала нужно научиться делать AI значительно дешевле, а уже потом масштабировать привлечение.

Так я занялась оптимизацией. И много изменений, которые рекомендовл Claude — никак не сказались на итоговой стоимости. Но раз в неделю я стабильно просила Клода подумать еще разок, приносила свли идеи ему и так шаг за шагом удалось найти восемь вещей, благодаря которым стоимость онординга во вреям регистарции снизилась до $0.30—$0.50, а синка — до $0.50-0.70 — без смены модели. Рассказываю, что мне помогло👇

1. Настройка памяти (кэш) для инструкций

У меня есть два вида данных: правила поведения (инструкции, как себя вести AI-агенту) и постоянно изменяемые самим агентом данные о пользователе (профиль, цель, метрики — что уже известно прямо сейчас).

Раньше все это склеивалось в один большой кусок текста. А раз в нем была часть, которая реально меняется (данные пользователя) — весь кусок целиком считывался как “перечитай заново каждый раз”, и я переплачивала за него на каждом сообщении, хотя инструкции никогда не меняются, а данные пользователя меняются редко.

Что сделала: разделили на «инструкции, которые не меняются» (их AI запоминает один раз) и «изменяемые данные» (это маленькая часть, которая каждый раз новая, но она короткая). На инструкции настроила кэширование. Изменяемые данные тоже кэшируются — просто пересобираются заново на каждое сообщение и сверяются с прошлой версией: не изменилось — берется из памяти дешево, изменилось (например, обновилась метрика) — разово дороже, а дальше снова дешево. Это убрало около 55% всех трат.

💬 Промпт для агента: Покажи мне весь системный промпт (system prompt), который мы отправляем в Claude для [название агента]. Раздели его на две части: (1) то, что реально одинаково на каждом вызове — инструкции, правила, статичные справочные данные; (2) то, что реально меняется — текущее состояние пользователя, таймстамп и т.п. Добавь cache_control (ephemeral) на часть (1): TTL “5m” на первое сообщение founder’а в сессии, и TTL “1h” начиная со второго сообщения. Часть (2) пересобирай заново каждый раз из базы данных, но тоже добавь ей cache_control TTL “5m”, кроме одной строки с точным временем — она должна остаться некэшируемой. Убедись, что часть (2) не потеряла ни одного поля, которое реально нужно AI каждый раз.

  • Нюанс, который нужно учесть: у Антропика есть “память на 5 минут” и “память на 1 час”. Час — более “прочная” память, но более дорогая. Разница окупается только если разговор реально продолжится в течение этого часа. Поэтому я проанализирвоала реальных пользователей: 38% людей открывают чат, пишут AI ровно одно сообщение и чат закрывают. Поэтому включать часовую память тут неразумно.

Что я сделала: первое сообщение — всегда дешевая 5-минутная память. Только если человек написал второе сообщение (значит, разговор действительно продолжается) — включается более дорогая часовая память. В промте предусмотрен именно такой сценарий.

Чтобы вам проще было определиться какой TTL выбрать, вот промт на это:Посмотри в наших логах вызовов к Claude, какой TTL ("5m" или "1h") стоит у cache_control для системного промпта. Посчитай по реальным данным: какой процент разговоров состоит ровно из одного сообщения пользователя и никогда не продолжается.

2. Память для самой переписки

Без специальной настройки AI на 50-м сообщении разговора платит не только за это сообщение, но фактически пересказывает себе все 49 предыдущих — заново, целиком, каждый раз. Чем длиннее разговор, тем дороже становится КАЖДЫЙ следующий ответ, и растет это не линейно, а быстрее.

Это уже третий, отдельный кусок данных в запросе — история переписки пользовтеля с агентов в конретном чате.

Что сделала: включила «запоминание» уже сказанного в разговоре, вместо пересказа с нуля на каждом шаге. Разговор на 50 сообщений подешевел примерно в 5 раз.

💬 Промпт для агента: Найди в коде место, где мы отправляем историю переписки в Anthropic API (Claude). Проверь: используется ли prompt caching (cache_control) на самой истории сообщений, а не только на системном промпте. Если нет — добавь ephemeral cache_control с TTL "5m" на последний content-блок предпоследнего сообщения, чтобы длинные разговоры не пересылались заново целиком на каждом ходу.

  • Нюанс, который мне все поломал: изначально Клод настроил кэш в чате на час. Оказалось, что у Anthropic есть жесткое правило: если в одном запросе к AI несколько кусков с разной памятью, все часовые метки должны идти РАНЬШЕ всех пятиминутных. Правила поведения идут в запросе первыми — им можно ставить час. Но следующий кусок (изменяемые данные пользователя) в нашей системе всегда стоит на 5 минутах — а значит, все, что идет после него в этом же запросе, тоже НЕ может претендовать на час. Это не выбор ради экономии — это ограничение по порядку, которое обязательно учитывать дальше.

Сначала Клод это не учел и по аналогии с инструкциями поставил переписке память на 1 час. Это сломало прод: Anthropic просто отклонял запросы. В зависимости от того сколько "слоев" данных вы отправляете на анализ, выберите какое кэширование тут будет задано у вас

3. Список действий AI не должен меняться в рамках одного разговора

У AI есть набор tools — «действий», которые он может совершать. Простыми словами: «tools» — это список действий, которые AI может совершать (записать данные, назначить встречу и т.д.). Нужно убедиться, что этот список не меняется в рамках одного разговора, иначе слетает вся экономия от «запоминания» из пунктов 1-2 выше.

Что сделала: набор действий AI теперь всегда одинаковый внутри разговора. Правила «когда что использовать» объяснили словами в инструкции, а не убиранием/добавлением самих действий.

💬 Промпт для агента:Проверь, меняется ли у нас где-нибудь список tools (function calling), который мы передаём в Claude, между вызовами в рамках одного разговора — например, условно скрывается какой-то инструмент на части ходов. Anthropic кэширует tools и system вместе одним блоком, так что любое отличие в списке tools ломает весь кэш, даже если сам system не менялся. Сделай так, чтобы список tools был identical на каждом вызове внутри одной сессии, а нужное поведение опиши текстом в промпте.

4. Если ответ AI всегда одинаковый — не спрашивай AI

Два места в продукте гоняли полноценный запрос к AI ради приветствия, которое было одинаковым для всех новых пользователей. То есть можно было просто написать этот текст один раз самим, без AI вообще. Например, если у вас есть агент на онбординге, первое сообщение агента сделайте заранее предустановленным.

Что сделала: заменили такие места готовым текстом. Теперь в некоторых сценариях пользователь первым видит заранее запрограммированное сообщение и только овтетив на него — к диалогу подключается агент.

💬 Промпт для агента: Найди в коде все места, где мы делаем вызов к Claude ради генерации приветствия или другого текста, который не зависит от данных конкретного пользователя (одинаковый для всех/для нового пользователя). Для каждого такого места: покажи мне реальный пример ответа AI в этой ситуации, и если он действительно всегда одинаковый — замени вызов статическим текстом прямо в коде, без обращения к API. Не трогай места, где ответ реально меняется в зависимости от того, что уже известно о пользователе.

5. Не отправляй AI данные, которые точно не нужны именно сейчас

Даже с «запоминанием» из пунктов 1-2 каждый лишний кусок данных все равно стоит денег: один раз — записать его в память, и понемногу — каждый раз, когда AI его «перечитывает». Нашла случай: одно сообщение в чате стоило 13 центов, потому что AI каждый раз получал вообще весь профиль пользователя, всю историю метрик, все цели и обязательства — хотя человек просто нажал кнопку «Показать расписание синков», а AI нужна была для этого только маленькая часть информации натсроек пользвоателя, а не все данные о его стартапе.

Что сделала: только для ситуаций, где мы заранее точно знаем, что спросит человек (например, он нажал конкретную кнопку в интерфейсе, вызвав агента, а не написал что-то своими словами в чат компаньону) — урезать данные до необходимого минимума. Важно: сделалть это нужно только там, где вопрос известен на 100% заранее. Пытаться угадывать по тому, что человек напечатал сам, инициируя получение данных через инструменты/колл — рискованно.

💬 Промпт для агента: Найди в коде вызовы AI, которые срабатывают по нажатию конкретной кнопки/ссылки с заранее известным вопросом (не по свободному тексту пользователя). Для каждого такого случая проверь — отправляем ли мы AI куда больше данных, чем нужно для ответа именно на этот конкретный, заранее известный вопрос. Если да — заведи отдельный урезанный набор данных для этого конкретного случая. Не трогай места, где вопрос пользователя не известен заранее (свободный ввод текста).

6. Не включай в контекст по умолчанию то, что нужно не всегда

Например, у агента-компаньона по умолчанию в каждый вызов подмешивались два увесистых куска данных (журнал саморефлексии и список подходящих инвесторов) — даже когда разговор был вообще не о них. Это данные, которые нужны редко, но отправлялись всегда.

Что сделала: убрала их из состава «по умолчанию» — подключаются только когда агенту реально нужно к ним обратиться.

💬 Промпт для агента: Покажи мне полный список данных, которые мы по умолчанию отправляем в каждом вызове для [название агента]. Для каждого блока данных ответь: используется ли он в большинстве реальных разговоров, или только в редких, отдельных случаях? Предложи, какие из редко нужных блоков можно убрать из "по умолчанию" и подключать только тогда, когда агент явно должен на них ссылаться.

7. Дай агенту короткую версию инструкции, если ему не нужны все детали

Один и тот же справочный документ (например, описание структуры данных) отправлялся всем агентам в полном виде — но не всем он нужен настолько подробно. Агенту, который собирает данные о пользователе с нуля, нужны все детали. Агенту, который просто сверяется с уже собранными данными, нужна только короткая выжимка.

Что сделала: короткую версию инструкции для агентов, которым не нужны все детали, оставив полную версию только там, где она реально нужна.

💬 Промпт для агента: Найди все справочные документы/файлы с инструкциями, которые мы отправляем нашим AI-агентам целиком на каждом вызове. Для каждого документа посмотри, каким агентам он передаётся — всем ли им реально нужны все детали, или части агентов достаточно короткой выжимки (например, тем, кто просто работает с уже существующими данными, а не создаёт их с нуля)? Предложи короткую версию для тех, кому не нужны все детали, не трогая агентов, которым полная версия действительно нужна.

8. Формат текста тоже стоит денег — markdown «тяжелее» обычной прозы

Одинаковый по смыслу текст, оформленный таблицами и разметкой (markdown — жирный текст, заголовки, таблицы со знаками |), превращается в больше токенов, чем тот же текст обычной прозой. Мы с Клодом сначала прикидывали экономию «на глазок» — по количеству символов в документе — а когда сверили с реальным числом токенов, которое возвращает сам API, оказалось, что оценки по символам были занижены на 15-20% именно на документах с таблицами.

Что сделала: перестала доверять «символы ÷ 4» как оценке количества токенов, особенно для документов с таблицами/списками — стала проверять по-настоящему, через реальный ответ API. Там, где таблица не критична для понимания агентом, заменяли ее на компактный простой текст.

💬 Промпт для агента: Найди наши справочные документы/системные промпты, где есть markdown-разметка — особенно таблицы. Посчитай реальное количество токенов в них через настоящий ответ API (поле usage в ответе Anthropic), не через деление количества символов на 4. Затем перепиши те же данные компактным простым текстом или списком вместо таблицы, сохранив смысл, и покажи мне разницу в реальных токенах до и после.

Рассмотрела, но пока не стала делать

Идея: у AI-провайдеров обычно есть несколько моделей — «быстрая и дешевая» и «самая умная и дорогая». Не для каждой задачи нужна самая мощная модель.

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

⚠ Что пробовала, но не сработало

Идея: просить AI самого «сокращать» длинные разговоры после определенного числа сообщений — казалось, что часть разговоров тянется без пользы.

Что выяснилось на реальных данных: люди, которые правда бросают разговор, делают это рано (5-11 сообщений). А нормальные успешные разговоры длиннее (16-24 сообщения). Лимит по числу сообщений ударил бы по хорошим, успешным разговорам — а не по тем, что реально проблема. Не стали внедрять.

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

Пример 1. Укоротили справочный документ для части агентов (пункт 7 выше), ожидая экономию ~2300 токенов на вызов. После реального замера получилось всего 390 токенов — примерно в 6 раз меньше обещанного.

Пример 2. Весь план экономии в одном из раундов сначала считали по формуле «число символов ÷ 4» (стандартная грубая прикидка количества токенов). Когда сверили с реальными токенами из ответа самого API, оказалось, что эта формула занижала реальный размер документов на 15-20% (см. пункт 8 про markdown) — то есть обещанный процент экономии в моменте пришлось пересчитывать уже постфактум, и не один раз.

💬 Промпт для агента: Прежде чем считать любую твою оценку экономии токенов окончательной — перепроверь её на реальных данных. Возьми конкретный реальный вызов ДО изменения, посчитай его настоящие токены из поля usage в ответе API (не через деление числа символов на 4 и не на глаз по объёму текста). Внеси изменение. Посчитай токены снова на том же самом типе запроса. Покажи мне разницу в реальных цифрах, а не в прогнозе.

Практические совет по контролю расходов

Заведите способ реально считать «сколько стоит один разговор целиком» и время от времени сверяйте со счетом, который присылает сам AI-провайдер.

У Anthropic есть отдельный, более привилегированный API-ключ специально для автоматического получения данных о реальных расходах (не для обычных AI-запросов, а именно для сверки счёта). Но здесь стоит помнить: каждый дополнительный ключ — это дополнительный риск утечки, а не просто еще один пароль. У меня уже был такой случай, когда именно утекший ключ обошелся в реальные деньги. Поэтому для начала проще и безопаснее просто вручную скачивать CSV-экспорт расходов из консоли провайдера раз в 1-2 недели — не заводить отдельный ключ ради автоматизации, если острой необходимости в ней нет.

А теперь я обращаюсь к Хабр-сообществу. Как не великий эксперт в области экономии ИИ-токенов, мне будет очень полезно почитать рекомендации профессионалов: как еще можно снизить затраты, на что обратить внимание и проверить.

А если вы строите свой продукт / стартап, то я приглашаю вам подписаться на мой Телеграм канал, в котором я рассказываю про свой опыт и скоро я, наконец, перейду к главной части — как "навайбкодить" пользователей. Потому что софт в 2026 году может разработать каждый, а вот намайнить покупателей на этот софт задачка со звездочкой. Присоединяйтесь: https://t.me/julia_goncharov/

Избранные посты: