Antigravity + OmniRoute: Get FREE Unlimited AI Access (Never Run Out of Credits Again)
想用 Claude Code、Codex 或 Cursor，又唔想被單一供應商限額綁死，OmniRoute 提供咗一條幾務實的路。它把免費模型池、備援切換同壓縮節省 token 放埋一齊。
寫程式最怕做到一半先撞到配額上限，或者工具只綁死某一個模型。OmniRoute 把自己放在 AI gateway 呢個位置，直接處理多個 AI coding 工具同多個模型供應商之間的路由問題，重點唔係再造一個聊天介面，而係幫你維持請求可用、控制成本，並用 auto-fallback 減少中斷。
同類做法通常會主打單一 API 聚合，OmniRoute 的取向明顯更偏向「免費額度整合 + 路由策略 + 壓縮節流」。它聲稱可接到 237 個 providers，當中 90+ 提供 free tiers，並以 RTK + Caveman compression 把 token 消耗壓低 15% 至 95%。呢個方向的好處係對長提示、程式碼上下文同重複輸出較有幫助，但壓縮始終係取捨，所以它加咗 inflation guard，遇到壓縮後反而變長，就會送回原文。
OmniRoute + OpenCode: 100% Free AI Coding Setup, Free AI Gateway
New FREE Unlimited AI Coder | OmniRoute
你可以把它理解成放在 Claude Code、Codex、Cursor、Cline、Copilot、Antigravity 後面的中介層。部署後，工具經同一個 endpoint 出請求，再由 OmniRoute 分配到 Claude、GPT、Gemini 及其他供應商；README 也提到每個模型會列出本月已用與剩餘額度，並標示 provider terms，這點對團隊控管比較有用。
幾個值得留意的重點：
– 定位屬於工具 / 閘道型軟件，解決的是多模型切換、免費額度整合同配額中斷
– 支援 Claude Code、Codex、Cursor、Cline、Copilot、Antigravity，適合多工具並行的開發流程
– 以 documented free tokens/month 作招徠，現有資料提到穩定約 1.6B，首月可到 2.1B
– 內建 17 routing strategies，並加入 auto-fallback，減少單一 provider 失效帶來的停頓
– 壓縮模組已針對 German、French、Japanese、Chinese，以及 Gradle、.NET 輸出做過強化
受益最大的一般會係重度依賴 AI 編碼助手的個人開發者、細團隊，同想把成本壓到最低的實驗性項目。要留意的是，免費池本身受各 provider 條款影響，OmniRoute 雖然強調統計方式較透明，但效能與穩定性仍然建基於外部服務；它較像一個把資源調度做得更聰明的控制層，而唔係保證品質一致的模型平台。
想令 coding agent 越跑越準，呢個項目用聊天指令就可以反覆試錯、驗證同回滾。它不是再訓練模型，而是直接改進 skill 與 agent 流程。
不少人用 coding agent 時，卡位不在模型本身，而在 prompt、skill 文件同執行流程點樣一路修正。SkillOpt-Lite 連同 HarnessOpt 就是針對這個位置而來的 Agentic 工具：把評測、修改、驗證同回滾包成兩個 slash command，讓 coding agent 在對話環境內自動迭代改善。
它反對一種常見範式：每次表現不好，就手動改 prompt、重跑少量樣本，再憑感覺決定有沒有進步。作者改用 looped improvements 配合 validation-gated rollback，先跑一批 scored rollouts，將失敗樣本交回 coding agent 修補，再用 val split 決定保留還是還原；焦點不是 fine-tuning，也不是增加 inference-time overhead，而是把現有 agent workflow 系統化地優化。
部署理解上，這個項目不是叫你在 shell 逐步砌環境，而是把 repo 資料夾直接開進支援 .github/prompts/*.prompt.md 的 coding agent，例如 VS Code Copilot Chat、Codex CLI、Claude Code。環境安裝、驗證、資料下載由 agent 協助處理；現成 benchmark 包括 LiveMath、SpreadsheetBench、ALFWorld、DocVQA、OfficeQA 同 SearchQA，亦支援帶入自家 repo 與資料格式。
- SkillOpt-Lite 只改
skill.md，適合先驗證 prompt/skill 層面的改善 - HarnessOpt 連 agent harness 一起改，包括 rollout、react-agent、executor 等程式部分
- 以 val gate 決定保留或回滾，比單看一次 train 結果更穩陣
- 官方重點是「no fine-tuning, no inference-time overhead」，取向明顯偏向低成本迭代
跟同類做法相比，它的差異不在於推出新模型，而是把「由 agent 自己根據失敗紀錄修補自己」做成可重覆流程。公開內容提到在 6 個 benchmarks 有結果，亦展示過 GPT-5.4-nano 配合 HarnessOpt 可超過較高階模型配標準 harness 的情況；不過現時較依賴 coding agent 工作流，最適合做 agent 評測、提示工程、內部工具自動化的團隊，而不是單純想下載一個模型即用的人。相關模型與目標例子則包括 GPT-5.4-nano、GPT-5.5，以及各種可讀取 prompt 檔的 coding agents。
模型識幾多，未必等於學得幾快。EdgeBench想回答的，是智能體在真實環境中隨時間互動後，能力會怎樣上升。
跑一次就評分的基準，通常只能看出模型本身已經識乜；EdgeBench關注的是另一件事：當智能體放進接近真實工作的環境，連續做十幾個鐘、接收回饋再反覆修正，它究竟會唔會愈做愈好。這是一個研究 environment learning 的 benchmark，核心問題不是單次答對率，而是學習曲線能否反映長時間互動後的能力變化。
它把 134 個任務分成六大類，包括科學與機器學習、系統與軟件工程、組合最佳化、知識工作、形式數學同遊戲，而且每個任務最少運行 12 小時，部分延伸到 72 小時以上。這個設計接近真實工作流，因為智能體需要面對 build logs、test failures、objective values、simulator traces、實驗誤差等回饋，而唔係只靠一次生成結果交卷。
同常見 benchmark 相比，EdgeBench的差異在於它量度「隨經驗累積而改善」的能力。研究者指出，多個模型在 134 個任務上的整體表現，都可用 log-sigmoid function 擬合，R²約為 0.997 至 0.999，表示 environment interaction time 與表現提升之間有相當穩定的關係。這令它不只是一張排行榜，也是一個用來觀察 scaling laws of environment learning 的分析工具。
- 覆蓋 134 個真實世界長時任務，重點放在學習速度與上限
- 任務橫跨科學、編程、最佳化、知識工作、數學與遊戲
- 每項任務持續 12 小時以上，部分超過 72 小時
- 回饋訊號來自接近真實工作的執行環境，而非單次靜態題目
- 整體學習曲線可用 log-sigmoid function 高精度擬合
這套 benchmark 對做 Agentic 項目、長流程自動化、程式代理與研究型智能體的人最有參考價值，因為它直接呈現模型在長時間任務中的耐力、修正能力與邊做邊學的幅度。現有資料集中在 benchmark 設計、任務結構、資料集與分析結果，未提供具體安裝步驟或完整使用流程；能確定的是，這個項目由 ByteDance Seed 發表，並附有 Paper、GitHub 與 Dataset 入口。
open-design 是一款本地優先的桌面應用，讓 AI 編碼代理直接生成設計稿、頁面與多媒體內容。
open-design 是一款本地優先（local-first）的開源桌面應用程式，主打讓 AI 編碼代理（coding agent）直接充當設計引擎，協助用戶快速產出原型設計（prototypes）、登陸頁面（landing pages）、儀表板（dashboards）、投影片、圖片甚至影片等各種多媒體素材，並輸出真實可用的檔案。這個項目的定位是 Claude Design 的開源替代方案，強調在桌面環境中本地執行，無需依賴雲端服務即可完成設計工作。
與傳統的設計工具相比，open-design 的最大差異在於將 AI 編碼代理作為核心驅動力，用戶可以透過自然語言指令讓代理直接生成設計內容，省去手動拖拽元件的繁瑣流程。從 GitHub 上的數據可見，該項目已獲得超過 7.5 萬顆星及 8 千多次 fork，社群關注度相當高，顯示開源社群對本地化 AI 設計工具的強烈需求。
這個項目最適合需要快速產出網頁原型或行銷素材的開發者、設計師及內容創作者。對於重視資料隱私、希望在本地環境完成設計工作的人來說，local-first 的架構尤為吸引。開發者亦可將其整合到現有的編碼工作流中，讓 AI 代理同時負責程式碼與設計兩個層面。
以下是這個項目的重點摘要：
- 屬於本地優先的開源桌面應用，定位為 Claude Design 的替代方案
- 核心功能是讓 AI 編碼代理生成設計稿、頁面、儀表板及多媒體內容
- 強調本地執行，無需依賴雲端服務，保障資料私隱
- 適用於開發者、設計師及內容創作者快速產出原型與行銷素材
- 社群關注度高，GitHub 上已累積超過 7.5 萬顆星
由於該項目仍處於活躍開發階段，功能成熟度與跨平台支援等細節尚未完全明朗，建議有興趣的使用者持續關注其更新進度。
以下是該網頁主要內容（麻省理工學院電子工程與計算機科學系 MIT EECS 的訪談文章）的繁體中文翻譯：
(more…)PAW（programasweights-python） 不是一般 LLM 封裝，而是把文字需求變成可離線執行的小型神經函數。它瞄準規則難寫、又不想長期依賴 API 的文字處理工作。
PAW(programasweights-python)是一個 Python 工具兼研究原型，屬於把「自然語言」規格編譯成小型神經函數的項目。它要解決的是一類很難用正則表達式或硬編碼規則寫穩定的工作，例如修復壞掉的 JSON、模糊搜尋、分類、抽取欄位，以及把文字意圖對應到正確操作。
現有做法通常有兩條路：一條是手寫規則，遇到錯字、格式飄移同邊界情況就容易失準；另一條是把每次輸入都送去 LLM API，換來較高彈性，但會帶來網絡依賴、成本同重現性問題。Program-as-Weights（PAW）提出的做法，是先用一個 compiler 把英文描述編譯成可重用的神經程式，之後每次呼叫都在本機執行，定位由「每次都問模型」改成「先造好工具再反覆用」。
安裝路線相當直接：Python 端可透過套件取得預編譯函數，亦可自行 compile；瀏覽器端則有 @programasweights/web，但只限用 paw-4b-gpt2 這條較細的 runtime。部署取捨也寫得清楚，paw-4b-qwen3-0.6b 準確度較高，程式體積約 22 MB，本地推理約 0.05 至 0.5 秒；paw-4b-gpt2 準確度較低，但程式只有約 5 MB，支援 WebAssembly，較適合前端或輕量分發。
項目的技術定位：作者把這類問題稱為 fuzzy-function programming，並釋出 FuzzyBench 這個 10M examples 數據集，用 4B compiler 為 frozen interpreter 產生 parameter-efficient adapters。文中指出，0.6B Qwen3 interpreter 執行 PAW 程式時，效果可接近直接 prompting Qwen3-32B，同時把推理記憶體壓到約五十分之一，並在 MacBook M3 達到 30 tokens/s；這些數字有助理解它不是單純包裝模型，而是在成本、可重用性與離線能力之間重新分配。
- 核心價值：把一次性的自然語言需求，轉成可重複呼叫的本地函數
- 適合情境：日誌分流、格式修復、文字分類、資料抽取、意圖路由
- 主要取捨：比直接調用大型 API 更可控、可離線，但編譯器與 runtime 選型會影響準確度與體積
- 相關模型：
paw-4b-qwen3-0.6b、paw-4b-gpt2，論文亦以 Qwen3-32B 作對照 - 受益團隊：重視本地執行、穩定輸出、低成本重複推理的開發團隊會較易受惠
這個項目最適合放在「規則太脆弱、API 又太重」的中間地帶。它未必取代通用 LLM，但對一批固定任務而言，先編譯、後離線執行的方式更像真正可落地的工程工具。
這個項目專注減少 AI agent 的 token 消耗，同時盡量保留答案品質。它適合想降低成本、加快回應的開發團隊。
Headroom 是一個給 AI agents 與 LLM 應用使用的庫兼代理工具，核心角色是把送進模型前的上下文做壓縮。它主要解決長對話、工具輸出、日誌、RAG 片段與檔案內容太長，令 token 成本、延遲與上下文容量很快爆滿的問題。
這個項目不只提供 Python 與 TypeScript 內嵌式 compress(messages) 用法，亦提供 proxy 模式與 MCP server，代表它可以直接插入現有流程，未必需要大改程式。README 提到 zero code changes 的代理方式，對已有多語言系統的團隊尤其實用；另外它走 local-first 與 reversible 路線，取向明顯是先保留可控性，再追求節省 token。
和一般只縮短輸入文字的做法相比，Headroom 的差異在於它同時處理模型輸出，會減少重複客套、重述程式碼，以及在例行步驟略過過深的「thinking」。這種取捨有助壓低來回 token，但也代表較依賴它對內容重要性的判斷；對需要完整推理痕跡或逐字保留輸出的流程，部署前應先做回歸測試。
結果列出的數字是 60–95% fewer tokens，示例亦有 10,144 壓到 1,260 tokens，同時保留相同問題結論；不過這些結果較適合視為官方展示，具體效果仍會受任務類型影響。較容易受益的情境包括多步驟 agent、跨工具調用、RAG 對話系統，以及 Claude、Codex、Gemini 之間需要共享記憶的團隊協作流程。
- 支援 Library、Proxy、MCP server 三種接入方式
- 可壓縮對話、工具輸出、logs、RAG chunks 與檔案內容
- 提供 cross-agent memory，支援 Claude、Codex、Gemini 共用與去重
headroom learn會整理失敗 session，寫入 CLAUDE.local.md、CLAUDE.md、AGENTS.md 或 GEMINI.md- 相關模型包括 Kompress-v2-base，而整體定位較接近 agent 基礎設施，不是單一聊天模型
整體來看，Headroom 最有價值的地方不在於再做一個包裝 LLM 的介面，而是把「上下文壓縮」獨立成基礎層。對經常被 token 成本、上下文長度與 agent 記憶雜訊拖慢的項目，它屬於值得優先測試的一類工具。
這是一個提升機械人操控穩定性的研究方法。它用模擬訓練的殘差策略，零樣本補強真實世界的 VLA 表現。
這是 Microsoft Research 的 Object-Centric Residual RL 方法。它的用途是為 Vision-Language-Action（VLA） 模型加入一層修正策略，減少機械人在真實操控中因細小誤差累積而失手的情況。
核心做法是把一個已凍結的 base VLA 保留不變，再額外疊加一個輕量 residual policy。這個 residual policy 完全在模擬環境訓練，輸入不是原始影像，而是 object-centric state、proprioception，以及 base VLA action，藉此避開常見的 visual sim-to-real gap，令策略可直接 zero-shot 轉移到真實機械人。
這個方法處理的是 imitation learning 常見的脆弱性：示範資料未覆蓋到的狀態一旦出現，誤差會一路放大。與直接微調 VLA、或在真實世界再做 reinforcement learning 相比，這個方法的差異在於只學「修正量」，而且訓練放在模擬中完成，成本與風險都較低。
- 保留 frozen base VLA，不用重訓整個模型
- residual policy 以物件中心狀態為主，減少依賴影像對齊
- 目標是 zero-shot sim-to-real enhancement
- 適合需要精準抓取、放置或接觸操作的機械人工作流
這類方法較適合關注 VLA、Robotic 與 sim-to-real transfer 的研究者和開發者。現有資料清楚交代方法方向與問題設定，但未提供完整安裝流程或操作步驟；評估部分可確認作者以真實機械人成功率改善作為重點，更多數值細節仍需參考原始論文。
一份聚焦於「看圖寫程式」的論文清單，涵蓋 UI、圖表、SVG、CAD 等多模態程式碼生成的研究與基準。
Awesome-Multimodal-LLM-for-Code 是一份論文整理型資源庫（paper list / survey collection），專門蒐集「多模態大型語言模型（Multimodal LLM, MLLM）用於程式碼生成」相關的研究論文、基準測試與評估方法，核心任務是把「視覺輸入」與「程式碼輸出」串接起來，例如把 UI 截圖、圖表、SVG 向量圖、CAD 草圖轉成可執行的程式碼。
傳統的 text-to-code 研究主要處理純文字描述生成程式碼，但很多真實任務的意圖是透過圖片、影片或互動畫面來表達的，純文字範式無法處理版面配置、視覺語意與互動行為等約束。這個資源庫把研究切成清楚的子題，包括 Web/Mobile UI 程式碼生成、科學圖表程式碼生成、視覺豐富的程式設計題、SVG 生成、簡報生成、UML、CAD、海報、3D 點雲、遊戲程式碼，以及程式修復等，方便研究者按場景查找對應論文。
與一般 Awesome 列表相比，這份資源的差異在於聚焦於「視覺證據如何影響程式正確性」，並收錄了 Design2Code、ChartMimic、Chart2Code、StarVector、PPTAgent、ScienceAgentBench 等具代表性的基準測試與模型。從支援資料可以看到，附帶的 survey 論文進一步把領域分成 GUI、科學視覺化、結構化圖形與前沿任務四大類，並指出視覺相似度不足以評估正確性，還需要語意、互動與領域約束的證據。
對前端工程師、資料視覺化研究者、AI 程式碼助手開發者，以及做 benchmark 設計的人特別有用，能快速掌握 MLLM 在程式碼任務上的最新進展與評測方法。
重點摘要：
- 屬於論文整理資源庫，聚焦多模態程式碼生成
- 涵蓋 UI、圖表、SVG、CAD、簡報、3D 等十多個子題
- 收錄 Design2Code、ChartMimic、ScienceAgentBench 等基準
- 強調視覺相似度不足以評估程式正確性
- 原始資料未提供安裝或部署方式，僅供論文索引與閱讀
GitHub： https://github.com/xjywhu/Awesome-Multimodal-LLM-for-Code
Interactions API 讓開發者用同一介面連接 Gemini 模型與 agents。它重點解決多種互動方式分散、整合複雜的問題。
Gemini Interactions API 是實驗性 API，可讓開發人員使用 Gemini 模型建構生成式 AI 應用程式。Gemini 是 Google 最強大的模型，打從設計之初就具有多模態的特質。可歸納內容，完美解讀、操作及結合語言、圖片、音訊、影片和程式碼等不同類型的資訊。您可以使用 Gemini API 處理各種用途，例如：跨文字和圖片進行推論、生成內容、對話式代理程式、摘要和分類系統等。
這是一個供開發者使用的 API，屬於 Google AI Studio 的 Interactions API。它的主要用途，是用一個統一介面去操作 Gemini models 與 agents，方便把模型回應、工具呼叫和代理人流程放在同一套工作流內處理。
和一般逐步拼接多個端點的做法相比，較值得留意的是它主打「統一」：同時面向模型和 agents，減少來回切換不同介面的負擔。這對要做多步驟互動、工具協調、或需要把 AI 行為包成穩定流程的團隊會更實用。
- 統一處理 Gemini models 與 agents
- 適合原型、整合與工作流測試
- 方便把模型回應與工具呼叫串接
- 較適合開發者與 agent 應用場景
項目主頁： blog.google