[ blog · deep-dive ]7 min read

Почему API должны брать деньги только за успех — аргумент в пользу тарификации по HTTP 200

Sarah ChoyОпубликовано 3 мая 2026 г.7 мин чтения

Большинство API берёт деньги за каждый тарифицируемый вызов. ИИ-агенты постоянно ретраят при нестабильных апстрим-сервисах — а значит, легаси-модель 'берём всегда' фактически облагает налогом устойчивость. Вот аргумент в пользу оплаты только при HTTP 200 и что это меняет в дизайне агентов.

Кратко

•ИИ-агенты разумно ретраят при временных сбоях (5xx, таймауты, rate-limit'ы). При тарификации 'берём всегда' каждый ретрай — это реальное списание, превращая апстрим с uptime 99.5% в 5-кратный штраф по стоимости в те самые плохие 0.5%.
•'Берём только при HTTP 200' выравнивает интерес провайдера с интересом клиента: провайдеры чинят нестабильность, клиенты за неё не платят.
•Это также разблокирует паттерны дизайна — агрессивные бюджеты ретраев, оптимистичный префетч, избыточные вызовы — которые при 'берём всегда' непомерно дороги.
•Большинство провайдеров так не делают, потому что их легаси-инфраструктура привязывает учёт к апстрим-вызову, а не к ответу. Это ограничение биллинговой системы, выдаваемое за политику.

Поведение, которое мы пытаемся поощрить

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

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

Конкретно: агент, который обращается к API с uptime 99.5% и ретраит до пяти раз при временных сбоях, в те самые плохие 0.5% сгенерирует до 5× вызовов — и 5× счёта. Агент поступил правильно. Клиент платит за нестабильность апстрима.

Более простая альтернатива

Берите деньги только при HTTP 200. Конкретно — только при успешном ответе с документированной формой ответа. Всё остальное — 4xx за ошибки вызывающей стороны, 5xx за наши ошибки, таймауты, rate-limit'ы, частичные-но-некорректные ответы — бесплатно.

Звучит как мелкий сдвиг. Это не так. Он меняет то, что экономически рационально с обеих сторон:

У провайдера теперь есть прямой финансовый стимул чинить нестабильность. Каждый нестабильный 503 — это упущенная продажа, а не халява. Мы обнаружили, что переход на оплату только за успех был самой мощной силой, вытащившей работу над надёжностью в начало дорожной карты — нет такого трюка в таблице, который заставил бы простой выглядеть нормально, когда вы упускаете выручку от этих вызовов.
Клиент может агрессивно закладывать бюджеты ретраев. Цикл с 5 ретраями и экспоненциальным бэкоффом — это no-brainer, когда худший случай при временном сбое — один оплаченный вызов (итоговый успех) вместо шести (по одному за каждую попытку).
Рынок может сравнивать API по долларам-за-успешный-вызов, а не по долларам-за-попытку. Это правильная единица. Если два API оба публикуют '$0.001 за вызов', но у одного uptime 99.9%, а у другого 95%, то видимые пользователю затраты различаются в 5× при модели 'берём всегда' и ровно на 0% при 'только за успех'. Какой из них стоит предпочесть покупателю — очевидно, и 'только за успех' делает это видимым.

Что меняется в том, как вы строите агентов

1. Бюджеты ретраев становятся бесплатными

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

2. Оптимистичный префетч становится дешёвым

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

3. Избыточные вызовы становятся инструментом надёжности

Иногда самая дешёвая стратегия надёжности — отправить два запроса к двум разным API, взять тот, что вернётся первым, и отбросить медленный. При 'берём всегда' это удваивает счёт. При 'только за успех' отброшенный вызов бесплатен (ответ вы не использовали, не заплатили). Внезапно стратегии хеджирования, которые были дорогими абстракциями, становятся практичными.

Что должно означать 'успех'

Модель работает, только если 'успех' однозначен. Мы определяем его узко:

HTTP 200 с документированной схемой ответа — тарифицируется.
HTTP 200 с ошибкой, обёрнутой в тело ответа — не тарифицируется (это была бы лазейка, ломающая всю модель).
HTTP 4xx — не тарифицируется. Сюда входят 401 (аутентификация), 402 (нехватка кредитов), 422 (валидация), 404 (не найдено в некоторых контекстах).
HTTP 5xx — не тарифицируется.
HTTP 429 (rate-limit) — не тарифицируется.
Сетевые ошибки / таймауты до нашего edge — не тарифицируются.

Для батчевых эндпоинтов (например, URL Extract с 25 URL в одном вызове) весь вызов — это один HTTP 200, если хоть какие-то URL удались, тарифицируемый по пер-URL ставке. Поле status по каждому URL сообщает вызывающей стороне, какие URL отвалились. Работа была выполнена; она тарифицируется.

Почему большинство провайдеров так не делают

Три причины, в порядке убывания значимости:

Биллинговая инфраструктура. Стандартный паттерн — учитывать на API-шлюзе, до того как известен ответ. Шлюз эмитит тарифицируемое событие в Kafka, биллинговая система его агрегирует, счёт отправлен. Перепаять учёт так, чтобы он срабатывал после того, как апстрим-сервис ответил со статус-кодом, требует либо (a) связать шлюз со здоровьем бэкенда (создавая новые режимы сбоев), либо (b) написать пайплайн сверки, который ретроспективно возвращает кредиты за неудавшиеся вызовы. И то, и другое — реальная инженерная работа.
Привычка. Паттерн задали надёжные бэкенды — Twilio, AWS, Stripe. Он отлично работает, когда апстрим на uptime 99.99%. API, оборачивающие LLM, скрейпящие веб или вызывающие медленных дата-партнёров, куда менее надёжны, но биллинговый паттерн унаследован от надёжной эпохи и так и не обновлялся.
Выручка. 'Берём всегда' — это просто больше денег. Большинству провайдеров не приходилось конкурировать по этому измерению, потому что большинство клиентов не были агентским трафиком, а синхронные пользователи-люди терпят случайные сбои лучше, чем чтение биллинговой модели.

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

На что смотреть как покупателю

Если вы оцениваете дата-API под агентскую нагрузку, три прямых вопроса:

'Вы берёте деньги только при HTTP 200 или за каждую тарифицируемую попытку?' — нужен прямой ответ. Не принимайте 'обычно' или 'зависит от плана'.
'Как тарифицируется HTTP 207 / частичный успех?' — выявляет лазейку.
'Какой у вас заявленный uptime и каков механизм возврата по SLA, если вы его не выполнили?' — 'только за успех' это сильный сигнал, но он не заменяет реальный SLA. Должны быть оба.

Почему мы построили API Pick именно так

Каждый эндпоинт в API Pick — Web Search, URL Extract, Email Validator, все они — тарифицируется только при HTTP 200. Это сделало реализацию чуть сложнее. Это сделало инженерную ответственность за надёжность куда острее. Это сделало нашу цену предсказуемой для агентских нагрузок. А ещё это заставило наш внутренний финансовый дашборд правильно наказывать нас, когда мы выпускаем что-то нестабильное. Это ровно та петля обратной связи, которую мы хотим.

Сдвиг, на который это указывает

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

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

Часто задаваемые вопросы

Разве 'только за успех' не подталкивает провайдеров выдавать успехи за сбои?

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

А если мой вызов частично успешен — например, батчевый extract, где 2 из 25 URL отвалились?

Две разумные модели. (a) Весь вызов — HTTP 200, если хоть какие-то URL удались; сбои по отдельным URL отражаются в пер-URL статусе. Работа была выполнена, значит, тарифицируется. (b) HTTP 207 (multi-status) для частичного — каждый URL тарифицируется по отдельности. Мы выбрали (a), потому что это делает цену предсказуемой: агенты знают, что успешный HTTP 200 означает худший случай в виде объявленной стоимости в кредитах. (b) 'справедливее', но под него труднее планировать бюджет.

Что считается сбоем?

Наше правило: HTTP 4xx, который явно вина вызывающей стороны (некорректное тело, отсутствие аутентификации, нехватка кредитов), не тарифицируется. HTTP 5xx не тарифицируется никогда — это наша проблема. Сетевые ошибки и таймауты на нашей стороне не тарифицируются никогда. Rate-limit'ы (429) не тарифицируются никогда. Единственное, что тарифицируется, — это HTTP 200 с объявленной формой ответа.

Почему большинство провайдеров берут деньги за каждый вызов?

Три причины, в основном исторические. (1) Легаси-биллинговые системы учитывают на API-шлюзе, до того как известен ответ. Привязать биллинг к статусу ответа постфактум — нетривиально. (2) Паттерн задали Twilio и AWS в эпоху надёжных бэкендов; API, оборачивающие LLM или скрейпящие веб, куда менее надёжны, так что допущение перестаёт работать. (3) Это больше выручки. Первые две — отговорки; третья — правда.

Бывают ли случаи, когда 'берём всегда' оправдано?

Когда вызов действительно потребляет фиксированную стоимость при каждом запуске независимо от исхода — например, обращение к железу (отправлен SMS), мутация, атомарная на границе (обновление DNS), или сервис, чей бэкенд не может отличить 'мы попробовали и не смогли' от 'мы сделали, а вы не заметили'. Для read-стиля дата-API и поисковых API модель не подходит.