Цены OpenRouter Fusion: размер панели и стоимость токенов

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

OpenRouter Fusion: главное правило для бюджета

OpenRouter Fusion обычно обходится дороже, чем однократный вызов сопоставимой модели. В документации OpenRouter по Fusion Router описана панель из трёх моделей по умолчанию и один вызов аналитика — примерно в 4–5 раз дороже одного ответа на том же запросе.

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

Единица расчёта — не токен Fusion, а целый стек вызовов

На странице Fusion API OpenRouter Fusion представлен как роутер, а для его алиаса указана нулевая стоимость входных и выходных данных. Это означает, что у самого Fusion нет отдельной самостоятельной ставки; это не означает бесплатное выполнение базовых моделей.

Документированная схема работы выглядит так:

1. Запрос отправляется каждой выбранной модели панели.
2. Ответы панели сравнивает модель-аналитик или судья.
3. Внешняя модель формирует финальный ответ.

Для предварительного расчёта используйте формулу:

Fusion cost = sum(panel model costs)
             + analyst/judge cost
             + any final outer-model cost shown for your integration

Точная схема списаний зависит от того, вызывается ли Fusion как алиас модели openrouter/fusion или как серверный инструмент openrouter:fusion. Не пытайтесь определить итоговый счёт по строке $0, которую показывает роутер. Проверьте фактическую генерацию и запись в OpenRouter Activity.

Документация OpenRouter поддерживает от 1 до 8 аналитических моделей. По умолчанию в панели три модели. Режимы Quality, Budget и пользовательские конфигурации означают, что универсальной цены Fusion за миллион токенов не существует.

Размер панели линейно увеличивает счёт — пока не начинает расти стоимость судьи

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

Однако одного числа вызовов недостаточно для оценки расходов: вход судьи увеличивается вместе с ответами панели.

C(n) = n × Cp + Cj(n) + Co

Здесь n — число моделей панели, Cp — средняя стоимость ответа модели панели, Cj(n) — стоимость судьи с учётом растущего входного контекста, а Co — стоимость ответа внешней модели, если она применяется.

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

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

Используйте эту заготовку с актуальными тарифами выбранных моделей. Числа ниже приведены только для иллюстрации и не являются ценами OpenRouter: предположим 10 000 входных токенов, 2 000 выходных токенов на каждый ответ панели, 6 000 токенов на входе судьи и 1 000 выходных токенов судьи.

Panel input  = 10,000 × sum(panel input rates)
Panel output = 2,000 × sum(panel output rates)
Judge input  = 6,000 × judge input rate
Judge output = 1,000 × judge output rate
Fusion total = panel input + panel output + judge input + judge output

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

При упрощённом предположении об одинаковой стоимости форма расчёта по числу вызовов выглядит так:

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

Объём токенов меняет сравнение сразу по двум направлениям

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

1. Входные токены дублируются для каждой модели панели

Пусть I — число токенов в запросе, а Pi — цена входных токенов для модели панели i:

Panel input cost = I × (P1 + P2 + ... + Pn)

Запрос на 10 000 токенов, отправленный трём моделям панели, создаёт три отдельных начисления за вход — потенциально по разным ставкам.

2. Выходные токены тоже умножаются

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

Затем эти ответы читает судья:

Judge input ≈ original prompt + n × panel output + orchestration overhead

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

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

Total monthly cost ≈ requests × (panel input + panel output
                                  + judge input + judge output
                                  + outer response)

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

Что выбрать: Budget, Quality или одну модель?

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

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

Сравнивать нужно следующее:

incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposure

В отдельном анонсе с результатами бенчмарка OpenRouter сообщает о тестировании DRACO на 100 задачах: конфигурация Fusion с передовыми моделями получила 69.0%, а бюджетная панель — 64.7%. Эти результаты подтверждают сценарий глубокого исследования, но не являются коэффициентом конверсии для любого запроса и не доказывают, что большая панель экономически выгоднее.

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

Первое внедрение Fusion стоит рассматривать как эксперимент по сбору данных. Логируйте:

1. ID моделей панели и ID модели-судьи.
2. Использование входных, выходных токенов и токенов рассуждений, если эти данные доступны.
3. Метаданные роутера, подтверждающие запуск Fusion.
4. Итоговую стоимость и задержку.
5. Сократилось ли число исправлений человеком.

В документации Fusion сказано, что метаданные генерации могут содержать "router": "openrouter/fusion". Обычное поле model показывает конкретную модель, которая обрабатывает запрос, но само по себе не подтверждает запуск Fusion.

Один пользователь описал возможный риск конфигурации так:

«Этот \"Fusion\" всё равно вызывает Opus 4.8 в качестве судьи. Я не вижу возможности отключить его». — @teortaxesTex в X

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

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

FAQ о ценах OpenRouter Fusion

Fusion дешевле одной модели?

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

OpenRouter Fusion бесплатен?

У алиаса роутера в полях входных и выходных данных может отображаться $0. OpenRouter отдельно указывает, что ответы моделей панели и судьи тарифицируются, поэтому обычный запрос Fusion не следует считать бесплатным.

Сколько вызовов делает один запрос Fusion?

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

Всегда ли большая панель повышает выгоду?

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

Как оценить стоимость OpenRouter Fusion?

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

Практический вывод

Используйте одну модель как базовый вариант. Прогоните через неё и небольшую панель Fusion тестовую выборку из 20–50 запросов. Оставляйте Fusion только в том случае, если меньшее число фактических исправлений, пропущенных источников или часов проверки человеком покрывает дополнительные расходы на модели панели и токены судьи.

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