mini-SWE-agent 與 Claude Code：工作流程、模型與總成本

mini-SWE-agent 和 Claude Code 不是同一產品的兩個版本：mini 是採用 MIT 授權的免費 Python 代理程式，只有一個工具——bash——並透過 LiteLLM 連接任何模型；Claude Code 則是 Anthropic 的專有代理程式，只支援 Anthropic 形式的通訊協定。 這項單一差異決定了大多數遷移，因為它是通訊協定邊界，而非偏好問題。如果你想要一個小到足以閱讀的工具框架，以及可自由選擇供應商，請選擇 mini；如果你需要編輯器、桌面和 CI 介面、權限模式與訂閱路徑，並且會持續使用 Claude 模型，請選擇 Claude Code。

mini-SWE-agent 由 SWE-agent GitHub 組織維護，並自稱「由 Princeton 與 Stanford 團隊打造，這支團隊也是 SWE-bench、SWE-agent 等專案背後的團隊」。在進入其他內容前，先更正一點，因為關於它最常被引用的資訊已經過時。其 v2 遷移指南指出：「v2.0 預設使用原生工具呼叫（而非基於正規表示式的文字解析）」；但專案自己的 FAQ仍寫著「它甚至不使用 LMs 的工具呼叫介面」，並且「動作會從三個反引號區塊中解析」。兩個頁面都是在 2026 年 9 月 19 日閱讀的。遷移指南和隨附設定應優先採信：mini.yaml 告訴模型：「每個回應都必須至少使用一次 'bash' 工具來執行命令。」任何建立在不使用工具呼叫的說法，或已移除的 MSWEA_MODEL_API_KEY 變數之上的教學，都早於 v2。

你應該選哪一個

選擇 mini-SWE-agent，如果你的工作具有批次或供應商導向的特性：對許多問題執行相同提示、比較模型，或在沙箱中工作，而一個小到足以稽核的代理程式比你無法檢視的功能集合更重要。它的執行模型才是決定性特性：mini 的 FAQ 說明動作會透過 subprocess.run 執行，其中「每個動作都完全獨立（相對於持續執行具狀態的 shell 工作階段）」；因此「代理程式無法切換目錄或匯出環境變數；不過，可以按動作設定環境變數」。隨附的 mini.yaml 也向模型說明相同事項——「目錄或環境變數變更不會持續。每個動作都會在新的子 shell 中執行」——並改為要求模型使用帶前綴的命令。這讓執行結果可重現，也能輕易容器化，但會讓長時間的具狀態 shell 工作變得不便。遷移成本只需一個下午：pip install mini-swe-agent、一個 YAML 檔案，以及一個金鑰。

選擇 Claude Code，如果價值在於介面和防護措施。Anthropic 表示它可「在終端機、IDE、桌面應用程式和瀏覽器中」使用，並指出「Terminal CLI、VS Code 和 JetBrains 也支援第三方供應商」——因此閘道路由只存在於其中部分介面。它提供權限模式、子代理程式、MCP 伺服器、hooks 和計畫模式；在 Pro 或 Max 訂閱中，你的用量會從方案額度中扣除，而不是按權杖計費。代價是特定形式的供應商鎖定：你無法讓它離開 Claude 模型，而 Anthropic 的 閘道文件指出，它「不支援透過任何閘道將 Claude Code 路由至非 Claude 模型」。

從 Claude Code 切換至 mini，表示放棄權限系統，以換取 mini 的三種模式；完全放棄 IDE 和桌面介面；並自行負責支出核算——mini 的每次執行預算只有在 LiteLLM 能為你的模型 ID 定價時才有效。從 mini 切換至 Claude Code，表示放棄免費的模型選擇，從可閱讀的工具框架轉向打包的二進位檔：claude-code 儲存庫是發佈點，而其 授權檔案只有一行通知——「© Anthropic PBC. All rights reserved」——使用須遵守 Anthropic 的 Commercial Terms of Service。

兩個代理程式並列比較

2026 年 9 月 19 日閱讀的來源：mini 的 PyPI 中繼資料、Claude Code 的 npm registry 文件、mini 的 CLI 頁面、mini 隨附的 mini.yaml，以及 Anthropic 的 CLI 參考資料和概覽。

為什麼「mini 勝過 Claude Code」不是結論

mini 的 首頁有一則新聞標題寫著「mini-swe-agent 在 DeepSWE 上擊敗 Claude Code 和 Codex」，值得看看 DeepSWE 實際測量了什麼。其 文章指出：「每次執行都使用 mini-swe-agent，也就是 SWE-bench 作者打造的工具框架。我們在每個模型中固定使用它，因此排行榜反映的是模型能力，而不是周邊工具框架。」因此，該排行榜是 mini 內部的模型排名，不是 mini 與其他代理程式之間的排名。

該研究中唯一的工具框架對工具框架比較，是針對「相同的 10 個 SWE-Bench Pro 任務」進行的試點；在這些任務上，標準化工具框架以相近的權杖成本達到或超越原生工具框架——而其作者隨即提醒：「其中部分差距很可能來自提示調校，而非能力。」十個任務、少數幾個模型，並不足以排名兩個代理程式；研究此頁面時也找不到其他具可信度且規模實用的直接對比。因此，本指南不為兩者評分，而是比較可核查的內容：通訊協定、權限、支出控制和遷移成本。

關鍵問題：兩者各自能連接哪些端點

這是兩者差異最大的地方，也是決定閘道是否可行的部分。

Claude Code 受到通訊協定鎖定。 Anthropic 的 閘道相容性指南列出三種格式：由 ANTHROPIC_BASE_URL 選取並呼叫 /v1/messages，另可選擇呼叫 /v1/messages/count_tokens 的 Anthropic Messages；Amazon Bedrock InvokeModel；以及 Google Cloud 的 Agent Platform rawPredict。沒有 chat-completions 模式。基礎 URL 是來源位址，因為 Claude Code 會附加路由——Kunavo 自己的 ANTHROPIC_BASE_URL 頁面也採用相同規則。

# Claude Code speaks the Anthropic Messages format and appends the route
# itself, so the variable is the ORIGIN — not the /v1 URL mini wants.
export ANTHROPIC_BASE_URL=https://api.kunavo.com   # origin, no /v1
export ANTHROPIC_AUTH_TOKEN=sk-kn-...              # sent as Authorization: Bearer

# Pin models Kunavo serves. Claude Code's default and its opus alias are the
# newest Opus — pinned here to Opus 5.5, which needs Claude Code v2.1.280 or
# later (run `claude update`). The sonnet alias asks for Sonnet 5.5, which
# Kunavo does not serve: unpinned, /model sonnet, opusplan's execution phase
# and sonnet subagents 404.
export ANTHROPIC_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5

claude

有三項後果值得納入預算。憑證變數決定標頭：Anthropic 的 連線頁面指出，「ANTHROPIC_AUTH_TOKEN 位於 Authorization: Bearer、ANTHROPIC_API_KEY 位於 x-api-key，而 apiKeyHelper 位於兩者」，並且憑證若放在錯誤變數中，「會以閘道不讀取的標頭抵達閘道，請求會因 401 而失敗」。提示快取沒有 beta 配對，且會靜默失敗：Anthropic 的指南表示，閘道若移除 cache_control，就會產生「沒有錯誤：每一回合的對話都會以未快取輸入計費」。除非設定 CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1，否則模型探索會關閉；設定後，Claude Code 只保留包含「claude」或「anthropic」的 ID。

mini 不受通訊協定限制，但設定較為繁瑣。 它完全沒有基礎 URL 環境變數；其 本地模型頁面說明，model_kwargs 會直接作為 litellm.completion(model=model_name, messages=messages, **model_kwargs) 傳入。此處請保留 /v1 後綴——這與上方 Claude Code 的規則相反。該頁面的範例本身在未加前綴的模型名稱上設定 custom_llm_provider: "openai"，因此下方的 openai/ 前綴是雙重保險，而非必要條件；該頁面明確要求的是，如果使用其中任一項，「這也必須與設定中的 litellm_provider 相符」。

# mini has no base-URL environment variable. The endpoint goes in a config
# file, because model_kwargs is splatted straight into litellm.completion().
model:
  model_name: "openai/claude-sonnet-5"        # prefix and provider must agree
  model_kwargs:
    custom_llm_provider: "openai"
    api_base: "https://api.kunavo.com/v1"    # keep /v1 here
    drop_params: true                        # the shipped mini.yaml sets this too
  # set_cache_control is already "default_end" for a name containing "claude"

將金鑰提供為 OPENAI_API_KEY，可以放在環境中，或透過 mini-extra config set 寫入 mini 的 .env；mini 的 全域設定頁面指出：「環境變數優先於 .env 檔案中設定的變數。」使用 mini -c kunavo.yaml 選取檔案，或使用 MSWEA_MINI_CONFIG_PATH 將其設為預設值。

有一種容易被忽略的失敗模式值得單獨處理。mini 的每次執行預算由 LiteLLM 的成本追蹤強制執行，而這需要識別模型 ID——本頁未檢查 Kunavo 的 ID 是否已在 LiteLLM 的登錄中定價。請假設尚未定價，並自行提供費率，不要使用 MSWEA_COST_TRACKING="ignore_errors"，因為它會移除防護，而不是修復問題。將 LITELLM_MODEL_REGISTRY_PATH 指向 LiteLLM 模型價格格式的檔案。mini 的操作範例以不含供應商前綴的模型名稱作為項目索引，並在 litellm_provider 中宣告供應商；此處複製的就是這種形式：

{
  "claude-sonnet-5": {
    "input_cost_per_token": 0.0000014000,
    "output_cost_per_token": 0.0000070000,
    "litellm_provider": "openai",
    "mode": "chat"
  }
}

兩項需要誠實說明的缺口。Kunavo 尚未在執行階段以任一用戶端測試其端點，而發佈設定參考資料也不等於相容性測試。尚未驗證的具體事項是：LiteLLM 的 openai/ 路徑是否會使用 原生工具呼叫——mini v2 的預設行為——與 Kunavo 的 chat-completions 端點協商。如果不會，mini 仍隨附舊版文字解析路徑 model_class: litellm_textbased，以及與預設設定並列的 mini_textbased.yaml 設定。嘗試任一用戶端時，請保留一條可運作的路徑，並閱讀帳戶對受限任務實際記錄的內容。

兩者執行時各自的成本

軟體價格無法直接比較，因為兩者中只有一個有價格。

價格卡和支援文章對 Max 層級的描述不同——前者將其合併為單一「起始」金額，後者則列出兩者。在編列預算前，請於結帳時確認層級和總額。此處刻意省略 Team 和 Enterprise 席次價格：它們是組織的席次決策，而非本頁所討論的單一開發者選擇。

對按量計費的用量，Anthropic 提供的是一個範圍，而不是每項任務的金額：「在企業部署中，平均成本約為每位開發者每個活躍日 $13、每位開發者每月 $150-250；90% 的使用者每個活躍日的成本低於 $30」（成本管理文件）。這是 Anthropic 自家部署的彙總資料，不是任一代理程式相互比較的測量結果；mini 也沒有相應數字。

一項實際 token 估算

這是示意性的權杖計算，不是測得的任務成本，也不是帳單上限。兩個代理程式都會在每回合重新傳送對話——Anthropic 自己的文件指出：「Claude Code 會在每次請求中傳送完整對話，而每當 Claude 使用工具時，它會再次傳送一個包含該批工具結果的請求」——因此輸入量占主導地位。假設一項受限任務在各回合合計包含 600k 個未快取輸入權杖，以及 25k 個輸出權杖。費率是目前 Kunavo 目錄中每百萬權杖的價格。

請將其視為比率，而不是預測。在這些假設下，Claude Haiku 4.5 和 Claude Opus 5 之間的差距約為 5.0×，這是比選擇用戶端更大的槓桿。另請注意，最低列示費率與完成任務的最低成本是不同的主張：需要三次嘗試的較便宜模型，成本可能高於一次就成功的模型；而 mini 的獨立子程序迴圈會在步驟失敗時重新傳送更多上下文。快取會再次改變情況，而且方向並非大多數文章所假設的那樣。Claude Code 會自行附加 cache_control 標記。mini 也會自行設定 set_cache_control: "default_end"，但只適用於部分模型名稱：其 模型選擇程式碼會在解析後的模型名稱包含 anthropic、claude、sonnet 或 opus，且設定尚未設定該索引鍵時套用此預設值。因此，Claude 名稱的 ID——包括上方帶前綴的 openai/claude-sonnet-5——會在你未要求的情況下取得標記；Gemini 名稱的 ID 則不會。本頁未測試 chat-completions 端點是否會對這些標記採取行動。請參閱 提示快取。

Kunavo 目錄中的金額是計費底線，而非上限：上游回報費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中較高者。快取費用和外部工具不包含在此範例中。最低加值金額為預付額度中的 $10——這是資金最低額，不是任務費用或訂閱費。請參閱 帳單詳細資料；另請注意，Claude Code 自己的 /usage 數值是「根據權杖數量和牌價在本機計算」，並明確是「估算值」，因此應以供應商的帳務紀錄核對，而不是以用戶端的讀數為準。

還有一項需要釐清：SWE-agent 不等於 mini-SWE-agent

較早的兄弟專案仍會出現在這些查詢的排名中，並共用同一個組織、README 系列和基準測試脈絡——但它有不同的設定語法、不同的文件，在 mini 教學中也沒有位置。其維護者自己也已轉向其他方向：SWE-agent README指出：「我們目前大部分的開發工作都在 mini-swe-agent 上，它已取代 SWE-agent」，並建議今後使用 mini（於 2026 年 9 月 19 日閱讀）。它尚未被封存，而且專案採用 MIT 授權，因此請將其視為「仍在維護但已被取代」，而不是已停止維護；新的工作請從 mini 開始。

設定任一者

Kunavo 發佈了 Claude Code 的設定參考資料，但沒有 mini-SWE-agent 的設定參考資料；這裡沒有對任一用戶端進行執行階段測試，而發佈設定頁面也不等於相容性測試。如果 Claude Code 是你的用戶端，請從 Claude Code 整合指南開始，準備為金鑰提供資金時再建立 Kunavo 帳戶。如果你要先在訂閱與按量計費的權杖之間做選擇，Claude Code 定價和不使用訂閱的 Claude Code涵蓋這項決策，而Claude Code 的最佳 API則比較各種路徑。至於 mini，做法就是 OpenAI 相容 API中描述的一般模式。想比較其他終端機代理程式？OpenCode 與 Claude Code 的比較和Aider 定價還涵蓋另外兩個用戶端，同樣區分免費工具框架與按量計費的模型帳單。

常見問題

於 2026 年 9 月 19 日直接擷取並查核每個來源：mini-SWE-agent 的 PyPI 中繼資料、首頁、v2 遷移指南、FAQ、CLI、全域設定和本地模型頁面；其主分支上的隨附 mini.yaml、run/mini.py 和 models/__init__.py；Claude Code 的 npm registry 文件、儲存庫授權檔案，以及其概覽、閘道、閘道通訊協定、閘道連線、成本和 CLI 參考文件；claude.com/pricing 和 Max 方案支援文章；SWE-agent README；以及 DeepSWE 文章。本頁未針對任一用戶端與 Kunavo 的搭配進行執行階段測試，也未重現本頁的任何基準測試結果。Kunavo 的權杖費率來自即時目錄，本頁所有美元範例都是示意性的權杖計算。