﻿# Usage OpenRouter: как связать токены и стоимость одного запроса

Как читать usage OpenRouter и сверять стоимость запроса: generation ID, входные и выходные токены, дополнительные компоненты, streaming и различия отчёта шлюза и поставщика.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-usage-accounting/
Language: ru

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

Материал проверен по официальным источникам 1 ноября 2026 года. Он описывает технический реестр операций, а не гарантированную экономику будущего GPU-пула.

## Сохраните идентификатор выполнения

В [описании generation metadata](https://openrouter.ai/docs/api/api-reference/generations/get-request-&-usage-metadata-for-a-generation) предусмотрен отдельный доступ к сведениям выполненной операции. Сохраняйте идентификатор вместе с внутренним ID задачи приложения, временем и запрошенной моделью.

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

## Разделите виды данных

| Поле реестра | Для чего оно нужно |
| --- | --- |
| Запрошенная и фактическая модель | Понять результат маршрутизации |
| Состояние завершения | Отличить полный результат от ошибки или отмены |
| Токены по данным API | Проверить объём конкретного выполнения |
| Стоимость и её единица | Сопоставить начисление со ставкой |
| Признак формы доступа | Различить BYOK и общую мощность, если данные доступны |

Храните исходное значение показателя и название поля. Преждевременное преобразование всех данных в одно число «токены всего» может скрыть важные различия при разборе расходов.

## Проверьте streaming отдельно

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

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

## Сверьте правила цены

[OpenRouter Pricing](https://openrouter.ai/pricing) разделяет оплату модельных токенов и условия платформы. Для BYOK дополнительно нужен счёт поставщика. Дополнительные сервисы также рассматриваются отдельно от одной модельной ставки, если они включены в сценарий.

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

## Подготовьте сверку периода

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

Отдельно оставляйте строки с неизвестным итогом вместо автоматического нуля. Это позволяет расследовать расхождение, не выдавая отсутствие данных за отсутствие расходов. Дальше пригодятся [BYOK pricing](/ru/journal/openrouter-byok-pricing/) и [биллинг роутера](/ru/journal/router-billing-token-accounting/).
