OpenRouter a ajouté un outil d'exécution de shell hébergé en version bêta et une API de fichiers, offrant aux développeurs un moyen de permettre aux modèles appelant des outils d'exécuter des commandes dans des conteneurs Linux isolés via la couche de routage d'OpenRouter. Cette version est bien plus qu'une autre fonctionnalité de l'agent. Il modifie le modèle de comptabilité pour l'infrastructure d'IA multimodèle : une requête peut désormais inclure des jetons de modèle, le temps d'exécution de l'outil, la gestion des fichiers et le comportement de compatibilité entre plusieurs styles d'API.

Le nouvel outil serveur, nommé openrouter:shell, permet aux modèles pris en charge d'exécuter des commandes dans des conteneurs hébergés et de renvoyer des résultats d'exécution standard, notamment stdout, stderr et les codes de sortie. OpenRouter affirme que l'outil fonctionne via son chemin d'API Responses et son chemin de compatibilité API Anthropic Messages, ce qui est important car les développeurs essaient de plus en plus de garder les implémentations d'agents portables entre les fournisseurs de modèles plutôt que de lier chaque flux de travail à l'interface d'outil native d'un fournisseur.

OpenRouter tarife le bac à sable à 0,0001 $ par seconde, facturé dans le cadre de la demande. L'utilisation de l'API Files est incluse pendant la version bêta. Cela crée une dimension de coût distincte des jetons d'entrée et de sortie ordinaires, et donne aux opérateurs de passerelle un exemple concret de la raison pour laquelle la facturation unifiée des API d'IA devient plus difficile que la somme des frais de jetons du modèle.

Ce qui a changé

Jusqu'à récemment, l'exécution de code hébergé était généralement liée à une pile d'agents spécifique au fournisseur ou obligeait les développeurs à exploiter leur propre parc de bacs à sable. La version bêta d'OpenRouter insère cette fonctionnalité dans une plateforme de routage déjà utilisée pour accéder à de nombreux modèles. Concrètement, un agent peut demander à un modèle d'inspecter des données, d'exécuter des scripts, de manipuler des fichiers ou de tester de petits morceaux de code sans que l'équipe d'application ne provisionne directement les conteneurs pour chaque exécution.

Les détails de compatibilité sont importants. OpenRouter positionne l'outil shell non pas comme une capacité d'une famille de modèles, mais comme une surface d'outils au niveau de la plate-forme disponible via des modèles d'API familiers. Pour les équipes qui ont construit une sémantique de réponses de style OpenAI ou une sémantique de messages de style anthropique, l'outil hébergé peut être plus proche de la couche passerelle que de la couche modèle.

Cela ne rend pas le comportement de l'outil magiquement uniforme. Différents modèles varient dans la manière dont ils appellent les outils, récupèrent après des échecs, raisonnent sur le résultat des commandes et gèrent les fichiers. Mais la décision en matière d’infrastructure est en train de changer. Au lieu de demander uniquement quel modèle peut écrire une commande shell, les développeurs doivent désormais demander quelle passerelle peut l'exécuter en toute sécurité, la mesurer et renvoyer les résultats dans la forme API que leur client comprend déjà.

Pourquoi la mesure du temps d'exécution est importante

La tarification des jetons ne suffit plus à décrire le coût d'une demande d'agent. Une seule action utilisateur peut impliquer une invite, plusieurs tours de modèle, des téléchargements de fichiers, l'exécution d'un shell, des tentatives et un résumé final. La partie la plus coûteuse peut être la sortie du modèle ou une commande de longue durée qui produit peu de texte. Le prix du bac à sable par seconde d'OpenRouter rend cette distinction explicite.

Pour les développeurs, la conséquence immédiate est la conception du budget. Les boucles d'agent nécessitent des limites sur la durée des commandes, le comportement des nouvelles tentatives et les hypothèses de conservation des fichiers. Une requête apparemment inoffensive qui se transforme en appels shell répétés peut accumuler des frais d'exécution même si l'utilisation du jeton reste modeste. La journalisation doit afficher non seulement le nombre de modèles, de fournisseurs et de jetons, mais également le nom de l'outil, la durée d'exécution, l'état de sortie et si le modèle a réessayé après une erreur.

Pour les entreprises qui s'appuient sur des passerelles modèles, le changement touche les marges et les rapports clients. Un produit partenaire qui revend l'automatisation de l'IA ne peut pas traiter chaque demande comme une complétion de texte avec un balisage. Il a besoin d'un grand livre d'utilisation capable d'attribuer le coût du modèle et le coût de l'outil hébergé au bon espace de travail, au client final ou à la clé API. Cela est directement pertinent pour l'automatisation des API partenaires, où le client en aval peut ne jamais voir la facture brute d'OpenRouter mais s'attend toujours à une facture cohérente.

Qui est concerné

Le premier groupe concerné est celui des développeurs d'agents qui souhaitent exécuter du code sans s'engager sur la plate-forme d'agent complète d'un fournisseur de modèles. L'approche d'OpenRouter peut plaire aux équipes qui acheminent déjà le trafic entre les modèles et souhaitent ajouter un accès au shell tout en préservant une certaine flexibilité dans le choix du modèle.

Le deuxième groupe est constitué des équipes de plate-forme et de passerelle. Ils doivent désormais décider si les outils hébergés constituent des éléments de catalogue de premier ordre, s'ils peuvent être activés par espace de travail et comment leurs coûts apparaissent dans les tableaux de bord. Une ligne du catalogue de modèles devra peut-être être associée à la disponibilité des outils, aux limites d'exécution et aux notes de compatibilité. Le contrôle d'accès devra peut-être faire la distinction entre autoriser un appel de modèle et autoriser cet appel à démarrer un conteneur.

Le troisième groupe est constitué des équipes financières et opérationnelles qui gèrent les dépenses en IA. L’analyse de l’utilisation qui s’arrête aux jetons passera à côté d’une classe croissante de coûts d’infrastructure d’agent. Un tableau de bord d'analyse de l'utilisation des API IA devrait indiquer si un pic provient du choix du modèle, du volume de jetons, de l'exécution du bac à sable ou d'une modification de la conception du flux de travail qui a provoqué des appels d'outils supplémentaires.

Ce qui reste incertain

La version bêta laisse plusieurs questions pratiques ouvertes. OpenRouter indique que l'utilisation de l'API Files est incluse dans l'outil shell pendant la version bêta, mais la tarification des fichiers à long terme, les règles de conservation et les limites opérationnelles peuvent toujours être importantes pour les charges de travail de production. Les développeurs devront également tester quels modèles fonctionnent de manière fiable avec l'outil shell sur les chemins de compatibilité API pris en charge.

La sécurité est une autre question de mise en œuvre non résolue pour les acheteurs. OpenRouter décrit les commandes comme s'exécutant dans des conteneurs Linux hébergés isolés, mais les entreprises poseront toujours des questions sur l'accès au réseau, l'installation des packages, la persistance des fichiers, les journaux d'audit et la gestion des données avant d'envoyer des charges de travail sensibles via un environnement d'exécution hébergé.

La direction générale est cependant claire : les passerelles absorbent davantage de temps d'exécution des agents. Le routage modèle signifiait auparavant choisir où une invite était envoyée. Désormais, cela inclut de plus en plus la sémantique des outils, l’état des fichiers, la politique d’exécution et la mesure des non-jetons. La version bêta du shell d’OpenRouter est un marqueur utile car elle fixe un prix clair à une fonctionnalité que de nombreux constructeurs d’agents ont considérée comme une infrastructure d’arrière-plan. Une fois que le temps d'exécution apparaît sur la facture, il devient partie intégrante de l'architecture du produit.