Атрибуция затрат по API-ключам OpenAI теперь программируема: что должен изменить каждый оператор маршрутизации

Запись в журнале изменений OpenAI от 4 августа легко пропустить: клиенты теперь могут фильтровать и группировать данные по использованию и затратам по API-ключу в дашборде платформы, а то же измерение api_key доступно программно через Usage API и Costs API.

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

Что фактически изменилось 4 августа

Два эндпоинта получили измерение группировки по api_key:

• Usage API (/v1/organization/usage): поддерживает group_by=api_key по числу завершений, токенов и запросов.
• Costs API (/v1/organization/costs): поддерживает group_by=api_key для агрегированных расходов в USD.

Дашборд platform.openai.com/settings/organization/usage предоставляет ту же разбивку в виде фильтра — выберите конкретный ключ, чтобы изолировать его вклад.

Миграция не требуется. Команды, уже использующие эти API, получают новое измерение без изменения структуры запросов. Если вы сегодня используете /v1/organization/usage, добавьте &group_by=api_key к существующему запросу.

Почему это важно для операторов AI-шлюзов

Шлюз маршрутизации обычно работает в рамках одной организации OpenAI, но выдаёт разные API-ключи для разных целей. Типичные сценарии:

• Изоляция окружений: отдельные ключи для продакшена, стейджинга, разработки. Нужно знать, что продакшен потребил 92% месячного счёта до получения инвойса.
• Биллинг по клиентам: SaaS-команды, включающие затраты OpenAI в клиентские счета. Без атрибуции по ключу сверка того, какой тенант сколько потратил, требовала агрегации логов на уровне запросов во внешних системах.
• Пути резервных моделей: основной ключ для GPT-5.6 Sol, вторичный ключ при переключении маршрутизатора на GPT-5.6 Luna. Знать, как часто срабатывают резервные пути и сколько они стоят — это входные данные для политики маршрутизации.

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

Какой разрыв с другими провайдерами это закрывает

Атрибуция затрат по API-ключу внутри одной организации — не универсальная возможность:

• Anthropic: не предоставляет разбивку затрат по ключу. Для изоляции затрат по ключу необходимо создавать отдельные рабочие пространства Anthropic, каждое с независимым биллингом и лимитами.
• Google Vertex AI: использует проекты, а не API-ключи, как единицу изоляции затрат. Атрибуция по ключу недоступна; минимальная гранулярность — атрибуция по проекту.
• Azure OpenAI / AI Foundry: использует деплойменты и группы ресурсов как единицы затрат. Атрибуция по API-ключу внутри группы ресурсов в Billing API недоступна напрямую.

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

Изменение политики маршрутизации: что проверить сейчас

1. Аудит архитектуры ключей

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

2. Алерты затрат по ключу

Costs API с group_by=api_key в сочетании с функцией лимитов расходов OpenAI (выпущена 22 июля) позволяет установить жёсткий месячный предел на каждый ключ маршрутизации — чтобы неисправный агент или неожиданный всплеск трафика возвращал 429, а не неограниченный счёт.

# Пример: получить затраты по ключам за последние 30 дней
import httpx

r = httpx.get(
    "https://api.openai.com/v1/organization/costs",
    params={
        "start_time": "2026-07-07T00:00:00Z",
        "end_time": "2026-08-07T00:00:00Z",
        "group_by": "api_key",
    },
    headers={"Authorization": f"Bearer {admin_key}"},
)
for bucket in r.json()["data"]:
    print(bucket["api_key_id"], bucket["amount"]["value"])

Примечание: для запросов затрат на уровне организации требуется Admin API Key, а не ключ проекта.

3. Видимость затрат резервных путей

Если ваш маршрутизатор использует отдельный API-ключ для резервных моделей, разбивка group_by=api_key теперь покажет: сколько раз в этом месяце срабатывали резервные пути и сколько они стоили. Это прямой вход для политики порога резервирования — если затраты на резервный путь превышают порог, сократите бюджет повторных попыток основной модели или переключитесь на более дешёвый резервный вариант.

4. Частота сверки биллинга

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

На что обратить внимание пользователям TheRouter

TheRouter маршрутизирует запросы через API-ключи, специфичные для провайдера. Разбивка затрат OpenAI по ключу означает, что теперь можно сопоставить логи маршрутизации TheRouter (какой путь сработал, какая модель использована, было ли резервное переключение) с данными по ключу из Costs API и получить полную картину затрат по пути маршрутизации без внешней агрегации логов. Настраивая ключи OpenAI в TheRouter, используйте разные ключи для основного и резервного путей — новый API обеспечит атрибуцию автоматически.