假設你在做一個幫客戶分析 CSV 的 agent，模型需要跑 Python 才能算出答案。那段程式碼要在哪裡執行？OpenRouter 在 2026 年 10 月 5 日發表的文章，把這個問題拆成兩條路：自己維護一個沙箱平台（E2B、Modal 或自架 Docker container），或者改用 server-side code execution tool——在 API 請求裡加一個工具項目，由 provider 在自家沙箱執行指令、把輸出回傳給模型，全程不離開同一次請求。
這個選擇影響的是你交出去的維運負擔。自己跑沙箱，代表你要選 base image、管安全邊界、設執行時限、補 image 漏洞。用 hosted tool，這些都歸 provider，代價是控制權。
四家 provider，差別在「能跑誰的模型」
根據 OpenRouter 整理的比較，OpenAI 的 hosted shell 只服務 OpenAI 模型，跑在 Responses API 上，環境是 Debian 12，預裝 Python 3.11、Node.js 22.16 等語言，預設沒有對外網路，要開的話得由組織管理員在 dashboard 設 allowlist。Anthropic 的 code execution tool 同樣只給 Claude 模型用，在 Messages API 上提供 Python 和 Bash，文件寫明 5 GiB 記憶體、5 GiB 儲存空間、單 CPU，且完全斷網、無法在執行時安裝套件。Google 的工具只支援 Gemini 模型，只能產生並執行 Python，單次執行上限 30 秒，同樣不能自行裝 library。
OpenRouter 自己的 openrouter:shell 和 openrouter:bash 則是唯一能搭配任何模型的路線，因為沙箱建在路由層，而不是綁在單一模型 provider 上。兩個工具目前都在 beta，且只在全域 openrouter.ai 端點可用，in-region 端點不支援。
同一個模型、同一份工具程式碼
hosted tool 真正省下的不只是維運，還有鎖定風險。我自己在整理四條 server-side code execution 工具線的挑選思路時就注意到，這類工具最大的實際好處是：換模型時不用動工具程式碼，因為工具就是請求裡的一個 JSON 項目。
OpenRouter 的 engine 參數把這件事變得更明確：設成 auto 時，openrouter:shell 會優先用 provider 原生的 hosted shell，沒有才落到自己的沙箱。也就是說，同一份程式碼在 Claude、Gemini 和不提供 hosted shell 的模型之間切換，執行路徑會自動跟著走。
迴圈是有上限的，帳單按秒算
這類工具的核心是一個執行迴圈：模型下指令、讀輸出、決定要不要再跑一次，直到給出答案。OpenRouter 用 max_tool_calls 把單次請求的 server-tool 步驟上限設為 30。計費方面，沙箱時間按每秒 $0.0001 計算，新啟動或休眠中的 container 有 30 秒最低收費。這代表短腳本很便宜，但讓模型反覆試錯的 agent 任務，帳單會隨著迴圈次數線性上升。
另一個實務細節：OpenRouter 沙箱回報的執行環境（2026 年 9 月 22 日測試時是 Ubuntu 22.04.5 加 Python 3.11.14）可能隨時改變。文件裡也提醒，版本應該從 container 裡讀出來，不要寫死在程式裡——這對任何 hosted runtime 都適用。
什麼時候還是該自己管沙箱
文章結尾把界線畫得清楚：hosted tool 適合短而有限的任務——跑一段腳本、轉換檔案、驗證一個結果。三種情況四家 hosted tool 都覆蓋不了：需要自訂 base image、需要 GPU、或者需要跑上數小時的長 session。這些還是得回到 E2B、Modal 或自架 container。
實際的建議是：先確認你的 agent 執行的是哪一類工作。如果只是每次請求幾條短指令，hosted tool 加一個 tools 項目就能上線；一旦需求碰到那三條界線，就不要勉強硬套。另外 openrouter:shell 還在 beta、API 可能變動，上線前把這點納入評估。