Gemini 4 Argon 怎麼用?Pro、Antigravity 與 API 遷移檢查
若 Gemini App 已經看到 Argon,Antigravity 卻顯示無法使用,或原本的免費 API 專案不能呼叫,應先核對入口資格。同一個模型出現在多個產品,資格與計費仍要逐一確認。
Gemini 4 Argon 的 API 模型名稱是 gemini-4-argon,導入時除了確認付費入口,也要重查輸出上限、thinking 與快取。 Google 在 10 月 13 日的公開推出公告區分了使用入口;本文於 2026-10-14 檢閱官方文件,未購買方案、登入讀者帳號或執行模型呼叫。
Pro 能用哪裡?先確認產品入口
| 要完成的工作 | 官方公開推出範圍 | 先查什麼 |
|---|---|---|
| 在 Gemini App 或 AI Mode 使用 | Google AI Pro 與 Ultra 訂閱者開始取得 rollout | 當前帳號、地區與模型選單 |
| 在 Antigravity desktop app/CLI 使用 | 官方推出文章列出 Ultra 與符合資格的 Gemini Enterprise 訂閱 | Antigravity 版本、方案與實際模型可用狀態 |
| 自己的程式透過 Gemini API 呼叫 | Gemini API paid tier;pricing 頁列出 Free tier 不提供 Argon | 專案的 API 付費資格與用量限制 |
Antigravity 的推出文章與 API pricing 頁描述各自的資格。API 文件寫的「不在 Google AI Pro plan 提供」,不能擴張成「Pro 在 Gemini App 也不能用」;反過來,App 有 Argon 也不能證明自己的 API 專案已有額度。
若帳號介面與公告不同,保存入口、方案、地區、App 版本與確認時間,再查該產品目前的說明。這份指南沒有驗證台灣個別帳號的 rollout,也不把尚未出現在模型選單裡的資格當成已開通。只想互動問答的讀者可先確認 App;要接進程式的讀者則從 API 專案資格開始,避免先升級了不對應需求的訂閱。
API 遷移最容易漏掉的三個邊界
輸入、thinking 與輸出共用一個視窗
模型規格列出 unified context window 為 1,048,576 tokens,預設同步輸出上限為 65,536。這個視窗要一起容納輸入、thinking 與輸出;不能放進接近一百萬 tokens 的資料後,再假設還有另一個獨立的一百萬輸出預算。
因此遷移記錄應同時保存輸入量、thinking level、輸出上限、完成狀態與實際 usage。模型回傳部分文字,不足以判定報告或修改任務已完整完成。輸入增加時,也要重新估算剩餘空間。
舊 sampling 參數與 explicit cache 不能照搬
遷移文件要求移除 temperature、top_p、top_k;Argon 會忽略這些參數。既有程式即使沒報錯,也不能再假設調整它們仍能控制輸出。
Explicit caching 不支援:原本建立 cachedContents 或在 request 引用 cached_content 的路徑要移除。Implicit caching 與明確建立 cache 是不同機制,不能保留舊的 cache ID 等待它自行相容。先找出哪些程式分支依賴舊快取,再確認移除後沒有漏掉原本應放入 prompt 的內容。
長輸出要改執行方式與完成判斷
官方 long decode 流程可透過 background execution 處理超過 64K 的輸出,並設定較大的 max_output_tokens。多個 continuation hop 會留下多個 model_output steps,結果整理要涵蓋所有 hop。不能只讀第一段就把工作標成完成。
這也改變逾時策略:前端短 timeout 不適合直接等待長推理工作。先保存 interaction ID,分開管理後端工作狀態與使用者等待畫面;若要重試,先確認原工作狀態,避免啟動第二份昂貴工作。一般 fetch 的取消界線可參考 逾時、本文讀取與 AbortSignal。
用小工作驗收,再提高輸出與推理預算
下面是依官方 Interactions API 格式縮小的 request body,供接到既有 API client;這是檢閱過的示意,沒有實際送出:
{ "model": "gemini-4-argon", "input": "檢查這份公開範例的取消流程,只列出可確認的問題。", "generation_config": { "thinking_level": "medium", "max_output_tokens": 32768 }}這是 Interactions API 的欄位,不能直接放進另一套 SDK 的 GenerateContent 設定而假設結構一致。要分析程式碼,還需把實際公開範例放進 input;上面的句子本身沒有附帶檔案,也沒有授予工具讀取 repository 的能力。
建議先選一個有已知答案、能確認完整性的非敏感工作,按以下順序驗收:
- 確認 API 專案可呼叫模型,記錄使用入口與模型名稱。
- 在相同輸入與完成標準下,比較
low、medium、high,記錄正確性、完成狀態、時間與 token 用量。 - 檢查錯誤路徑、快取移除後的 prompt,以及被忽略的舊參數;通過才接回原工作流。
- 任務確實需要長輸出時,再測 background、輪詢與多個 output steps 的組合,確認取消畫面與伺服器工作狀態不會混淆。
max_output_tokens 同時限制 thinking 與輸出,因此不能只把它當成「答案長度」。這裡選 medium 與 32,768 是小範圍導入的起點,未證明足夠完成任何真實 repository 任務。若要讓 coding agent 進一步改檔,還要沿用 可驗證的完成條件,核對 diff 與測試結果。
導入價到期後,要用另一組成本預算
Standard API pricing以每百萬 tokens、美元計價:
| 項目 | 至 2026-11-30 的導入價 | 2026-12-01 起 |
|---|---|---|
| Input | US$2 | US$4 |
| Output,包含 thinking | US$10 | US$20 |
| Implicit cache 命中的 input | US$0.10 | US$0.20 |
這是 Standard API 費率,其他 consumption option、grounding 工具與訂閱費用要分開核對。快取折扣也不能套到所有 input。
例如,假設一次工作有 10 萬個未命中快取的 input tokens,加上 2 萬個計費 output/thinking tokens,單純 token 成本在導入價下是 US0.80;此計算沒有包含 grounding、其他工具或稅費,也不是實際帳單。把到期前後兩種預算都放進試用紀錄,才能判斷這個工作流是否值得保留。
參考資料: