Oh My Pi 與 Pi：分支、差異及應執行哪一個

Oh My Pi 是 Pi 的硬分支，不是從旁邊發展起來的競爭者——程式碼流向是 Pi → Oh My Pi，兩個專案如今都仍在運作，而且現在針對相反的目標進行最佳化。 Pi 是刻意保持精簡的終端機框架，你可以用 TypeScript 擴充它。Oh My Pi 則是同一脈絡的重新打造版本，成為內建完整功能的程式設計介面，內含 LSP、偵錯器、子代理程式與瀏覽器工具。兩者都採用 MIT 授權，安裝費用都是 $0，因此決策取決於工作流程、執行模型與設定格式，而不是授權費。

先說名稱，因為其中有三個會混淆。這裡的 Pi 指的是 pi.dev 上的代理程式框架，由 Earendil Works 透過 earendil-works/pi 發布。它不是 Inflection AI 的 Pi（pi.ai）、Pi Network 的代幣，也不是 Raspberry Pi。Oh My Pi 指的是 omp.sh 上的代理程式，來源為 can1357/oh-my-pi，其執行檔是 omp——不是搜尋這個詞組時佔主導地位的派餡餅店，也不是 Oh My Zsh 或 Oh My Posh，儘管名稱相似。而 pi-mono 不是第三個產品：它是 Pi 舊的儲存庫名稱。github.com/badlogic/pi-mono 現在會回傳 301 並導向 earendil-works/pi，但第三方文件仍使用舊路徑——DeepSeek 的官方 Pi 整合頁面目前確實位於 /agent_integrations/pi_mono/。

分支方向值得明確說清楚，因為搜尋會朝兩個方向進行，而答案並不對稱。Oh My Pi 的 README 在自己的標題中寫明它是「由 @mariozechner 開發的 Pi 分支」，並連結至改名之前的 URL。GitHub 對它回報 fork: false 與 parent: null，因為這是原始碼分支，而不是透過分支按鈕建立的分支——所以 API 不會告訴你這件事。該儲存庫仍保留 docs/porting-from-pi-mono.md，這是一份合併檢查清單，其中記錄的 Last Sync Point 是提交 b21b42d，日期為 2026 年 3 月 22 日。這個標記是外部目前能取得的唯一分歧證據；此後是否曾進行未記錄的同步，不是本頁能夠確認的事項。

Oh My Pi 與 Pi：你應該選哪一個？

五個軸向會決定這件事——無論你是從哪個方向開始比較——而其中只有一個與功能有關。

• 工作流程。 如果你想要小型核心，並打算自行撰寫缺少的部分，請選擇 Pi。在 2026 年 9 月 22 日文件更新之前，其官方使用文件表示它「刻意不包含內建 MCP、子代理程式、權限快顯、計畫模式、待辦事項或背景 bash」，並將你導向擴充功能、套件、容器與 tmux。該更新移除了這句話，而 v0.99.0 隨後將 MCP 變成預設載入的內建擴充功能；在 v0.99.2 中，子代理程式、計畫模式、待辦事項與核准提示仍是擴充功能。如果你希望第一天就擁有這些功能，且不想維護擴充功能，請選擇 Oh My Pi。
• 權限與執行模型。 兩者的預設值都不是安全選項，因此請根據你能接受哪種失效模式來選擇。Pi 沒有權限系統，並明確說明這一點。Oh My Pi 有真正的三層權限系統，預設值為 yolo。如果你需要逐工具提示，Oh My Pi 在加入一行設定後可以提供；Pi 若不使用擴充功能，完全無法提供。
• 通訊協定與方案限制。 如果你的模型路由是第三方 OpenAI 或 Anthropic 相容端點，兩者都能連線，但 Oh My Pi 記載了九種線路方言，而 Pi 在 2026 年 9 月 22 日文件更新前記載四種，且 Oh My Pi 額外提供 Pi 沒有的環境變數路由。程式碼中的方言差距比文件上更窄：Pi v0.99.2 的原始碼會將自訂供應商的 api 分派至十種內建實作中的任一種，其中六種從未被文件記載為可用於此目的。如果你的路由是 OAuth 訂閱——Claude Pro/Max、Codex、GitHub Copilot——兩個用戶端都會透過 /login 附加它，並儲存供應商 token，而中間的閘道會拒絕該 token；Oh My Pi 自己的供應商文件以此作為 models.yml 金鑰刻意優先於已儲存 OAuth 的理由。不要將中國的程式設計方案歸入該群組：Pi 在其API 金鑰表格中列出 ZAI/GLM、Kimi For Coding 與 Qwen Token Plans（ZAI_API_KEY、KIMI_API_KEY、QWEN_TOKEN_PLAN_API_KEY），而 Oh My Pi 將它們標記為 plan 而不是 oauth，因此在兩者中都是一般以金鑰驗證的供應商。
• 成本路徑。 兩邊的用戶端都是免費的，而且兩者都不會改變你的每 token 費率。不對稱之處在於，Pi 有一個第一方付費閘道（由同一家公司營運），並連接至自己的 /login；Oh My Pi 不提供任何託管路由——它唯一營運的伺服器是 /collab 工作階段連結背後的中繼站，不會收費。
• 遷移成本。 大致上只需重新輸入一個供應商區塊。設定格式與目錄不同——JSON 位於 ~/.pi 下，YAML 位於 ~/.omp 下——而兩個儲存庫都沒有記載匯入工具。兩者共用幾個環境變數名稱，但下文有注意事項。

不應用來決定它的是版本號。Oh My Pi 在分支時重新編號，因此它的 18.2.7 與 Pi 的 0.86.1 是不同的編號方案，不代表多出十八個版本的成熟度。

兩者實際上有何不同

2026 年 9 月 19 日讀取自兩個儲存庫自己的文件：Pi 的概覽、安全性與模型頁面，以及 Oh My Pi 的README、核准模式與供應商頁面。Pi 的設計理念、MCP、權限模型與方言列於 2026 年 10 月 1 日，根據其更新後的文件、README 與 v0.99.2 原始碼重新檢查。Oh My Pi 列中的功能數量是該專案自己的宣稱；未發布任何方法論，而其 README 的基準測試表同樣是本頁未重現的供應商聲明。

兩者都仍在運作。沒有任何單一指標能決定「哪一個更大」

關於這一對產品最常見的單一錯誤，是把其中一個當成已被放棄或已被取代。這次檢查當天，兩者都曾推送程式碼。

儲存庫、版本發布與星數資料來自 2026 年 9 月 21 日讀取的 GitHub API；下載量來自截至 2026 年 9 月 16 日當週的 npm 下載量 API。不要將任一欄轉化為採用結論。 尤其 npm 比較並非同類比較：Pi 自己的文件以 npm install -g 開始，而 Oh My Pi 的 README 記載 curl-to-shell、Homebrew、Bun、Nix、PowerShell 與 mise，完全沒有提供 npm 指令，因此 npm 會大幅低估它，低估程度無法由本頁任何資料衡量。星數偏向 Pi；發布節奏偏向 Oh My Pi；任何只根據單一指標描述人氣的句子，至少會在一個方向上出錯。

如果你想要不依賴這些指標、顯示兩者目前仍活躍的中立第三方證據：Ollama 分別發布了 Oh My Pi 與 Pi 的整合頁面，DeepSeek 也為兩者各自發布代理程式整合指南——其中 Pi 指南仍位於舊的 pi_mono 路徑下。四個頁面都在 2026 年 9 月 21 日成功回應。

將任一者指向你自己的端點

這裡最能看出分支差異，而錯誤的 /v1 可能讓你浪費一個下午。兩個用戶端都能連線至第三方 OpenAI 或 Anthropic 相容端點，但採用的機制不同，URL 慣例也相反。

Oh My Pi 有 Pi 沒有的環境變數路由。 其 Anthropic 供應商會透過 normalizeAnthropicBaseUrl($env.ANTHROPIC_BASE_URL) 解析基礎 URL，優先於官方預設值；該正規化器會移除尾端的 /v1，因此 https://api.kunavo.com 與 https://api.kunavo.com/v1 都會連到同一個主機。2026 年 9 月 19 日讀取自 packages/ai/src/providers/anthropic-state.ts，其中定義了 resolveDirectAnthropicBaseUrl() 與正規化器；資料來自原始碼，而不是我們發出的請求。

# Oh My Pi honours ANTHROPIC_BASE_URL for its built-in anthropic provider.
# normalizeAnthropicBaseUrl() strips a trailing /v1, so both forms resolve
# to the same host here. Pi ships no equivalent gateway base-URL variable.
export ANTHROPIC_API_KEY="$KUNAVO_API_KEY"
export ANTHROPIC_BASE_URL="https://api.kunavo.com"
omp

這條路由還有一個優先順序陷阱。Oh My Pi 的文件化順序將 models.yml apiKey 放在第 2 位，位於第 3 位的已儲存 OAuth 之上，但供應商環境變數位於第 5 位，低於它。因此，如果你已經透過 Anthropic /login，訂閱 token 會優先於 ANTHROPIC_API_KEY，而你的閘道金鑰永遠不會被使用。請在設定中固定金鑰，或先登出該供應商。

對於具名供應商，Oh My Pi 使用 YAML——而在這裡 /v1 會重新加回，因為其 OpenAI 路徑會將 /chat/completions 原封不動地附加到去除尾端內容的基礎 URL。

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1   # /v1 REQUIRED: omp appends /chat/completions
    api: openai-completions              # use anthropic-messages, and then drop /v1
    apiKey: KUNAVO_API_KEY               # env var name, a literal, or "!cmd"
    authHeader: true                     # send Authorization: Bearer <key>
    models:
      - id: claude-sonnet-5
        contextWindow: 200000
        maxTokens: 64000

要讓 Pi 指向閘道，你只有一條路由：~/.pi/agent/models.json。 Pi 不會讀取 ANTHROPIC_BASE_URL——2026 年 9 月 19 日對整個儲存庫進行的程式碼搜尋，對該確切字串找到兩個結果，且兩者都不是覆寫設定（一個是 Cloudflare AI Gateway 常數，另一個是模型產生腳本）——而且也不存在單獨的 OPENAI_BASE_URL。確實存在一個基礎 URL 變數，但它不是通用的逃生門：AZURE_OPENAI_BASE_URL 列於Pi 的供應商文件中，會將 Azure OpenAI 供應商指向你自己的 Azure 資源，除此之外沒有其他用途。

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com",
      "api": "anthropic-messages",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

關於尾碼，Pi 自己的文件從未確定過，你應該知道這一點，而不是相信單一範例。在 2026 年 9 月 22 日文件更新之前，其模型頁面在一處將 anthropic-messages 代理伺服器顯示為 https://proxy.example.com/v1，另一處則顯示為 https://proxy.example.com 且沒有尾碼；更新後兩者都被移除，但仍未確定慣例。應遵循無尾碼形式，理由來自原始碼而非執行期測試：Pi 在 anthropic-messages 路徑上沒有 Oh My Pi 那種會移除 /v1 的正規化器——其文件描述的唯一正規化是 Azure 專用的：Azure 自有網域下的資源根 URL「會被正規化為 OpenAI API 路徑」——其內建 Anthropic 預設值是沒有 /v1 的 https://api.anthropic.com，而 OpenAI 預設值是 https://api.openai.com/v1；對於 anthropic-messages，它會直接將 model.baseUrl 傳給官方 Anthropic SDK，由 SDK 自行附加 /v1/messages。如果在那裡加入 /v1，就會產生 /v1/v1/messages。Kunavo 在其基礎 URL 頁面上也記載相同慣例：Anthropic 類型的用戶端只使用 origin，OpenAI 類型的用戶端使用 /v1。

還有兩個值得納入規劃的界線。在 2026 年 9 月 22 日更新文件前，Pi 的文件表格為自訂提供者列出四種方言，即使儲存庫已提供額外處理常式；更新後表格被移除，卻未指定替代清單，因此這四種仍是 Pi 為自訂提供者記載的唯一介面。不過，額外處理常式並非僅保留給內建項目：Pi v0.99.2 的原始碼將 models.json 中的 api 欄位定義為不受限定的字串，並將其分派給十個已註冊實作中符合者（BUILTIN_APIS 位於 packages/ai/src/compat.ts），因此自訂提供者可以將該欄位指定為 bedrock-converse-stream 或 google-vertex——但兩者是否能對第三方端點運作，並無文件記載，這裡也未經測試。至於 Oh My Pi，disabledProviders 會在檢查憑證之前先行檢查——被該清單攔截的提供者 ID 無論你提供什麼金鑰都會靜默消失——而設定陣列會由優先順序較高的層級整體取代，而非合併，因此專案層級清單會悄悄捨棄全域清單。兩個專案也都提供你在閘道上可能確實需要的相容性逃生機制：Oh My Pi 的 disableStrictTools、Pi 的 supportsEagerToolInputStreaming 和 allowEmptySignature。Kunavo 是否接受任一用戶端的預設嚴格結構描述、快取標記或即時工具輸入串流，尚未在此測試。

實際切換成本

比版本號差距所暗示的少，但不只是複製檔案。兩個儲存庫的文件樹中都沒有記載匯入命令、工作階段轉換器或設定遷移工具，因此請規劃在另一種格式中重新輸入提供者區塊——從 JSON 轉為 YAML，或反向轉換。憑證也不會移動：Pi 將其儲存在 ~/.pi/agent/auth.json，而 Oh My Pi 將 SQLite 驗證儲存在 ~/.omp/agent/agent.db。

環境變數的通用程度不如兩者的共同淵源所暗示的那麼高，因此請仔細閱讀這一節。Oh My Pi 確實仍會讀取以 PI_ 為前綴的名稱，其中包括 PI_CONFIG_DIR 和 PI_CODING_AGENT_DIR，但它們會變更 Oh My Pi 的目錄位置，因此在與 Pi 共用的 shell 設定檔中匯出其中一個變數，會讓兩個用戶端都指向同一路徑，而不是讓設定可攜。其環境變數參考文件所述的 OMP_ 至 PI_ 鏡像對應，適用範圍更窄：該文件指出，此規則適用於每個經過解析的 .env 檔案內，並明確表示「不適用於從父程序繼承的任意變數」。完全無法直接沿用的，則是任何針對執行框架開發的功能：Pi 的 TypeScript 擴充功能是依據 Pi 的 API 撰寫的，而自 2026 年 3 月 22 日的同步標記以來，約六個月各自維護的開發，正是這些 API 產生差異的原因。請測試擴充功能，而不要假設它能直接移植。

兩邊的費用相同

兩個用戶端都不會向你收費，因此在兩者之間切換不會改變模型支出，差額為零。變數在於你透過哪條路徑購買權杖，而兩者在這方面有一項差異：Pi 有第一方付費閘道，Oh My Pi 則沒有。Radius 由 Earendil 營運、採封閉原始碼，透過 Pi 自己的 /login 存取；其 常見問題指出，它會在標價之上收取「我們向付款處理商支付的費用」——該百分比並未公布，因此無法從外部計算 Radius 的總額。Oh My Pi 唯一的閘道是 omp auth-gateway serve，也就是由你代管的軟體，傳輸安全性則交由營運者負責。

在它進入預算前，有一件事必須先釐清：登入任一框架的 Claude Pro 或 Max 訂閱並不代表免費使用。在 2026 年 9 月 22 日更新文件移除該句子前，Pi 的提供者文件表示，第三方框架使用「會從額外用量扣除，並按權杖計費，而不是計入 Claude 方案限額」；Pi 在 Anthropic 模型使用訂閱驗證時顯示的警告仍寫著，這會「從額外用量扣除，並按權杖計費，而不是計入你的 Claude 方案限額」（來源，v0.99.2）。Oh My Pi 的文件中未找到等效聲明，因此不要假設它的行為不同——請查看你自己的帳戶。

對閘道路徑而言，以下是針對工作負載而非用戶端的算式。假設一個月持續進行代理工作：5,000,000 個未快取輸入權杖和 400,000 個輸出權杖，不讀取或寫入快取，也不收取影像或工具費用。費率是即時的Kunavo 目錄每百萬權杖價格。

這些是依據上述假設的說明性權杖估算，不是實測任務成本，也不是帳單上限。兩個用戶端的欄位相同，因為用戶端不是定價變數——但工作負載可能不同：Oh My Pi 的 task 工具會並行展開子代理，而每個並行代理都會攜帶自己的上下文，這是本表無法替你估算的輸入權杖倍數。請先在一項範圍明確的變更上測量，再擴大估算。

兩項 Kunavo 方面的注意事項應納入同一個數字。目錄金額是計費底線而非上限：上游回報費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中較高者，正如計費指南所說明。此外，最低加值金額是 $10 的預付額度——這是為帳戶提供資金所需的現金，不是任務費用或訂閱費。

Kunavo 為每個用戶端發布設定指南——Pi 和 Oh My Pi——但尚未對任一用戶端與其端點進行執行階段測試，而且設定指南是設定參考，而非相容性測試。以上兩種設定均根據已發布的文件與原始碼撰寫，應在你自己的機器上驗證。嘗試其中一種時，請保留一條可運作的路徑。當你想為實際任務而非模型定價時，請建立 Kunavo 帳戶、存入資金，並針對你選定的模型執行一項範圍明確的變更。如果你仍在選擇框架而非提供者，Pi coding agent pricing會拆解 Pi 的四條計費路徑，而 Pi vs OpenCode則將 Pi 與另一個具有已發布 Kunavo 設定指南的用戶端比較。

常見問題

兩個儲存庫的文件樹與 npm 套件已於 2026 年 9 月 19 日檢查，基礎 URL 與憑證順序的說法則於同日從內文所列原始碼檔案讀取；儲存庫指標與版本發布歷程於 2026 年 9 月 21 日重新閱讀。Pi 於 2026 年 9 月 22 日更新文件後，其 anthropic-messages 基礎 URL 範例、Azure 正規化句子、文件記載的 api 值與憑證順序，已於 2026 年 10 月 1 日依更新後文件及 v0.99.2 原始碼重新核對。同日，在 Pi v0.99.0 發布內建 MCP 後，其省略功能清單、專案信任措辭與所述設計，已依其使用方式、MCP、設定與安全性頁面、README、原始碼實際分派的 api 值，以及本網站自己的整合索引重新核對；關於額外用量的那句敘述，也已對照該原始碼中的終端機警告重新核對。此外，2026 年 10 月 1 日，Oh My Pi 文件記載的 api 值已對照 v18.4.8 中的 docs/models.md 與 models.yml 結構描述重新核對。Kunavo 費率取自即時目錄，本頁每個美元數字均為說明性權杖算式。兩個用戶端都未針對 Kunavo 進行執行階段測試，也不暗示兩個專案之間存在任何效能或基準測試比較——沒有可供本頁引用的此類比較。