Инструмент размещенной оболочки OpenRouter делает выставление счетов во время выполнения частью многомодельной маршрутизации.

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

Новый серверный инструмент под названием openrouter:shell позволяет поддерживаемым моделям выполнять команды в размещенных контейнерах и возвращать стандартные результаты выполнения, включая стандартный вывод, стандартный вывод и коды завершения. OpenRouter утверждает, что инструмент работает через свой путь API ответов и путь совместимости API Anthropic Messages, что важно, поскольку разработчики все чаще пытаются обеспечить переносимость реализаций агентов между поставщиками моделей, а не привязывать каждый рабочий процесс к собственному интерфейсу инструмента одного поставщика.

OpenRouter оценивает песочницу по цене 0,0001 доллара США в секунду, оплата взимается как часть запроса. Использование Files API включено в бета-версию. Это создает отдельное измерение затрат от обычных входных и выходных токенов и дает операторам шлюза конкретный пример того, почему выставление счетов за единый AI API становится сложнее, чем суммирование сборов за токены модели.

Что изменилось

До недавнего времени выполнение размещенного кода обычно было привязано к стеку агентов конкретного поставщика или требовало от разработчиков использования собственного парка песочниц. Бета-версия OpenRouter добавляет эту возможность в платформу маршрутизации, которая уже используется для доступа ко многим моделям. На практике агент может попросить модель проверить данные, запустить сценарии, манипулировать файлами или протестировать небольшие фрагменты кода, при этом команда приложения не будет предоставлять контейнеры непосредственно для каждого запуска.

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

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

Почему важно учитывать время выполнения

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

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

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

Кто пострадал

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

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

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

Что остается неясным

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

Безопасность — еще один нерешенный вопрос реализации для покупателей. OpenRouter описывает команды как выполняемые в изолированных размещенных контейнерах Linux, но предприятия по-прежнему будут спрашивать о доступе к сети, установке пакетов, сохранении файлов, журналах аудита и обработке данных, прежде чем отправлять конфиденциальные рабочие нагрузки через размещенную среду выполнения.

Однако более широкое направление очевидно: шлюзы поглощают большую часть времени выполнения агента. Маршрутизация модели раньше означала выбор места отправки приглашения. Теперь оно все чаще включает в себя семантику инструментов, состояние файлов, политику выполнения и измерение без использования токенов. Бета-версия оболочки OpenRouter является полезным маркером, поскольку она четко определяет цену возможности, которую многие разработчики агентов рассматривают как фоновую инфраструктуру. Как только время выполнения появляется в счете, оно становится частью архитектуры продукта.