OmniRoute:MIT 開源 AI 閘道,358 家供應商、1200+ 模型與 Token 壓縮
OmniRoute 是 MIT 授權的開源 AI 閘道,用一個端點把 Claude Code、Codex、Cursor 等工具接入 358 家供應商,其中 150 多家有免費額度。它按共享池去重,估算每月約 16.2 億免費 token,並以 19 種路由策略、自動回退和 RTK 加 Caveman 壓縮(自報平均省約 89%)降低成本與中斷風險。
OmniRoute 是一個以 MIT 授權開源的 AI 閘道,作者是 diegosouzapw。它的主張很直接:讓 Claude Code、Codex、Cursor、Cline、Copilot 和 Antigravity 這類編碼工具,透過同一個端點,接入 358 家模型供應商(專案標題寫作 359 家、1200 多個模型),其中 150 多家提供免費額度,額度用盡時自動回退到下一家。它給出的頭條數字是每月約 16.2 億免費 token,起步成本為零。這個數字很搶眼,所以值得先弄清它是怎麼算出來的,再判斷它有多少分量。 README 揭露的算法比行銷口號克制得多。專案編目了 489 條免費層條目,歸併為 35 個循環額度池。頭條數字只統計其中 17 個有公開、為正的月度預算的池,外加 Groq 的五個按模型上限,並且按共享池去重,同一個池只算一次。需要先通過地區身分核驗才能開通的額度,目前是 ModelScope,約 600 萬,被單獨列出,不計入頭條。首月疊加註冊贈送額度,上限約 22.2 億。預算條裡點名的大宗包括 Mistral 的 10 億、Nara 的 2.1 億、LLM7 與 xKiro 各 1.5 億,以及 Groq 五個模型上限合計 3000 萬。另有 13 家供應商在條款風險目錄中被標為「避免」,交給使用者自己決定。專案還承諾每兩週對照即時目錄複核一次,數字會漲也會跌。這套做法的價值在於透明:免費層真正的難題不是找不到,而是看不清。
在路由與成本這一側,OmniRoute 提供 19 種路由策略,並在上游額度耗盡或出錯時自動切換。它還疊加了 RTK 與 Caveman 兩層壓縮,宣稱可節省 15% 到 95% 的 token,平均約 89%。壓縮發生在閘道內部,上游工具無需改動。這裡需要冷靜讀數:89% 是專案自報的平均值,實際收益取決於負載。重複的工具輸出、冗長的日誌和樣板上下文壓縮空間很大,而高密度的程式碼推理與新穎的需求描述壓縮空間小得多。把它當成上限參考,用自己的真實會話去測,比直接相信平均值可靠。把視線從數字移開,看工程細節,會更清楚它解決的是哪一類問題。多家供應商意味著多種介面方言、多套認證方式、多種限速語意:有的按每分鐘請求數限流,有的按每日 token 總量,有的按單個模型設上限。閘道要做的,是把這些差異摺疊成一個統一的呼叫面,同時記住每個池還剩多少、何時重置。19 種路由策略正是為此而設,它們讓開發者可以按延遲、成本、額度餘量或模型能力來決定下一跳,而不是把選擇權交給運氣。自動回退則把失敗變成一次內部重試,上層的編碼工具看到的只是一次略慢的成功回應。對長時間執行的智能體任務來說,這比任何單點的穩定性承諾都更實用,因為中途斷流的代價通常是整段上下文重來。
從架構角度看,這個專案的意義在於把「閘道」推成了編碼智能體的控制面。編碼智能體的用量模式很特殊:會話長,工具呼叫多,上下文反覆重放,對額度極其敏感,也最容易在中途撞上限流。一個懂配額、懂協定差異、能在失敗時無縫換路的中間層,把「選哪家模型」這件事從每個工具的設定裡抽出來,集中到一處管理。開發者不再為每個工具單獨設定十幾個金鑰和限速規則,而是面對一個端點、一塊儀表板。MIT 授權意味著可以自行託管並審計這層程式碼,這對一個會經手提示詞的元件尤其重要。 放到產業背景裡看,OmniRoute 反映了一種正在成形的分工:模型供應商競爭能力與價格,而「如何用好這麼多供應商」正在成為獨立的一層基礎設施。免費層本來是獲客手段,被系統化地聚合之後,它變成了一種可被調度的公共算力池。這對學生、獨立開發者和資源有限的小團隊意義最大,因為它降低了試驗智能體工作流程的門檻。但它同時提醒我們,免費額度的可持續性取決於供應商的商業選擇,聚合層越成功,越可能促使供應商調整規則。因此,更穩妥的讀法是把它看作一個觀察窗口和一套可遷移的工程模式,而不是永久免費的承諾。對團隊而言,真正可以長期受益的部分,是把額度監控、回退邏輯和路由策略沉澱為自己的基礎設施能力,這些能力無論免費層如何變化都不會過時,也能遷移到付費供應商的場景中。換句話說,閘道裡最值錢的是經驗,而不是那串數字。
當然,風險同樣集中。第一,免費層條款隨時會變,供應商收緊政策時,依賴它的工作流程會立刻受影響,專案自己也承認數字會雙向變化。第二,提示詞裡常含原始碼與內部上下文,經閘道轉發到數十家第三方,資料流向比單一供應商複雜得多。第三,金鑰與路由設定集中後,閘道本身成為高價值目標,需要按正式環境元件對待。務實的做法是:把它用在開源或非敏感的專案上,把敏感倉庫路由到自有或付費的可信供應商,並持續關注 /dashboard/free-tiers 上的即時額度。對多數個人開發者與小團隊,它是一次把免費算力變成可管理資產的認真嘗試,值得今天就拉下來試用。
Sources
FAQ
OmniRoute 號稱每月約 16.2 億免費 token,這個數字可信嗎?
它比口號克制。專案編目 489 條免費層條目,歸併為 35 個額度池,只統計 17 個有公開正向月度預算的池加 Groq 的五個按模型上限,並按共享池去重。需地區身分核驗的額度(如 ModelScope,約 600 萬)單列不計入。數字每兩週複核,會漲也會跌,應視為估算而非保證。
RTK 加 Caveman 壓縮真的平均省 89% token 嗎?
89% 是專案自報的平均值,範圍 15% 到 95%。重複的工具輸出、長日誌和樣板上下文壓縮空間大,高密度程式碼推理壓縮空間小。建議用自己的真實會話測量,把平均值當作上限參考。
把程式碼提示詞經 OmniRoute 轉發到多家免費供應商安全嗎?
有風險。提示詞常含原始碼,轉發給多家第三方使其資料流向更複雜,閘道集中保存金鑰也成為高價值目標。建議用於開源或非敏感專案,敏感倉庫走自有或可信的付費供應商,並自行託管審計 MIT 程式碼。