Hostovaný shellový nástroj OpenRouteru činí účtování za běhu součástí vícemodelového směrování

OpenRouter přidal beta hostovaný nástroj pro provádění shellu a Files API, což vývojářům poskytuje způsob, jak umožnit modelům volání nástrojů spouštět příkazy v izolovaných kontejnerech Linuxu prostřednictvím směrovací vrstvy OpenRouter. Vydání je více než další funkce agenta. Mění model účtování pro infrastrukturu umělé inteligence s více modely: požadavek nyní může zahrnovat tokeny modelu, dobu spuštění nástroje, práci se soubory a chování kompatibility ve více než jednom stylu API.

Nový serverový nástroj s názvem openrouter:shell umožňuje podporovaným modelům spouštět příkazy v hostovaných kontejnerech a vracet standardní výsledky provádění, včetně stdout, stderr a výstupních kódů. OpenRouter říká, že tento nástroj funguje prostřednictvím své cesty Responses API a cesty kompatibility Antropických zpráv API, což je důležité, protože vývojáři se stále více snaží zachovat přenositelnost implementací agentů mezi poskytovateli modelů, spíše než vázat každý pracovní postup na nativní rozhraní nástroje jednoho dodavatele.

OpenRouter oceňuje izolovaný prostor na 0,0001 $ za sekundu, účtováno jako součást požadavku. Využití Files API je zahrnuto během beta verze. To vytváří samostatnou nákladovou dimenzi od běžných vstupních a výstupních tokenů a dává operátorům bran konkrétní příklad toho, proč je sjednocená fakturace AI API stále obtížnější než sčítání modelových poplatků za tokeny.

Co se změnilo

Až donedávna bylo provádění hostovaného kódu obvykle vázáno na zásobník agentů specifických pro poskytovatele nebo vyžadovalo, aby vývojáři provozovali vlastní flotilu sandboxů. Beta verze OpenRouter vkládá tuto schopnost do směrovací platformy, která se již používá pro přístup k mnoha modelům. Prakticky řečeno, agent může požádat model o kontrolu dat, spouštění skriptů, manipulaci se soubory nebo testování malých částí kódu, aniž by aplikační tým poskytoval kontejnery přímo pro každé spuštění.

Podrobnosti o kompatibilitě jsou důležité. OpenRouter umísťuje nástroj shell nikoli jako funkci jedné rodiny modelů, ale jako povrch nástroje na úrovni platformy dostupný prostřednictvím známých vzorů API. Pro týmy, které vycházejí ze sémantiky odpovědí ve stylu OpenAI nebo sémantiky zpráv v antropickém stylu, může hostovaný nástroj sedět blíže k vrstvě brány než k vrstvě modelu.

To neznamená, že chování nástroje je magicky jednotné. Různé modely se liší v tom, jak volají nástroje, obnovují se po selhání, zdůvodňují výstup příkazů a spravují soubory. Ale rozhodnutí o infrastruktuře se posouvá. Namísto toho, aby se vývojáři ptali pouze na to, který model může napsat příkaz shellu, se nyní musí ptát, která brána jej může bezpečně spustit, měřit a vracet výsledky ve tvaru API, kterému jejich klient již rozumí.

Proč je měření doby běhu důležité

Cena tokenů již nestačí k popisu nákladů na požadavek agenta. Akce jednoho uživatele může zahrnovat výzvu, několik otočení modelu, nahrání souborů, spuštění shellu, opakování a závěrečnou sumarizaci. Drahou částí může být výstup modelu nebo to může být dlouhotrvající příkaz, který produkuje málo textu. Díky ceně izolovaného prostoru OpenRouter za sekundu je tento rozdíl jasný.

Pro vývojáře je bezprostředním důsledkem návrh rozpočtu. Smyčky agentů vyžadují omezení na dobu trvání příkazu, chování opakování a předpoklady uchovávání souborů. Neškodně vypadající požadavek, který se rozšíří do opakovaných volání shellu, může akumulovat poplatky za běh, i když využití tokenu zůstane skromné. Protokolování musí ukazovat nejen počet modelů, poskytovatelů a tokenů, ale také název nástroje, dobu provádění, stav ukončení a to, zda se model opakoval po chybě.

Pro firmy, které staví na modelových branách, se změna dotýká marží a hlášení zákazníků. Partnerský produkt, který dále prodává automatizaci AI, nemůže každý požadavek považovat za dokončení textu s označením. Potřebuje účetní knihu použití, která dokáže přiřadit náklady na model a náklady na hostovaný nástroj správnému pracovnímu prostoru, koncovému zákazníkovi nebo klíči API. To se přímo týká automatizace partnerského rozhraní API, kde následný zákazník nikdy neuvidí nezpracovanou fakturu OpenRouter, ale přesto očekává koherentní vyúčtování.

Koho se to týká

První dotčenou skupinou jsou vývojáři agentů, kteří chtějí spustit kód, aniž by se zavázali k plné platformě agentů jednoho poskytovatele modelu. Přístup OpenRouter může oslovit týmy, které již směrují provoz napříč modely a chtějí přidat shellový přístup při zachování určité flexibility při výběru modelu.

Druhou skupinou jsou týmy platformy a brány. Nyní se musí rozhodnout, zda jsou hostované nástroje prvotřídními položkami katalogu, zda je lze povolit pro jednotlivé pracovní prostory a jak se jejich náklady objeví na řídicích panelech. Řádek katalogu modelu může být potřeba spárovat s dostupností nástroje, limity doby běhu a poznámkami ke kompatibilitě. Řízení přístupu může potřebovat rozlišovat mezi povolením volání modelu a povolením tohoto volání spustit kontejner.

Třetí skupinou jsou finanční a provozní týmy spravující výdaje na umělou inteligenci. Analýzy využití, které se zastaví u tokenů, budou minout rostoucí třídu nákladů na infrastrukturu agentů. Užitečný panel analýzy využití rozhraní AI API by měl ukazovat, zda k prudkému nárůstu došlo v důsledku výběru modelu, objemu tokenů, runtime izolovaného prostoru nebo změny návrhu pracovního postupu, která způsobila další volání nástrojů.

Co zůstává nejisté

Beta ponechává několik praktických otázek otevřených. OpenRouter říká, že použití Files API je součástí nástroje shell během beta verze, ale dlouhodobé oceňování souborů, pravidla pro uchovávání a provozní limity mohou být stále důležité pro produkční zátěž. Vývojáři také budou muset otestovat, které modely spolehlivě fungují s nástrojem shell napříč podporovanými cestami kompatibility API.

Zabezpečení je další nevyřešenou otázkou implementace pro kupující. OpenRouter popisuje příkazy jako spuštěné v izolovaných hostovaných linuxových kontejnerech, ale podniky se budou stále ptát na síťový přístup, instalaci balíčků, perzistenci souborů, protokoly auditu a manipulaci s daty před odesláním citlivých úloh prostřednictvím hostovaného prováděcího prostředí.

Širší směr je však jasný: brány pohlcují více času běhu agenta. Směrování modelu dříve znamenalo výběr, kam byla odeslána výzva. Nyní stále více zahrnuje sémantiku nástrojů, stav souborů, politiku provádění a měření bez tokenů. Beta shell OpenRouteru je užitečný ukazatel, protože přiřazuje jasnou cenu schopnosti, kterou mnoho tvůrců agentů považuje za infrastrukturu na pozadí. Jakmile se na vyúčtování objeví čas provedení, stane se součástí architektury produktu.