OpenRouter добави бета хостван инструмент за изпълнение на обвивка и API за файлове, давайки на разработчиците начин да позволят на моделите за извикване на инструменти да изпълняват команди в изолирани контейнери на Linux чрез слоя за маршрутизиране на OpenRouter. Изданието е повече от друга функция на агента. Той променя модела на отчитане за многомоделна AI инфраструктура: заявката вече може да включва токени на модела, време за изпълнение на инструмента, обработка на файлове и поведение за съвместимост в повече от един стил на API.
Новият сървърен инструмент, наречен openrouter:shell, позволява на поддържаните модели да изпълняват команди в хоствани контейнери и да връщат стандартни резултати за изпълнение, включително stdout, stderr и кодове за изход. OpenRouter казва, че инструментът работи чрез своя път на Responses API и неговия път за съвместимост на API на Anthropic Messages, което има значение, тъй като разработчиците все повече се опитват да запазят внедряванията на агенти преносими между доставчиците на модели, вместо да обвързват всеки работен процес с родния интерфейс на инструмента на един доставчик.
OpenRouter оценява пясъчната среда на $0,0001 на секунда, таксувано като част от заявката. Използването на API за файлове е включено по време на бета версията. Това създава отделно измерение на разходите от обикновените входни и изходни токени и дава на операторите на шлюза конкретен пример защо унифицираното таксуване на AI API става по-трудно от сумирането на таксите за токени на модела.
Какво се промени
Доскоро изпълнението на хостван код обикновено беше обвързано със специфичен за доставчика агентен стек или изискваше разработчиците да управляват своя собствена група от пясъчници. Бета версията на OpenRouter вмъква тази възможност в платформа за маршрутизиране, която вече се използва за достъп до много модели. На практика агентът може да поиска от модел да инспектира данни, да изпълнява скриптове, да манипулира файлове или да тества малки части от код, без екипът на приложението да осигурява контейнери директно за всяко изпълнение.
Детайлите за съвместимост са важни. OpenRouter позиционира инструмента на обвивката не като възможност на едно семейство модели, а като инструментална повърхност на ниво платформа, достъпна чрез познати модели на API. За екипи, които са изградили семантика на Responses в стил OpenAI или семантика на съобщения в антропичен стил, хостваният инструмент може да се намира по-близо до слоя на шлюза, отколкото до слоя на модела.
Това не прави поведението на инструмента магически еднообразно. Различните модели се различават по начина, по който извикват инструменти, възстановяват се от повреди, разсъждават за извеждане на команди и управляват файлове. Но решението за инфраструктурата се променя. Вместо да питат само кой модел може да напише команда на обвивката, разработчиците сега трябва да попитат кой шлюз може безопасно да я изпълни, да я измери и да върне резултатите във формата на API, която техният клиент вече разбира.
Защо измерването на времето за изпълнение има значение
Цената на токена вече не е достатъчна, за да опише цената на заявка за агент. Едно действие на един потребител може да включва подкана, няколко обръщания на модела, качване на файлове, изпълнение на обвивка, повторни опити и окончателно обобщение. Скъпата част може да е изходът на модела или може да е дълго изпълняваща се команда, която произвежда малко текст. Цената за пясъчник на OpenRouter за секунда прави това разграничение ясно.
За разработчиците непосредствената последица е бюджетният дизайн. Циклите на агента се нуждаят от ограничения за продължителността на командата, поведението при повторен опит и допусканията за задържане на файлове. Безобидно изглеждаща заявка, която се разширява в повтарящи се извиквания на обвивката, може да натрупа такси за време на изпълнение, дори ако използването на токена остава скромно. Регистрирането трябва да показва не само броя на модела, доставчика и токена, но и името на инструмента, продължителността на изпълнение, състоянието на изход и дали моделът е опитал повторно след грешка.
За фирми, които надграждат моделни шлюзове, промяната засяга маржовете и отчитането на клиентите. Партньорски продукт, който препродава AI автоматизация, не може да третира всяка заявка като довършване на текст с маркиране. Нуждае се от регистър на използването, който може да припише цената на модела и цената на хоствания инструмент към правилното работно пространство, краен клиент или API ключ. Това е пряко свързано с автоматизирането на приложния програмен интерфейс на партньора, където клиентът надолу по веригата може никога да не види необработената фактура на OpenRouter, но въпреки това очаква последователна сметка.
Кой е засегнат
Първата засегната група са разработчици на агенти, които искат изпълнение на код, без да се обвързват с пълна агентска платформа на доставчик на модел. Подходът на OpenRouter може да се хареса на екипи, които вече маршрутизират трафик между модели и искат да добавят достъп до обвивката, като същевременно запазят известна гъвкавост при избора на модел.
Втората група са екипи за платформа и шлюз. Сега те трябва да решат дали хостваните инструменти са първокласни каталожни елементи, дали могат да бъдат активирани за работно пространство и как разходите им се показват в таблата за управление. Може да се наложи ред от каталог на модели да бъде съчетан с наличността на инструмента, ограниченията на времето за изпълнение и бележките за съвместимост. Може да се наложи контролът на достъпа да прави разлика между разрешаването на извикване на модел и разрешаването на това извикване да стартира контейнер.
Третата група са финансови и оперативни екипи, управляващи разходите за AI. Анализите на използването, които спират до токени, ще пропуснат нарастващ клас разходи за агентска инфраструктура. Полезно табло за анализ на използването на AI API трябва да показва дали пикът идва от избор на модел, обем на токена, време на изпълнение на пясъчна среда или промяна в дизайна на работния процес, която е причинила допълнителни извиквания на инструмент.
Какво остава несигурно
Бета версията оставя отворени няколко практически въпроса. OpenRouter казва, че използването на Files API е включено в инструмента на обвивката по време на бета версията, но дългосрочното ценообразуване на файловете, правилата за задържане и оперативните лимити все още може да имат значение за производствените натоварвания. Разработчиците също ще трябва да тестват кои модели работят надеждно с инструмента на обвивката в поддържаните пътища за съвместимост на API.
Сигурността е друг неразрешен въпрос за внедряването за купувачите. OpenRouter описва командите като изпълняващи се в изолирани хоствани Linux контейнери, но предприятията все още ще питат за достъп до мрежата, инсталиране на пакети, постоянство на файлове, журнали за одит и обработка на данни, преди да изпратят чувствителни работни натоварвания през хоствана среда за изпълнение.
По-широката посока обаче е ясна: шлюзовете поемат повече от времето за изпълнение на агента. Маршрутизирането на модела означаваше избор къде да бъде изпратена подкана. Сега той все повече включва семантика на инструмента, състояние на файла, политика за изпълнение и измерване без токени. Бета версията на Shell на OpenRouter е полезен маркер, защото придава ясна цена на възможност, която много създатели на агенти са третирали като фонова инфраструктура. След като времето за изпълнение се появи в сметката, то става част от продуктовата архитектура.