Цена AI-конструктора приложений зависит от того, что считается работой

Самый дешевый тариф для 100 итераций запросов в неделю обычно тот, который учитывает меньше всего работы вокруг каждого запроса. Указанная месячная цена почти ничего не говорит, пока не ясно, попадают ли в тот же счетчик повторная попытка, планирование, запуск тестов, развертывание и работа агента в фоне.

Я видел, как команды сравнивают тарифы, деля цену подписки на 100 запросов. Арифметика аккуратная, но неверная. Запрос на изменение текста кнопки и запрос на перестройку базы данных для пишущего человека выглядят как одно сообщение, однако счета за них могут сильно отличаться. Честное сравнение начинается с журнала нагрузки, затем к нему применяются правила тарификации каждого поставщика.

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

Одинаковое число запросов может скрывать три разных счета

Число пользовательских сообщений измеряет разговор, а не вычисления или выполненную работу. Тарифы с кредитами обычно измеряют активность модели, тарифы по задачам - определенную поставщиком единицу работы, а фиксированные тарифы продают доступ в определенных границах. Поэтому итоговые суммы отличаются, даже если приложение и 100 еженедельных запросов остаются теми же.

Предположим, основатель проекта каждую неделю просит внести 70 небольших изменений интерфейса, 20 изменений в нескольких файлах и 10 изменений, связанных со сборкой или развертыванием. Видимое число - 100. За ним конструктор может изучить репозиторий, составить план, несколько раз вызвать модель, запустить тесты, исправить неудачное изменение, пересобрать приложение и оставить агента работать после появления ответа в чате. Один тариф может брать плату за каждый вызов модели. Другой посчитает всю последовательность одной задачей. Подписка может включать эту работу, ограничивать ее или относить часть к перерасходу.

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

Для сравнения берите среднее значение 4.33 недели в месяце, а не делайте вид, что в каждом месяце четыре недели. Сто еженедельных итераций превращаются в 433 ежемесячные. Эта небольшая поправка добавляет 33 итерации еще до учета хотя бы одной повторной попытки или фоновой задачи.

Полезный запрос на расчет просит поставщика классифицировать работу, а не просто оценить общую сумму. Спросите: что запускает счетчик? Когда он останавливается? Считается ли неудачный запуск? Считается ли автоматическая повторная попытка? Какая работа продолжается после того, как интерфейс сообщает о готовом ответе? Переносится ли неиспользованный объем? Ответы определяют счет.

Определите одну нагрузку до того, как открыть калькулятор

Соберите типичную неделю из работы, которую вы действительно ожидаете, и зафиксируйте ее перед сравнением тарифов. Если менять нагрузку под каждую модель оплаты, вы проверяете рекламные тексты, а не цены.

Для расчета я возьму такую еженедельную нагрузку:

• 70 небольших правок по одной кредитной единице каждая
• 20 изменений в нескольких файлах по три кредитные единицы каждое
• 10 изменений сборки или развертывания по пять кредитных единиц каждое
• 25 повторных запусков в среднем по две кредитные единицы
• 35 фоновых запусков, которые суммарно потребляют 45 кредитных единиц

Первые попытки по 100 запрошенным итерациям расходуют 180 условных кредитных единиц. Повторные попытки добавляют 50. Планирование, индексация, тесты и развертывание добавляют 45. Итого 275 единиц в неделю, или 1,190.75 единиц в среднем месяце.

Та же активность иначе выглядит при оплате по задачам. Она создает 100 задач, инициированных пользователем, 25 повторных запусков и 35 фоновых запусков задач в неделю. Это 160 событий в неделю и 692.8 события в месяц. Будут ли все 692.8 событий платными, зависит от определения задачи в договоре.

Записывайте успешную и неудачную работу отдельно. Доля ошибок, рассчитанная только по видимым сообщениям, не учитывает незаметные исправления, автоматическое переключение моделей и повторные запуски тестов. Экспорт использования платформы, если он есть, надежнее истории чата: чат может объединять несколько запусков агентов в один ответ.

Берите неделю с обычным рабочим беспорядком: один неясный запрос, один конфликт зависимостей, тест, упавший по посторонней причине, и исправление развертывания. Идеальная демо-неделя дает бюджет, который держится лишь до начала реальной разработки.

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

Пакеты кредитов берут плату за движение внутри конструктора

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

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

Оценим условную нагрузку пакетом из 500 единиц за $30. Месячный спрос равен 1,190.75 единицам. Поскольку пакеты нельзя делить, покупателю нужно три пакета, и он платит $90. В конце месяца на счете остается 309.25 единиц, если кредиты не сгорают. Фактическая стоимость потребленной работы составляет около 7.56 цента за единицу, хотя в пакете заявлено 6 центов: пришлось купить неиспользованную емкость.

Перенос меняет результат. Если оставшиеся 309.25 единиц сохраняются, в следующем месяце может понадобиться два, а не три пакета. За несколько стабильных месяцев средняя цена приблизится к заявленной ставке. Если кредиты сгорают каждый месяц, застрявший остаток - часть цены. Никогда не исключайте его из модели.

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

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

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

Оплата по задачам зависит от того, где задача начинается и заканчивается

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

Применим условную ставку $0.14 к каждому начатому событию из журнала. При 692.8 ежемесячных событиях стоимость после округления до центов составит $96.99. Это выше результата в $90 для пакетов кредитов, хотя четырнадцать центов на странице цен кажутся небольшой суммой.

Теперь изменим одно предложение договора: брать плату только за 433 итерации, запрошенные пользователем, включая повторные попытки и фоновую работу в каждую задачу. Месячная стоимость падает до $60.62. В приложении ничего не изменилось. Изменилась граница задачи, и она сдвинула сумму на $36.37.

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

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

У оплаты по задачам есть преимущество для бюджета, когда единица соответствует тому, что человеку понятно. Команда увереннее оценит 400 принятых изменений, чем миллионы токенов. Это преимущество исчезает, если продукт называет индексацию, планирование, тестирование и развертывание отдельными задачами. Прочитайте названия событий в реальном счете или экспорте использования, прежде чем считать единицу стабильной.

Спросите и о параллельности. Два одновременно работающих агента могут сократить время выполнения, но удвоить число начатых задач. Фоновое исправление, запускающее агента тестирования, может считаться один раз, дважды или не считаться вовсе. Счет следует за счетчиком, а не за временем на часах.

Фиксированные подписки выгодны только в пределах включенного объема

Фиксированная подписка дешевле для этой нагрузки, когда месячная плата включает все 433 пользовательские итерации, 108.25 повторных запусков и 151.55 фоновых запусков. Если какая-либо категория не входит в подписку, добавьте ее до вывода о том, что фиксированный тариф дешевле.

Возьмем условный тариф $79 в месяц, включающий до 600 интерактивных и повторных запусков плюс 200 фоновых. В примере получается 541.25 интерактивных и повторных запусков и 151.55 фоновых в месяц. Оба значения укладываются в лимиты, поэтому стоимость остается $79. При этих допущениях фиксированная цена выигрывает у пакетов кредитов за $90 и тарифа за начатые задачи за $96.99.

Слово «безлимитный» не имеет ценности в таблице. Замените его реальным порогом добросовестного использования, ограничением параллельности, ограничением моделей или правилом замедления. Если поставщик не называет границу, постройте низкий и высокий сценарий. Тариф, который выглядит дешевым только при безграничном толковании, не дает надежной цены.

Фиксированные тарифы также создают скачки цены. При 599 включенных запусках еще один может ничего не стоить. При 600 следующий запуск может вызвать перерасход или потребовать более дорогой уровень. Постройте хотя бы три уровня нагрузки: спокойный месяц, ожидаемый месяц и месяц релиза. Один ожидаемый сценарий скрывает точку, в которой подписка дорожает.

Количество мест важно, когда оплата зависит от пользователей, а не от работы. Тариф $79 для одного человека стоит $316 для четырех обязательных мест, даже если команда делит те же 433 итерации. Не предполагайте, что общий доступ к аккаунту разрешен. Учтите людей, которым нужно проверять запросы, утверждать развертывания или изучать использование.

Фиксированная плата может поддерживать полезные эксперименты, потому что каждая неудачная идея не создает заметного микросписания. Она также может скрывать потери, пока платформа не начнет ограничивать аккаунт. Видимость использования все равно важна. Нужно знать, не зациклились ли агенты и не пересечет ли месяц релиза включенную границу.

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

Повторные попытки должны быть в базе, а не в сноске

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

В примере 125 интерактивных попыток на 100 запрошенных итераций, то есть коэффициент повторных попыток равен 1.25. Это не означает, что 25 процентов запросов просто терпят неудачу. Некоторым требованиям нужно уточнение, некоторые правки проходят проверки кода, но не соответствуют намерению, а часть ошибок связана с инструментами или зависимостями. Для счета эффект одинаков, когда тариф измеряет еще одну попытку.

Измеряйте повторные попытки по правилу, которое два человека смогут одинаково применять. Считайте попытку повторной, если пользователь снова добивается того же результата после отклонения или исправления предыдущего вывода. Не считайте повторной попыткой действительно новое требование. Автоматические повторы отмечайте отдельно, поскольку пользователь может их вообще не увидеть.

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

Повторные попытки по-разному влияют на модели оплаты:

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

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

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

Фоновые агенты - невидимый множитель

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

В нашем примере заложены 35 фоновых запусков и 45 кредитных единиц в неделю. Это намеренно видимые допущения. Замените их данными использования из пилота. Если поставщик показывает только один общий итог, выполните один и тот же запрос с отключенной дополнительной автоматизацией, затем с включенной. Разница - оценка, а не доказательство, но она лучше, чем считать работу бесплатной.

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

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

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

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

Установите бюджет для фоновой работы, если продукт позволяет, но не путайте лимит с предсказуемостью. Лимит предотвращает перерасход, останавливая работу. Приложение все равно может не выйти в релиз, пока агент ждет дополнительной емкости. Записывайте и финансовое ограничение, и операционное последствие.

Проведите каждого кандидата через один журнал

Журнал делает сравнение воспроизводимым и показывает неоднозначности договора до того, как они превратятся в спор по счету. Одна строка должна описывать одно измеряемое событие и содержать достаточно контекста, чтобы сопоставить его с кредитами, задачами и лимитами подписки.

Скопируйте этот заголовок CSV и используйте его во время пилота:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Не смешивайте тип события и результат. Фоновый тест может успешно завершиться, хотя запрошенное изменение все еще не принято. Если свести эти факты к одному статусу, вы не сможете проверить правило поставщика о завершенной задаче.

В конце недели рассчитайте четыре значения:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Затем примените условия тарифов, не меняя строки. Для условного каталога расчет такой:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Таблица также должна показывать застрявшие кредиты, остаток включенной емкости и следующую ценовую границу. У выигравшего в примере тарифа остается 58.75 интерактивных запусков и 48.45 фоновых. Такого запаса недостаточно для недели релиза, где работа развертывания удваивается, поэтому этот сценарий нужно рассчитать до принятия обязательств.

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

Отклонения важнее цены на витрине

В примере фиксированная подписка стоит $79, пакеты кредитов - $90, а оплата начатых задач - $96.99. Такой порядок действует только для заявленного каталога и нагрузки. Небольшое изменение учета повторов или включенной фоновой работы может его изменить.

Рассчитайте точку безубыточности для каждой пары. Тариф $79 выгоднее пакетов по $30, когда месячный спрос требует трех или более пакетов, если неиспользованные кредиты не имеют будущей ценности. Если перенос позволяет использовать каждую единицу, $79 соответствует примерно 1,316.7 кредитной единицы по шесть центов. При меньшем использовании полностью израсходованные кредиты дешевле.

По сравнению с начатыми задачами по $0.14 сумма $79 соответствует примерно 564.3 событиям. Ожидаемые 692.8 событий выше этой точки. Однако если тариф по задачам берет плату только за 433 запрошенные итерации, он стоит $60.62 и выигрывает. Одно определение снова важнее заявленной ставки.

Проводите анализ чувствительности, а не делайте вид, будто оценка точна. Для этой нагрузки измените коэффициент повторов с 1.10 до 1.50, фоновую работу с 20 до 60 еженедельных событий и расход на сложные правки на разумный множитель, раскрытый поставщиком. Не нужны десятки сценариев. Нужны несколько переменных, способных изменить решение.

Денежный поток и обязательства оценивайте отдельно от стоимости единицы. Пакеты могут сохранять гибкость. Месячная подписка создает предсказуемый потолок, пока вы остаетесь в ее границах. Годовая подписка меняет гибкость на скидку. Экспорт исходного кода и снимки состояния могут снизить стоимость ухода из конструктора, но не делают миграцию бесплатной: экспортированному приложению все еще нужны рабочая сборка, инфраструктура и человек, способный его поддерживать.

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

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

Проверьте модель оплаты приемочным тестом

Модель цен готова к решению, когда другой человек может воспроизвести месячную сумму по журналу и условиям тарифа. Если расчет зависит от того, как продавец задним числом истолкует внутреннюю задачу, модель не прошла проверку.

Используйте этот краткий приемочный список:

1. Запишите 100 типичных запрошенных итераций или меньшую выборку, включающую все основные типы работы.
2. Отмечайте повторы, автоматические повторы, планы, тесты, сборки, развертывания и другие фоновые запуски.
3. Сопоставьте каждое событие с правилом поставщика о кредитах, задачах или включенном лимите.
4. Рассчитайте ожидаемые, спокойные месяцы и месяцы релиза с тем же множителем 4.33.
5. Сохраните условия тарифа и сравните первый реальный счет с прогнозом.

До пилота задайте допустимое отклонение. Например, можно изучать любой итог, превышающий прогноз более чем на 10 процентов. Этот процент - управленческий выбор, а не отраслевой стандарт. Он нужен, чтобы провести проверку, пока история событий еще доступна.

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

Первые три расчетных периода держите журнал рядом со счетом: спокойный пилот может не показать пакетные задания, работу перед релизом и автоматические исправления. Поэтому самый дешевый вариант для 100 еженедельных итераций зависит от условий, но решение не обязано быть расплывчатым. В явном примере выигрывает фиксированная подписка за $79. При оплате задач с привязкой к успешному результату та же работа стоит $60.62, и выигрывает оплата по задачам. Пакеты кредитов выгодны при меньшем или скачкообразном использовании, если перенос предотвращает потери. Запишите, что считается, измерьте скрытую работу и пусть счет подтвердит обещание.