要把一個 agent 從「會講話」推到「會做事」，遲早要讓模型跑程式碼。過去的標準做法是自己開容器：provision、隔離、清理，一套下來工程量不小。根據 OpenRouter 在 2026 年 10 月 5 日發布的 Insights 文章（以下細節來自 OpenRouter 的 Insights 頁面 的 supplied RSS summary），供應商現在可以直接替你跑。
什麼是 server-side code execution
所謂 server-side code execution tool，是供應商在自己的 sandbox 裡執行模型下達的指令，過程發生在你的 API request 期間。你不需要自己佈建或維護容器，也不用操心安全隔離。這對還在原型階段的團隊特別有感：省掉的不只是基礎設施，而是整條「跑一段程式碼要開機器」的決策鏈。
四條工具線的分工
OpenRouter 把現有的選項分成四條：
- OpenAI、Anthropic、Google 各自為自家模型提供 code execution，也就是模型和沙箱綁在同一家的 stack 裡。
- openrouter:shell 則跨出了這個限制——根據該 summary 的說法，它能為 Responses 和 Messages API 上的任何模型執行指令。
- openrouter:bash 在 Messages API 上提供同樣能力。
換句話說，前三條是「模型跟沙箱同一家」的組合，OpenRouter 的兩個工具則把沙箱這一層抽成了跨模型的公共服務。對 builder 來說，這改變的是汰換模型時的搬家成本：沙箱介面不變，底下的模型可以換。
該比的是四個維度
這篇文章真正有用的地方在於它沒有停在功能清單，而是提出四個比較軸：runtime、isolation、persistence、cost。
- Runtime：指令跑多久、支援哪些語言與套件。
- Isolation：執行環境怎麼隔離，出了事影響範圍多大。
- Persistence：這次執行產生的檔案和狀態，下一次 request 還拿不拿得到。
- Cost：沙箱時間怎麼計費，和 token 費用怎麼疊加。
其中 persistence 大概是最容易被忽略的一項。如果你的 agent 是多步驟工作流——先下載資料、再處理、再畫圖——沙箱能不能保留中間狀態，會直接決定你要不要自己上平台。文章也根據 supplied RSS summary 的說法，列出了「仍然需要自建 sandbox 平台」的工作類型；summary 本身沒有具體列出是哪些場景，這點得回原文確認。
對既有路由策略的影響
如果你已經在用 OpenRouter 做模型選擇——例如先前介紹過的 cheap-first 路由做法——openrouter:shell 等於把「路由」和「執行」放在同一層。以前便宜的模型配不上便宜的沙箱，現在同一個 request 裡兩件事一起結帳，成本模型的變數少了一個。
不過要留意取捨：把執行交給供應商，代表 runtime 行為、隔離等級、資料滯留位置都由對方決定。對有合規要求的團隊，isolation 的細節值得先讀完原文的比較表再下判斷。
一個務實的下一步
如果你的 agent 目前只是「模型加 prompt」，最快驗證價值的方法是挑一個真正需要跑程式碼的環節，用 provider-side 的工具先試，把自建沙箱留到 persistence 或隔離需求真的出現的那天。多一個可換的抽象層，總比一開始就綁死單一供應商來得穩。