OpenRouter ir pievienojis beta mitinātu čaulas izpildes rīku un failu API, sniedzot izstrādātājiem iespēju ļaut rīku izsaukšanas modeļiem palaist komandas izolētos Linux konteineros, izmantojot OpenRouter maršrutēšanas slāni. Izlaidums ir vairāk nekā cita aģenta funkcija. Tas maina vairāku modeļu AI infrastruktūras uzskaites modeli: pieprasījums tagad var ietvert modeļa marķierus, rīka izpildes laiku, failu apstrādi un saderības darbību vairāk nekā vienā API stilā.

Jaunais servera rīks ar nosaukumu openrouter:shell ļauj atbalstītajiem modeļiem izpildīt komandas mitinātos konteineros un atgriezt standarta izpildes rezultātus, tostarp stdout, stderr un izejas kodus. OpenRouter saka, ka rīks darbojas, izmantojot tā Responses API ceļu un Anthropic Messages API saderības ceļu, kas ir svarīgi, jo izstrādātāji arvien vairāk cenšas nodrošināt, lai aģentu ieviešana būtu pārnēsājama starp modeļu nodrošinātājiem, nevis saistītu katru darbplūsmu ar viena piegādātāja vietējā rīka saskarni.

OpenRouter cena smilškastei ir 0,0001 ASV dolārs sekundē, kas tiek iekasēta kā daļa no pieprasījuma. Failu API lietojums ir iekļauts beta versijā. Tas rada atsevišķu izmaksu dimensiju no parastajiem ievades un izvades marķieriem un sniedz vārtejas operatoriem konkrētu piemēru, kāpēc vienotā AI API norēķini kļūst grūtāk nekā modeļa marķiera maksu summēšana.

Kas mainījies

Līdz nesenam laikam mitinātā koda izpilde parasti bija saistīta ar pakalpojumu sniedzēja specifisku aģentu kopu vai prasīja izstrādātājiem darboties pašiem ar savu smilškastes parku. OpenRouter beta versija ievieto šo iespēju maršrutēšanas platformā, kas jau tiek izmantota, lai piekļūtu daudziem modeļiem. Praktiski aģents var lūgt modelim pārbaudīt datus, palaist skriptus, manipulēt ar failiem vai pārbaudīt mazus koda fragmentus, lietojumprogrammu komandai nesniedzot konteinerus tieši katrai izpildei.

Svarīga ir informācija par saderību. OpenRouter čaulas rīku pozicionē nevis kā vienas modeļu saimes iespēju, bet gan kā platformas līmeņa rīku virsmu, kas pieejama, izmantojot pazīstamus API modeļus. Komandām, kas izmantojušas OpenAI stila atbildes semantiku vai antropiskā stila ziņojumu semantiku, mitinātais rīks var atrasties tuvāk vārtejas slānim, nevis modeļa slānim.

Tas nepadara instrumenta darbību maģiski vienādu. Dažādi modeļi atšķiras atkarībā no tā, kā tie izsauc rīkus, atkopjas pēc kļūmēm, pamato komandu izvadi un pārvalda failus. Taču lēmums par infrastruktūru mainās. Tā vietā, lai jautātu tikai par to, kurš modelis var rakstīt čaulas komandu, izstrādātājiem tagad ir jājautā, kura vārteja to var droši izpildīt, izmērīt to un atgriezt rezultātus tādā API formā, ko klients jau saprot.

Kāpēc izpildlaika mērīšana ir svarīga

Ar marķiera cenu vairs nepietiek, lai aprakstītu aģenta pieprasījuma izmaksas. Viena lietotāja darbība var ietvert uzvedni, vairākus modeļa pagriezienus, failu augšupielādi, čaulas izpildi, atkārtotus mēģinājumus un galīgo kopsavilkumu. Dārgā daļa var būt modeļa izvade, vai arī tā var būt ilgstoša komanda, kas rada maz teksta. OpenRouter smilškastes sekundes cena padara šo atšķirību nepārprotamu.

Izstrādātājiem tūlītējas sekas ir budžeta izstrāde. Aģentu cilpām ir jāierobežo komandas ilgums, atkārtota mēģinājuma darbība un pieņēmumi par failu saglabāšanu. Nekaitīga izskata pieprasījums, kas izvēršas par atkārtotiem čaulas izsaukumiem, var uzkrāt izpildlaika izmaksas, pat ja marķiera lietojums joprojām ir neliels. Reģistrēšanā ir jāparāda ne tikai modeļa, nodrošinātāja un pilnvaru skaits, bet arī rīka nosaukums, izpildes ilgums, izejas statuss un tas, vai modelis tika atkārtoti mēģināts pēc kļūdas.

Uzņēmumiem, kas balstās uz modeļu vārtejām, izmaiņas skar maržas un klientu pārskatus. Partnera produkts, kas tālāk pārdod AI automatizāciju, nevar uzskatīt katru pieprasījumu kā teksta pabeigšanu ar marķējumu. Tam ir nepieciešama lietošanas virsgrāmata, kas modeļa izmaksas un mitinātā rīka izmaksas var attiecināt uz pareizo darbvietu, gala klientu vai API atslēgu. Tas ir tieši saistīts ar partneru API automatizāciju, kur pakārtotais klients, iespējams, nekad neredzēs OpenRouter neapstrādāto rēķinu, bet tomēr sagaida saskaņotu rēķinu.

Kas tiek ietekmēts

Pirmā skartā grupa ir aģentu izstrādātāji, kuri vēlas koda izpildi, neapņemoties izmantot viena modeļa nodrošinātāja pilno aģentu platformu. OpenRouter pieeja var patikt komandām, kas jau novirza trafiku starp modeļiem un vēlas pievienot čaulas piekļuvi, vienlaikus saglabājot zināmu elastību modeļu izvēlē.

Otrā grupa ir platformu un vārtejas komandas. Viņiem tagad ir jāizlemj, vai mitinātie rīki ir pirmās klases kataloga vienumi, vai tos var iespējot katrai darbvietai un kā to izmaksas tiek rādītas informācijas paneļos. Modeļa kataloga rinda, iespējams, ir jāsavieno pārī ar rīku pieejamību, izpildlaika ierobežojumiem un saderības piezīmēm. Piekļuves kontrolei, iespējams, būs jānošķir modeļa izsaukuma atļaušana un konteinera palaišanas atļaušana šim zvanam.

Trešā grupa ir finanšu un operāciju komandas, kas pārvalda AI izdevumus. Lietojuma analīzē, kas aprobežojas ar marķieriem, netiks izmantota arvien lielāka aģentu infrastruktūras izmaksu klase. Noderīgam AI API lietojuma analīzes informācijas panelim ir jāparāda, vai pieaugumu izraisīja modeļa izvēle, pilnvaras apjoms, smilškastes izpildlaiks vai darbplūsmas dizaina izmaiņas, kas izraisīja papildu rīku izsaukumus.

Kas paliek neskaidrs

Beta versija atstāj atklātus vairākus praktiskus jautājumus. OpenRouter saka, ka beta versijas laikā čaulas rīkā ir iekļauts Files API lietojums, taču ilgtermiņa failu cenas, saglabāšanas noteikumi un darbības ierobežojumi joprojām var būt svarīgi ražošanas darba slodzēm. Izstrādātājiem būs arī jāpārbauda, kuri modeļi droši darbojas ar čaulas rīku atbalstītajos API saderības ceļos.

Drošība ir vēl viens pircēju neatrisināts ieviešanas jautājums. OpenRouter apraksta, ka komandas darbojas izolētos mitinātos Linux konteineros, taču uzņēmumi joprojām jautās par piekļuvi tīklam, pakotņu instalēšanu, failu noturību, audita žurnālus un datu apstrādi, pirms tiek nosūtītas sensitīvas darba slodzes, izmantojot mitinātu izpildes vidi.

Tomēr plašāks virziens ir skaidrs: vārtejas absorbē vairāk aģenta izpildlaika. Modeļa maršrutēšana agrāk nozīmēja izvēli, kur tika nosūtīta uzvedne. Tagad tas arvien vairāk ietver rīku semantiku, faila stāvokli, izpildes politiku un bezžetonu mērīšanu. OpenRouter apvalka beta versija ir noderīgs marķieris, jo tas piešķir skaidru cenu iespējai, ko daudzi aģentu veidotāji ir uzskatījuši par fona infrastruktūru. Kad izpildes laiks ir norādīts rēķinā, tas kļūst par daļu no produkta arhitektūras.