OpenRouter には、ベータ版のホスト型シェル実行ツールとファイル API が追加されており、開発者はツール呼び出しモデルが OpenRouter のルーティング層を介して分離された Linux コンテナ内でコマンドを実行できるようになります。このリリースは単なるエージェント機能ではありません。これにより、マルチモデル AI インフラストラクチャの会計モデルが変更されます。リクエストには、モデル トークン、ツール実行時間、ファイル処理、複数の API スタイルにわたる互換性動作を含めることができるようになりました。

openrouter:shell という名前の新しいサーバー ツールを使用すると、サポートされているモデルがホストされたコンテナ内でコマンドを実行し、stdout、stderr、終了コードなどの標準的な実行結果を返すことができます。 OpenRouter によれば、このツールは Responses API パスと Anthropic Messages API 互換性パスを通じて機能します。これは、開発者がすべてのワークフローを 1 つのベンダーのネイティブ ツール インターフェイスにバインドするのではなく、モデル プロバイダー間でエージェント実装の移植性を維持しようとする傾向が強まっているため、重要です。

OpenRouter のサンドボックスの料金は 1 秒あたり 0.0001 ドルで、リクエストの一部として請求されます。ファイル API の使用はベータ版に含まれています。これにより、通常の入出力トークンとは別のコスト ディメンションが作成され、ゲートウェイ オペレーターは、統合 AI API の請求がモデル トークンの料金を合計するよりも難しくなっている理由の具体例が得られます。

何が変わったのか

最近まで、ホストされたコードの実行は通常、プロバイダー固有のエージェント スタックに関連付けられているか、開発者が独自のサンドボックス フリートを操作する必要がありました。 OpenRouter のベータ版では、多くのモデルへのアクセスにすでに使用されているルーティング プラットフォームにその機能が組み込まれています。実際には、アプリケーション チームが実行ごとにコンテナを直接プロビジョニングすることなく、エージェントはモデルにデータの検査、スクリプトの実行、ファイルの操作、または小さなコードのテストを依頼できます。

互換性の詳細は重要です。 OpenRouter は、シェル ツールを 1 つのモデル ファミリの機能としてではなく、使い慣れた API パターンを通じて利用できるプラットフォーム レベルのツール サーフェスとして位置付けています。 OpenAI スタイルの Responses セマンティクス、または Anthropic スタイルのメッセージ セマンティクスに基づいて構築したチームの場合、ホストされるツールはモデル層よりもゲートウェイ層の近くに配置できます。

だからといって、ツールの動作が魔法のように均一になるわけではありません。モデルによって、ツールの呼び出し方法、障害からの回復方法、コマンド出力の理由付け、ファイルの管理方法が異なります。しかし、インフラストラクチャに関する決定は変わりつつあります。開発者は、どのモデルがシェル コマンドを作成できるかだけを尋ねるのではなく、どのゲートウェイがシェル コマンドを安全に実行し、測定し、クライアントがすでに理解している API 形式で結果を返すことができるかを尋ねる必要があります。

ランタイム メータリングが重要な理由

トークンの価格設定だけでは、エージェント リクエストのコストを説明するのに十分ではなくなりました。単一のユーザー アクションには、プロンプト、複数のモデル ターン、ファイル アップロード、シェルの実行、再試行、および最終的な要約が含まれる場合があります。高価な部分はモデル出力である可能性があります。あるいは、テキストをほとんど生成しない長時間実行されるコマンドである可能性があります。 OpenRouter の 1 秒あたりのサンドボックス価格により、その違いが明確になります。

開発者にとって、直接的な影響は予算の設計です。エージェント ループには、コマンドの継続時間、再試行動作、およびファイル保持の前提条件に関する制限が必要です。反復的なシェル呼び出しに拡張される無害に見えるリクエストは、トークンの使用量がわずかなままであっても、ランタイム料金を蓄積する可能性があります。ログには、モデル、プロバイダー、トークンの数だけでなく、ツール名、実行時間、終了ステータス、エラー後にモデルが再試行されたかどうかも表示する必要があります。

モデル ゲートウェイ上に構築している企業にとって、この変更は利益と顧客レポートに影響を及ぼします。 AI オートメーションを再販するパートナー製品は、すべてのリクエストをマークアップ付きのテキスト補完として扱うことはできません。モデルのコストとホストされたツールのコストを適切なワークスペース、エンド顧客、または API キーに帰属させることができる使用状況台帳が必要です。これは、パートナー API の自動化に直接関係しており、下流の顧客は OpenRouter の生の請求書を見ることはないかもしれませんが、それでも一貫した請求書を期待しています。

誰が影響を受けますか

最初に影響を受けるグループは、1 つのモデル プロバイダーの完全なエージェント プラットフォームにコミットせずにコードの実行を希望するエージェント開発者です。 OpenRouter のアプローチは、すでにモデル間でトラフィックをルーティングしていて、モデル選択の柔軟性を維持しながらシェル アクセスを追加したいと考えているチームにとって魅力的かもしれません。

2 番目のグループは、プラットフォーム チームとゲートウェイ チームです。今後は、ホストされているツールがファーストクラスのカタログ アイテムであるかどうか、ワークスペースごとに有効にできるかどうか、およびそのコストがダッシュボードにどのように表示されるかを決定する必要があります。モデル カタログの行は、ツールの可用性、実行時間の制限、および互換性に関するメモと組み合わせる必要がある場合があります。アクセス制御では、モデル呼び出しの許可とその呼び出しによるコンテナの開始の許可を区別する必要がある場合があります。

3 番目のグループは、AI 支出を管理する財務チームと運用チームです。トークンにとどまる使用状況分析では、増大するクラスのエージェント インフラストラクチャ コストを見逃してしまいます。便利な AI API 使用状況分析ダッシュボードには、スパイクの原因がモデルの選択、トークンの量、サンドボックスのランタイム、または追加のツール呼び出しを引き起こしたワークフロー設計の変更によるものなのかが表示されます。

まだ不確実な点

ベータ版では、いくつかの実用的な疑問が残されています。 OpenRouterによると、Files APIの使用はベータ版のシェルツールに含まれているが、長期的なファイルの価格設定、保持ルール、運用制限が本番環境のワークロードにとって依然として重要となる可能性があるという。開発者は、サポートされている API 互換性パス全体でシェル ツールを使用してどのモデルが確実に動作するかをテストする必要もあります。

セキュリティは、購入者にとってもう 1 つの未解決の実装問題です。 OpenRouter は、コマンドが分離されたホストされた Linux コンテナ内で実行されると説明していますが、企業は依然として、ホストされた実行環境を通じて機密ワークロードを送信する前に、ネットワーク アクセス、パッケージのインストール、ファイルの永続性、監査ログ、データ処理について質問することになります。

ただし、より大きな方向性は明らかです。ゲートウェイがエージェントの実行時間をより多く吸収しています。モデル ルーティングは、プロンプトの送信先を選択することを意味していました。現在では、ツール セマンティクス、ファイル状態、実行ポリシー、非トークン メータリングがますます含まれています。 OpenRouter のシェル ベータ版は、多くのエージェント ビルダーがバックグラウンド インフラストラクチャとして扱ってきた機能に明確な価格を設定するため、有益な指標となります。実行時間が請求書に表示されると、それは製品アーキテクチャの一部になります。