文件

goose

goose 將端點拆成兩部分：Host URL，以及由它自行附加的請求路徑。填入不帶路徑的來源網址並保持路徑不變，內建的 OpenAI provider 就能透過同一把金鑰呼叫 Claude 和 GPT。

Settings → Models → Configure providers → OpenAI：Host URL 填寫純 origin，因為 goose 會自行附加請求路徑（v1/chat/completions）。

設定提供者 → OpenAI，或環境

# goose Desktop → Settings → Models → Configure providers → OpenAI
API Key           sk-kn-...
Host URL          https://api.kunavo.com
Organization ID   (leave blank)
Project           (leave blank)

# …or as environment variables, which goose CLI reads too:
OPENAI_API_KEY=sk-kn-...
OPENAI_HOST=https://api.kunavo.com

# OPENAI_BASE_PATH is left unset on purpose. Its default is
# v1/chat/completions, which is the path Kunavo serves — that default is
# exactly why Host URL above carries no /v1.

Host URL 不得包含 /v1。 goose 將 OPENAI_BASE_PATH 說明為「附加至主機的請求路徑（預設為 v1/chat/completions）」，並告訴代理伺服器使用者將 OPENAI_HOST 設為「您代理伺服器的根網址（不含尾端路徑）」。這兩點足以釐清表單的填法：欄位中填入來源網址，預設路徑會隨 /v1 一併附加。輸入 https://api.kunavo.com/v1 會要求 /v1/v1/chat/completions — 同一頁也說明，若回傳 404，代表路徑有誤，而非金鑰有誤。

此設定是根據下方日期當天 goose 自家的文件整理而成。Kunavo 尚未使用其端點執行 goose — 沒有執行工作階段、串流回合或工具往返。設定說明頁不等於測試，本文也不應被視為測試結果；下方的 curl 是你可以在十秒內自行確認的部分，而用戶端的行為則由你和 goose 負責。

Kunavo 不提供嵌入、文字轉語音或語音轉文字模型，因此此端點只會回應聊天完成請求。goose 設定中任何用於轉錄音訊或建立向量索引的功能，都會繼續使用原有的 provider 金鑰 — 將 OpenAI provider 指向此處，不會轉移那些呼叫。

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

逐步操作

在 /app/keys 建立金鑰並複製——金鑰只會顯示一次。
在 goose Desktop 中：側邊欄 → Settings（設定） → Models（模型） → Configure providers（設定 provider） → OpenAI。在 CLI 中：goose configure → Configure Providers（設定 provider） → OpenAI。
填入 API Key（API 金鑰） 和 Host URL（主機 URL）。將 Organization ID（組織 ID） 和 Project（專案） 留白 — goose 文件說明這兩個欄位用於追蹤 OpenAI 自家帳戶的用量及管理資源，而 Kunavo 沒有對應資訊可填。按一下 Submit（送出）。
選擇模型。goose 的說明明確指出，goose configure「不支援輸入自訂模型名稱」— 因此如果清單中沒有您要使用的 ID，請在 goose Desktop 中輸入，或在 config.yaml 設定 GOOSE_MODEL；此設定會覆寫該程序使用的檔案內容。
啟動工作階段，並交付一項會存取檔案的任務。goose 幾乎所有操作都依賴工具呼叫 — 其供應商頁面也警告，不支援工具呼叫的模型「只能完成聊天」，而且使用這類模型時必須停用擴充功能 — 因此第一次執行時讀取並編輯某些內容，比只打招呼更能驗證設定。

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

除錯用戶端前先驗證

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

# 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 輸入／輸出	它在 goose 中的位置
`claude-sonnet-5`	$1.40 / $7.00	適合作為會編輯檔案的工作階段預設模型
`claude-opus-5`	$3.50 / $17.50	規劃一項出錯代價高昂的變更
`claude-haiku-4-5`	$0.70 / $3.50	低成本回合——分類、摘要，以及全天候執行的迴圈
`gpt-5-6-sol`	$2.00 / $12.00	來自另一個系列的第二意見，使用相同金鑰與相同 Host URL

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

另一種方式：Kunavo 的 provider 檔案

goose 也會從 custom_providers 目錄中的 JSON 檔案載入 provider 定義；以這種方式新增的 provider 會在選擇器中取得獨立項目、自有金鑰和儲存的模型清單，不必佔用名為 OpenAI 的欄位。Kunavo 在 kunavo.com/goose/kunavo.json 發布了一個檔案。它由即時目錄產生，因此模型清單是 Kunavo 今日提供的模型集合；檔案會列出金鑰變數名稱，但不會包含金鑰：

terminal

# macOS / Linux — goose reads every JSON file in this directory
mkdir -p ~/.config/goose/custom_providers
curl -fsSL https://kunavo.com/goose/kunavo.json \
  -o ~/.config/goose/custom_providers/kunavo.json

# The file names the variable; the key itself never goes in the file
export KUNAVO_API_KEY=sk-kn-...
goose session start --provider kunavo

Windows 上的目錄是 %APPDATA%\Block\goose\config\custom_providers\。在 goose Desktop 中，該 provider 會出現在 Configure providers（設定 provider） 下方，名稱為 Kunavo；你可以將金鑰存入鑰匙圈，而非環境變數。

端點。 此檔案將 base_url 設為 https://api.kunavo.com/v1。goose 文件並未說明該欄位要填 /v1 基礎網址，還是範例中的完整 /v1/chat/completions；原始碼則釐清了這點 — derive_base_path 會將兩者轉換成相同的 v1/chat/completions 路徑。
GPT ID 使用 Responses API。 goose 會將以 gpt-5 或 gpt-6 開頭的模型 ID 傳送至 /v1/responses，其餘則傳送至 /v1/chat/completions。Kunavo 兩者皆有提供，因此檔案中的 Claude 和 GPT ID 可使用同一把金鑰。
清單只列出支援工具呼叫的模型。 goose 幾乎每個回合都依賴工具，因此檔案未列入影像、影片和音訊模型，即使同一把金鑰也能呼叫這些模型。

本頁其他內容同樣適用的注意事項：這些資訊是根據 goose 的文件和原始碼整理而成，並非實際執行的結果。想自行撰寫 provider 嗎？Configure providers（設定 provider） → Add Custom Provider（新增自訂 provider） 會要求輸入相同資訊 — 類型 OpenAI Compatible、API URL https://api.kunavo.com/v1、你的 sk-kn- 金鑰，以及以逗號分隔的模型清單。

常見問題

如何將 goose 指向自訂的 OpenAI 相容 API？

使用內建的 OpenAI provider 並指定主機。在 goose Desktop 中，前往 Settings → Models → Configure providers → OpenAI，欄位包含 API Key、Host URL、Organization ID 和 Project；在 CLI 中，執行 `goose configure` → Configure Providers → OpenAI，並依提示輸入相同資訊。若使用環境變數，則是 OPENAI_API_KEY 和 OPENAI_HOST。若需要同時使用多個端點，goose 的 Add Custom Provider 流程會在 provider 清單中為每個端點建立獨立項目。

goose 的 Host URL 末尾需要加上 /v1 嗎？

不需要，加上去會讓請求出錯。goose 文件說明，OPENAI_BASE_PATH 是附加到主機的請求路徑，預設為 v1/chat/completions；並告訴代理伺服器使用者將 OPENAI_HOST 設為代理伺服器根網址，不帶尾端路徑。因此欄位應填不帶路徑的來源網址 — https://api.kunavo.com — 而 /v1 會由預設路徑補上。若主機網址以 /v1 結尾，就會要求 /v1/v1/chat/completions，回傳的是 404，而非驗證錯誤。

設定自訂主機後，為什麼 goose 回傳 404？

goose 自家的說明指出，404 通常表示基礎路徑不符合該端點：大多數代理伺服器提供 v1/chat/completions，有些則提供不含 v1 的 chat/completions，設定值必須與其相符。Kunavo 提供 v1/chat/completions，這是 goose 的預設值，因此 Kunavo 回傳 404，最常見的原因是主機欄位也輸入了 /v1，導致路徑重複。若 401 錯誤訊息指出沒有傳入 API 金鑰，則是另一種問題 — goose 文件說明，放在 config.yaml 的金鑰會被忽略。

goose 能否透過 OpenAI 相容端點使用 Claude 模型？

可以。provider 類型代表線路協定，而非廠商：goose 會向你設定的主機傳送 OpenAI 格式的聊天完成請求，並直接傳遞模型 ID，因此 Claude ID 會由該端點解析，而非在 goose 內部解析。請留意，goose 大量使用工具呼叫，其 provider 頁面表示，無法使用工具呼叫的模型只能進行聊天完成，且必須停用擴充功能 — 因此請選擇支援工具的 ID。

Kunavo 測試過這項設定嗎？

沒有。已查核的是 goose 自家的文件（2026 年 9 月 21 日和 29 日）— 欄位名稱、順序，以及主機加路徑的規則均引自該文件 — 至於 provider 檔案，則查核了 goose 的 provider 原始碼（9 月 29 日）。Kunavo 尚未使用其端點執行 goose 工作階段，也未對此用戶端的串流、工具往返或擴充功能行為作出任何聲明。唯一可以獨立確認的是端點和金鑰是否能正常運作；本頁的 curl 指令即可做到。

goose 有現成的 Kunavo provider 檔案嗎？

有：https://kunavo.com/goose/kunavo.json。將它儲存至 goose 的 custom_providers 目錄（macOS 和 Linux 為 ~/.config/goose/custom_providers/，Windows 為 %APPDATA%\Block\goose\config\custom_providers\），設定 KUNAVO_API_KEY，Kunavo 就會出現在 provider 清單中，且已填入模型 ID。此檔案由即時目錄產生，因此只列出 Kunavo 目前提供的模型，且不包含金鑰。