OpenRouter a adăugat un instrument de execuție shell găzduit beta și Files API, oferind dezvoltatorilor o modalitate de a permite modelelor care apelează instrumente să execute comenzi în containere Linux izolate prin stratul de rutare al OpenRouter. Lansarea este mai mult decât o altă funcție de agent. Schimbă modelul de contabilitate pentru infrastructura AI cu mai multe modele: o solicitare poate include acum jetoane de model, timpul de execuție a instrumentului, gestionarea fișierelor și comportamentul de compatibilitate în mai mult de un stil API.

Noul instrument de server, denumit openrouter:shell, permite modelelor acceptate să execute comenzi în containere găzduite și să returneze rezultate standard de execuție, inclusiv coduri stdout, stderr și de ieșire. OpenRouter spune că instrumentul funcționează prin calea Responses API și calea de compatibilitate cu Anthropic Messages API, ceea ce contează deoarece dezvoltatorii încearcă din ce în ce mai mult să mențină implementările agenților portabile între furnizorii de modele, mai degrabă decât să lege fiecare flux de lucru la interfața nativă a instrumentului unui singur furnizor.

OpenRouter prețează sandbox-ul la 0,0001 USD pe secundă, facturat ca parte a solicitării. Utilizarea fișierelor API este inclusă în perioada beta. Acest lucru creează o dimensiune separată a costurilor față de tokenurile obișnuite de intrare și de ieșire și oferă operatorilor de gateway un exemplu concret de ce facturarea unificată AI API devine mai dificilă decât însumarea tarifelor pentru simboluri de model.

Ce s-a schimbat

Până de curând, execuția codului găzduit era de obicei legată de o stivă de agenți specifică furnizorului sau solicita dezvoltatorilor să își opereze propria flotă sandbox. Beta OpenRouter inserează această capacitate într-o platformă de rutare folosită deja pentru a accesa multe modele. În termeni practici, un agent poate cere unui model să inspecteze date, să execute scripturi, să manipuleze fișiere sau să testeze bucăți mici de cod fără ca echipa aplicației să furnizeze containere direct pentru fiecare rulare.

Detaliul de compatibilitate este important. OpenRouter poziționează instrumentul shell nu ca o capacitate a unei familii de modele, ci ca o suprafață de instrumente la nivel de platformă disponibilă prin modele API familiare. Pentru echipele care au construit semantică de răspunsuri în stil OpenAI sau semantică de mesaje în stil antropic, instrumentul găzduit poate sta mai aproape de stratul gateway decât de stratul de model.

Aceasta nu face ca comportamentul sculei să fie uniform în mod magic. Diferitele modele variază în ceea ce privește modul în care apelează instrumentele, se recuperează după defecțiuni, motivează ieșirea comenzii și gestionează fișierele. Dar decizia de infrastructură se schimbă. În loc să întrebe doar ce model poate scrie o comandă shell, dezvoltatorii trebuie acum să întrebe ce gateway o poate executa în siguranță, o poate măsura și returna rezultatele în forma API pe care o înțelege deja clientul lor.

De ce contează măsurarea timpului de rulare

Prețul pentru token nu mai este suficient pentru a descrie costul unei solicitări de agent. O singură acțiune a utilizatorului poate implica un prompt, mai multe transformări de model, încărcări de fișiere, execuție shell, reîncercări și rezumare finală. Partea scumpă poate fi rezultatul modelului sau poate fi o comandă de lungă durată care produce puțin text. Prețul pe secundă pentru mediul de testare al OpenRouter face această distincție explicită.

Pentru dezvoltatori, consecința imediată este proiectarea bugetului. Buclele de agent necesită limite privind durata comenzii, comportamentul reîncercării și ipotezele de păstrare a fișierelor. O solicitare cu aspect inofensiv care se extinde în apeluri shell repetate poate acumula taxe de rulare chiar dacă utilizarea token-ului rămâne modestă. Înregistrarea trebuie să arate nu numai numărul de model, furnizor și token, ci și numele instrumentului, durata execuției, starea de ieșire și dacă modelul a reîncercat după o eroare.

Pentru companiile care se bazează pe modele de gateway, schimbarea atinge marjele și raportarea clienților. Un produs partener care vinde automatizarea AI nu poate trata fiecare solicitare ca o completare a textului cu un marcaj. Are nevoie de un registru de utilizare care să poată atribui costul modelului și costul instrumentului găzduit spațiului de lucru potrivit, clientului final sau cheii API. Acest lucru este direct relevant pentru automatizarea API-ului partenerului, unde clientul din aval poate să nu vadă niciodată factura brută a OpenRouter, dar se așteaptă totuși la o factură coerentă.

Cine este afectat

Primul grup afectat este reprezentat de dezvoltatorii de agenți care doresc execuția codului fără a se angaja în platforma completă de agenți a unui singur furnizor de modele. Abordarea OpenRouter poate atrage echipele care direcționează deja traficul între modele și doresc să adauge acces shell, păstrând în același timp o oarecare flexibilitate în alegerea modelului.

Al doilea grup este echipele de platformă și gateway. Acum trebuie să decidă dacă instrumentele găzduite sunt articole de catalog de primă clasă, dacă pot fi activate pe spațiu de lucru și cum apar costurile lor în tablourile de bord. Este posibil ca un rând de catalog de modele să fie asociat cu disponibilitatea instrumentului, limitele de rulare și note de compatibilitate. Este posibil ca controlul accesului să fie necesar să facă distincția între permiterea unui apel model și permiterea apelului respectiv să pornească un container.

Al treilea grup este echipele de finanțe și operațiuni care gestionează cheltuielile cu inteligența artificială. Analizele de utilizare care se opresc la jetoane vor pierde o clasă în creștere de costuri de infrastructură a agenților. Un tabloul de bord de analiză a utilizării API-ului AI util ar trebui să arate dacă un vârf a venit de la alegerea modelului, volumul jetonului, durata de rulare a sandbox-ului sau o modificare a designului fluxului de lucru care a cauzat apeluri suplimentare de instrumente.

Ce rămâne nesigur

Versiunea beta lasă deschise câteva întrebări practice. OpenRouter spune că utilizarea Files API este inclusă cu instrumentul shell în timpul beta, dar prețul fișierelor pe termen lung, regulile de reținere și limitele operaționale pot conta în continuare pentru sarcinile de producție. Dezvoltatorii vor trebui, de asemenea, să testeze ce modele funcționează fiabil cu instrumentul shell pe căile de compatibilitate API acceptate.

Securitatea este o altă întrebare de implementare nerezolvată pentru cumpărători. OpenRouter descrie comenzile ca rulând în containere Linux găzduite izolate, dar întreprinderile vor întreba în continuare despre accesul la rețea, instalarea pachetului, persistența fișierelor, jurnalele de audit și gestionarea datelor înainte de a trimite sarcini de lucru sensibile printr-un mediu de execuție găzduit.

Direcția mai largă este totuși clară: gateway-urile absorb mai mult din timpul de rulare a agentului. Modelul de rutare însemna obișnuit alegerea locului în care a fost trimis un prompt. Acum include din ce în ce mai mult semantica instrumentului, starea fișierului, politica de execuție și măsurarea non-token. shell-ul beta al OpenRouter este un marker util, deoarece atașează un preț clar unei capacități pe care mulți constructori de agenți au tratat-o ​​ca infrastructură de fundal. Odată ce timpul de execuție apare pe factură, acesta devine parte a arhitecturii produsului.