У подписки и оплаты за токены есть чёткая точка пересечения

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

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

Важная единица - принятая функция

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

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

Базовая стоимость при оплате по счётчику:

metered_feature_cost = sum(attempt_input_tokens * input_rate
                         + attempt_output_tokens * output_rate
                         + tool_charges)

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

Для подписки нужна та же граница:

subscription_feature_cost = allocated_monthly_subscription_cost
                            / accepted_features_within_plan

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

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

Доля повторных попыток нелинейно меняет их число

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

expected_attempts = 1 / (1 - r)

При доле повторов 20% ожидается 1,25 попытки. При 50% - 2 попытки. При 80% - 5 попыток. Кривая становится круче, потому что каждая повторная попытка тоже может не сработать. Расчёт 1 + r учитывает максимум один повтор и сильно занижает объём сложной работы.

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

observed_attempts_per_feature = total_material_attempts / accepted_features
observed_retry_rate = (total_material_attempts - accepted_features)
                      / total_material_attempts

Если на 40 принятых функций потребовалось 68 существенных попыток, число попыток на функцию равно 1,7, а наблюдаемая доля повторов составляет около 41%. Этот показатель уже включает повторные неудачи и надёжнее попыток восстановить ход работы по памяти.

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

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

Рост контекста часто обходится дороже самого повтора

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

Смоделируйте рост ввода по наблюдаемому числу токенов или с помощью множителя:

input_tokens_on_attempt_n = initial_input_tokens * growth_factor^(n - 1)
output_tokens_on_attempt_n = initial_output_tokens * output_factor^(n - 1)

Предположим, начальная попытка использует 30 000 входных токенов и 4 000 выходных. Если ввод растёт на 35% с каждой попыткой, а вывод остаётся прежним, четвёртая попытка несёт примерно 73 800 входных токенов. Пять внешне одинаковых сообщений в чате не дают пять одинаковых счетов.

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

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

reset_cost = repository_context + specification + accepted_decisions

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

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

Найдите точку пересечения одним уравнением

Чистое сравнение использует месячное число принятых функций как общий результат. Задайте переменные:

• S: общая месячная стоимость подписки, включая обязательные места.
• F: число принятых функций в месяц.
• A: ожидаемое число попыток на одну принятую функцию.
• C(A): стоимость токенов и инструментов по счётчику для этих попыток, включая рост контекста.
• L: максимальное число принятых функций, которое поддерживает подписка до лимитов или доплат.

В пределах включённой мощности подписка выгоднее, когда:

S / F < C(A), provided F <= L

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

F_crossover = S / C(A)

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

Чтобы найти именно долю повторов, подставьте A = 1 / (1 - r) и функцию стоимости для растущего контекста. В простом случае с одинаковой стоимостью попытки c:

S / F = c / (1 - r)
r_crossover = 1 - (c * F / S)

Этот короткий путь работает, только когда попытки стоят примерно одинаково. Если в поздних попытках больше контекста, рассчитайте C(A) для нескольких вариантов доли повторов и найдите первую, при которой месячная стоимость по счётчику превышает S. Небольшая таблица понятнее, чем попытка подогнать замкнутую формулу под многоуровневое кеширование и лимиты тарифов.

Сделайте таблицу: доли повторов по строкам, месячное число функций по столбцам. В каждой ячейке покажите metered_monthly_cost - subscription_monthly_cost. Отрицательное значение означает, что оплата по счётчику дешевле, положительное - что дешевле подписка. Добавьте второй индикатор для превышения мощности. Финансово выгодная ячейка, выходящая за лимит тарифа, не даёт пригодной точки пересечения.

Пример расчёта показывает скрытые переменные

Рассмотрим продуктовую команду из четырёх человек, которая оценивает подписку за $120 за место в месяц. Значит, тариф стоит $480 в месяц. Это иллюстративная цена, а не утверждение о каком-либо конкретном сервисе. Команда ожидает 24 принятые функции среднего размера за месяц.

После учёта реального соотношения входных токенов, кешированного ввода и вывода ставки по счётчику составляют $0.000006 за входной токен и $0.000018 за выходной. Плата за инструменты не учитывается, потому что в этом процессе команда не использует платные инструменты. Первая попытка в среднем содержит 40 000 входных токенов и 5 000 выходных. Ввод увеличивается на 30% при каждом повторе, а вывод остаётся на уровне 5 000 токенов.

Без повторов одна функция стоит:

40,000 * $0.000006 + 5,000 * $0.000018 = $0.33

Это всего $7.92 за 24 функции, поэтому оплата по счётчику уверенно выигрывает. При независимой доле повторов 50% ожидаемое число попыток равно двум. Приблизительный расчёт двух попыток на функцию даёт:

attempt 1: 40,000 input + 5,000 output = $0.33
attempt 2: 52,000 input + 5,000 output = $0.402
feature total: $0.732
monthly total: $17.568

Подписка всё ещё проигрывает с большим запасом. Даже пять попыток с растущим контекстом в этом примере стоят около $2.42 на функцию, или примерно $58 в месяц. Одна лишь высокая доля повторов не делает тариф за $480 выгодным, когда исходная функция мала, а ставки на токены низкие.

Теперь изменим размер функции, а не долю повторов. Рефакторинг всего репозитория начинается с 900 000 входных токенов и 35 000 выходных, а ввод растёт на 25%. Первая попытка при тех же ставках стоит $6.03. Пять попыток стоят около $41.88. При 24 таких функциях расходы по счётчику достигают примерно $1,005. Подписка может стать выгоднее, но только если её мощность выдерживает эту нагрузку.

Короткий расчёт с одинаковой стоимостью попыток даёт приблизительный порог до учёта роста контекста. При $S = 480, $F = 24 и стоимости первой попытки $c = 6.03:

r_crossover = 1 - (6.03 * 24 / 480)
            = 0.6985

Приблизительная точка пересечения - доля повторов 69.85%. Рост контекста снижает этот порог, потому что поздние попытки стоят больше $6.03. Таблица сценариев поместит более реалистичную точку пересечения между проверенными значениями, не создавая ложной точности до знаков после запятой.

Этот пример также объясняет, почему чужой порог повторов нельзя переносить без проверки. Изменение начального контекста с 40 000 до 900 000 токенов влияет на решение гораздо сильнее небольшого изменения доли неудач. Копируйте метод, а не процент.

Места могут свести на нет выгодное сравнение токенов

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

Рассчитывайте S по оплачиваемым местам, а не по числу ежедневно активных пользователей:

S = required_seats * seat_price + fixed_plan_fees

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

Использование мест заслуживает отдельного показателя:

seat_utilization = active_prompting_days / available_workdays

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

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

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

Лимиты использования создают вторую точку пересечения

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

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

feature_capacity = usable_monthly_units
                   / expected_units_per_accepted_feature

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

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

hybrid_cost = subscription_cost + max(0, usage - included_usage) * overage_rate

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

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

Koder.ai предлагает тарифы free, pro, business и enterprise, поэтому сравнивать нужно тот тариф, чьи места и мощность подходят команде, а не самый дешёвый отображаемый вариант. Его режим планирования, снимки состояния и откат также могут изменить наблюдаемое число повторов, поэтому команде стоит измерить пилот, а не переносить долю повторов из другого процесса.

Как измерить пилот и не обмануть себя

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

Записывайте одну строку на каждую существенную попытку со следующими полями:

• ID функции и диапазон размера функции;
• номер попытки и принятый или отклонённый результат;
• входные токены, кешированные входные токены и выходные токены либо единицы тарифа;
• сброс контекста, стоимость инструментов и прошедшее рабочее окно;
• место или человек, начавший попытку.

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

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

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

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

Выбирайте тариф по форме нагрузки, а не по убеждениям

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

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

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

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

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

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

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

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

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

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

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

Отдел закупок иногда просит одну безубыточную долю повторов. Дайте им диапазон, привязанный к названным допущениям: например, от 55% до 65%, если месячное число принятых функций остаётся между двумя наблюдаемыми значениями, а контекст растёт в измеренном диапазоне. Укажите долю, при которой не хватает мощности. Такой ответ менее аккуратен, чем один процент, зато гораздо полезнее, когда месяц релиза отличается от месяца поддержки.

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

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

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

Округляйте деньги только для представления. Внутри расчёта сохраняйте полные числа токенов и точность ставок, особенно если кешированный и некешированный ввод имеют разную цену. Но показывайте безубыточную долю повторов диапазоном или целым процентом. Результат вроде 62.437% создаёт видимость точности, которой входные данные не подтверждают.

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