OpenRouter dodał narzędzie do wykonywania powłoki w wersji beta i interfejs API Files, dając programistom możliwość umożliwienia modelom wywołującym narzędzia uruchamiania poleceń w izolowanych kontenerach systemu Linux za pośrednictwem warstwy routingu OpenRouter. Ta wersja to coś więcej niż kolejna funkcja agenta. Zmienia model rozliczania wielomodelowej infrastruktury AI: żądanie może teraz obejmować tokeny modelu, czas wykonania narzędzia, obsługę plików i zachowanie zgodności w więcej niż jednym stylu API.

Nowe narzędzie serwerowe o nazwie openrouter:shell umożliwia obsługiwanym modelom wykonywanie poleceń w hostowanych kontenerach i zwracanie standardowych wyników wykonania, w tym stdout, stderr i kodów wyjścia. OpenRouter twierdzi, że narzędzie działa poprzez ścieżkę interfejsu API Responses i ścieżkę zgodności interfejsu API Anthropic Messages, co ma znaczenie, ponieważ programiści coraz częściej starają się zapewnić przenośność implementacji agentów między dostawcami modeli, zamiast wiązać każdy przepływ pracy z natywnym interfejsem narzędzia jednego dostawcy.

OpenRouter wycenia piaskownicę na 0,0001 USD za sekundę i jest rozliczana jako część żądania. W wersji beta uwzględnione jest korzystanie z interfejsu Files API. Tworzy to odrębny wymiar kosztów od zwykłych tokenów wejściowych i wyjściowych i daje operatorom bram konkretny przykład tego, dlaczego ujednolicone rozliczanie interfejsu API AI staje się trudniejsze niż sumowanie opłat za tokeny modelu.

Co się zmieniło

Do niedawna wykonywanie kodu hostowanego było zwykle powiązane ze stosem agentów specyficznym dla dostawcy lub wymagało od programistów obsługi własnej floty piaskownicy. Wersja beta OpenRouter dodaje tę funkcję do platformy routingu, z której korzysta się już w celu uzyskania dostępu do wielu modeli. W praktyce agent może poprosić model o sprawdzenie danych, uruchomienie skryptów, manipulowanie plikami lub testowanie małych fragmentów kodu bez bezpośredniego udostępniania kontenerów przez zespół aplikacji dla każdego uruchomienia.

Szczegóły dotyczące zgodności są ważne. OpenRouter pozycjonuje narzędzie powłoki nie jako funkcję jednej rodziny modeli, ale jako powierzchnię narzędziową na poziomie platformy dostępną poprzez znane wzorce API. W przypadku zespołów, które korzystały z semantyki odpowiedzi w stylu OpenAI lub semantyki wiadomości w stylu antropicznym, hostowane narzędzie może znajdować się bliżej warstwy bramy niż warstwy modelu.

To nie sprawia, że zachowanie narzędzia jest magicznie jednolite. Różne modele różnią się sposobem wywoływania narzędzi, przywracaniem działania po awariach, określaniem wyników poleceń i zarządzaniem plikami. Jednak decyzja dotycząca infrastruktury ulega zmianie. Zamiast pytać tylko, który model może napisać polecenie powłoki, programiści muszą teraz zapytać, która brama może bezpiecznie je wykonać, zmierzyć to i zwrócić wyniki w kształcie interfejsu API, który ich klient już rozumie.

Dlaczego pomiar czasu działania ma znaczenie

Cena tokena nie jest już wystarczająca do opisania kosztu żądania agenta. Pojedyncza akcja użytkownika może obejmować monit, kilka obrotów modelu, przesłanie pliku, wykonanie powłoki, ponowne próby i końcowe podsumowanie. Kosztowną częścią może być wynik modelu lub może to być długotrwałe polecenie generujące niewielką ilość tekstu. Cena piaskownicy OpenRouter za sekundę wyraźnie pokazuje to rozróżnienie.

Dla programistów bezpośrednią konsekwencją jest projekt budżetu. Pętle agentów wymagają ograniczeń dotyczących czasu trwania poleceń, zachowania ponownych prób i założeń dotyczących przechowywania plików. Nieszkodliwie wyglądające żądanie, które rozwija się w powtarzające się wywołania powłoki, może skumulować opłaty za czas wykonania, nawet jeśli użycie tokenu pozostaje skromne. Rejestrowanie musi pokazywać nie tylko liczbę modeli, dostawców i tokenów, ale także nazwę narzędzia, czas wykonania, status wyjścia i informację, czy model został ponowiony po wystąpieniu błędu.

W przypadku firm korzystających z bram modelowych zmiana dotyczy marż i raportowania klientów. Produkt partnerski sprzedający automatyzację AI nie może traktować każdego żądania jako uzupełnienia tekstu znacznikiem. Potrzebuje księgi użytkowania, która może przypisać koszt modelu i koszt hostowanego narzędzia do odpowiedniego obszaru roboczego, klienta końcowego lub klucza API. Ma to bezpośrednie znaczenie dla automatyzacji partnerskiego API, w przypadku której dalszy klient może nigdy nie zobaczyć surowej faktury OpenRouter, ale nadal oczekuje spójnego rachunku.

Kogo dotyczy

Pierwszą grupą, której to dotyczy, są programiści agentów, którzy chcą wykonywania kodu bez konieczności korzystania z pełnej platformy agenta jednego dostawcy modelu. Podejście OpenRouter może spodobać się zespołom, które już kierują ruch między modelami i chcą dodać dostęp do powłoki, zachowując jednocześnie pewną elastyczność w wyborze modelu.

Druga grupa to zespoły zajmujące się platformą i bramą. Muszą teraz zdecydować, czy hostowane narzędzia są najwyższej klasy elementami katalogu, czy można je włączyć dla każdego obszaru roboczego i jak ich koszty są wyświetlane na pulpitach nawigacyjnych. Może zaistnieć potrzeba sparowania wiersza katalogu modelu z dostępnością narzędzi, ograniczeniami czasu wykonywania i uwagami dotyczącymi kompatybilności. Kontrola dostępu może wymagać rozróżnienia pomiędzy zezwoleniem na wywołanie modelowe a zezwoleniem na uruchomienie kontenera przez to wywołanie.

Trzecia grupa to zespoły finansowe i operacyjne zarządzające wydatkami na sztuczną inteligencję. Analityka użytkowania, która kończy się na tokenach, pominie rosnącą klasę kosztów infrastruktury agentów. Przydatny pulpit nawigacyjny analizy użycia interfejsu API AI powinien pokazywać, czy skok wynika z wyboru modelu, wolumenu tokenów, środowiska wykonawczego piaskownicy czy zmiany w projekcie przepływu pracy, która spowodowała wywołania dodatkowych narzędzi.

Co pozostaje niepewne

W wersji beta kilka praktycznych kwestii pozostaje otwartych. OpenRouter twierdzi, że korzystanie z interfejsu Files API jest uwzględnione w narzędziu powłoki w wersji beta, ale długoterminowe ceny plików, zasady przechowywania i limity operacyjne mogą nadal mieć znaczenie w przypadku obciążeń produkcyjnych. Programiści będą musieli także przetestować, które modele działają niezawodnie z narzędziem powłoki w ramach obsługiwanych ścieżek zgodności API.

Bezpieczeństwo to kolejna nierozwiązana kwestia dotycząca wdrożenia dla kupujących. OpenRouter opisuje polecenia jako działające w izolowanych hostowanych kontenerach systemu Linux, ale przedsiębiorstwa nadal będą pytać o dostęp do sieci, instalację pakietów, trwałość plików, dzienniki audytu i obsługę danych przed wysłaniem wrażliwych obciążeń przez hostowane środowisko wykonawcze.

Jednak szerszy kierunek jest jasny: bramy pochłaniają więcej czasu działania agenta. Routing modelowy oznaczał kiedyś wybór miejsca wysłania podpowiedzi. Obecnie w coraz większym stopniu obejmuje semantykę narzędzi, stan plików, zasady wykonywania i pomiary nietokenowe. Wersja beta powłoki OpenRouter jest użytecznym znacznikiem, ponieważ przywiązuje jasną cenę do możliwości, które wielu twórców agentów traktowało jako infrastrukturę w tle. Gdy czas realizacji pojawi się na rachunku, staje się on częścią architektury produktu.