從API回覆到真正完成程式任務，分開驗證連線、設定與工具行為。

替Claude Code換後端時，最容易忽略的不是API Key，而是「哪一層已經驗證」。終端機收到OK，只能說這次API請求成功；不能直接延伸成讀檔、修改程式與執行測試都正常。

本文以Crazyrouter作為OpenRouter以外的一個候選，記錄2026年10月12日的Messages、工具往返與thinking參數測試。從這幾個小實驗，可以看出設定問題、協定行為與回答品質各自需要什麼證據。測試透過HTTP執行，沒有把文件中的Claude Code設定說明當作用戶端已完成專案的證明。

先畫清楚兩個位址

Claude Code使用Anthropic Messages協定。Crazyrouter的接入指南要求基礎位址填根網址，由用戶端補上API路徑。

兩行不一樣是正常的。把完整endpoint填進用戶端的Base URL，可能造成路徑被重複附加。另一方面，其他採OpenAI相容協定的工具可能要求/v1；不能把它的設定直接搬進Claude Code。

官方文件畫面，2026年10月12日擷取。綠色提示說明用戶端會自行補上路徑。

用最小請求把網路與模型權限分離出來

先準備獨立的測試token，在本機環境變數設定CRAZYROUTER_API_KEY，確認它能存取指定模型。以下為Bash語法；Windows使用者可在Git Bash或WSL執行，不要直接把反斜線續行貼進PowerShell。

curl --silent --show-error --fail-with-body \
  https://api.crazyrouter.com/v1/messages \
  -H "x-api-key: $CRAZYROUTER_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-5-5","max_tokens":512,"messages":[{"role":"user","content":"Reply with exactly: OK"}]}'

本次取得HTTP 200，文字區塊為OK，結束原因為end_turn。紀錄的輸入與輸出token分別為42和4。這個樣本沒有啟用thinking，也沒有產生快取讀取，因此不能拿它比較推理能力或快取成本。

成功後保存脫敏的請求參數與回應，至少包含日期、model、endpoint及HTTP狀態。下次失敗時，就有一份可比較的基準，而不是靠記憶猜「上次好像可以」。

加入工具後，回應成功還要再拆一層

連線基準通過後，測試加入了add_numbers工具。它只接受整數a、b，用來計算3加4；模型維持claude-haiku-5-5，輸出上限512，第一輪明確指定tool_choice為這個工具。這樣可以先觀察協定往返，不把「是否自行選對工具」混進同一次驗收。

第一輪收到HTTP 200，stop_reason為tool_use，內容中的呼叫名稱正確，參數也確實是3與4。此時伺服器給的是工具呼叫要求，並不是本機已完成執行。測試程式在本地計算7，再把結果放進tool_result，帶回原本的tool_use_id。

第二輪訊息歷史保留第一輪assistant的完整content，接著加入user角色的工具結果。工具定義仍在，但移除強制呼叫條件，讓模型可以完成回答。第二次也是HTTP 200、end_turn，數值正確。

有趣的是，它在答案裡說工具清單沒有add_numbers，自己用的是Agent。這與結構化紀錄不一致。這個案例的結論因此不是單純「工具支援」：工具往返成功，但對執行過程的文字描述有錯。

換成程式任務，就知道為什麼不能只看「測試已通過」。應確認用戶端真的執行命令、拿到什麼退出碼、檔案差異是否存在。結構化事件與自然語言敘述要分開保存，兩者矛盾時才有線索可追查。這次沒有足夠資訊歸因到模型、路由或上游轉換，不從工具別名猜測內部架構。

thinking預算不是一個保證開關

下一組實驗固定問題9.11 and 9.9, which is larger?，將max_tokens設為2048，thinking設定為enabled、預算1024。以下數字是回應usage報告值，不是外部量測的內部運算量。

Haiku另以128預算試過，再分別重複128與1024兩種條件，仍然只有text。這表示本次沒有重現「提高預算就會出現thinking」的效果，不表示這個型號永遠沒有thinking能力。前面的工具實驗，同一型號就回傳了thinking相關欄位，而且區塊文字為空。

對解析程式來說，至少要保留「區塊是否存在」「區塊是否有文字」「計量值是多少」三個不同狀態。若只寫if (thinking)，很容易把空字串、缺少欄位和零計量混成一件事。小數比較題只適合這裡的結構觀察，不能拿來排名模型的程式能力。

再處理Claude Code設定

依Crazyrouter的文件，Claude Code以根網址及Anthropic認證變數接入。設定時要確認變數存在於啟動claude的同一個shell，且沒有舊的認證設定干擾。

有些人把新Key寫進一個設定檔，卻仍使用原本已開啟的終端機；也有人切換服務後保留了另一家的模型ID。這些情況都可能表現成「模型不存在」或「認證失敗」，但不能立刻歸咎於服務中斷。

實際驗收建議分成三個小任務：請它只回覆OK；再請它唯讀整理專案目錄；最後在可回復的分支中完成一項小修改並執行既有測試。每一步都查看實際輸出及服務端用量紀錄，不只看聊天文字宣稱「已完成」。

回應欄位可以觀察，不能過度解讀

最小請求的回應包含cache_creation與output_tokens_details，也帶有diagnostics.cache_miss_reason。這些資訊有助於後續排錯，但本次只能證明該模型在這個請求下回傳了它們。

官方文件畫面，2026年10月12日擷取；圖中內容為協定說明，實測結果見本文文字。

不要把這些欄位的出現寫成「全部原生功能保證透傳」。程式也應容許選用欄位缺席，避免換一個模型就因直接存取巢狀屬性而出錯。

OpenRouter同樣提供Claude Code接入方式，不是只能接OpenAI格式。它的文件建議將Anthropic第一方provider設為優先，這是相容性條件，也應列入測試紀錄。

讀懂快取計量，才知道長對話省在哪裡

OpenRouter快取文件把讀取與寫入分開：cached_tokens是讀取，cache_write_tokens是寫入。Anthropic的5分鐘寫入費率為一般輸入的1.25倍，1小時為2倍，讀取則為0.1倍。寫入本身有成本，不能只看到快取欄位就認為本輪比較便宜。

以相同可快取前綴計算，假設一般輸入一次成本為C，而且後續都在有效期限內命中。使用三次時，不快取是3C；5分鐘方案為1.25C+0.1C+0.1C=1.45C；1小時方案為2.2C。若只使用兩次，1小時方案是2.1C，甚至高於不快取的2C。

這是依文件倍率推算的前綴費用，沒有計入每次新增的問題、輸出和工具重試，也不是Crazyrouter的實測帳單。它帶來的實際判斷是：選TTL應配合工作間隔與重用次數。一次性讀入的大檔案，與連續問十輪同一份程式，不能使用同一個節省比例。

另外，OpenRouter的sticky routing會嘗試維持同一provider來利用快取，但手動設定的provider.order優先，provider不可用時仍可能回退。排查長對話成本突然增加，除了看前綴有沒有變，也要看請求路由是否改變。快取期限和路由黏著是不同機制，不能只設好其中一個就保證命中。

遇到錯誤，先看是哪一種限制

Crazyrouter的錯誤文件區分認證、權限、額度與頻率問題。尤其403不能只看狀態碼就下結論，要一起看error.code和訊息；重新送出相同的錯誤參數不會解決它。

OpenRouter則將信用額度、組織預算及請求限流分開說明；Limits文件也提醒，多建立Key不會提高總限額。把token依環境拆開，主要是管理與歸因手段，不能自行當成擴容方式。

OpenRouter還記載適用於部分預付費帳戶的在途花費預算。新請求會占用預估費用，計算涉及輸入與max_tokens；剛結束但尚未結算的請求也可能影響下一次是否獲准。因此402不一定表示實際餘額歸零。JSON中的in_flight_budget_exhausted與一般429需要不同處理，前者應查看在途工作及預算，後者才是頻率限制的方向。

OpenRouter路由文件也值得放進設定紀錄：order表示優先順序，only才是允許清單，allow_fallbacks預設允許備援路由。把某個provider排第一，不等於請求只會交給它。如果公司要求程式碼只能送到核准的供應商，優先順序就不是足夠的限制。

另外，require_parameters預設為false，設為true才會依請求參數支援情況篩選provider。這是API層的選項，不能自行假設Claude Code會傳送，也不能把其他用戶端的JSON原樣塞進環境變數。實際採用前應確認目前的用戶端路徑或帳戶設定如何落實這項要求。

回到接入選擇，本次有一條可用的Messages基準、一次完成的工具往返，也有需要正視的描述錯誤與thinking差異。這比單一「支援」標籤更能幫助開發者：需要可見thinking的功能先驗收那一組參數；需要工具完成工作的功能檢查真實執行紀錄；關心成本則分開統計快取寫入、讀取與輸出。

本文使用AI協助撰稿。實測日期為2026年10月12日，涵蓋上述HTTP請求；未進行OpenRouter付費實測、負載測試或完整用戶端效能比較。