lidge-jun/opencodex 是什麼？

lidge-jun/opencodex 的功能、安裝路徑與維護取捨。本文只採用 README 能核對的內容，並指出適合與不適合的工作流。

lidge-jun/opencodex 可以商用嗎？

可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。

lidge-jun/opencodex 還在維護嗎？

有在維護。儲存庫在最近一天內有新的提交。

lidge-jun/opencodex 是用什麼程式語言寫的？

主要是 TypeScript（依據 GitHub 的語言統計）。

opencodex：安裝、架構與採用限制

秒懂

它是什麼？: lidge-jun/opencodex 的功能、安裝路徑與維護取捨。本文只採用 README 能核對的內容，並指出適合與不適合的工作流。
適合誰用？: 適合需要 Universal provider proxy for OpenAI Codex & Claude Code, use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code. 所涵蓋工作流，且能管理其依賴與設定的使用者。不適合把未記載的相容性、效能或服務保證當成既定條件的團隊。
可以商用嗎？: 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
還在維護嗎？: 有在維護。儲存庫在最近一天內有新的提交。
用什麼語言寫的？: 主要是 TypeScript（依據 GitHub 的語言統計）。

以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。

開源專案深度解析

Hysen Labs 編輯部 · 2026年8月8日 · lidge-jun/opencodex

opencodex 如何重新路由 Codex 與 Claude Code

第1節第1段：opencodex 是一個以 TypeScript 撰寫的本地代理，用於 OpenAI Codex 與 Claude Code。它位於 Codex 用戶端與 LLM 供應商之間，將 Codex 發送的 Responses API 呼叫轉換為所選供應商的協定。README 表示這個轉換在串流、工具呼叫、推理 token 與圖片上雙向運作。五個協定介接器涵蓋 Anthropic Messages、Google Gemini、Azure OpenAI、OpenAI Responses 透傳以及所有 OpenAI 相容的 Chat Completions 端點，合計內建超過 40 個供應商。對於 Claude Code，`ocx claude` 指令會以模型探索模式啟動代理。README 沒有提供基準數字或使用者數量，因此這些數據不在本文檔的確認範圍內。

安裝或啟動 opencodex 前，先對照 README 寫出的命令與依賴，並觀察實際產生的檔案或輸出。 opencodex 的文件脈絡在本節特別落到第1個觀察點，讀者可從相同入口逐項比對，不應把其他專案的預設值套進來。這個檢查也能把文件宣稱和部署現象分開，避免只看標題或功能清單就下結論。實際記錄時，應把 opencodex 的命令列、設定檔路徑、輸出格式、失敗狀態與使用的版本放在同一份紀錄中。如此才能分辨問題來自輸入、執行環境或專案本身，而不是將一次偶然成功誤認成穩定能力。對需要交接的團隊，這些項目也比抽象的功能描述更容易重現與審閱。

安裝與兩條關鍵命令

第2節第1段：README 中給人類使用的快速入門是兩條指令：`npm install -g @bitkyc08/opencodex` 與 `ocx start`。這會啟動代理並在 `http://localhost:10100` 開啟網頁儀表板。對於代理工作流程，`ocx init` 以互動方式寫入 `~/.opencodex/config.json` 並連接 Codex，但它不會啟動代理。`ocx provider add` 與 `ocx combo set` 等無頭指令需要與正在執行的代理通訊，無法存取時會以非零狀態結束。`ocx status`、`ocx doctor` 與 `ocx health` 報告執行狀態。需要 Node 18 或更高版本，README 指出 Bun 會在 `npm install` 期間自動打包，因此不需要另外安裝 Bun。這個安裝方式在 macOS、Linux 與 Windows 上均以原生方式運作，Windows 不需要 WSL。

若要把 opencodex 放進自動化流程，應先確認其設定鍵、退出狀態與錯誤訊息是否符合現有執行器。 opencodex 的文件脈絡在本節特別落到第2個觀察點，讀者可從相同入口逐項比對，不應把其他專案的預設值套進來。這個檢查也能把文件宣稱和部署現象分開，避免只看標題或功能清單就下結論。實際記錄時，應把 opencodex 的命令列、設定檔路徑、輸出格式、失敗狀態與使用的版本放在同一份紀錄中。如此才能分辨問題來自輸入、執行環境或專案本身，而不是將一次偶然成功誤認成穩定能力。對需要交接的團隊，這些項目也比抽象的功能描述更容易重現與審閱。

供應商選擇、模型路由與推理強度

第3節第1段：模型以 `provider/model` 形式指定。README 的範例包含 `codex -m "anthropic/claude-opus-5"`、`codex -m "google/gemini-3-pro"` 與 `codex -m "ollama/llama3"`。省略供應商前綴時，opencodex 會路由到預設供應商，或依模型名稱模式自動比對，例如 `claude-*` 到 Anthropic，`gpt-*` 到 OpenAI。路由後的模型會出現在 Codex App 的模型選擇器中，並帶有推理強度控制。README 解釋 `ultra` 與上游 Codex 的意義相同：它在用戶端啟用最大推理與主動多代理委派，實際請求以 `max` 送出。只有透過 `reasoningEfforts` 設定選擇加入的供應商才會廣告 `ultra`。GPT-5.6 Sol/Terra/Luna 會做為目錄項種子寫入 OpenAI API key 與 OpenRouter 預設，但實際可用性取決於上游預覽門控；opencodex 只準備路由與目錄中繼資料。

README 沒有提供的效能數字、相容矩陣或服務承諾，本文一律視為未知，不延伸成推測。 opencodex 的文件脈絡在本節特別落到第3個觀察點，讀者可從相同入口逐項比對，不應把其他專案的預設值套進來。這個檢查也能把文件宣稱和部署現象分開，避免只看標題或功能清單就下結論。實際記錄時，應把 opencodex 的命令列、設定檔路徑、輸出格式、失敗狀態與使用的版本放在同一份紀錄中。如此才能分辨問題來自輸入、執行環境或專案本身，而不是將一次偶然成功誤認成穩定能力。對需要交接的團隊，這些項目也比抽象的功能描述更容易重現與審閱。

ChatGPT 帳戶池：親和性、配額與故障轉移

第4節第1段：對於 Codex 認證，opencodex 可以管理一個 ChatGPT 與 Codex 帳戶池。既有執行緒保持其起始帳戶，因此長時間的 SSH、tmux 或行動裝置工作階段不會在對話中途切換帳戶。啟用自動切換後，新工作階段會比較 5 小時、每週與 30 天配額視窗中最熱的一個，並路由到使用量較低的合格帳戶。儀表板可以一次重新整理所有帳戶的配額，請求紀錄使用非 PII 帳戶序號標記池流量。令牌失敗採取 fail-closed 策略：它顯示需要重新認證，而不是靜默回退到另一個憑證；429 配額回應會將帳戶放入冷卻狀態，並允許故障轉移到另一個合格的池帳戶。還有 `openai-apikey` 模式，完全繞過帳戶路由，使用 API key 或 key 池。README 沒有說明池中可以容納多少帳戶，也沒有給出具體配額閾值。

和直接使用底層工具相比，opencodex 的取捨是少寫重複整合程式，但要接受它自己的目錄結構與操作模型。 opencodex 的文件脈絡在本節特別落到第4個觀察點，讀者可從相同入口逐項比對，不應把其他專案的預設值套進來。這個檢查也能把文件宣稱和部署現象分開，避免只看標題或功能清單就下結論。實際記錄時，應把 opencodex 的命令列、設定檔路徑、輸出格式、失敗狀態與使用的版本放在同一份紀錄中。如此才能分辨問題來自輸入、執行環境或專案本身，而不是將一次偶然成功誤認成穩定能力。對需要交接的團隊，這些項目也比抽象的功能描述更容易重現與審閱。

設定、遠端存取與解除安裝

第5節第1段：設定檔位於 `~/.opencodex/config.json`。如果檔案是無效 JSON，opencodex 會將其備份為 `config.json.invalid-<timestamp>` 並以預設值啟動，因此原始檔案不會悄悄消失。預設情況下，代理綁定到 `127.0.0.1`，不需要單獨認證。如果設定 `"hostname": "0.0.0.0"` 以在 LAN 上暴露，opencodex 會要求透過 `OPENCODEX_API_AUTH_TOKEN` 設定 bearer token，並用於管理 API 與資料平面路徑；沒有該變數則拒絕啟動。README 表示 token 比較以常數時間進行以減少時序攻擊。`ocx uninstall` 會停止代理、移除已安裝的服務與 shim、還原 Codex 設定/目錄/歷史，並刪除 `~/.opencodex`。有兩種自動啟動選項：使用作業系統服務管理員（launchd、systemd、Task Scheduler）保持常駐，或使用 codex shim 在每次 `codex` 呼叫時執行 `ocx ensure`。README 也描述了 resume 歷史重新對應，在代理使用期間保留舊的 OpenAI 執行緒，並在停止時將它們彈出。

升級時應對照 lidge-jun/opencodex 的 release 或主分支變更，尤其檢查命令名稱、設定檔格式及輸出欄位是否改動。 opencodex 的文件脈絡在本節特別落到第5個觀察點，讀者可從相同入口逐項比對，不應把其他專案的預設值套進來。這個檢查也能把文件宣稱和部署現象分開，避免只看標題或功能清單就下結論。實際記錄時，應把 opencodex 的命令列、設定檔路徑、輸出格式、失敗狀態與使用的版本放在同一份紀錄中。如此才能分辨問題來自輸入、執行環境或專案本身，而不是將一次偶然成功誤認成穩定能力。對需要交接的團隊，這些項目也比抽象的功能描述更容易重現與審閱。

授權、保固與供應商條款

第6節第1段：該儲存庫以 MIT 授權。授權摘錄授予使用、複製、修改、合併、發布、散布、再授權與銷售副本的權限，並聲明軟體按原樣提供，不提供任何形式的擔保，包括適銷性、特定用途適用性與非侵權性。README 補充聲明 opencodex 是一個獨立的社群專案，與 OpenAI、Anthropic 或其他供應商沒有關聯或背書。它警告某些供應商，尤其是 Anthropic，可能會暫停或限制透過第三方代理路由 API 流量的帳戶，並讓使用者自行檢查供應商的服務條款。README 與授權沒有建立任何支援承諾、正常運行時間保證或生產就緒聲明，除了 LAN 模式中提到的常數時間 token 比較。

若你的團隊需要完全不同的協定、部署方式或授權條件，opencodex 不會因 README 的功能清單而自動成為合適選項。 opencodex 的文件脈絡在本節特別落到第6個觀察點，讀者可從相同入口逐項比對，不應把其他專案的預設值套進來。這個檢查也能把文件宣稱和部署現象分開，避免只看標題或功能清單就下結論。實際記錄時，應把 opencodex 的命令列、設定檔路徑、輸出格式、失敗狀態與使用的版本放在同一份紀錄中。如此才能分辨問題來自輸入、執行環境或專案本身，而不是將一次偶然成功誤認成穩定能力。對需要交接的團隊，這些項目也比抽象的功能描述更容易重現與審閱。

編輯結論

適合需要 Universal provider proxy for OpenAI Codex & Claude Code, use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code. 所涵蓋工作流，且能管理其依賴與設定的使用者。不適合把未記載的相容性、效能或服務保證當成既定條件的團隊。採用前先依 lidge-jun/opencodex README 的實際入口執行最小流程，核對輸出、錯誤處理與設定檔，再決定是否納入正式系統。

官方來源

社群筆記