Claude Code API: когда он дешевле подписки
Подписка оплачивает человека за клавиатурой, API — код, который работает без человека. Показываю, как считать границу, и где я сам держу одно, а где другое.
Два разных счёта за одно и то же
«Claude Code API или подписка?» — вопрос задают так, будто это два тарифа одного продукта. Это не тарифы. Это два разных ответа на вопрос, кто сидит за клавиатурой.
Подписка оплачивает вашу личную работу: вы открываете терминал, ставите задачи, принимаете результат. Лимиты считаются по интервалам использования, и пока вы человек, а не завод, их обычно хватает.
Claude Code API оплачивает работу, которую делает ваш код без вас: фоновые задачи на сервере, генерация внутри вашего продукта, агент, который ночью разбирает заявки. Здесь вы платите за фактический объём.
Отсюда простое правило, к которому я пришёл на своих проектах: подписка — это про вас, API — это про ваш продукт. Дальше разберём, как посчитать границу в деньгах, потому что она у каждого своя.
Сколько у меня уходит на подписку
Чтобы разговор был предметным: моя подписка на Claude стоит 22 000 ₽ в месяц, а личный сервер — 18 000 ₽. Это профессиональный уровень: я работаю в этом каждый день, веду свои проекты и клиентские, и подписка окупается первым же заказом.
Отдельно стоит следить за лимитами. Весной, с 13 по 27 марта 2026 года, Claude на две недели удваивал пятичасовой лимит в непиковые часы — за пределами 8:00–14:00 по восточному времени, то есть по нашему как раз вечером и ночью. Включалось автоматически на всех тарифах: Free, Pro, Max, Team. Мелочь, но если вы работаете ночами, это ощутимая прибавка без доплаты.
Вывод по подписке: пока задачи ставит человек руками, она почти всегда выгоднее. Один активный разработчик физически не выберет столько генераций, чтобы API оказался дешевле.
Как считать API
Claude Code API считают не в токенах, а в стоимости одного полезного действия. С API логика меняется: вы перестаёте платить за доступ и начинаете платить за единицу работы. Тарифы за токены меняются по нескольку раз в год, поэтому смотрите актуальные цифры у вендора — а считать нужно не токены, а стоимость одного полезного действия.
Покажу метод на примере из своего сервиса, где мы делали модуль озвучки текста нейросетью. Там экономика посчитана до копейки: около 30 рублей за тысячу знаков, тридцатисекундный рилс — 12 рублей, часовой подкаст — примерно полторы тысячи. Это дешевле и быстрее, чем нанимать диктора, и — главное — цифра понятна заранее.
Ровно так же нужно считать любую генерацию в продукте. Не «сколько стоит API», а «сколько стоит одна карточка товара, один ответ клиенту, один разбор заявки». Как только у вас есть цена одного действия, дальше считается всё: сколько действий в месяц, какая себестоимость, при каком объёме вы упираетесь в потолок.
Четыре ситуации, где API дешевле
Генерация внутри вашего продукта. Если тексты, описания или ответы клиентам генерируются для ваших пользователей, подписка тут вообще не подходит — ни технически, ни по правилам использования. Нужен API и посчитанная себестоимость одного действия.
Фоновые задачи на сервере. Ночной разбор заявок, обработка входящих писем, классификация обращений, сборка отчётов. Человека за клавиатурой нет, задачи идут по расписанию — платите за объём и не держите подписку, которая простаивает днём.
Пиковая нагрузка вместо ровной. Сезонный проект, где три недели интенсивной работы, а потом тишина. Подписка списывается ровно, API — по факту. На неровной нагрузке API почти всегда дешевле.
Много одновременных процессов. Когда несколько агентов работают параллельно и упираются в лимиты, а не в бюджет, API снимает потолок — вы ограничены только деньгами и здравым смыслом.
Три ситуации, где подписка выигрывает
Вы учитесь. На старте расход непредсказуем, а руки ещё не поставлены. Подписка ограничивает вас лимитом, а не счётом, и это полезно: вы не проснётесь с неожиданной суммой.
Вы работаете руками каждый день. Один человек, один проект, долгие сессии, много итераций. Тут подписка — самый дешёвый способ, других мнений у меня нет.
Вам важна предсказуемость. Фиксированная сумма в месяц проще для планирования, чем счёт по факту, особенно когда вы не один.
Как посчитать свою границу
Три шага, которые займут полчаса.
- Определите цену одного полезного действия. Прогоните десять реальных задач через API, поделите расход на десять. Не берите средние цифры из интернета: у вас свои промпты и своя длина контекста.
- Умножьте на месячный объём. Честно: не на планируемый, а на тот, который реально нужен бизнесу сегодня.
- Сравните с подпиской. Получилось меньше стоимости подписки — берите API. Больше — оставайтесь на подписке и оптимизируйте промпты, потому что расход у вас раздут.
Чаще всего у людей выходит гибрид, и это нормально: подписка на свою ручную работу плюс API на то, что молотит в продукте. У меня именно так.
Как не спалить бюджет на API
Пять правил, которых я держусь в продакшене.
- Лимит на уровне вашего кода. Дневной и месячный потолок расходов, после которого задачи встают в очередь, а не продолжают жечь деньги. Это первое, что нужно написать, ещё до фич.
- Дешёвая модель на простых шагах. Классификация, извлечение полей, короткие проверки не требуют самой мощной модели. Тяжёлую оставьте на сложное.
- Кэш на повторах. Одинаковые запросы, повторяющийся системный промпт, типовые ответы. Повторная генерация того же самого — самая обидная статья расходов.
- Короткий контекст. Не отправляйте весь проект, если задача про один файл. Длина контекста — главный множитель счёта.
- Логирование расходов по функциям. Вы должны видеть, какая именно фича съедает бюджет. Без этого оптимизировать нечего.
Кому это считать за вас
Если у вас продукт, внутри которого работает ИИ, эта арифметика перестаёт быть теорией: от неё зависит себестоимость и цена для клиента. Я такие вещи считаю до строчки кода — на этапе, когда решается архитектура: где фоновые задачи, где очереди, где лимиты, где кэш.
Нужен сервис или автоматизация, в которой генерация встроена в процесс и не разоряет вас на третьем месяце, — напишите мне, посчитаем юнит-экономику под ваш объём. Как это выглядит на практике, можно посмотреть в разработке сервисов.