OpenRouter ha aggiunto uno strumento di esecuzione della shell in hosting beta e un'API Files, offrendo agli sviluppatori un modo per consentire ai modelli che chiamano strumenti di eseguire comandi in contenitori Linux isolati attraverso il livello di routing di OpenRouter. Il rilascio è più di un'altra funzionalità dell'agente. Cambia il modello contabile per l'infrastruttura AI multimodello: una richiesta ora può includere token del modello, tempo di esecuzione dello strumento, gestione dei file e comportamento di compatibilità su più di uno stile API.
Il nuovo strumento server, denominato openrouter:shell, consente ai modelli supportati di eseguire comandi in contenitori ospitati e restituire risultati di esecuzione standard, inclusi stdout, stderr e codici di uscita. OpenRouter afferma che lo strumento funziona attraverso il percorso API Responses e il percorso di compatibilità API Anthropic Messages, il che è importante perché gli sviluppatori cercano sempre più di mantenere le implementazioni degli agenti portabili tra i fornitori di modelli anziché vincolare ogni flusso di lavoro all'interfaccia dello strumento nativo di un fornitore.
OpenRouter valuta il sandbox a $ 0,0001 al secondo, fatturato come parte della richiesta. L'utilizzo dell'API File è incluso durante la versione beta. Ciò crea una dimensione di costo separata dai normali token di input e output e fornisce agli operatori gateway un esempio concreto del motivo per cui la fatturazione API AI unificata sta diventando più difficile della somma dei costi dei token modello.
Cosa è cambiato
Fino a poco tempo fa, l'esecuzione del codice ospitato era solitamente legata a uno stack di agenti specifico del provider o richiedeva agli sviluppatori di gestire il proprio parco sandbox. La versione beta di OpenRouter inserisce questa funzionalità in una piattaforma di routing già utilizzata per accedere a molti modelli. In termini pratici, un agente può chiedere a un modello di ispezionare dati, eseguire script, manipolare file o testare piccole porzioni di codice senza che il team dell'applicazione fornisca direttamente i contenitori per ogni esecuzione.
I dettagli sulla compatibilità sono importanti. OpenRouter sta posizionando lo strumento shell non come una funzionalità di una famiglia di modelli, ma come una superficie di strumenti a livello di piattaforma disponibile attraverso modelli API familiari. Per i team che si sono basati sulla semantica delle risposte in stile OpenAI o sulla semantica dei messaggi in stile Anthropic, lo strumento ospitato può trovarsi più vicino al livello gateway che al livello del modello.
Ciò non rende magicamente uniforme il comportamento dello strumento. Diversi modelli variano nel modo in cui chiamano gli strumenti, ripristinano gli errori, ragionano sull'output dei comandi e gestiscono i file. Ma la decisione sulle infrastrutture sta cambiando. Invece di chiedere solo quale modello può scrivere un comando shell, gli sviluppatori ora devono chiedersi quale gateway può eseguirlo in sicurezza, misurarlo e restituire i risultati nella forma API che il loro cliente già comprende.
Perché la misurazione del tempo di esecuzione è importante
Il prezzo dei token non è più sufficiente per descrivere il costo di una richiesta di un agente. Una singola azione dell'utente può comportare un prompt, diversi turni del modello, caricamenti di file, esecuzione della shell, tentativi e riepilogo finale. La parte costosa potrebbe essere l'output del modello oppure un comando di lunga esecuzione che produce poco testo. Il prezzo sandbox al secondo di OpenRouter rende esplicita questa distinzione.
Per gli sviluppatori, la conseguenza immediata è la definizione del budget. I cicli dell'agente necessitano di limiti sulla durata del comando, sul comportamento dei tentativi e sui presupposti di conservazione dei file. Una richiesta apparentemente innocua che si espande in ripetute chiamate alla shell può accumulare costi di runtime anche se l'utilizzo del token rimane modesto. La registrazione deve mostrare non solo il numero di modelli, provider e token, ma anche il nome dello strumento, la durata dell'esecuzione, lo stato di uscita e se il modello ha riprovato dopo un errore.
Per le aziende che si basano su gateway modello, il cambiamento tocca i margini e il reporting dei clienti. Un prodotto partner che rivende l'automazione AI non può trattare ogni richiesta come un completamento di testo con un markup. Ha bisogno di un registro di utilizzo in grado di attribuire il costo del modello e il costo dello strumento ospitato allo spazio di lavoro, al cliente finale o alla chiave API corretti. Ciò è direttamente rilevante per l'automazione delle API partner, in cui il cliente a valle potrebbe non vedere mai la fattura grezza di OpenRouter ma si aspetta comunque una fattura coerente.
Chi è interessato
Il primo gruppo interessato è quello degli sviluppatori di agenti che desiderano l'esecuzione del codice senza impegnarsi nella piattaforma di agenti completa di un fornitore di modelli. L'approccio di OpenRouter potrebbe attrarre i team che già instradano il traffico attraverso modelli e desiderano aggiungere l'accesso alla shell preservando una certa flessibilità nella scelta del modello.
Il secondo gruppo è costituito dai team della piattaforma e del gateway. Ora devono decidere se gli strumenti ospitati sono elementi di catalogo di prima classe, se possono essere abilitati per ogni area di lavoro e come vengono visualizzati i relativi costi nei dashboard. Potrebbe essere necessario associare una riga del catalogo modelli alla disponibilità dello strumento, ai limiti di runtime e alle note di compatibilità. Il controllo degli accessi potrebbe dover distinguere tra consentire una chiamata al modello e consentire a tale chiamata di avviare un contenitore.
Il terzo gruppo è costituito dai team finanziari e operativi che gestiscono la spesa relativa all'intelligenza artificiale. L'analisi dell'utilizzo che si ferma ai token non terrà conto di una classe crescente di costi dell'infrastruttura degli agenti. Un utile dashboard di analisi dell'utilizzo dell'API AI dovrebbe mostrare se un picco è derivato dalla scelta del modello, dal volume del token, dal runtime del sandbox o da una modifica alla progettazione del flusso di lavoro che ha causato chiamate aggiuntive a strumenti.
Ciò che rimane incerto
La versione beta lascia aperte diverse questioni pratiche. OpenRouter afferma che l'utilizzo dell'API Files è incluso nello strumento Shell durante la beta, ma i prezzi dei file a lungo termine, le regole di conservazione e i limiti operativi potrebbero comunque avere importanza per i carichi di lavoro di produzione. Gli sviluppatori dovranno inoltre testare quali modelli funzionano in modo affidabile con lo strumento Shell attraverso i percorsi di compatibilità API supportati.
La sicurezza è un'altra questione di implementazione irrisolta per gli acquirenti. OpenRouter descrive i comandi come eseguiti in contenitori Linux ospitati isolati, ma le aziende continueranno a chiedere informazioni sull'accesso alla rete, l'installazione dei pacchetti, la persistenza dei file, i registri di controllo e la gestione dei dati prima di inviare carichi di lavoro sensibili attraverso un ambiente di esecuzione ospitato.
Tuttavia, la direzione più ampia è chiara: i gateway assorbono una quota maggiore del tempo di esecuzione dell'agente. Il routing del modello significava scegliere dove veniva inviato un prompt. Ora include sempre più la semantica degli strumenti, lo stato dei file, la politica di esecuzione e la misurazione non token. La versione beta della shell di OpenRouter è un indicatore utile perché attribuisce un prezzo chiaro a una funzionalità che molti costruttori di agenti hanno trattato come infrastruttura di background. Una volta indicato in fattura, il tempo di esecuzione diventa parte dell'architettura del prodotto.