【2026 最新】Grok 4.6 API 實戰：接入 OpenRouter／OpenCode，測懂 Context、成本與 Coding 能力

Grok 4.6 API 現在到底去哪裡用？更實際的問題是：接進 Coding Agent 後，一項完整 repo 任務究竟花多少錢；官方標示的 500K Context，又有沒有讓模型更早找到正確檔案、少走幾次回頭路？這篇不拿單一 benchmark 分數宣布勝負，而是從 xAI API、OpenRouter、OpenCode 一路搭到可重跑的 coding 評測。

需求很明確。2026 年 8 月 13 日查核時，讀者提供的四串討論分別在 r/singularity、r/opencodeCLI、r/codex 與 r/grok 累積約 +446、+123、+23、+34；留言反覆追問的不是榜單名次，而是每任務實付、奇怪改動、失敗恢復，以及 API 和聊天介面是不是同一個入口。這些動態數字只用來辨識需求，價格與規格則全部回到官方文件查證。

xAI 在 8 月 12 日發布 Grok 4.6，定位於 coding、agentic tasks 與 knowledge work。它在 xAI 公布的部分 coding 評測領先、部分落後：例如 CursorBench 3.2 是 69.9% 對 GPT-5.6 Sol 的 67.2%，但 DeepSWE 1.1 是 65.9% 對 73.0%，Terminal-Bench 3.0 則是 26.0% 對 34.6%。更麻煩的是 Grok 用 High、競品常用 Max，且分數來自各方最佳公開結果；所以 xAI 發表頁能告訴我們「值得測」，卻不能回答你的 repo 會花多少錢。

先說結論：Grok 4.6 API 要看「通過驗收的每任務成本」

🧪 記憶把手：真正成本＝所有已計費呼叫（含重試與失敗）÷ 通過驗收的任務數；Context 是容量，不是能力。
如果模型花 0.3 美元卻沒修好，不能叫便宜；如果 500K 只讓它讀了更多無關檔案，也不能叫長 Context 利用得好。

• 可用入口：官方已明確列出 xAI API、Grok Build、Cursor，以及 OpenRouter／Vercel／Cloudflare 等 gateway；一般 grok.com 聊天介面是否能直接指定同一個 API model ID，官方頁面沒有給出同等明確的說法。
• 模型 ID：xAI API 使用 grok-4.6；OpenRouter 使用 x-ai/grok-4.6。不要自行猜 grok-4.6-latest 或 grok-4.6-fast。
• Context 與價格：500K context；prompt 少於 200K 時，每百萬 input／cached input／output 是 2／0.5／6 美元；達 200K 後，整個 request 全部改用 4／1／12 美元。
• 成本主證據：直連 xAI 讀 usage.cost_in_usd_ticks；OpenRouter 讀 usage.cost。單純用 token 單價反推，只適合核對，不是最終帳單。
• 公平比較：模型實驗固定同一個 OpenCode／runner；Grok Build、Claude Code、Codex CLI 的產品比較另開一張表，不能混在一起。

Grok 4.6 API 可用在哪？先分清 5 個入口

① xAI API：最適合查真正的每次呼叫成本

若你要做嚴謹成本實驗，優先使用 xAI 的 Responses API：POST https://api.x.ai/v1/responses。官方 Grok 4.6 模型頁列出 500,000-token context、2026-02-01 knowledge cutoff、文字與圖片輸入、文字輸出，以及 low／medium／high／xhigh 四檔 reasoning；high 是預設，reasoning 不能關閉。

xAI 的 OpenAI SDK 相容層可以直接把 base_url 換成 https://api.x.ai/v1。但「相容」不等於所有功能完全相同：Responses API 承接新功能、狀態與內建工具；舊的 Chat Completions 已被官方標成 deprecated，較適合既有 function-calling 程式遷移，不應成為新專案首選。

② OpenRouter：最適合把多個 API 模型放進同一條測試管線

OpenRouter 的 Grok 4.6 模型頁使用 x-ai/grok-4.6，同樣標示 500K context 與 2／0.5／6 美元基礎費率；其模型 registry 也列出 prompt 達 200K 後的 4／1／12 美元 override。好處是 Grok、Claude、OpenAI 都能走同一個 API 形狀；代價是多了一層 routing，實驗時必須保存實際 model／provider，並關閉 fallback。

OpenRouter 的 Usage Accounting會在非串流完整回應或串流最後一個 SSE message 放入 usage.cost、prompt／completion／reasoning tokens 與 cached tokens。它和 xAI 的 ticks 欄位不是同一單位，因此 log schema 要先統一成美元，再保留原始欄位供稽核。

③ OpenCode：最適合做「同 Harness、換模型」

OpenCode 是 Coding Agent harness：它負責讀檔、搜尋、編輯、執行命令、工具迴圈、權限與 session。接 xAI 時可以用 SuperGrok subscription OAuth 或 pay-as-you-go API key；接 OpenRouter 則輸入 OpenRouter key，再從 /models 選模型。本文用 OpenRouter 路線示範，是因為三個模型可以留在同一個 gateway；如果你的唯一目標是核對 xAI 原始帳單，則改走 xAI 原生 key。

④ Grok Build／Cursor：適合實際工作，不適合冒充純模型實驗

xAI 官方列出 Grok 4.6 是 Grok Build 的預設模型，也供 Cursor 各方案使用。這些入口很適合回答「整套產品好不好用」，但它們可能有不同的 system prompt、工具、context compaction、權限、重試、索引與訂閱額度。拿 CursorBench 或 Grok Build 的結果直接寫成「Grok 4.6 API 分數」，等於把車手、賽車和賽道混成同一個變因。

⑤ grok.com 聊天介面：不要用 model picker 猜 API 供應

API 與消費者聊天產品共享品牌，帳務卻是兩套系統。Grok 4.6 發表頁的明確供應清單包含 API、Grok Build、Cursor 與 gateway；它沒有同樣明確地承諾一般聊天介面可直接指定 grok-4.6。因此最穩妥的做法是：開發者在 API 的 /v1/models 或 gateway model registry 驗證 ID，不用聊天介面的顯示名稱推導 API 可用性。

Grok 4.6 API 最小呼叫：同時把帳單寫進 JSONL

先做一個不改 repo 的 reachability check。下面使用官方文件示範的 OpenAI Python SDK 相容路線；金鑰只放環境變數，不寫進程式、shell history 或 repository。

python -m pip install -U openai
# 靜默讀入，不把 key 本身留在 shell history
read -s XAI_API_KEY
export XAI_API_KEY

python - <<'PY'
import json, os, time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)

r = client.responses.create(
    model="grok-4.6",
    reasoning={"effort": "high"},
    prompt_cache_key="grok46-reachability-v1",
    input="只回覆 READY，不要使用工具。",
)

row = {
    "ts": int(time.time()),
    "provider": "xai",
    "model": r.model,
    "response_id": r.id,
    "input_tokens": r.usage.input_tokens,
    "output_tokens": r.usage.output_tokens,
    "cost_ticks": r.usage.cost_in_usd_ticks,
    "cost_usd": r.usage.cost_in_usd_ticks / 1e10,
}
print(r.output_text)
print(json.dumps(row, ensure_ascii=False))
PY

cost_in_usd_ticks 是該 request 實際收費，1 美元等於 10,000,000,000 ticks；它已包含 cache 折扣與 xAI server-side tools。若用 streaming，OpenAI SDK／REST 要加 stream_options: {"include_usage": true}，成本只在最後一個 usage chunk 出現。Coding Agent 會送出很多 request，因此每一筆都要存，不能只看 final answer 那一筆。

Grok 4.6 成本怎麼算？200K 有一道加倍門檻

截至 2026 年 8 月 13 日，xAI 的文字模型價目把 Grok 4.6 分成兩段。prompt 少於 200K tokens 時，input／cached input／output 每百萬 tokens 分別是 2／0.5／6 美元；prompt 達到 200K 時，全 request 的所有 tokens 都改用 4／1／12 美元。cached tokens 也計入 200K 門檻，而 reasoning tokens 以 output 費率收費。

用一個固定算例看斷點：如果一次 request 有 120K uncached input、60K cached input、8K output，prompt 合計 180K，按牌價是 0.12×2 + 0.06×0.5 + 0.008×6 = US$0.318。如果只多 40K uncached input，變成 160K uncached＋60K cached＋8K output，prompt 合計 220K，整筆改按長 Context 費率，變成 0.16×4 + 0.06×1 + 0.008×12 = US$0.796。這段是費率算式；正式實驗仍以 response 的實際 cost 欄位入帳。

一個 coding task 若先送出 US$0.796 的嘗試、測試失敗後又重送一次同價 request，最後才成功，task cost 是 US$1.592，而不是 final response 的 US$0.796。遇到 HTTP 429 或網路錯誤，先用 response／generation ID 到 provider Activity 對帳；確定沒有 usage 與帳單才只記延遲。client 收到部分輸出後自動重試，可能形成兩筆付費 generation，也要全部納入。想先建立這套觀測心智模型，可搭配 AlphaLab 的 Agent Observability 完整教學與 MCP vs CLI Harness Tax A/B Test。

Prompt cache 能省錢，但不能假裝 Context 沒占空間

xAI 會自動嘗試 prompt caching，官方建議 Responses API 設定穩定的 prompt_cache_key；Chat Completions 則用 x-grok-conv-id header，把同一 conversation 路由到相同 server。cache hit 不是保證，prefix 變動或 cache eviction 都會讓 cached_tokens 回到 0。測試時分開跑 cold cache／warm cache，並同時記錄 uncached、cached、output、reasoning 與實付美元。

OpenRouter＋OpenCode 設定：把 Grok 4.6 放進同一 Harness

OpenCode 官方安裝命令如下。啟動後輸入 /connect，選 OpenRouter、貼上 API key，再用 /models 搜尋 x-ai/grok-4.6。如果選 xAI 原生 provider，也能改用 SuperGrok device-code OAuth 或 xAI API key。

curl -fsSL https://opencode.ai/install | bash
opencode

# 在 TUI 內依序執行
/connect
/models

要把模型與 provider 鎖死，在 fixture repo 根目錄建立 opencode.json。OpenRouter 預設會為可用性做 provider routing；評測不需要「自動救援」，所以指定 xAI 並關閉 fallback。這個檔案也讓每個 reviewer 看得見實驗到底叫了誰。

{
  "$schema": "https://opencode.ai/config.json",
  "model": "openrouter/x-ai/grok-4.6",
  "provider": {
    "openrouter": {
      "models": {
        "x-ai/grok-4.6": {
          "options": {
            "provider": {
              "only": ["xai"],
              "allow_fallbacks": false,
              "require_parameters": true
            }
          }
        }
      }
    }
  }
}

先更新 model catalog，再確認 ID；新模型發布隔天，舊 cache 很容易讓人誤判「OpenCode 不支援」。非互動 run 使用 provider/model 完整 ID，並把原始事件保留下來。只有當 models --verbose 明確列出 high variant 時，才加上 --variant high；不同 OpenCode／adapter 版本若沒有列出，就先省略而不要假設參數已轉送。--auto 只在沒有 secrets、可丟棄且有外部 sandbox 的 worktree 使用。

opencode models --refresh
opencode models openrouter --verbose | grep 'x-ai/grok-4.6'

opencode run \
  --model openrouter/x-ai/grok-4.6 \
  --variant high \
  --format json \
  --title "grok-46-benchmark-01" \
  --dir "$PWD" \
  "先重現失敗測試，再做最小修補並跑指定驗收；最後列出 changed files。" \
  | tee run-grok46.jsonl

opencode stats --models 10

run --format json的外層事件名是 step_finish，實際 step 在 .part；把每個 step 的 cost加總，才是 root session 內所有模型呼叫，而不是只看最後一筆。下面同時保留 input、output、reasoning 與 cache；reasoning 已包含在 output 計費裡，不可再加價一次。

jq -s '
  [ .[] | select(.type == "step_finish") | .part ] as $s
  | {
      steps: ($s | length),
      cost_usd: ([ $s[] | .cost ] | add // 0),
      input: ([ $s[] | (.tokens.input // 0) ] | add // 0),
      output: ([ $s[] | (.tokens.output // 0) ] | add // 0),
      reasoning: ([ $s[] | (.tokens.reasoning // 0) ] | add // 0),
      cache_read: ([ $s[] | (.tokens.cache.read // 0) ] | add // 0)
    }
' run-grok46.jsonl

opencode stats適合快速看 session token／cost，opencode export <sessionID>適合留下整段 session。三者不要重複相加：session 的 .info.cost、assistant message 的 cost 與 step cost 是同一批費用的不同聚合層。若啟用 subagent，root NDJSON 目前不含 child-session events；要以 opencode session list --format json找出 parentID對應的 child，逐一 export，且每個 session 只計一次。OpenCode cost 是 model catalog 的本地估算，正式帳務仍以 OpenRouter Activity／usage.cost或 xAI response cost 對帳。若你還不熟悉模型、工具、loop、memory 與 stop condition，可先讀 AI Agent Harness 心智模型；要自己做最小 runner，則接著看 最小 AI Agent Harness 實作。

Grok、Claude、Codex 怎麼公平比？先拆成兩條賽道

「Grok vs Claude vs Codex」其實把品牌、API 模型和產品混在一起。最乾淨的做法是先做 model-only lane，再做 product-harness lane。前者回答模型在相同工具與 loop 中的表現；後者回答你真正每天會用的整套產品，兩張表都重要，但不能互相代替。

賽道 A｜API 模型：同一個 OpenCode，只換 model ID

• 能力線：grok-4.6、claude-opus-5、gpt-5.6-sol，全部先用 high effort。
• 成本線：grok-4.6、claude-sonnet-5、gpt-5.6-terra。截至 2026 年 8 月 13 日，三者每 MTok 的基礎 input／output 分別是 2／6、2／10、2.5／15 美元；它們是各家較平衡的 coding 選項，不是假裝同價。Sonnet 5 的 2／10 美元是到 8 月 31 日的 introductory pricing，9 月 1 日起為 3／15 美元，跨日期 run 不可混在同一張成本表。
• 上限線：每家各用最大可用 effort，另表呈現；high、xhigh、max 名稱相近，卻不代表相同 test-time compute。

為什麼不只挑一個 Claude？因為 Opus 5 是複雜 agentic coding 的主對手，Sonnet 5 才是接近 Grok input 單價的成本對照；Fable 5 是更高價的能力天花板，不是同價位產品。OpenAI 同理：Sol 是旗艦能力線，Terra 是成本平衡線。想先理解「依任務而不是品牌選模型」，可延伸 AlphaLab 的 AI 模型路由小型 Eval。

賽道 B｜產品 Harness：Grok Build／OpenCode vs Claude Code vs Codex CLI

這條賽道保留各產品的原生 system prompt、工具、索引、sandbox、permissions、compaction 與 retry，回答「整套 Coding Agent 誰更好用」。費用也照產品真實方案記錄：subscription included quota 與 pay-as-you-go API 帳單分欄，不能把月費硬除以單次 token，或把 Codex CLI 的結果標成 GPT-5.6 Sol 純模型成績。

同 Repo Coding 實測：一套可重跑的 8 步 Protocol

Step 1｜先寫驗收器，再寫 prompt

準備三種 held-out tasks：有 hidden regression test 的 bug fix、多檔案且有 edge cases 的 feature、規格散落多處的 refactor／migration。每題從同一 immutable commit 建 fresh worktree；grader 在 Agent 結束後獨立執行，不採信模型寫在 final answer 的「測試已通過」。

Step 2｜凍結 Harness manifest

保存 OpenCode 版本／commit、OS／container、dependency lockfile、repo SHA、system prompt、tools、permission、timeout、max turns、retry policy、compaction、network、MCP、plugins、memory、subagents 與 cache policy。主實驗只有 model ID 能改；任何其他漂移，都必須讓那一對 run 失去 paired 資格。

Step 3｜固定 transport：全部原生 API，或全部 OpenRouter

若目標是跨模型比較，全部走 OpenRouter、pin provider、關 fallback；若目標是核對各廠原生能力，全部走各家 native API，但延遲和 gateway overhead 不再可直接比較。不要用 xAI native、OpenRouter Claude、OpenAI native 混出一張 latency／cost 排名。

Step 4｜Context 分成自然任務與受控梯度

自然 coding lane 讓 Agent 自己搜尋 repo，不預先傾倒整個 codebase。受控 long-context lane 則把可驗證 constraints 埋在相同位置，跑 100K、190K、220K、300K、450K 五檔；這會穿越 Grok 200K 價格門檻，也能測出「讀得到」和「遵守得到」是否同一件事。共同上限只跑三家都能容納的 450K，advertised maximum 另列。

Step 5｜Reasoning 主表統一 high，上限另表

同名 high 不是等量算力，但至少比「Grok High 對 Sol Max」更可解讀。每家最大 effort 是另一個問題，必須另跑 ceiling lane。若某 provider adapter 沒有忠實轉送 reasoning 參數，該 run 先標成 configuration failure，不要偷偷使用 default。

Step 6｜每個 model-task 跑 5 次，隨機交錯順序

三次只能當 case study；五次仍不算大型研究，卻足以看出是否有昂貴 outlier。每輪隨機化模型順序，cold／warm cache 分開，記錄 service tier、region、開始時間與 wall time，避免某一家永遠在不同負載時段出場。

Step 7｜成功先看 hidden tests，再做盲評 diff

最低成功條件是 hidden acceptance tests、原有 regression suite、必要 requirements 全通過，而且沒有弱化測試。接著由不知道模型名稱的 reviewer 評 scope／minimality、idiomatic／maintainability、edge cases、instruction following、安全性、dead code 與 unrelated edits。這能抓到「tests 綠了，但順手重寫半個 repo」的模型。

Step 8｜保留所有 attempts，不刪失敗

每次 request 記 model、provider、reasoning、prompt／cache／output／reasoning tokens、實付 cost、tool calls、retry cause 與 latency；每個 task 再記 completion、tests、diff、recovery、context compliance 與 wall time。failed、aborted、auto-retry 都留在總帳，否則最不穩定的模型反而會顯得最便宜。

結果表要記什麼？別只留下 Token 與一個總分

• Success：first-attempt pass、after-retry pass、hidden／regression tests、requirements compliance。
• Diff quality：最小範圍、可維護性、edge cases、指令遵從、安全與 unrelated changes。
• Tool path：read／search／edit／test 次數、invalid calls、重複呼叫、first edit 與 first green 的步數。
• Recovery：0 無恢復；1 盲重試；2 找到原因但未完成；3 診斷後換策略並成功。
• Context：constraint discovery／compliance、peak input、cache、compaction／truncation 次數、relevant files 占比。
• Latency：time-to-first-action、first edit、first green、總 wall time；API 等待和本機工具時間分開。
• Cost：實際 billed USD、server-tool fee、service tier、長 Context 費率、所有 retry；另存原始 usage。

{"run_id":"bugfix-03-grok-r2",
 "lane":"api-openrouter-common-high",
 "model":"x-ai/grok-4.6","provider":"xai",
 "reasoning_effort":"high","prompt_band":"190k",
 "attempts":3,"first_attempt_pass":false,"verified_pass":true,
 "input_tokens":381420,"cache_read_tokens":126300,
 "output_tokens":11840,"reasoning_tokens":7420,
 "billed_cost_usd":1.2746,"tool_calls":31,"invalid_calls":2,
 "recovery_score":3,"constraint_compliance":0.92,
 "wall_seconds":614,"unrelated_files":0}

上面的 JSONL 是欄位模板，不是 Grok 4.6 的實際跑分。真正報表至少同時給三個成本值：retry_adjusted_task_cost 是該 task 所有已計費 attempts 加總；cost_per_success 是全部 trial 帳單除以成功數；failure_cost_share 是失敗 trial 花費占全部花費。跨廠商 raw token 還受 tokenizer 影響，最好另列輸出字元、patch LOC 與 tool-call 數。

Grok 4.6 的 500K Context 真的有用嗎？測「找到並遵守」

Context window 像倉庫容積，只代表放得進去，不代表模型會走到正確貨架。受控實驗要在不同距離埋入互相依賴的 constraints，例如：「API response 不得改欄位名」「migration 必須可逆」「只能修改兩個 allowlisted 目錄」，再檢查模型是否找到、引用並落實。單看 peak input tokens，只能證明 Harness 搬了多少貨。

最有用的 Context 指標是 constraint discovery rate、constraint compliance rate、relevant files／total files read、首次找到責任檔案的 tool step，以及 compaction 後是否遺失早期要求。若 190K 到 220K 的品質沒有上升、帳單卻因 Grok 跨門檻大幅增加，就該優先做 retrieval、摘要或把 task 拆小，而不是繼續灌滿 500K。想補底層觀念，可讀 Context Engineering。

Grok 4.6 適合你嗎？用 4 個判斷代替排行榜

• 先用 OpenRouter 試：你要快速把 Grok 放進既有多模型 harness、統一 API 與帳務，並願意 pin provider／關 fallback。
• 改用 xAI native：你要精確的 cost_in_usd_ticks、Responses 新功能、xAI server tools 或 prompt-cache routing。
• 先留在現有模型：你的 tasks 已穩定通過、切模型省下的 token 價差小於 migration／retest 成本，或工作流依賴特定 provider tool semantics。
• 先修 Harness：失敗多半來自權限、錯誤 stop rule、巨大工具輸出、未受控 retry 或 grader 太弱；此時換更強模型只會把同一個洞放大。

如果你想看本機長 Context 的另一種取捨，可讀 Muse Glimmer 30B 本機 Agent 教學；它談的是 24GB GPU、llama.cpp 與 OpenCode，和本文的雲端 API 成本實驗形成很好的對照。

常見問題（FAQ）

Q1：Grok 4.6 API 是不是全面贏過 Claude 或 Codex？

公開資料不支持這個結論。xAI 發表表格的 coding 子評測互有勝負，effort 與 harness 也不一致；Codex 又是產品，不是單一 API model。最有用的答案來自同 repo、同 harness、同 effort、同 grader 的重複實驗。

Q2：500K Context 是否代表可以直接塞完整 repo？

容量允許，不代表策略正確。多數 coding tasks 先搜尋再讀相關檔案更省；整包傾倒可能引入噪音，還會在 200K 跨入 Grok 的加倍費率。

Q3：OpenCode 裡看不到 Grok 4.6 怎麼辦？

先執行 opencode models --refresh，再以 opencode models openrouter --verbose查完整 catalog。仍沒有時，分別檢查 provider credential、OpenRouter model page 與 xAI /v1/models；不要用聊天 app 的 model picker 當 API registry。

Q4：為什麼不直接用 token 單價算成本？

因為 Agent 有 cache、reasoning、server tools、長 Context multiplier、priority tier、失敗與重試。直連 xAI 的實際 ticks、OpenRouter 的 usage.cost才是每 request 主帳；牌價公式用來找異常。

Q5：OpenRouter fallback 有什麼問題？

正式產品的 fallback 能提高可用性；評測時卻可能換 provider，甚至在 model fallback 設定下換模型。關閉 fallback、保存 response 的 resolved model／provider，才能知道分數和帳單屬於誰。

Q6：最該盯的單一指標是什麼？

Cost per verified success。它強迫你把 hidden tests、失敗與 retry 全部算回來；再搭配 first-attempt pass rate、diff quality 與 recovery score，就不會讓便宜但不可靠的模型躲在平均 token 後面。

Q7：200K 門檻是看 prompt，還是輸出後的總 token？

看這個 request 的 prompt tokens。只要 prompt 達到 200K，整筆 request 的輸入、快取輸入與輸出都套用長 Context 費率，不是等輸出完成後才判定，也不是只有超過門檻的那一小段變貴。

Q8：xAI 與 OpenRouter 的 cost 欄位可以直接相加嗎？

先換成美元，再按 request 去重後相加。xAI 的 cost_in_usd_ticks要除以 10¹⁰；OpenRouter 的 usage.cost已是美元。保留兩邊原始欄位與 request ID，避免同一呼叫被 gateway 與 provider ledger 重複計入。

給新手的 6 個重點

• xAI API 用 grok-4.6；OpenRouter 用 x-ai/grok-4.6。
• 直連 xAI 看 ticks，OpenRouter 看 usage.cost，每個 request 都要加總。
• Grok prompt 達 200K 後，整個 request 的 input、cache、output 費率都加倍。
• 先比通過驗收的成本，再看 token；失敗和 retry 不能刪。
• API 模型比較固定同一 Harness；Claude Code、Codex、Grok Build 另做產品比較。
• 500K 是容量；是否有用，要量 constraint discovery、compliance 與完成品質。

要把這套方法帶進自己的 Agent 專案，可以從 AlphaLab AI 課程補齊 prompt、tools、eval 與 automation；也可以回到 AI 專區，依序讀 Harness、Context Engineering、Observability 與模型路由。