文件

Open Interpreter

Open Interpreter 透過 TOML 表格讀取供應商設定，方式與其 Codex 前身相同 — 但它保留了上游 Codex 已移除的 Chat Completions 傳輸方式。只要加入一個 [model_providers.kunavo] 區塊，代理程式就能使用此金鑰可連線的任何模型。

在 ~/.openinterpreter/config.toml 中設定一個 [model_providers.kunavo] 表格 — base_url、env_key、wire_api = "chat" — Rust 終端代理即可執行金鑰可存取的任何模型。

~/.openinterpreter/config.toml

model_provider = "kunavo"
model = "claude-sonnet-5"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"     # the NAME of the variable, not the key
wire_api = "chat"

在 chat 傳輸方式下，基礎 URL 保留 /v1 後綴。Open Interpreter 的文件透過範例而非明確規則來說明：providers 頁面的自訂供應商區塊使用 base_url = "https://api.example.com/v1"，設定頁面使用 "https://api.acme.example/v1"，而具名記載的代管閘道使用 "https://app.nz/v1"。若省略此後綴，會出現 404，而不是驗證錯誤。

Kunavo 尚未使用此用戶端連線至其端點 — 本頁其他設定中的用戶端也都尚未測試。已查核的是設定項目：下方的鍵名取自 Open Interpreter 自己的文件，並在本頁底部所列日期查閱；基礎 URL 和模型 ID 則取自 Kunavo。已發布的設定頁不等於實際測試。請以驗證請求確認設定是否正常運作。

有兩個不同程式都叫做「Open Interpreter」，此區塊適用於 Rust 版本。凍結在 0.4.3 的 Python 套件是透過 --api_base、--api_key 和 --model openai/<id>，或在 Python 中透過 interpreter.llm 進行設定。目前的終端機代理程式並沒有這些設定方式，只讀取上方的 TOML 表格。請先執行 interpreter --version 再編輯任何內容 — 舊教學中的 pip install open-interpreter 會造成另一個二進位檔以相同名稱搶占執行位置。

Claude 模型 ID 會讓 Open Interpreter 自動選用 claude-code harness——其文件說明的預設規則會在符合「Anthropic、Claude 模型 ID、Anthropic base URL，或任何 messages provider」時選用它。這在此處是受支援的組合：路由表列出 claude-code 與 wire_api = "chat" 相容。若要改用其他項目，請明確設定 harness；明確指定的值一律優先，無法辨識的值則會退回使用沒有內建 request builder 的 chat，而不會直接報錯。

還沒有金鑰？建立 Kunavo 帳戶，建立金鑰（以 sk-kn- 開頭），並從 $10 起新增額度——呼叫會從該餘額扣款，失敗的呼叫不會計費。之後儀表板會開啟 Open Interpreter 設定。

逐步操作

在 /app/keys 建立金鑰並複製——金鑰只會顯示一次。
將金鑰匯出為你準備填入 env_key 的名稱：export KUNAVO_API_KEY=sk-kn-...。該欄位存放的是變數名稱，而不是變數值——文件將 env_key 列為「從環境變數讀取 bearer token」的來源。
將上方區塊放在 ~/.openinterpreter/config.toml；若只想套用於單一儲存庫，也可以放在受信任專案中的 .openinterpreter/config.toml。專案設定的優先級高於使用者設定；執行時的 -c key=value 旗標則高於兩者。
啟動 interpreter 並執行 /model。模型選擇器會先詢問目前 provider 的 models 路由，Kunavo 會回覆 GET /v1/models，因此清單會自動載入。
如果使用了錯誤的值，請執行 /debug-config——它會列印生效中的設定，以及每個值的來源。比起重新閱讀 TOML，這更能快速找出過期的設定檔或專案檔案。

已於 2026年9月21日根據 Open Interpreter 的 Model Providers 頁面進行確認。第三方設定會變動；如果這裡的欄位名稱不再與你看到的內容相符，應以該頁面為準，而不是本頁。

這是簡短版本。完整指南——模型選擇、實際工作階段費用，以及失敗情況——請參閱 Open Interpreter 的版本差異、定價與替代方案。

除錯用戶端前先驗證

一個請求就能判斷失敗原因是端點、金鑰還是設定檔。如果這裡回傳 JSON，則相同的基礎 URL 與金鑰在 Open Interpreter 中也能運作。

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

欄位中應填入哪個模型 ID

每個文字模型都能以模型 ID 存取——即時清單位於 GET /v1/models，帶有價格的目錄位於模型頁面。費率是每 1M 權杖的美元價格，輸入／輸出。

模型 ID	Kunavo 輸入／輸出	它在 Open Interpreter 中的位置
`claude-sonnet-5`	$1.40 / $7.00	適合編輯與執行循環的預設工作模型
`claude-opus-5`	$3.50 / $17.50	規劃大型重構；錯誤的計畫代價很高
`claude-haiku-4-5`	$0.70 / $3.50	以 shell 操作為主的工作階段；回合數是主要考量
`gpt-5-6-sol`	$2.00 / $12.00	來自不同家族的第二意見，共用同一把金鑰

計費方式是從預付餘額按權杖計費，沒有月費——請參閱 billing。在重複的上下文中——這是編輯器或聊天用戶端傳送內容的大部分——提示快取對帳單的影響比模型選擇更大。

常見問題

如何讓 Open Interpreter 使用自訂 API provider？

在 ~/.openinterpreter/config.toml 中新增 [model_providers.<id>] 區塊，填入 name、base_url、env_key 和 wire_api，接著使用頂層的 model_provider key 選取它，並以 model 指定模型。若要使用 OpenAI 相容端點，請設定 wire_api = "chat"，並讓 base URL 以 /v1 結尾——這是 Open Interpreter 自家 provider 頁面所示的自訂 provider 格式，也適用於文件中以名稱介紹的託管 gateway。env_key 存放的是環境變數名稱，因此請匯出金鑰，而不要將金鑰直接貼進檔案。

Open Interpreter 的 base_url 需要以 /v1 結尾嗎？

若使用 chat wire，答案是需要。文件沒有用文字說明路徑組成規則，但列出的每個自訂 provider 範例都帶有這個尾碼：provider 頁面上的 https://api.example.com/v1、設定頁面上的 https://api.acme.example/v1，以及文件所列 gateway 的 https://app.nz/v1。messages wire 的行為不同——用戶端內建的 Anthropic 風格 provider 使用不含 /v1 的 API 根路徑——因此 /v1 的答案僅適用於 wire_api = "chat" 和 wire_api = "responses"。

舊的 --api_base 和 --model openai/... 旗標還能用嗎？

不能。這些旗標屬於凍結在 0.4.3 版的 Python 套件；該版本透過 LiteLLM 路由，因此需要 openai/ 前綴。目前的終端代理程式是 Codex 的 Rust 分支，沒有這些旗標，也不採用前綴慣例：它會從 ~/.openinterpreter/config.toml 或專案層級的 .openinterpreter/config.toml 讀取 TOML provider 區塊，並透過 model_provider 和 model 選取。設定檔需從頭撰寫，而 docs.openinterpreter.com 會重新導向至 Rust 文件，因此舊教學的連結雖然仍可開啟，內容描述的卻是你並未安裝的程式。

為什麼 /model 選擇器沒有顯示自訂 provider 的 context window？

因為這項中繼資料來自用戶端隨附的目錄；該目錄由 models.dev 加上少數即時 provider 端點產生，而且只有在 provider 透過 Anthropic 身分、base URL、provider 名稱或驗證環境變數與目錄中的某個項目相符時，才會載入這項中繼資料。Kunavo 不在這份產生的目錄中——已於 2026 年 9 月 21 日比對儲存庫中的檔案確認——因此手動撰寫的 provider 會從端點本身的 models 路由取得模型清單，除此之外沒有其他資料。模型仍可執行；只是選擇器能在模型旁顯示的資訊較少。

沒有 Anthropic 帳戶也能透過 Open Interpreter 使用 Claude 模型嗎？

可以，因為 wire_api 指定的是傳輸格式，而非供應商。設定 wire_api = "chat" 時，模型 ID 會原樣傳送至你設定的 base_url，並由該端點解析，因此你持有的憑證是該端點的憑證。Open Interpreter 仍會根據 Claude 模型 ID 自動選取 claude-code harness，而該 harness 列為與 chat wire 相容，因此這是文件所述的組合，不是權宜做法。