19 августа Anthropic перевела Files API Anthropic в статус general availability, одновременно выведя из беты набор computer-use и запустив browser-use toolset. На бумаге идея выглядит почти идеальной для команд, которые гоняют в модель одни и те же документы: загрузил файл один раз, дальше просто передаёшь его ID. Но практический тест показал неприятную для инженеров и закупщиков деталь: Files API Anthropic действительно упрощает работу, однако почти не помогает сократить счёт за токены.
Об этом сообщает The New Stack, где журналистка Джессика Вахтель сравнила три подхода к работе с одним и тем же справочным документом через Claude API. Сценарий был предельно прикладной: бот поддержки разработчиков отвечает на вопросы по внутренней API-документации. Проверяли не маркетинговый тезис, а то, что волнует любую команду с растущим AI-биллингом: сколько токенов съедает каждый способ, влияет ли он на качество ответов и насколько усложняет интеграцию.
Для теста автор подготовила вымышленную документацию Ledgerline примерно на 1200 слов. В ней были собраны типичные для API-сервиса темы: аутентификация, лимиты запросов, идемпотентность, вебхуки, bulk-операции и sandbox. Затем к этому документу задали пять вопросов, где правильный ответ можно проверить по тексту. Среди них были разбор двух разных ошибок 403, безопасный повтор создания платежа после таймаута, проверка подписи вебхука и защита от replay-атак, массовое создание 2000 инвойсов и действия после утечки API-токена в публичный репозиторий. То есть не абстрактный QA, а вопросы, на которых легко поймать модель на пропущенной детали.
Дальше The New Stack прогнала один и тот же набор запросов тремя способами на claude-sonnet-5 с одинаковыми инструкциями. Первый вариант: каждый раз вставлять весь справочник в запрос вручную. Второй: один раз загрузить документ через Files API и дальше ссылаться на file ID. Третий: положить документ в system prompt и включить prompt caching. По качеству победителя не оказалось: все 15 ответов во всех трёх сценариях совпали с эталоном. Модель корректно находила нюансы вроде неизменяемых token scopes, отдельного rate limit для bulk-эндпоинта, сравнения подписи в constant time и пятиминутного окна защиты от повторной отправки. Для разработчиков это важный вывод: переход на Files API сам по себе не делает ответы точнее.
А вот по расходам картинка оказалась куда менее интуитивной. При простом копипасте в каждый запрос набежало 15 246 входных токенов и 1399 выходных. У Files API Anthropic получилось 15 371 входной токен и 1434 выходных. То есть вариант с заранее загруженным файлом оказался не дешевле, а немного дороже. По расчётам автора, содержимое файла всё равно обрабатывается моделью в каждом запросе, примерно по 3050 входных токенов на вопрос, а ссылка на file ID добавляет сверху ещё около 25 токенов на запрос. На пяти запросах это дало лишние 125 входных токенов. Ключевая мысль здесь простая и для продакта, и для CTO: Files API решает проблему удобства, а не проблему стоимости.
Единственный вариант, который действительно снизил цену обработки, оказался совсем в другой плоскости. При использовании prompt caching обычных входных токенов было всего 271, отдельно записалось 2990 токенов в кэш и ещё 11 960 токенов читались из него. В материале подчёркивается важная деталь тарификации: чтение из кэша обходится примерно в одну десятую от цены обычных input tokens, хотя первичная запись в кэш идёт с наценкой примерно 25% к стандартной стоимости входа. В этом тесте итоговая схема стала выгоднее уже на серии из пяти запросов: первый запрос дороже, зато последующие читают документ заметно дешевле. Для команд, которые строят RAG-подобные сценарии поверх коротких и часто используемых инструкций, это уже не косметика, а вполне ощутимый операционный эффект.
Что именно меняет Files API
Это, впрочем, не делает Files API бесполезным. Напротив, у него есть вполне приземлённая ценность. Во-первых, документ больше не нужно держать в коде или вставлять в каждый вызов, а значит меньше шансов ошибиться с версией текста или случайно размножить чувствительные данные по логам и шаблонам. Во-вторых, API работает с форматами, которые не так просто «вставить в prompt» как обычный текст, например с PDF и изображениями. В-третьих, у сохранённых файлов появились настройки срока жизни, что полезно для внутренних пайплайнов и комплаенса. Иными словами, для инженерной команды это шаг в сторону более вменяемого управления артефактами, а не скидка на inference.
Есть и практические ограничения. В тесте до первого нормального прогона пришлось чинить две вещи: параметр temperature, выставленный в ноль ради воспроизводимости, API отклонил, потому что для claude-sonnet-5 он уже deprecated; кроме того, один из ответов пришёл с thinking block вместо обычного текста, из-за чего упал код вывода. Сама загрузка файла через Files API при этом прошла без драмы: один вызов, один file ID, дальше ссылка работала во всех запросах. Но и у prompt caching есть свои условия, о которых бизнесу полезно помнить заранее. Кэш протухает через пять минут бездействия, так что экономия проявляется там, где запросы идут более-менее регулярно. Плюс сам запрос нужно перестроить, перенеся документ в system prompt и пометив его для кэширования.
Для рынка это ещё один холодный душ после волны анонсов вокруг «агентных» API. Инфраструктурные новинки всё чаще продаются как средство уменьшить боль разработчика, но боль бывает разной: где-то это латентность, где-то поддержка форматов, где-то стоимость токенов, а где-то контроль над окружением. Ошибка начинается в момент, когда команда принимает улучшение DX за оптимизацию бюджета. История с Files API хорошо показывает, что у поставщиков LLM всё чаще нужно читать не заголовок релиза, а механику тарификации и фактический путь данных внутри запроса.
Для русскоязычных продуктовых и инженерных команд вывод предельно прикладной. Если у вас много повторного контекста и задача упирается именно в счёт за input tokens, смотреть надо в сторону caching. Если болит хранение документов, работа с PDF, изображениями и управлением файлами, тогда Files API даёт более аккуратную архитектуру, но не более дешёвую. Следующий большой вопрос для рынка уже не в том, смогут ли LLM-платформы упростить интеграцию, а в том, начнут ли они честно разделять инструменты для удобства разработки и инструменты для экономии, не заставляя команды выяснять это на собственных счетах за inference.