GLM-5.2 Claude Code Codex CLI 的討論,在 2026 年 7 月 3 日已經從模型發表轉成工作流選擇:1M context、每百萬 token USD 1.40 / USD 4.40 定價、DeepSWE 44% Pass@1,讓開發者開始計算它能不能成為長時間 coding agent 的執行層。 Reddit 社群的主流看法並不一致。有人把它當作 Claude Opus 或 Codex 高階模型的省錢替身;也有人抱怨速度、額度、供應商穩定性與純文字模型的 UI 後續修正限制。真正值得帶走的結論更樸素:GLM-5.2 值得測,但要放在正確位置。
GLM-5.2 是什麼?
Z.ai 把 GLM-5.2 定位為 long-horizon tasks 的 flagship foundation model。它的核心賣點在完整工程脈絡:一次吃下 repo、規格、測試輸出、錯誤 log 與團隊工程規範,讓 agent 在長任務裡維持脈絡。官方文件列出 text input / text output、1M context、128K 最高輸出、thinking mode、function call、context caching、structured output 與 MCP。
| 項目 | 目前公開資訊 | 對開發團隊的意義 |
|---|---|---|
| 發布時間 | 2026 年 6 月 16 日,Together AI model card | 新模型,社群評價仍在快速變動 |
| Context window | Z.ai 1M;Together AI 256K;Cloudflare Workers AI 262,144 tokens | 不同供應商限制不同,不能只看模型宣傳頁 |
| 最高輸出 | Z.ai 128K;Together AI 131,072 tokens | 長 patch、長報告、長 agent trace 才有空間 |
| 架構 | MoE,約 744B total / 40B active per token | 一般筆電很難舒服自架 |
| 授權 | Together AI 標示 MIT open weights | 對私有部署、微調、審計有吸引力 |
| 官方 API 價格 | Input USD 1.40 / M、cached input USD 0.26 / M、output USD 4.40 / M | 長 context 可控,長推理仍會燒輸出 token |
| OpenRouter 參考價 | 約 USD 0.93 / M input、USD 3 / M output | 多供應商路由可省錢,但穩定性要自己驗證 |
| DeepSWE v1.1 | 44% ±2% Pass@1、平均 USD 3.92、78K output tokens、129 steps | 已是可測的長程工程模型,還不是整體最強 |
Z.ai 自己的 benchmark 敘事很強:Terminal-Bench 2.1 從 GLM-5.1 的 62.0 提升到 GLM-5.2 的 81.0,SWE-bench Pro 從 58.4 到 62.1。外部資料要冷靜看。Datacurve DeepSWE 在 2026 年 7 月 1 日更新的 113 題、91 個 repo、5 種語言榜單中,GLM-5.2 max 位於中上段,落後 Claude Fable 5、GPT-5.5、Claude Opus 4.8、Claude Sonnet 5 與 GPT-5.4,但成本明顯低於不少高階封閉模型。

Reddit 社群討論什麼?
Reddit 上的討論可以分成四群。
第一群是成本派。他們不一定認為 GLM-5.2 比 Opus 或 Codex 更聰明,重點是每次長任務的帳單比較好看。DeepSWE 的 GLM-5.2 平均任務成本是 USD 3.92;若企業每天跑大量 agent session,這個數字會比一次 demo 更接近真實決策。
第二群是額度派。Z.ai GLM Coding Plan 官方說 Lite / Pro / Max 分別約每 5 小時 80 / 400 / 1,600 prompts,週額度約 400 / 2,000 / 8,000 prompts。每個 prompt 估計會呼叫模型 15–20 次。麻煩在於 GLM-5.2 屬於高階模型,官方文件寫明 peak hours 會以 3 倍扣額度,off-peak 以 2 倍扣額度;2026 年 9 月底前 off-peak 有 1 倍限時優惠。Peak hours 是 UTC+8 的 14:00–18:00。這解釋了為什麼有人覺得便宜,有人覺得額度燒太快。
第三群是供應商派。他們比較 Z.ai direct、OpenRouter、Ollama Cloud、Neuralwatt、opencode Go 與其他 gateway。這一派的共識很務實:模型本身只是其中一半,另一半是 gateway 是否穩、能否切模型、是否有 failover、活動紀錄能不能查、額度規則是否透明。
第四群是 UI 與設計派。他們的批評最具體。GLM-5.2 是 text-only。它能寫出一個可看的頁面,不代表它能看懂自己輸出的畫面。Spacing、hover、icon 對齊、色彩層級、截圖後修正,仍需要 vision model、瀏覽器檢查或真人設計 review。

最多人採用的方式:把 GLM-5.2 放進既有 coding harness
我會把熱門用法排成三層。
| 用法 | 適合誰 | 優點 | 風險 |
|---|---|---|---|
| Claude Code + Z.ai GLM Coding Plan | 主要用 Claude Code、想要官方 1M 設定的人 | Z.ai 官方文件直接支援 glm-5.2[1m] |
額度扣抵規則、peak hours 與訂閱方案要看清楚 |
| Claude Code + OpenRouter | 想在 GLM、Claude、Kimi、Qwen、DeepSeek 間切換的人 | 一個 gateway 管多模型,活動紀錄集中 | Claude Code 對非 Anthropic provider 仍可能有相容性問題 |
| Codex CLI + OpenRouter 或 OpenAI-compatible endpoint | 已經用 Codex CLI、想保留 AGENTS.md 與本機流程的人 | Codex 官方支援 custom model providers | 需要確認 provider 的 wire API、model slug 與 token 行為 |
Z.ai 直接路線最乾淨。官方 Claude Code 文件建議在 ~/.claude/settings.json 加入:
{
"env": {
"ANTHROPIC_AUTH_TOKEN": "your_zai_api_key",
"ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.7",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]",
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
"API_TIMEOUT_MS": "3000000"
}
}
這條路線適合想要少踩轉接坑的人。Z.ai 還建議在 Claude Code 裡用 /effort 切換思考強度;xhigh、max、ultracode 會對應到 GLM-5.2 的 max effort。複雜 refactor 可以用 max,例行修改就別浪費額度。
OpenRouter 路線比較像多模型控制台。OpenRouter Claude Code 文件 建議使用 https://openrouter.ai/api,把 OpenRouter key 放到 ANTHROPIC_AUTH_TOKEN,並把 ANTHROPIC_API_KEY 明確設成空值,避免 Claude Code 仍使用舊的 Anthropic 登入。這點很重要,因為網路上不少教學還在混用 ANTHROPIC_API_KEY 或 /v1 endpoint。
Codex CLI 的做法更像工程設定。OpenAI Codex 文件 說明 custom model provider 由 base URL、wire API、auth 與 headers 組成;Codex config basics 則確認使用者層設定在 ~/.codex/config.toml。OpenRouter 的 Codex CLI 文件提供了這種設定:
model_provider = "openrouter"
model_reasoning_effort = "high"
model = "z-ai/glm-5.2"
[model_providers.openrouter]
name = "openrouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"
這是我認為最適合 Codex CLI 使用者的起手式。它保留 Codex 的本機工作方式、AGENTS.md、profile 與專案信任設定,也讓你用同一個 provider block 測 GLM-5.2、其他開源模型或封閉模型。若改接 Z.ai direct,請優先核對 Z.ai 當下的 OpenAI-compatible endpoint 與 Codex 版本支援;我們在本機驗證的 Codex CLI 版本是 0.142.5,已具備 profile、--config 與 custom provider 相關設定面。
企業導入建議:讓 GLM-5.2 做長工時,不要讓它當萬能主管
我不建議把 GLM-5.2 設成所有任務的唯一預設。比較合理的角色是 execution model。
規劃階段可以用你最信任的高階模型,把需求拆成規格、風險、驗證方法與不可碰的邊界。執行階段再讓 GLM-5.2 負責讀 repo、改檔、跑測試、修錯。最後的設計、資安與產品判斷,仍要回到更合適的模型或真人。
企業測試時,請不要用一兩個漂亮 demo 下決定。拿 30–50 個真實任務做小型 benchmark,至少記錄成功率、平均花費、輸出 token、重跑次數、人工修正分鐘數、測試通過率、資料外流要求與 provider error。GLM-5.2 最大的價值,不在一次驚艷,而在它能否把長時間實作的單位成本壓低。

FAQ
GLM-5.2 適合取代 Claude Code 嗎?
它適合取代一部分長時間實作任務。規劃、產品判斷、視覺 review 與高度不確定任務,仍建議保留 Claude、Codex 或其他高階模型做交叉檢查。
GLM-5.2 用 Claude Code 還是 Codex CLI 比較好?
如果你已經住在 Claude Code 裡,Z.ai direct 或 OpenRouter 都是成熟路線。如果你重視 AGENTS.md、profile、專案信任設定與本機自動化,Codex CLI + OpenRouter 比較自然。
Reddit 社群對 GLM-5.2 的共識是什麼?
共識是它值得實測,分歧在訂閱額度、供應商穩定性、速度與 UI 工作限制。許多討論焦點已從模型聰明程度,轉向它能不能承接日常工程工作。
GLM-5.2 真的便宜嗎?
API 單價便宜,但長推理會增加輸出 token,訂閱方案也有倍率扣抵。對長 repo 任務與批次 implementation agent 較有利;短問答和小修小補未必划算。
本地部署 GLM-5.2 現實嗎?
開放權重讓本地部署成為可能,但 744B total / 40B active 的 MoE 尺寸讓一般團隊更適合先用 hosted API、OpenRouter、Cloudflare Workers AI 或 Together AI 做驗證。
權威引用
- Z.ai Developer Documentation — GLM-5.2 Overview
- Z.ai Developer Documentation — Pricing
- Z.ai Developer Documentation — GLM Coding Plan Overview
- Z.ai Developer Documentation — Claude Code
- Z.ai Developer Documentation — How to Switch Models
Author Insight
我們替團隊導入 coding agent 時,最常看到的錯誤是把模型升成主管,忘了它其實是員工。GLM-5.2 的價值在長時間執行:讀完 repo、照規範改檔、跑測試、回報風險。真正的系統能力來自分工,把規劃、執行、視覺檢查、資安 review 與部署驗證拆開。如果你想評估 GLM-5.2、Claude Code 或 Codex CLI 該怎麼放進團隊流程,歡迎與 Tenten 團隊預約諮詢。
術語表
| 術語 | 說明 |
|---|---|
| GLM-5.2 | Z.ai 於 2026 年 6 月推出的長程 coding 與 agentic engineering 模型 |
| 1M context | 單次請求可處理約 100 萬 tokens 的上下文容量,實際上限依供應商而異 |
| MoE | Mixture-of-Experts,每個 token 只啟用部分參數的模型架構 |
| Claude Code | Anthropic 的終端機 coding agent |
| Codex CLI | OpenAI 的本機 coding agent CLI,可透過 config 使用 custom providers |
| OpenRouter | 多模型路由平台,可用單一 key 接多個 provider 與模型 |
| DeepSWE | Datacurve 建立的長程軟體工程 benchmark |
| Execution model | 在 agent pipeline 中負責長時間實作、測試與修正的模型角色 |
