Когда OpenAI API дешевле Claude для вашей нагрузки?

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

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

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

Цены токенов дают коэффициенты, а не готовый ответ

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

• Большой объем: GPT-5.6 Luna стоит $0.20 за ввод, $0.02 за закэшированный ввод и $1.20 за вывод на MTok. Для Claude Haiku 4.5 цены составляют $1.00, $0.10 и $5.00.
• Обычная рабочая нагрузка: GPT-5.6 Terra стоит $2.00 за ввод, $0.20 за закэшированный ввод и $12.00 за вывод. Для Claude Sonnet 4.6 цены составляют $3.00, $0.30 и $15.00.
• Сложные задачи: GPT-5.6 Sol стоит $5.00 за ввод, $0.50 за закэшированный ввод и $30.00 за вывод. Для Claude Opus 4.8 цены составляют $5.00, $0.50 и $25.00.

MTok означает один миллион токенов. Anthropic также указывает для Claude Sonnet 5 акционные цены $2 за ввод и $10 за вывод до 31 августа 2026 года, после чего они составят $3 и $15. Я бы не строил годовой прогноз на временной цене. Если трафик продолжится после этой даты, внесите в прогноз оба периода.

На странице сравнения моделей OpenAI называет Luna экономичным вариантом, Terra балансом возможностей и цены, а Sol моделью для самых сложных задач. Anthropic похожим образом располагает Haiku, Sonnet и Opus по возрастанию возможностей. Эти описания помогают выбрать кандидатов, но не доказывают одинаковое качество. Классификатор обращений в поддержку может успешно работать на обеих дешевых моделях, а перенос репозитория может не пройти ни на одной из них.

Первая формула учета проста:

call_cost =
  uncached_input_tokens * input_rate / 1_000_000 +
  cached_input_tokens * cache_read_rate / 1_000_000 +
  output_tokens * output_rate / 1_000_000 +
  provider_tool_fees

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

Эти цены также показывают, почему общие заявления не работают. По опубликованным тарифам у Luna большое преимущество перед Haiku 4.5. У Sol и Opus 4.8 одинаковая цена ввода и чтения из кэша, но вывод у Opus дешевле. Terra и Sonnet 4.6 ближе друг к другу. Токенизация, длина ответа, повторы и доля успешно принятых результатов могут перечеркнуть небольшую разницу в тарифе.

Форма задачи определяет главную статью расходов

Профиль нагрузки должен описывать движение токенов и критерии приемки для каждой задачи, потому что одно название скрывает самую дорогую часть. «Поддержка клиентов» может означать метку намерения на 200 токенов или ответ на 6000 токенов с учетом истории аккаунта.

Я разделяю рабочие запросы на пять типов:

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

Для классификации обычно выигрывает дешевая модель, которая с первой попытки возвращает корректный JSON. Допустим, запрос отправляет 1200 входных токенов и получает 80 выходных. По тарифам Luna токены стоят $0.000336. По тарифам Haiku 4.5 они стоят $0.0016. При миллионах запросов разница существенна, если обе модели проходят одинаковые тесты точности и схемы.

При суммаризации важно соотношение вывода к вводу. Договор на 60 000 токенов, сокращенный до 2000 токенов, создает основную нагрузку на ввод. Техническое задание на 3000 токенов, развернутое в черновик на 12 000, нагружает вывод. Одни и те же две модели могут поменяться местами, потому что выходные токены стоят в несколько раз дороже входных.

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

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

Кэширование меняет экономику длинного контекста

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

И GPT-5.6, и Claude сейчас оценивают чтение из кэша в одну десятую обычной цены ввода. За короткую запись в кэш оба берут 1.25 обычной цены. Anthropic указывает стандартный срок хранения пять минут, а запись на один час стоит вдвое дороже обычного ввода. OpenAI поддерживает неявное и явное кэширование для GPT-5.6; руководство по моделям советует следить за записями и закэшированными токенами, а не считать, что любой повтор обязательно попадет в кэш.

Для начала запроса длиной P токенов, числа вызовов N, базового тарифа ввода R, множителя записи W и множителя чтения H сравните:

uncached_cost = N * P * R
cached_cost = P * R * W + (N - 1) * P * R * H

При расчете точки окупаемости общий объем токенов и ставка сокращаются. Если запись стоит 1.25, а чтение 0.10, два вызова с кэшем стоят 1.35 условной единицы против 2 без кэша. Один вызов приносит убыток, потому что вы заплатили 1.25 единицы за запись, которую больше не прочитали. Часовая запись Anthropic стоит 2 единицы, поэтому ей нужны три вызова, чтобы оказаться дешевле трех обычных чтений. Формула не учитывает меняющийся конец запроса и вывод, поскольку в обоих вариантах их стоимость одинакова.

Разберем конкретный пример GPT-5.6 Terra. У агента поддержки есть стабильное начало на 40 000 токенов с правилами, примерами и описаниями инструментов. Пока эта часть остается пригодной для повторного использования, агент обрабатывает 100 запросов. Без кэша начало стоит 40,000 * 100 * $2 / 1M, то есть $8.00. Одна запись и 99 чтений стоят 40,000 * ($2 * 1.25 + 99 * $0.20) / 1M, то есть $0.892. Меняющиеся сообщения пользователей и ответы все равно нужно добавить к счету.

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

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

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

Выходные токены часто определяют счет

Вывод стоит достаточно дорого, чтобы правила ответа перевесили экономию на вводе. У моделей из списка вывод стоит в пять или шесть раз дороже базового ввода, кроме Opus 4.8 с множителем пять.

Возьмем обычный рабочий запрос с 8000 незакэшированных входных токенов и 3000 выходных. GPT-5.6 Terra стоит $0.016 + $0.036, то есть $0.052. Claude Sonnet 4.6 стоит $0.024 + $0.045, то есть $0.069. Если ответ OpenAI вырастет до 5000 токенов, а Claude закончит на 3000, Terra обойдется в $0.076, а Claude останется на $0.069. Более дешевый тариф проиграл, потому что система использовала больше оплачиваемого вывода.

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

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

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

cost_per_accepted_run =
  total_model_cost + tool_cost + retry_cost + reviewer_cost
  divided by accepted_runs

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

Журнал нагрузки полезнее среднего счета за месяц

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

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

{
  "run_id": "run_7f31",
  "task": "support_reply",
  "route": "general",
  "provider": "openai",
  "model": "gpt-5.6-terra",
  "input_tokens": 8421,
  "cached_input_tokens": 6100,
  "cache_write_tokens": 0,
  "output_tokens": 734,
  "tool_cost_usd": 0,
  "latency_ms": 2840,
  "attempt": 1,
  "accepted": true,
  "review_seconds": 18
}

Храните исходные поля статистики поставщика рядом с приведенными к общему виду. OpenAI и Anthropic называют поля по-разному, и названия меняются. Единая таблица упрощает анализ, а исходные данные позволяют исправить преобразование и не потерять историю.

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

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

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

Особенно полезен еженедельный отчет: объем, стоимость принятых результатов, задержка и качество по (task, route, model_version). Во время сравнения закрепляйте версии моделей. Если псевдоним изменился только в одной ветке теста, вы уже не поймете, что повлияло на результат: маршрутизатор или модель.

Пакетная скидка должна влиять на маршрут

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

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

Распространенная ошибка состоит в том, что синхронный запрос OpenAI сравнивают с пакетным запросом Claude, а разницу приписывают цене модели. Отделяйте класс обслуживания от поставщика и модели. В маршруте должны быть как минимум interactive, deferred и quality_first, у каждого со своим допустимым временем ответа.

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

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

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

Маршрут зависит от задачи, уверенности и класса обслуживания

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

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

Я использую три уровня возможностей:

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

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

Требования к данным могут отменить решение по цене. Если поставщик, регион или метод API не соответствует вашим правилам хранения и размещения данных, он не участвует в выборе. Документация OpenAI по данным указывает, что расширенный кэш требует хранения и несовместим с Zero Data Retention. Anthropic описывает кэш в рамках собственных правил хранения. Проверка безопасности предшествует сравнению тарифов.

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

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

Небольшой маршрутизатор остается понятным

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

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

const routes = {
  economy: ["openai:gpt-5.6-luna", "anthropic:claude-haiku-4-5"],
  general: ["openai:gpt-5.6-terra", "anthropic:claude-sonnet-4-6"],
  frontier: ["anthropic:claude-opus-4-8", "openai:gpt-5.6-sol"]
};

function chooseRoute(job, telemetry) {
  if (job.dataPolicy.allowedProviders.length === 0) {
    throw new Error("No provider satisfies the data policy");
  }

  const tier = job.risk === "high" || job.previousCheckFailed
    ? "frontier"
    : job.task === "classify" || job.task === "extract"
      ? "economy"
      : "general";

  const service = job.deadlineMinutes >= 60 ? "batch" : "interactive";
  const candidates = routes[tier]
    .filter(id => job.dataPolicy.allowedProviders.includes(id.split(":")[0]))
    .filter(id => telemetry[id].healthy)
    .filter(id => telemetry[id].evalPassRate >= job.minimumPassRate)
    .sort((a, b) => telemetry[a].acceptedCost - telemetry[b].acceptedCost);

  if (candidates.length === 0) throw new Error("No tested route is available");

  return {
    model: candidates[0],
    service,
    reason: `${tier}:${service}:lowest_accepted_cost`
  };
}

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

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

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

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

Повторы и циклы инструментов съедают экономию на бумаге

Самый частый сбой начинается с аккуратной таблицы и заканчивается более крупным счетом. В таблице на задачу заложен один запрос. В работе их отправляется три.

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

Задавайте бюджеты на весь запуск:

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

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

Описания инструментов тоже входят во ввод. Большие схемы JSON повторяются на каждом ходу, если кэш не захватил стабильное начало. Уберите инструменты, недоступные текущей задаче, и сократите описания, сохранив точность поведения. Документация Anthropic по ценам прямо говорит, что параметр tools, блоки вызова и результата инструмента, а также добавленный поставщиком системный запрос расходуют токены. Вызовы инструментов OpenAI тоже добавляют токены модели, а некоторые серверные инструменты оплачиваются отдельно.

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

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

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

Один поставщик все равно может дать более дешевую архитектуру

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

Второй поставщик добавляет особенности SDK, аутентификацию, квоты, сверку счетов, поля наблюдаемости, обработку защитных отказов, варианты запросов, проверки моделей, планы действий при сбоях и анализ договора. Это постоянные расходы. Если годовые расходы на модели составляют $12 000, а маршрутизация экономит 15 процентов, $1800 не оплатят большой объем инженерной работы. Если расходы равны $1.2 миллиона, тот же процент заслуживает внимания.

Используйте простой расчет:

annual_router_value =
  baseline_accepted_cost
  minus routed_accepted_cost
  plus outage_loss_avoided
  minus router_build_and_operations_cost

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

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

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

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