Az OpenRouter hozzáadott egy béta hosztolt shell-végrehajtási eszközt és a API fájlokat, így a fejlesztők lehetővé teszik, hogy az eszközhívó modellek parancsokat futtassanak izolált Linux-tárolókban az OpenRouter útválasztási rétegén keresztül. A kiadás több, mint egy másik ügynöki funkció. Megváltoztatja a többmodelles AI-infrastruktúra elszámolási modelljét: egy kérés mostantól modelltokeneket, szerszámvégrehajtási időt, fájlkezelést és kompatibilitási viselkedést is tartalmazhat egynél több API stílusban.
A openrouter:shell nevű új szervereszköz lehetővé teszi a támogatott modellek számára, hogy parancsokat hajtsanak végre hostolt tárolókban, és szabványos végrehajtási eredményeket adjanak vissza, beleértve az stdout, stderr és kilépési kódokat. Az OpenRouter szerint az eszköz a Responses API útvonalon és a Anthropic Messages API kompatibilitási útvonalán keresztül működik, ami azért fontos, mert a fejlesztők egyre inkább igyekeznek hordozhatóvá tenni az ügynökmegvalósításokat a modellszolgáltatók között, ahelyett, hogy minden munkafolyamatot egy gyártó natív eszközfelületéhez kötnének.
Az OpenRouter a homokozót másodpercenként 0,0001 USD áron árazza, a kérés részeként számlázva. A bétaverzió során a fájlok API használata is benne van. Ez külön költségdimenziót hoz létre a szokásos bemeneti és kimeneti tokenektől, és konkrét példát ad az átjáró operátoroknak arra, hogy az unified AI API billing miért válik nehezebbé, mint a modell token díjainak összegzése.
Mi változott
A közelmúltig a tárolt kód végrehajtása általában szolgáltató-specifikus ügynökkészlethez volt kötve, vagy a fejlesztőknek saját sandbox-flottájukat kellett működtetniük. Az OpenRouter béta verziója beilleszti ezt a képességet egy útválasztási platformba, amelyet már sok modell eléréséhez használtak. Gyakorlatilag az ügynök megkérheti a modellt adatok vizsgálatára, szkriptek futtatására, fájlok manipulálására vagy kis kódrészletek tesztelésére anélkül, hogy az alkalmazáscsapat minden futtatáshoz közvetlenül tárolókat biztosítana.
A kompatibilitási részletek fontosak. Az OpenRouter a shell eszközt nem egy modellcsalád képességeként pozicionálja, hanem platformszintű eszközfelületként, amely ismert API mintákon keresztül érhető el. Azon csapatok esetében, amelyek a OpenAI-stílusú válaszok szemantikája vagy a Anthropic-stílusú Messages szemantika ellen építenek, a hosztolt eszköz közelebb kerülhet az átjáróréteghez, mint a modellréteghez.
Ez nem teszi varázslatosan egységessé a szerszám viselkedését. A különböző modellek eltérő módon hívják meg az eszközöket, hogyan állítják helyre a hibákat, hogyan indokolják a parancskimenetet és kezelik a fájlokat. Az infrastrukturális döntés azonban megváltozik. Ahelyett, hogy csak azt kérdeznék, hogy melyik modell írhat shell-parancsot, a fejlesztőknek most meg kell kérdezniük, hogy melyik átjáró tudja biztonságosan végrehajtani, mérni, és az eredményeket az ügyfeleik által már értett API alakzatban kell visszaadni.
Miért fontos a futásidejű mérés
A token árazás már nem elegendő az ügynökkérelem költségeinek leírásához. Egyetlen felhasználói művelet tartalmazhat egy felszólítást, több modellfordulatot, fájlfeltöltést, shell-végrehajtást, újrapróbálkozásokat és végső összegzést. A drága rész lehet a modell kimenete, vagy lehet egy hosszan futó parancs, amely kevés szöveget produkál. Az OpenRouter sandbox másodpercenkénti ára egyértelművé teszi ezt a különbséget.
A fejlesztők számára ennek közvetlen következménye a költségvetés tervezése. Az ügynökhurkoknak korlátozniuk kell a parancs időtartamát, az újrapróbálkozási viselkedést és a fájlmegőrzési feltételezéseket. Egy ártalmatlannak tűnő kérés, amely ismételt shell-hívásokba terjed ki, futási díjakat halmozhat fel, még akkor is, ha a tokenhasználat szerény marad. A naplózásnak nemcsak a modellek, a szolgáltatók és a jogkivonatok számát kell megjelenítenie, hanem az eszköz nevét, a végrehajtás időtartamát, a kilépési állapotot, valamint azt, hogy a modell megpróbálta-e újra egy hiba után.
A modellátjárókra építkező vállalkozások esetében a változás az árréseket és az ügyféljelentéseket érinti. Az AI-automatizálást viszonteladó partnertermékek nem kezelhetnek minden kérést jelöléssel ellátott szövegkiegészítésként. Szüksége van egy használati főkönyvre, amely a megfelelő munkaterülethez, végfelhasználóhoz vagy API kulcshoz tudja rendelni a modellköltséget és a tárolt eszköz költségét. Ez közvetlenül vonatkozik a partner API automatizálására, ahol előfordulhat, hogy a későbbi ügyfél soha nem látja az OpenRouter nyers számláját, de továbbra is koherens számlát vár.
Kit érint
Az első érintett csoport az ügynökfejlesztők, akik anélkül szeretnének kódot futtatni, hogy elköteleznék magukat egyetlen modellszolgáltató teljes ügynöki platformja mellett. Az OpenRouter megközelítése vonzó lehet azoknak a csapatoknak, akik már a forgalmat modellek között irányítják, és shell-hozzáférést szeretnének adni, miközben megőriznek bizonyos rugalmasságot a modellválasztásban.
A második csoport a platform- és átjárócsapatok. Most el kell dönteniük, hogy a tárolt eszközök első osztályú katalóguselemek-e, engedélyezhetők-e munkaterületenként, és hogyan jelennek meg költségeik a műszerfalakon. Előfordulhat, hogy egy modellkatalógus-sort össze kell párosítani az eszköz elérhetőségével, a futási idejű korlátokkal és a kompatibilitási megjegyzésekkel. Előfordulhat, hogy a hozzáférés-vezérlésnek különbséget kell tennie a modellhívás engedélyezése és a tároló indításának engedélyezése között.
A harmadik csoport a mesterséges intelligencia kiadásait kezelő pénzügyi és üzemeltetési csapatok. A tokeneknél megálló használati elemzések az ügynökinfrastruktúra költségeinek egyre növekvő osztályát hagyják figyelmen kívül. Egy hasznos AI API használati elemzési irányítópultnak meg kell mutatnia, hogy a kiugrás a modellválasztásból, a token mennyiségéből, a sandbox futási idejéből vagy a munkafolyamat-terv olyan változásából származik-e, amely extra eszközhívásokat okozott.
Ami még bizonytalan
A béta számos gyakorlati kérdést nyitva hagy. Az OpenRouter szerint a Files API használatát tartalmazza a shell eszköz a béta alatt, de a hosszú távú fájlok ára, a megőrzési szabályok és a működési korlátok továbbra is számíthatnak az éles munkaterheléseknél. A fejlesztőknek azt is tesztelniük kell, hogy mely modellek működnek megbízhatóan a shell eszközzel a támogatott API kompatibilitási útvonalakon.
A biztonság egy másik megoldatlan megvalósítási kérdés a vásárlók számára. Az OpenRouter leírja, hogy a parancsok izolált hosztolt Linux-tárolókban futnak, de a vállalatok továbbra is rákérdeznek a hálózati hozzáférésre, a csomagok telepítésére, a fájlok fennmaradására, az auditnaplókra és az adatkezelésre, mielőtt érzékeny munkaterheléseket küldenek el egy hosztolt végrehajtási környezetben.
A tágabb irány azonban egyértelmű: az átjárók többet vesznek fel az ügynök futásidejéből. A modell-útválasztás korábban azt jelentette, hogy meg kell választani, hová küldjék a prompt. Mostanra egyre inkább magában foglalja az eszközszemantikát, a fájlállapotot, a végrehajtási szabályzatot és a token nélküli mérést. Az OpenRouter shell bétája hasznos jelző, mert egyértelmű árat tulajdonít egy olyan képességnek, amelyet sok ügynökkészítő háttérinfrastruktúraként kezel. Amint a végrehajtási idő megjelenik a számlán, az a termék architektúrájának részévé válik.