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 с текущия си експорт, преди да изберат дата на мигриране. Странирането, актуалността на данните и поведението при групиране могат да повлияят на работните места надолу по веригата, дори когато два интерфейса докладват като цяло сходна информация. Промяна, която изглежда като подмяна на крайна точка, може да изисква актуализации на схеми, логика на агрегиране и исторически сравнения.
Временното изпълнение на двата пътя ще позволи на организацията да сравнява сумите по ден, модел и работно пространство. Съществените разлики трябва да бъдат разбрани, преди бета данните да се превърнат в основа за фактури, извлечения от клиенти или автоматизирани AI API контроли на разходите.
По-висок стандарт за отчитане с множество модели
Изданието също повишава очакванията за анализа на шлюза. Клиентите все повече се нуждаят от повече от символична сума: те се нуждаят от заявени и таксувани модели, нива на обслужване, собственост на идентификационни данни, цена на доставчика и цена, представена на клиента. Измеренията за отчитане на първа страна правят пропуските в собствената книга на шлюза по-видими.
За платформи като Model Gate практическата възможност е да се използва анализът на доставчика като вход за съгласуване в рамките на unified AI API billing. Емисията на доставчика може да проверява Claude разходи, докато шлюзът продължава да нормализира използването между доставчиците и да го свързва с екипи, клиенти и управлявани API ключове.
Това, което остава несигурно, е колко стабилен ще бъде бета договорът и доколко записите му ще съответстват на окончателното таксуване в различните договорености на акаунта. Докато тези въпроси не бъдат тествани в производството, новите крайни точки се третират най-добре като ценен счетоводен източник с контроли за съгласуване около тях, а не като единствената книга на записи.