Oh My Pi 與 OpenCode：工作流程、模型與總成本

兩個用戶端都是免費的 MIT 軟體，因此選擇的關鍵不是價格，而是你是否希望模型帳單與用戶端來自同一個帳戶。OpenCode 直接銷售模型：每月 $10 的 OpenCode Go 訂閱，以及按用量付費的 OpenCode Zen 閘道。Oh My Pi 完全不銷售任何內容，期待你自備金鑰。如果你已經知道從哪裡購買 token，並希望深入控制路由，請選擇 Oh My Pi；如果你想要更廣泛的介面——終端機、IDE、伺服器、SDK——以及不離開其中即可購買模型的選項，請選擇 OpenCode。

在上述內容具備實用價值之前，必須先釐清三個名稱衝突，因為其中兩個會將你導向錯誤的文件。

哪個專案是哪個

儲存庫、版本與套件資訊取自 GitHub 與 npm API，查核日期為 2026 年 9 月 19 日。Oh My Pi 明確是分支：其 README 表示「omp 是 Mario Zechner 的 Pi 分支，重新改寫為以程式設計為優先的介面」，而儲存庫仍保留將變更從上游向前移植的檢查清單。OpenCode 的遷移是公司重新命名，而非所有者變更——sst 組織現在顯示「我們已移至 https://github.com/anomalyco」，而anomalyco 組織的名稱是 Anomaly。本頁不主張該重新命名的日期，因為公開證據無法相互吻合。

你應該選哪一個

工作流程。Oh My Pi 是以終端機優先的代理程式，具有異常明確的路由層：其 README 描述九種按意圖路由工作的角色——一般回合使用 default、以低成本分派多個子代理程式使用 smol、深度推理使用 slow，另外還有 plan、commit、vision、task、advisor 與 tiny——每個角色都可以指定不同模型；當主要模型碰到配額限制時，retry.fallbackChains 下方提供回退鏈。OpenCode 則改為橫向擴展：有兩個可使用 Tab 切換的內建代理程式，以及跨 IDE、Web 介面、伺服器、SDK 與外掛程式的文件化整合。如果你的痛點是「我希望讓低成本模型處理低成本部分」，那就是 omp 的內建形態。如果你的痛點是「我希望從更多地方存取這個代理程式」，那就是 OpenCode 的形態。

權限與執行。兩者預設都不是謹慎的那一個。omp 的核准模式文件將 yolo列為預設模式，會自動核准 read、write 與 exec，且不提示任何內容；always-ask與write則是更嚴格的設定。它確實會辨識一小組關鍵的 bash 模式——rm -rf /、fork bomb、先從遠端擷取再執行，以及類似模式——但在依賴這點前，請仔細閱讀 omp 的核准模式頁面：同一份文件表示，在 yolo 中，單獨的關鍵覆寫會被忽略，只有明確的工具或使用者 prompt/deny 政策仍會強制停止。OpenCode 的權限頁面表示，大多數權限預設為 "allow"，doom_loop 與 external_directory 預設為 "ask"，而讀取 .env 檔案則被拒絕。兩者的結構也不同，這在移植政策時很重要：omp 為每個工具宣告 read/write/exec 層級，並以 tools.approval.<toolName> 覆寫；OpenCode 則評估模式規則，最後一個相符規則勝出。

方案與協定限制。這裡唯一具有方案形態的限制，方向與人們預期的不同。兩個用戶端都不會以方案限制自備金鑰。但OpenCode Go對使用它的用戶端有一些要求：它表示該方案是為 OpenCode 及其他產生類似請求的程式設計代理程式而設計，且「會監控流量以防止濫用」；你的用戶端「應」傳送典型的程式設計代理程式流量、「以自身的 user agent 識別自己」，並在每次對話中「於 x-opencode-session 傳送穩定的工作階段 ID」。omp 為其 opencode-go 供應商確實實作了這套管線。OpenCode 的已驗證用戶端表格列出一列僅名為「Pi」的項目，沒有區分上游專案與此分支，因此無法從該頁判定是否涵蓋 Oh My Pi——本指南不宣稱 Oh My Pi 是已驗證的 OpenCode Go 用戶端。

各自的費用

查核日期：2026 年 9 月 19 日。Oh My Pi 不銷售任何內容的證據是間接但有力的：其網站地圖發布 36 個 URL，即首頁加上 35 個文件頁面，其中沒有定價、帳務、結帳或註冊途徑，且儲存庫採用 MIT 授權。其唯一的託管接觸點是工作階段協作中繼站，預設為 wss://my.omp.sh，並在每個工作階段承載內容抵達 socket 前加以密封——沒有附帶價格，也沒有註冊方式。它接受自訂中繼站 URL，但同一頁面表示目前未提供生產中繼站供自行託管。

$10 方案是上限，不是配額

OpenCode Go 值得精確理解，因為第三方摘要一再誤述。官方頁面表示「使用量限制以每月美元金額定義」，而不是請求數量。每個模型都有自己的每月美元上限——依模型而定為 $15、$30 或 $60——較短的時間窗則是同一個每模型上限的百分比：5 小時時間窗為其 20%，每週時間窗為其 50%。因此廣泛流傳的「每 5 小時 $12」只有在模型的每月上限為 $60 時才成立。另有兩項規則會改變算術：「每個工作區只能有一名成員訂閱 OpenCode Go」，而達到上限並不是硬性停止——頁面表示你仍可繼續使用免費模型，或啟用餘額回退，讓請求改用 Zen 額度而非被阻擋。請直接閱讀該頁的模型名單表，而不是任何摘要。頁面表示清單可能變更，而且變更速度比指南能追蹤的速度更快：在某個限時促銷倍數顯示於模型旁時，同一模型的上限在相隔一天的兩次查核中讀值不同，因此無論任何地方引用的上限——包括此處——都應僅作為了解上限制度的概略參考，而非目前的確切數字。

Zen 是同一帳戶中按用量計費的一側。其文件表示，你會依每次請求從額度餘額扣款；除非你變更或停用，當餘額低於 $5 時會自動補入 $20；卡片費用則按成本轉嫁，報價為每筆交易 4.4% 加 $0.30。其明示立場是「以成本價銷售，將任何降價轉嫁出去；因此唯一的加價是用來支付我們的處理費」。其中有兩項明確是暫時性的，且會過時：標示為 $0 的模型都各自說明為「限時」免費，其中大多數還註明團隊利用這段時間收集回饋並改進模型；團隊工作區則僅在測試版期間免費。列出的免費模型數量會變動——請在頁面上自行計數，不要相信此處的任何數字。這兩項說明在 2026 年 9 月 19 日仍位於該頁，預算規劃前應重新閱讀。至於完整的 Go 與 Zen 費率表，OpenCode 定價已經持續追蹤。

同條件 token 估算

這是token 算術，不是實測工作成本，也不是帳單上限。假設單一工作階段包含200,000 個未快取輸入 token 與 15,000 個輸出 token，並且只比較兩份價格表上同時出現的兩個模型名稱。Kunavo 費率取自即時目錄；Zen 費率則讀自其自身文件，查核日期為 2026 年 9 月 19 日。

請嚴格按此範圍閱讀。在這些假設下，兩份價格表對 Claude Sonnet 5 得出相同估算，對 Claude Opus 5 得出不同估算；這是關於同一天公布的兩個費率的陳述，不是宣稱任一閘道普遍較便宜。Zen 公布了 Kunavo 不銷售的模型費率，而 Kunavo 的目錄也包含 Zen 未列出的模型，因此兩份費率表的大部分內容都沒有可比較的對應項目。列出的最低費率與完成工作的最低成本也是不同問題——需要嘗試三次的較便宜模型，成本可能高於一次完成工作的較昂貴模型。

即使看起來相似，10 美元的數字也無法直接比較。OpenCode Go 的 10 美元是每月定期訂閱費，其價值取決於你是否實際使用到每個模型的上限。Kunavo 的 $10 最低額度是預付額度的加值——是資金門檻，不是月費，也不是任務價格。Kunavo 目錄中的金額是計費下限，而非上限：當上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者之較高者。快取費用與外部工具不包含在此範例中；請參閱 計費詳細資訊。

將任一用戶端指向你自己的金鑰

這是兩個用戶端差異最大的地方，也是實際遷移會耗費你時間的地方。兩者都接受自訂的 OpenAI 相容端點，且不受方案限制。差異在於設定檔、各自支援的線路格式，以及一個自動偵測陷阱。

上方兩個表格均取自這些專案截至 2026 年 9 月 19 日的官方文件——omp 的 docs/models.md 與 OpenCode 的供應商頁面。

Oh My Pi 與探索陷阱

# Derived from omp's documented schema in docs/models.md.
# Not runtime-tested by Kunavo against a running omp.
providers:
  # OpenAI wire. baseUrl ENDS IN /v1 here.
  kunavo:
    baseUrl: https://api.kunavo.com/v1
    apiKey: KUNAVO_API_KEY      # an env var name, or a literal key
    api: openai-completions     # required whenever discovery is set
    authHeader: true            # sends Authorization: Bearer <key>
    discovery:
      type: openai-models-list  # reads /v1/models, picks up context_length

  # Anthropic wire. Written without /v1, matching omp's own proxy examples;
  # omp's docs say its Anthropic SDK strips a trailing /v1 either way.
  kunavo-anthropic:
    baseUrl: https://api.kunavo.com
    apiKey: KUNAVO_API_KEY
    api: anthropic-messages
    authHeader: true
    # disableStrictTools: true  # only if strict tool schemas are rejected
    models:
      - id: claude-sonnet-5
        name: Claude Sonnet 5

有一個細節值得占據整個段落。omp 文件記載了一種 discovery.type: proxy 模式，專為在同一個主機後方同時提供 /v1/messages 和 /v1/chat/completions 的閘道而設計——這正是 Kunavo 的架構。但它會從 GET /v1/models 中的 supported_endpoint_types 欄位推導每個模型的線路；沒有該欄位的模型則「若已設定，回退到供應商層級的 api，否則捨棄」。Kunavo 的 /v1/models 不會輸出該欄位，因此僅使用 discovery.type: proxy 會捨棄整個目錄。上方的片段避開了這個問題：discovery.type: openai-models-list 會先讀取 max_model_len，接著讀取 context_length，而 Kunavo 確實會發布 context_length。omp 自身的驗證規則規定，只要設定了探索，供應商層級的 api: 就是必要項目，但 proxy 模式除外。

使用閘道時，omp 的另一項行為也很實用：其文件記載的金鑰解析順序會將 models.yml 中的 apiKey 置於 已儲存的 OAuth 之上，並表示這是刻意設計的，「因此為自訂 baseUrl 或閘道提供的金鑰會獲得採用，而不會轉發代理程式會拒絕的上游 OAuth 權杖」。這會在最常見的閘道驗證失敗發生前先將其排除。

OpenCode 與 Anthropic 的特殊情況

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  },
  "model": "kunavo/claude-sonnet-5"
}

上方的聊天完成路徑直接遵循 OpenCode 文件記載的自訂供應商格式。Anthropic 相容路徑則沒有這種格式：OpenCode 文件說明，若要連線至 Anthropic 端點，必須覆寫內建供應商——「你可以設定 baseURL 選項，為任何供應商自訂基底 URL」——這表示你會繼承該供應商的模型 ID，並在同一份設定中放棄由該廠商自有主機提供的模型。OpenCode 的已發布 JSON Schema允許宣告 "npm": "@ai-sdk/anthropic" 的自訂供應商，其中 npm 是不受限制的字串，但供應商文件中完全沒有出現這項設定；請將此路徑視為未經驗證。

請留意基底 URL 的拼法，但應依照各用戶端自身的規則檢查，不要將一種慣例套用到兩者。在 OpenAI 相容介面中，兩者都需要 https://api.kunavo.com/v1。至於 Anthropic 線路，兩者的處理方式不同：omp 文件表示，其 Anthropic SDK「會先從 baseUrl 移除結尾的 /v1，再附加 /v1/messages」，而 omp 自己的 Anthropic 代理範例使用不含 /v1 的基底 URL；OpenCode 則將 Anthropic 路徑說明為覆寫內建供應商的 baseURL，且其覆寫範例以 /v1 結尾。僅來源的形式——https://api.kunavo.com，由用戶端附加 /v1/messages——是 ANTHROPIC_BASE_URL 本身採用的規則；在該規則下，結尾的 /v1 確實會產生 /v1/v1/messages；請參閱基底 URL 參考。Kunavo 同時接受 Authorization: Bearer 和 x-api-key，因此 omp 的 authHeader: true 與 AI SDK 自身的預設值都能形成有效路徑。

遷移實際上需要付出什麼

在這兩個用戶端之間切換，需要重寫設定，而不是直接複製。omp 的上下文檔案探索登錄表確實包含 opencode 來源，但其文件將該來源限定為單一使用者層級檔案 ~/.config/opencode/AGENTS.md，沒有專案層級的對應項目——因此，只有當你的專案指示已經位於兩個用戶端都能探索的檔案中（例如儲存庫根目錄的 AGENTS.md）時，才能轉移。omp 的文件沒有任何內容會讀取 opencode.json 供應商區塊，因此基底 URL、金鑰、模型項目與上下文限制都必須從頭重新宣告。

有一項差異值得審慎決定，而不是置之不理。OpenCode 的供應商頁面提醒，舊版曾附帶用於使用 Claude Pro 或 Max 訂閱的外掛程式，並表示「截至 1.3.0 已不再如此」，理由是該廠商禁止這種做法；同一頁仍列出 ChatGPT Plus、GitHub Copilot 和 GitLab Duo，表示這些訂閱可以零設定使用。相較之下，omp 仍為數個程式設計方案供應商提供具備多帳戶輪替功能的 OAuth 登入。如果你打算以訂閱而非按權杖計費的金鑰付款，這項差異就會替你決定該使用哪個用戶端——而這是政策問題，因此請查看該訂閱目前自身的條款，不要只依賴任一用戶端的文件。另請注意，OpenCode 自己的 Anthropic 區段在發布內容上前後不一致：描述 Pro/Max 登入選項的文字位於刪除該選項的提醒上方；本指南引用該提醒，因為它是具體且有日期的陳述。

最後，如果你只是要更換購買權杖的地方，而不是更換使用的用戶端，請先做這件事——這是成本較低的實驗。請透過適用於 OpenCode 的最佳 API比較供應商；如果閘道概念本身才是新內容，則參閱LLM 閘道的運作方式。如果你正在全面評估其他用戶端，OpenCode 替代方案會涵蓋更廣泛的選項。

在一項範圍明確的任務上試用

Kunavo 已發布 OpenCode 的設定指南，但尚未發布 Oh My Pi 的指南；而已發布的設定參考並不等同於相容性測試：這裡尚未針對 Kunavo 的端點對任一用戶端進行執行期測試，上方的 omp 片段是 Kunavo 首次發布的內容，根據 omp 文件記載的 Schema 推導而來。在試用任一用戶端時，請保留一條可運作的路徑，執行一項範圍明確的任務，然後查看你的帳戶實際記錄的費用。請從 OpenCode 整合指南開始，準備為金鑰儲值時再建立 Kunavo 帳戶。

常見問題

已於 2026 年 9 月 19 日對照 GitHub 與 npm API 核查儲存庫、發布版本與套件資訊；同日也閱讀了 OpenCode 的 Go、Zen、權限、供應商與企業頁面，以及 Oh My Pi 的 docs/ 樹狀目錄與網站地圖。Oh My Pi 允許的 api 值已於 2026 年 10 月 1 日，根據 v18.4.8 的 docs/models.md 與 models.yml Schema 重新核查。這兩個用戶端都未針對 Kunavo 進行執行期測試。Kunavo 詞元費率取自即時目錄，本頁所有美元數字都是示意性的詞元算術，而非實際測量的任務成本。