OpenRouter ha afegit una eina d'execució de l'intèrpret d'ordres allotjada en versió beta i una API de fitxers, que ofereix als desenvolupadors una manera de permetre que els models de trucada d'eines executin ordres en contenidors Linux aïllats mitjançant la capa d'encaminament d'OpenRouter. El llançament és més que una altra característica d'agent. Canvia el model de comptabilitat per a una infraestructura d'IA multimodel: ara una sol·licitud pot incloure testimonis de model, temps d'execució de l'eina, maneig de fitxers i comportament de compatibilitat en més d'un estil d'API.
La nova eina de servidor, anomenada openrouter:shell, permet als models compatibles executar ordres en contenidors allotjats i retornar resultats d'execució estàndard, inclosos els codis stdout, stderr i de sortida. OpenRouter diu que l'eina funciona a través de la seva ruta de l'API de Respostes i la seva ruta de compatibilitat de l'API de missatges antròpics, que és important perquè els desenvolupadors intenten cada cop més mantenir les implementacions d'agents portàtils entre proveïdors de models en lloc d'enllaçar tots els fluxos de treball a la interfície d'eina nativa d'un proveïdor.
OpenRouter valora el sandbox a 0,0001 $ per segon, facturat com a part de la sol·licitud. L'ús de l'API de fitxers s'inclou durant la versió beta. Això crea una dimensió de cost separada dels testimonis d'entrada i sortida normals i ofereix als operadors de passarel·la un exemple concret de per què la facturació unificada de l'API d'IA s'està tornant més difícil que sumar els càrrecs dels testimonis del model.
Què ha canviat
Fins fa poc, l'execució de codi allotjat normalment estava lligada a una pila d'agents específica del proveïdor o requeria que els desenvolupadors operessin la seva pròpia flota de sandbox. La versió beta d'OpenRouter insereix aquesta capacitat en una plataforma d'encaminament que ja s'utilitza per accedir a molts models. En termes pràctics, un agent pot demanar a un model que inspeccioni dades, executi scripts, manipuli fitxers o proveu petits fragments de codi sense que l'equip de l'aplicació proporcioni contenidors directament per a cada execució.
El detall de la compatibilitat és important. OpenRouter està posicionant l'eina shell no com una capacitat d'una família de models, sinó com una superfície d'eina a nivell de plataforma disponible a través de patrons d'API familiars. Per als equips que han creat una semàntica de respostes d'estil OpenAI o una semàntica de missatges d'estil antròpic, l'eina allotjada pot estar més a prop de la capa de passarel·la que de la capa del model.
Això no fa que el comportament de l'eina sigui màgicament uniforme. Els diferents models varien pel que fa a com criden a les eines, com es recuperen de fallades, raonen la sortida d'ordres i gestionen fitxers. Però la decisió sobre la infraestructura està canviant. En lloc de preguntar només quin model pot escriure una ordre d'intèrpret d'ordres, ara els desenvolupadors han de preguntar quina passarel·la pot executar-la de manera segura, mesurar-la i retornar els resultats en la forma d'API que el seu client ja entén.
Per què és important la mesura del temps d'execució
El preu del testimoni ja no és suficient per descriure el cost d'una sol·licitud d'agent. Una única acció de l'usuari pot implicar una indicació, diversos girs de model, càrregues de fitxers, execució de l'intèrpret d'ordres, reintents i resum final. La part cara pot ser la sortida del model, o pot ser una ordre de llarga durada que produeix poc text. El preu del sandbox per segon d'OpenRouter fa aquesta distinció explícita.
Per als desenvolupadors, la conseqüència immediata és el disseny del pressupost. Els bucles d'agent necessiten límits en la durada de les ordres, el comportament dels reintents i els supòsits de retenció de fitxers. Una sol·licitud d'aspecte inofensiu que s'expandeix en trucades d'intèrpret d'ordres repetides pot acumular càrrecs en temps d'execució, fins i tot si l'ús del testimoni segueix sent modest. El registre ha de mostrar no només el recompte de models, proveïdors i testimonis, sinó també el nom de l'eina, la durada de l'execució, l'estat de sortida i si el model s'ha tornat a intentar després d'un error.
Per a les empreses que es basen en passarel·les models, el canvi afecta els marges i els informes dels clients. Un producte associat que ven l'automatització d'IA no pot tractar totes les sol·licituds com a finalització de text amb un marcatge. Necessita un registre d'ús que pugui atribuir el cost del model i el cost de l'eina allotjada a l'espai de treball, el client final o la clau API adequats. Això és directament rellevant per a l'automatització de l'API del partner, on és possible que el client aigües avall mai vegi la factura sense processar d'OpenRouter però encara espera una factura coherent.
Qui està afectat
El primer grup afectat són els desenvolupadors d'agents que volen executar codi sense comprometre's amb la plataforma d'agents completa d'un proveïdor de models. L'enfocament d'OpenRouter pot agradar als equips que ja encaminen el trànsit entre models i volen afegir accés a l'intèrpret d'ordres alhora que es conserven una certa flexibilitat en l'elecció del model.
El segon grup són els equips de plataforma i passarel·la. Ara han de decidir si les eines allotjades són articles de catàleg de primera classe, si es poden habilitar per àrea de treball i com apareixen els seus costos als taulers de control. És possible que s'hagi de vincular una fila de catàleg de models amb la disponibilitat de l'eina, els límits de temps d'execució i les notes de compatibilitat. És possible que el control d'accés hagi de distingir entre permetre una trucada de model i permetre que aquesta trucada iniciï un contenidor.
El tercer grup són els equips de finances i operacions que gestionen la despesa en IA. Les analítiques d'ús que s'aturen en els testimonis perdran una classe creixent de costos d'infraestructura d'agents. Un tauler d'anàlisi d'ús de l'API d'AI útil hauria de mostrar si un augment prové de l'elecció del model, el volum del testimoni, el temps d'execució de la caixa de proves o un canvi de disseny del flux de treball que va provocar trucades addicionals a l'eina.
Què segueix sent incert
La versió beta deixa obertes diverses preguntes pràctiques. OpenRouter diu que l'ús de l'API de fitxers s'inclou amb l'eina d'intèrpret d'ordres durant la versió beta, però els preus dels fitxers a llarg termini, les regles de retenció i els límits operatius encara poden importar per a les càrregues de treball de producció. Els desenvolupadors també hauran de provar quins models funcionen de manera fiable amb l'eina shell als camins de compatibilitat de l'API compatibles.
La seguretat és una altra qüestió d'implementació no resolta per als compradors. OpenRouter descriu que les ordres s'executen en contenidors Linux allotjats aïllats, però les empreses encara preguntaran sobre l'accés a la xarxa, la instal·lació de paquets, la persistència dels fitxers, els registres d'auditoria i el maneig de dades abans d'enviar càrregues de treball sensibles a través d'un entorn d'execució allotjat.
La direcció més àmplia és clara, però: les passarel·les absorbeixen més temps d'execució de l'agent. El model d'encaminament solia significar triar on s'enviava una sol·licitud. Ara inclou cada cop més la semàntica de l'eina, l'estat del fitxer, la política d'execució i la mesura sense testimoni. La beta de l'intèrpret d'ordres d'OpenRouter és un marcador útil perquè associa un preu clar a una capacitat que molts creadors d'agents han tractat com a infraestructura de fons. Un cop apareix el temps d'execució a la factura, passa a formar part de l'arquitectura del producte.