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

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

Что выпущено Anthropic

Бета-версия предоставляет две конечные точки GET на уровне организации: /v1/organizations/analytics/usage для записей о потреблении и /v1/organizations/analytics/cost для финансовых данных. Запросы должны включать бета-заголовок analytics-usage-cost-2026-08-24.

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

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

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

Почему это должно волновать шлюзы и реселлеры

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

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

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

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

Устаревшие интеграции теперь сталкиваются с решением о миграции

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

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

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

Более высокий стандарт для многомодельной отчетности

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

Для таких платформ, как Model Gate, практическая возможность заключается в использовании аналитики поставщика в качестве входных данных для сверки в рамках унифицированного AI API выставления счетов. Фид поставщика может проверять расходы Claude, в то время как шлюз продолжает нормализовать использование между поставщиками и связывать его с командами, клиентами и управляемыми ключами API.

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