Az OpenRouter hozzáadott egy béta-hosztolt shell-végrehajtási eszközt és a Files API-t, í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, eszközvégrehajtási időt, fájlkezelést és kompatibilitási viselkedést is tartalmazhat egynél több API stílusban.
Az openrouter:shell nevű új kiszolgálóeszkö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-n és az Anthropic Messages API-kompatibilitási útvonalon keresztül működik, ami azért számít, mert a fejlesztők egyre inkább igyekeznek hordozhatóvá tenni az ügynök-megvaló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 sandboxot másodpercenként 0,0001 USD áron árazza, a kérés részeként számlázva. A Files API használatát a béta tartalmazza. 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ó-üzemeltetőknek arra, hogy az egyesített AI API-számlázás miért válik nehezebbé, mint a modell-token díjak összegzése.
Mi változott
A közelmúltig a hosztolt kód végrehajtása általában egy 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, hogy vizsgálja meg az adatokat, futtasson szkripteket, manipuláljon fájlokat vagy teszteljen kis kódrészleteket anélkül, hogy az alkalmazáscsapat minden egyes 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. Azoknál a csapatoknál, amelyek az OpenAI-stílusú válaszok szemantikája vagy az antropikus stílusú üzenetek szemantikája ellen építettek, 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. De az infrastrukturális döntés megváltozik. Ahelyett, hogy csak azt kérdeznék meg, 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 visszaadni az eredményeket abban az API alakban, amelyet az ügyfeleik már megértenek.
Miért számít 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 és 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.
Ki érintett
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 hozzá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. Lehetséges, 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ás, a token mennyisége, a sandbox futási ideje vagy a munkafolyamat-terv olyan változása miatt következett be, amely extra eszközhívásokat okozott.
Ami továbbra is bizonytalan
A béta számos gyakorlati kérdést nyitva hagy. Az OpenRouter szerint a Files API használatát a shell eszköz tartalmazza a béta alatt, de a hosszú távú fájlárak, 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 nagyobb részt 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. Ha a végrehajtási idő megjelenik a számlán, az a termék architektúrájának részévé válik.