PicoClaw model not found 404：模型 ID 與 Anthropic 協定

在 PicoClaw 中，「找不到模型」和 404 是四種不同的失敗，而且只有其中一種發生在您的機器之外。 其中三種是本機問題——無法解析的別名、PicoClaw 自己的網頁後端回應 404，以及未知的通訊協定字串；第四種是上游 404，其本文會告訴您錯誤出在路由還是模型 ID。先閱讀錯誤文字，才能避免為了修正拼字錯誤而切換通訊協定。

本頁假設您已經有可運作的 model_list 項目和金鑰；設定本身以及 PicoClaw 的費用，請參閱 PicoClaw 定價與 API 設定。以下所有內容都是在已發布的 v0.3.1 標籤上讀取；releases API 於 2026 年 9 月 21 日確認該版本為最新版本，發布日期為 2026 年 7 月 3 日。儲存庫最後一次推送為 2026 年 9 月 17 日，因此 main 領先於該標籤——如有影響，文中會加以說明。2026 年 10 月 1 日，v0.3.1 仍是最新版本；接著使用其發布二進位檔對本機記錄端點執行測試，並使用刻意無效的金鑰對 Kunavo 執行測試；測試結果記錄如下。

四種失敗，一句話

因此，首先要確認請求是否離開您的機器，而單靠字串就能判定。別名不相符是已有記錄的案例，而非假設：PicoClaw 議題 #958 回報 error creating provider: model "llama3.2" not found in model_list，同時 picoclaw status 顯示 Ollama 端點可連線，且存在名為 llama3.2:latest 的模型。該議題於 2026 年 3 月 25 日由儲存庫的過期議題機器人關閉。請注意，在此儲存庫中，標示為 completed 的已關閉議題不代表已修正——同一個機器人以相同文字關閉了 #1624。

包裝文字會指出實際執行的通訊協定

因為帶有 api key 的 anthropic 和 anthropic-messages 會建立不同的供應商，它們的 404 包裝文字也不同——因此錯誤字串本身就是免費的診斷資訊。

為什麼 PicoClaw 自己的 404 建議可能把您引向錯誤方向

PicoClaw 的 供應商指南 告訴您，當「現有的 anthropic 通訊協定傳回 404 錯誤（表示端點不支援 OpenAI 相容格式）」時，切換至 anthropic-messages，並補充一則解決命名問題的說明：「anthropic 通訊協定使用 OpenAI 相容格式（/v1/chat/completions），而 anthropic-messages 使用 Anthropic 的原生格式（/v1/messages）。」兩段引文均於 2026 年 9 月 21 日在 v0.3.1 上重新讀取。

該建議對路由 404 是正確的，對模型 404 則是錯誤的。同一檔案中，該建議位於一個表格下方 294 行，而表格的 Protocol 欄在 anthropic 列讀作 Anthropic，結論正好相反。程式碼以不明顯的方式解決這項矛盾：anthropic 會依據 auth_method 成為兩種通訊協定。 使用 oauth 或 token 時，它會建立原生 Anthropic SDK 供應商，表格的說法正確；使用 api key 時，它會退回與 openai 及其整個系列相同的 OpenAI 相容供應商，而說明的說法正確。

這直接帶來兩個結果。在 openai 系列中，若填入 https://api.kunavo.com 而非 https://api.kunavo.com/v1，就會組合出 https://api.kunavo.com/chat/completions——這是由你自己的設定造成的路由 404，也是最常見的一種。在兩種 Anthropic 協定中，都不可能發生這個錯誤，因為無論使用哪一種，都會強制加上 /v1；但同樣因為這項強制行為，如果某個閘道的路徑必須不以 /v1 結尾，就完全無法透過這兩種協定設定，而必須改用 openai 協定。PicoClaw 自己的文件也採用這個替代方式，來處理某家供應商的基底網址以不同版本路徑區段結尾的情況。

有一項說法仍應視為未定論。PicoClaw 議題 #269 中唯一的留言聲稱，在 Anthropic 對 /v1/chat/completions 發送 POST 請求會得到 404，因為正確端點是 /v1/messages。Anthropic 自己的文件與此矛盾：它發布了 OpenAI SDK 相容層，使用的 base_url 為 https://api.anthropic.com/v1/，並將 authorization 標頭標為「Fully supported」（已於 2026 年 9 月 21 日查核）；同一頁面也提醒，該相容層「對大多數使用情境而言，不被視為長期或可用於生產環境的解決方案」。議題 #269 於 2026 年 3 月 13 日關閉，沒有關閉留言——issues API 顯示其中有一則留言，即上述分析，來自一個沒有儲存庫關聯的帳戶——因此實際解決方式未知。比起上述兩種說法，請更相信您自己收到的 404 回應本文。

當 404 是由模型 ID 造成時

PicoClaw 議題 #1624——於 2026 年 3 月 16 日開啟、2026 年 3 月 31 日關閉——記錄了帶點號 Claude ID 設定為 "model": "anthropic/claude-sonnet-4.6" 時的實際回應本文：Status: 404，並包含 {"error":{"code":"not_found_error","message":"model: claude-sonnet-4.6 was not found. Did you mean claude-sonnet-4-6?"…。其標題及唯一留言於 2026 年 9 月 21 日從 issues API 重新讀取：留言來自過期機器人，因此議題雖已關閉，卻沒有修正證據。

「您是不是要」提示就是判斷依據。它只會由已解析請求的端點傳回，因此路由正常，切換通訊協定不會有幫助。PicoClaw 不替您修正拼字的原因很明確且可查核：strings.ReplaceAll(model, ".", "-") 在儲存庫中只出現一次，位於 pkg/providers/anthropic/provider.go 第 219 行——也就是 OAuth 和權杖路徑使用的 SDK 供應商。anthropic_messages/provider.go 和 openai_compat/provider.go 都不包含它。這兩項陳述均於 2026 年 9 月 21 日在 v0.3.1 重新查核；本頁撰寫前進行的研究也在同日從 main 重新取得相同檔案，結果一致。2026 年 10 月 1 日執行 v0.3.1 二進位檔，在兩條 API 金鑰路徑上確認了這一點：帶點號的 ID 完全照原樣抵達端點，並回傳端點自己的 404（請參閱執行 v0.3.1 的結果）。唯一具有改寫功能的 OAuth 和權杖路徑未執行。

PicoClaw 自己的檔案對拼寫也不一致：provider_metadata.go 為兩個 Anthropic 項目列出帶連字號的 ID，供應商指南中的 anthropic 範例使用帶點號的 ID，而 anthropic-messages 透過 GetDefaultModel 回傳帶點號的預設值——這正是 #1624 顯示遭拒的拼寫。Anthropic 的 模型總覽列出的每個 Claude API ID 都使用連字號，而且該頁面將 Claude Sonnet 4.6 和 Claude Opus 4.6 列在「Legacy models (still available)」下，因此目前在 Anthropic 上，4.6 ID 收到 404 的原因不是已退役。這排除了一個原因，但不是所有原因：不支援該模型的閘道仍可能拒絕帶連字號的 ID。請從您呼叫的端點複製 ID，而不是從 README 複製。

明確寫入兩個項目，並保留帶連字號的 ID。金鑰不屬於此檔案——PicoClaw 會從 ~/.picoclaw/.security.yml 讀取金鑰，詳情請參閱 設定指南。

{
  "agents": {
    "defaults": {
      "model_name": "kunavo-sonnet"
    }
  },
  "model_list": [
    {
      "model_name": "kunavo-sonnet",
      "provider": "openai",
      "model": "claude-sonnet-4-6",
      "api_base": "https://api.kunavo.com/v1"
    },
    {
      "model_name": "kunavo-sonnet-native",
      "provider": "anthropic-messages",
      "model": "claude-sonnet-4-6",
      "api_base": "https://api.kunavo.com"
    }
  ]
}

第一個項目自行提供 /v1，因為 OpenAI 相容系列會將 /chat/completions 逐字串接到 api_base 上。第二個項目刻意省略它，以顯示在 anthropic-messages 中兩種拼寫會正規化為相同的基底。Kunavo 發布的基底 URL 是 https://api.kunavo.com/v1，用於 聊天完成，而 https://api.kunavo.com/v1/messages 用於 Messages 路由。兩組 URL 算術結果相符，是對兩組文件進行算術運算的結果；2026 年 10 月 1 日，兩個項目都從 v0.3.1 對 Kunavo 執行測試，並使用刻意無效的金鑰：openai 項目到達 /v1/chat/completions，anthropic-messages 項目到達 /v1/messages，兩者都收到 Kunavo 的 401 回應。這證明 URL 正確，並不代表請求已完成：本頁沒有任何地方聲稱測試過整合。關於基底 URL 問題的一般形式，請參閱Anthropic 基底 URL 文件。

閘道也可能刻意回應 404，而這不是 PicoClaw 的錯誤。Kunavo 會對暫時暫停的模型回傳 404，本文會命名該模型以及應改用的替代模型，並從 /v1/models 中省略暫停的模型；請比對該訊息的結構，而不是特定名稱，因為哪些模型暫停會變動。Kunavo 也不提供 embedding、文字轉語音或語音轉文字模型，因此命名其中任何一種模型的 model_list 項目無論選擇哪種通訊協定都會收到 404——請將這些項目指向其他供應商，並在 Kunavo 金鑰上只保留聊天項目。

v0.3.1 執行結果

2026 年 10 月 1 日，v0.3.1 發行二進位檔已使用發行版本自身的 checksums 檔案完成校驗，並在一次性容器中逐次執行，每次只放入一個 model_list 項目，並使用 picoclaw agent -m。端點是當時行為如 Kunavo 路由的本機記錄伺服器——/v1/* 是 API，其他任何路徑都會回傳 HTML 404 頁面（Kunavo 現在會對這些路徑以 JSON 404 回應並指出修正方式；請參閱 Kunavo 列）——它知道 claude-sonnet-5 和 claude-sonnet-4-6，但不知道帶點的 ID；最後三列使用真正的 api.kunavo.com 搭配刻意無效的金鑰，因此其中沒有任何內容產生計費。

這次執行確定了兩件僅靠閱讀原始碼只能預測的事。錯誤包裝器確實會指出實際執行的提供者，因此可以放心據此判讀通訊協定；而帶點的 ID 在兩條 API 金鑰路徑上都會原樣傳送，因此引用帶點 ID 的「找不到模型」錯誤，修正方式是重新拼寫 ID，而不是切換通訊協定。本次未涵蓋：OAuth 和 token 路徑、啟動器的網頁 UI、串流，以及任何透過 Kunavo 完成的請求——Kunavo 列刻意使用了無效金鑰。

最精簡的檢查順序

1. 有任何內容離開這台機器嗎？ 若終端機錯誤包含 not found in model_list 且沒有 HTTP 狀態碼，這是本機錯誤。讓 agents.defaults.model_name 等於某個 model_name 項目，然後停在這裡。
2. 它來自 localhost 嗎？ 在 PicoClaw 網頁 UI 中選取預設模型時，瀏覽器顯示的 404 是相同的不相符問題，由 PicoClaw 自己的後端提供。沒有涉及模型 API。
3. 哪個提供者執行了？ 將包裝器文字與上表比對。如果包裝器與你認為已設定的通訊協定不符，provider 欄位或模型前綴就不是你以為的內容。
4. 是路由 404 還是模型 404？ 指出你模型的主體——尤其是附有 did you mean 提示——就是模型 404：修正 ID。HTML 頁面、空主體或一般性的找不到錯誤則是路由 404：在處理其他事項前，先根據表格重新推導組合後的 URL。
5. 詢問端點提供哪些服務。 PicoClaw 無法對任一 Anthropic 通訊協定執行此操作，因為兩個目錄項目都未設定 fetch 旗標。使用 curl 對閘道自身的 /v1/models 執行，或暫時讓同一閘道指向 openai 通訊協定。Model not found across providers 涵蓋該方法，而 Anthropic 404 model not found 涵蓋 ID 本身有問題的情況。
6. 現在才變更通訊協定，而且只有在第 4 步指出是路由 404 時才變更。如果阻礙因素是驗證標頭而不是線上格式，auth token versus api key 會說明其中差異。
7. 使用一輪工具重新驗證，而不是單純的聊天回合。 能回答裸訊息的設定，仍可能在第一次工具呼叫時失敗，因此用來確認修正有效的受限任務應包含一次工具呼叫。

通訊協定選擇的代價

最大的成本影響是提示快取，而且這是結構性因素，不是設定。在 PicoClaw v0.3.1 中，唯一會產生快取斷點的程式碼位於 pkg/providers/anthropic/provider.go，而且只有在 OAuth 和 token 路徑上才會到達。使用 API 金鑰——一般的自備金鑰情況——兩種 Anthropic 通訊協定都不會傳送 cache_control。對 Anthropic 自身的相容層而言，這會更加不利，因為其文件明確指出「不支援提示快取，但 Anthropic SDK 支援」。對會為 OpenAI 格式呼叫者插入斷點的閘道而言，節省的成本會改由閘道端實現；Kunavo 的 caching documentation 表示它會這樣做，且精確限定適用範圍：透過 /v1/chat/completions 或 /v1/responses 到達的 Claude 模型。同一頁也表示，在原生 Messages 路由上，cache_control 會未翻譯地傳遞——因此 anthropic-messages 項目兩端都不會取得斷點，而下方第二欄僅描述 openai 通訊協定項目。未檢查其他閘道是否會插入斷點，以上任何內容也不是在 PicoClaw 內部觀察到的。

這項價值是用於說明的 token 算術，不是測得的任務成本，也不是帳單上限。假設一次代理程式回合包含 10 輪工具操作，每一輪都重新傳送相同的 20,000 個 token 前綴（系統提示、工具結構描述、目前為止的轉錄內容），加入 1,000 個新的輸入 token，並回傳 600 個輸出 token。這些比例僅是說明用假設。第一欄以完整費率計算每一輪的輸入；第二欄則從第二輪起，以快取讀取費率計算重複的前綴。費率是即時的 Kunavo 目錄每百萬 token 價格。

在這些假設下，Claude Sonnet 4.6 會從 $0.504 變成 $0.164，完成相同的工作。請將第二欄視為樂觀估計：快取寫入會以其自身費率計費，且兩個方向都未加以建模；如果前綴每輪都變更，則完全不會成為快取命中。在將任何數字視為預算前，先按照每天的回合數進行換算。

同時將兩筆帳單分開看。PicoClaw 本身免費——該儲存庫採用 MIT 授權，而且沒有任何通訊協定（包括兩種 Anthropic 通訊協定）需要付費才能使用。持續產生的成本是依你提供者費率計算的模型 token。Kunavo 的目錄金額是計費下限而非上限：上游回報費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中的較高者。最低加值金額是 $10 的預付額度，這是資金下限，不是任務費或訂閱費——請參閱 billing details。

直接供應商、閘道、訂閱或本機

是在選擇執行環境，而不是路由嗎？PicoClaw vs OpenClaw 會比較兩者的部署形式。如果你選擇閘道並想為金鑰儲值，請建立 Kunavo 帳戶，然後傳送一個包含工具呼叫的受限任務，並查看你的帳戶實際記錄的費用。

常見問題

已於 2026 年 9 月 21 日檢查。本次任務在 v0.3.1 標籤重新驗證：提供者指南的通訊協定備註與 Anthropic 供應商列、factory_provider.go 中的 anthropic 分支與預設分支、NormalizeBaseURL、anthropic-messages 的 URL、標頭與 404 字串、openai_compat 的 URL 串接與 Bearer 標頭、三個 HTTP 請求發出前的「not found in model_list」字串、網頁後端的 404、唯一一次的點號轉連字號替換、提供者選項表的 SupportsFetch 欄，以及 docs/operations/troubleshooting.md 中的 OpenRouter 範例；此外還檢查了 releases API（v0.3.1，於 2026 年 7 月 3 日發布），以及 issue #1624、#958 和 #269 的標題、狀態、日期與留言。Anthropic 的 OpenAI-SDK 相容性頁面也在同日閱讀。2026 年 10 月 1 日執行：在容器中對本機記錄端點執行 v0.3.1 發行二進位檔，並以無效金鑰對 Kunavo 執行——涵蓋上表的每一列。未驗證：main 中研究進行差異比對的檔案以外的任何內容、issue #269 是因何關閉、OAuth 和 token 路徑，以及任何透過 Kunavo 完成的請求。Kunavo token 費率來自即時目錄，而此處每個美元數字都是說明用的 token 算術。