TL;DR
Grok Build 0.1 是 xAI 面向代理式軟體工程的程式碼專用模型，而非一般的聊天機器人對話用途。於 2026 年 5 月 29 日以公開測試版釋出到 xAI API，重點在於網頁開發、偵錯、工具呼叫、MCP 工作流程與自主式編碼代理。
該模型提供 256,000 標記的上下文視窗，可接受文字與影像輸入，支援推理、結構化輸出與函式呼叫；標準費率為每百萬輸入標記 $1、每百萬輸出標記 $2。其強項不是單次程式碼補全，而是多步驟工作流程：代理檢視儲存庫、編輯檔案、呼叫工具、執行測試，並迭代直到獲得經驗證的結果。
關鍵差異很簡單：Grok Build 是編碼代理產品，而 grok-build-0.1 是可透過 API 在其他代理式編碼框架內運行的模型。Grok Build 0.1 API in CometAPI 亦已上線，透過相容 OpenAI 的閘道提供相同模型 ID。
Key Takeaways
- Grok Build 0.1 針對代理式編碼、儲存庫作業、偵錯與工具驅動的軟體工程進行最佳化。
- 其 API 模型 ID 為
grok-build-0.1，具備 256K 上下文視窗與文字與影像輸入。 - 短上下文的 xAI 定價為每百萬輸入 $1、每百萬快取輸入 $0.20、每百萬輸出 $2。Grok Build 0.1 API in CometAPI 價格低 20%，為每百萬輸入 $0.80、每百萬快取輸入 $0.16、每百萬輸出 $1.60；達到或超過 200K 門檻的請求採用較高的長上下文費率。
- 支援推理、函式呼叫與結構化輸出，但不支援 Batch API。
- 評估時應以每個成功完成的工程任務之成本與耗時為準，而非僅看標記單價或單一基準。
What Is Grok Build 0.1?
Grok Build 0.1 是一款圍繞代理式軟體工程工作流程設計的 xAI 專用語言模型。據 xAI 表示，其訓練針對網頁開發、偵錯與支援 MCP 的編碼代理等任務，並曾為最初的 Grok Build 編碼環境提供動力。
此定位使其有別於傳統的通用型助理。編碼代理必須反覆檢視儲存庫、識別相關檔案、呼叫工具、編輯程式碼、執行測試、閱讀失敗訊息，並在不丟失任務狀態的情況下修訂實作。
因此，有意義的評估單位是端到端工程任務：儲存庫導覽 → 規劃 → 編輯 → 工具執行 → 失敗恢復 → 驗證。
Is Grok Build 0.1 the Same as Grok Build?
不是。Grok Build 是 xAI 的基於終端機的編碼代理，而 Grok Build 0.1 是可透過 API 調用的底層模型。
Grok Build 包含規劃審查、程式碼差異、支援 AGENTS.md、外掛、掛鉤、技能、MCP 伺服器、平行子代理、worktree 整合，以及用於自動化的無頭模式。該模型也可在該終端機產品之外，於相容的代理框架與閘道中使用。
What Are the Grok Build 0.1 Specifications?
| 規格 | Grok Build 0.1 |
|---|---|
| 開發方 | xAI / SpaceXAI |
| 模型 ID | grok-build-0.1 |
| 主要重點 | 代理式編碼與軟體工程 |
| 輸入 / 輸出 | 文字與影像輸入；文字輸出 |
| 上下文視窗 | 256,000 標記 |
| 能力 | 推理、函式呼叫、結構化輸出 |
| 標準標記定價 | $1.00/M 輸入；$0.20/M 快取輸入；$2.00/M 輸出 |
| 長上下文門檻 | 200K 提示標記 |
| 長上下文定價 | $2.00/M 輸入；$0.40/M 快取輸入；$4.00/M 輸出 |
| Batch API | 不支援 |
| 已記載限制 | 37 次/秒；10,000,000 標記/分鐘 |
| 區域 | us-east-1, us-west-2 |
上述規格載於官方 xAI 模型頁面。256K 上下文視窗可容納大量儲存庫內容；影像輸入則讓代理能與螢幕截圖、模型圖、架構圖與視覺化錯誤回報搭配原始碼一同處理。
一旦提示達到長上下文門檻，本次請求的所有標記均適用較高費率。因此，重度倚賴儲存庫的代理應壓縮或選擇性擷取上下文，而非持續附加檔案與工具輸出。
What Makes Grok Build 0.1 Different?
以代理式編碼為主要優化目標
Grok Build 0.1 不只是能撰寫 Python 或 JavaScript 的模型。其專長在於推理、程式碼產生與工具之間的互動。實用的編碼代理必須規劃、檢視、編輯、執行、從失敗中恢復，並持續進行而不丟失任務狀態。
面向 MCP 的工具工作流程
面向 MCP 的工作流程可將編碼代理透過標準化介面連接至資料庫、部署系統、文件庫、議題追蹤、可觀測性系統與內部開發工具。
結構化自動化
當代理需回傳可預測的物件而非散文時（例如檔案變更計畫、工具參數、測試結果、審查發現或部署決策），結構化輸出能降低模型與編排層之間易碎的解析。
支援網頁與 UI 工作的視覺上下文
由於模型可接受影像輸入，代理得以在原始碼之外處理螢幕截圖、已渲染頁面、介面參考、錯誤對話框與架構圖。
How Fast Is Grok Build 0.1?
xAI 在發佈時將 Grok Build 0.1 描述為其速度最快的編碼模型，並宣稱每秒超過 100 個輸出標記。這是官方服務聲稱，並非對每個提示或端點的保證。
獨立量測應視為帶時間戳的觀察值。Artificial Analysis 目前回報，在 SpaceXAI API 上約為 69.6 個輸出標記/秒，首個標記時間 0.54 秒。供應商基礎設施、提示長度、推理行為、工具使用與伺服器負載都可能影響結果。
How Should You Interpret the Benchmarks?
| 獨立指標 | 目前回報值 | 解讀 |
|---|---|---|
| Artificial Analysis Intelligence Index | 27，估計值 | 綜合估計；獨立評測仍標示為即將發布 |
| 輸出速度 | 69.6 tokens/s | 在第一方 SpaceXAI API 上於第一個回應區塊之後測得 |
| 首個標記時間 | 0.54 s | 端點延遲測量；非任務總完成時間 |
上述數據已於 2026 年 9 月 22 日對照 Artificial Analysis 檢核。由於頁面動態更新，未來版本應重新核對數值並保留驗證日期。
對於自主式編碼系統，基準分數只是評估的一部分。儲存庫導覽、編輯精度、工具選擇、恢復行為、測試紀律、延遲與總標記用量對開發效率往往更為重要。
How Much Does Grok Build 0.1 Cost?
Grok Build 0.1 採用短上下文與長上下文的分級費率。當提示長度低於 200,000 標記時套用短上下文費率；一旦達到門檻，則本次請求改採較高的長上下文費率。
| 定價層級 | CometAPI | xAI 官方 |
|---|---|---|
| 短上下文輸入 | $0.80/M | $1.00/M |
| 短上下文快取輸入 | $0.16/M | $0.20/M |
| 短上下文輸出 | $1.60/M | $2.00/M |
| 長上下文輸入 | $1.60/M | $2.00/M |
| 長上下文快取輸入 | $0.32/M | $0.40/M |
| 長上下文輸出 | $3.20/M | $4.00/M |
在短上下文費率下，一百萬輸入標記加上一百萬輸出標記，透過 CometAPI 的成本為 $2.40，相較 xAI 官方 API 的 $3.00 更低。在長上下文費率下，相同標記組合透過 CometAPI 為 $4.80，而 xAI 為 $6.00。以上僅為模型標記成本；實際上線預算還應包含工具呼叫、重試、測試執行與編排開銷。
Grok Build 0.1 vs Grok 4.7 vs Grok Code Fast 1
| 維度 | Grok Build 0.1 | Grok 4.7 | Grok Code Fast 1 |
|---|---|---|---|
| 生命週期 | 當前的程式碼專用模型 | 當前的前沿模型 | 前一代編碼模型；已於 2026 年 5 月 15 日退役 |
| 主要定位 | 專用的代理式編碼模型 | 前沿編碼、代理式任務與知識型工作 | 快速編碼模型，屬 xAI 編碼模型系譜的前代 |
| 上下文視窗 | 256K | 500K | 舊版規格；不應作為新部署的依據 |
| 推理與工具 | 推理、函式呼叫、結構化輸出 | 可設定的推理；函式呼叫、網路搜尋、X 搜尋與程式碼執行 | 舊版編碼工作流程；應遷移，而非擴大新的生產用途 |
| 官方短上下文 輸入/輸出 | 每 M 標記 $1.00 / $2.00 | 每 M 標記 $2.00 / $6.00 | 已退役；不應假設有當前生產費率 |
| CometAPI 短上下文 輸入/輸出 | 每 M 標記 $0.80 / $1.60 | 每 M 標記 $1.60 / $4.80 | 請使用當前目錄與替代模型，而非已退役的識別代號 |
| 官方長上下文 輸入/輸出 | 每 M 標記 $2.00 / $4.00 | 每 M 標記 $4.00 / $12.00 | 作為當前模型選擇的定價不適用 |
| 典型適配 | 高頻儲存庫迭代、偵錯與成本敏感的編碼代理 | 更困難、執行時間更長且需要更強前沿推理與更大上下文的編碼與專業工作流程 | 僅供遷移參考；對當前編碼工作請鎖定 grok-build-0.1 |
當重複的儲存庫檢視、編輯與測試主導工作量時，Grok Build 0.1 是更具經濟性的專家型選擇。Grok 4.7 提供近兩倍的上下文與更廣的前沿能力，但其輸出標記價格顯著更高。實務決策應基於每個成功完成任務的總成本，包括重試、工具呼叫與人工修正時間。
兩者皆可在 CometAPI 取得，讓團隊能透過同一閘道執行相同的編碼任務，並在一致的控制框架下比較完成率、延遲、上下文使用與總成本。
How Is Grok Build 0.1 Related to Grok Code Fast 1?
識別代號 grok-code-fast-1 已包含於 xAI 於 2026 年 5 月 15 日的模型退役名單中。遷移指南包含一則概述，指稱已退役的 slug 將導向 grok-4.3；而其模型對應替代表與「Code workloads」章節則建議 grok-build-0.1，並指出該編碼 slug 會路由至該模型。
由於同一份官方指南在兩個層級描述了導向，生產使用者不應將已退役的 slug 視為穩定的模型識別符。請對編碼工作明確鎖定 grok-build-0.1，並在部署前驗證當前路由。
Grok Build 0.1 API in CometAPI 可在現行模型 ID 下直接存取，避免依賴已退役的別名。
Where Can You Use Grok Build 0.1?
這意味著模型不綁定於單一 IDE 或供應商端點。透過 CometAPI，團隊可在相容 OpenAI 的工作流程中使用相同的 grok-build-0.1 識別符，並與其他編碼模型比較，而不需重建周邊的代理控制器。
Grok Build 0.1 可透過 xAI 或 CometAPI 呼叫。對於 CometAPI，請以授權的 POST 請求送至 api.cometapi.com/v1/chat/completions，指定 model: "grok-build-0.1" 與標準的 messages 陣列。
curl "https://api.cometapi.com/v1/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $COMETAPI_KEY" \
-d '{
"model": "grok-build-0.1",
"messages": [
{
"role": "user",
"content": "Find the bug in this repository and propose a minimal fix."
}
]
}'
When Should You Use Grok Build 0.1?
IDE 編碼代理
其編碼專精與較低標記定價適合代理反覆讀取、編輯與驗證程式碼的互動式工作流程。
自動化偵錯
代理可檢視錯誤、搜尋相關檔案、產生修補、執行測試並精修修復。
網頁與 UI 開發
影像輸入讓以螢幕截圖與設計參考為驅動的工作流程可與原始碼並行。
基於 MCP 的軟體代理
函式呼叫與面向 MCP 的工作流程，適合需受控存取外部開發系統的助理。
CI 與工程自動化
無頭工作流程可支援缺陷分級、自動修復、測試生成、重構、遷移與建立 Pull Request。
Is Grok Build 0.1 Still Relevant in 2026?
是，但其角色屬於專用型而非「xAI 最新的前沿模型」。其價值在於結合編碼專精、256K 上下文視窗、推理、工具呼叫、結構化輸出、影像輸入與相對較低的標準標記價格。
當團隊需要對重複的軟體代理迴圈具良好回應速度的模型，並能以自身的儲存庫、測試、延遲目標與失敗成本進行評估時，最具吸引力。
Conclusion
Grok Build 0.1 是聚焦於編碼代理的模型，而非通用的前沿模型。其官方規格與定價使其在高頻儲存庫作業中具吸引力，但能否在生產中延續優勢，取決於周邊代理設計。
採用前，請進行具代表性的評估，量測成功任務完成率、人工修正時間、工具呼叫次數、標記使用量、測試通過率與長上下文觸發比例。當整體工作流程（而非僅僅是基準或標記價格）優於替代方案時，再選擇它。