OpenRouter добави бета хостван инструмент за изпълнение на обвивка и файлове API, като дава възможност на разработчиците да позволят на моделите за извикване на инструменти да изпълняват команди в изолирани Linux контейнери чрез слоя за маршрутизиране на OpenRouter. Изданието е повече от друга функция на агента. Той променя модела на отчитане за многомоделна AI инфраструктура: заявката вече може да включва токени на модела, време за изпълнение на инструмента, обработка на файлове и поведение за съвместимост в повече от един API стил.

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

OpenRouter оценява пясъчната среда на $0,0001 на секунда, таксувано като част от заявката. Използването на файлове API е включено по време на бета версията. Това създава отделно измерение на разходите от обикновените входни и изходни токени и дава на операторите на шлюза конкретен пример защо унифицираното AI API таксуване става по-трудно от сумирането на таксите за токени на модела.

Какво се промени

Доскоро изпълнението на хостван код обикновено беше обвързано със специфичен за доставчика стек от агенти или изискваше разработчиците да управляват своя собствена група от пясъчници. Бета версията на OpenRouter вмъква тази възможност в платформа за маршрутизиране, която вече се използва за достъп до много модели. От практическа гледна точка агентът може да поиска от модел да инспектира данни, да изпълнява скриптове, да манипулира файлове или да тества малки части от код, без екипът на приложението да предоставя контейнери директно за всяко изпълнение.

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

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

Защо измерването на времето на изпълнение е важно

Цената на токена вече не е достатъчна, за да опише цената на заявка за агент. Едно действие на един потребител може да включва подкана, няколко обръщания на модела, качване на файлове, изпълнение на обвивка, повторни опити и окончателно обобщение. Скъпата част може да е изходът на модела или може да е дълго изпълняваща се команда, която произвежда малко текст. Цената за пясъчник на OpenRouter за секунда прави това разграничение ясно.

За разработчиците непосредствената последица е проектирането на бюджета. Циклите на агента се нуждаят от ограничения за продължителността на командата, поведението при повторен опит и допусканията за задържане на файлове. Безобидно изглеждаща заявка, която се разширява в повтарящи се извиквания на обвивката, може да натрупа такси за време на изпълнение, дори ако използването на токена остава скромно. Регистрирането трябва да показва не само броя на модела, доставчика и токена, но и името на инструмента, продължителността на изпълнение, състоянието на изход и дали моделът е опитал повторно след грешка.

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

Кой е засегнат

Първата засегната група са разработчици на агенти, които искат изпълнение на код, без да се обвързват с пълна агентска платформа на доставчик на модел. Подходът на OpenRouter може да се хареса на екипи, които вече маршрутизират трафик между модели и искат да добавят достъп до обвивката, като същевременно запазят известна гъвкавост при избора на модел.

Втората група са екипи за платформа и шлюз. Сега те трябва да решат дали хостваните инструменти са първокласни каталожни елементи, дали могат да бъдат активирани за работно пространство и как разходите им се показват в таблата за управление. Може да се наложи ред от каталог на модели да бъде съчетан с наличността на инструмента, ограниченията на времето за изпълнение и бележките за съвместимост. Може да се наложи контролът на достъпа да прави разлика между разрешаването на извикване на модел и разрешаването на това извикване да стартира контейнер.

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

Какво остава несигурно

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

Сигурността е друг неразрешен въпрос за внедряването за купувачите. OpenRouter описва командите като изпълняващи се в изолирани хоствани Linux контейнери, но предприятията все още ще питат за достъп до мрежата, инсталиране на пакети, постоянство на файлове, регистрационни файлове за одит и обработка на данни, преди да изпратят чувствителни работни натоварвания през хоствана среда за изпълнение.

По-широката посока обаче е ясна: шлюзовете поемат повече от времето за изпълнение на агента. Маршрутизирането на модела означаваше избор къде да бъде изпратена подкана. Сега той все повече включва семантика на инструмента, състояние на файла, политика за изпълнение и измерване без токени. Бета версията на Shell на OpenRouter е полезен маркер, защото придава ясна цена на възможност, която много създатели на агенти са третирали като фонова инфраструктура. След като времето за изпълнение се появи в сметката, то става част от продуктовата архитектура.