今天的 LLM 圈沒有旗艦模型發表，但工程師圈正在拆解一個更根本的問題：你的 coding agent 在「幫你寫程式」之前，到底先往伺服器塞了多少東西？一篇 token 級別的 Claude Code vs OpenCode 實測，把 33K 的隱形入場費攤在陽光下；另一篇對 xAI Grok CLI 的逆向分析，則發現它在你看不到的地方把整份 repo（含 .env）打包上傳。同一天，陶哲軒寫下他用 AI agent 搬遷 20 年前 Java applet 的體驗，George Hotz 用一篇部落格同時告白 LLM 與宣戰 hype。

🔥 Claude Code 實測：一句「OK」要付 33K token 入場費，OpenCode 只要 7K

Systima 團隊做了一件所有用 coding agent 的工程師都該做的事：在兩個 harness 和模型端點之間插一層 logging proxy，直接看它們到底傳了什麼。

結果很具體。在同樣的模型（Claude Sonnet 4.5）、同樣的機器、同樣的 prompt——只要求回覆「OK」——Claude Code 在第一個請求中就送出了約 33,000 token 的 system prompt、tool schema 和注入式 scaffold，而 OpenCode 送出約 7,000 token。差距約 4.7 倍。換到 Claude Fable 5 後差距縮小到約 3.3 倍，原因是 Claude Code 對新模型送出的 system prompt 明顯較短——同一個 harness，不同模型，不同帳單。

拆開來看，Claude Code 的 33K token 中約 24K 是 27 個 tool 的定義（包含 CronCreate、Monitor、Task 家族、worktree 管理等背景代理和編排套件），OpenCode 的 7K token 中約 4.8K 是 10 個基礎 coding tool。拿掉所有 tool 之後，Claude Code 的純 system prompt 約 6.5K token，OpenCode 約 2.0K——三倍差距，殘餘的是行為教條、語氣規則、任務管理指令和環境描述。

這不只是「誰比較胖」的比較。測試進一步揭露了幾個會讓帳單失控的乘數：

  • 指令檔：一個真實專案的 72KB AGENTS.md（或 CLAUDE.md），不論哪個 harness，每請求都多吃約 20,000 token。OpenCode 的 baseline 直接被拉到接近四倍。
  • MCP 伺服器：五個輕量公開 MCP 伺服器增加約 5,000-7,000 token。生產環境中 API 豐富的伺服器 schema 更大。
  • 子代理：一個簡單任務從直接執行的 121,000 token，拆給兩個子代理後暴漲到 513,000 token——4.2 倍。每個子代理要付自己的 bootstrap 成本，父代理再吃一次 transcript。
  • Cache 穩定性（這是重點）：OpenCode 每次請求的 prefix 是 byte-identical，cache 寫一次、之後全部用讀的。Claude Code 在同一個 session 中反覆改寫數以萬計的 cache token，cache 寫入量最高是 OpenCode 的 54 倍。cache 寫入以溢價計費——這才是使用量儀表板一直往上爬的原因。

最後的「真實配置數字」：一個使用中的 OpenCode 配置（11 個 MCP 伺服器 + 72KB 指令檔），第一請求的 metered input 來到 90,817 token——在 user 打出任何字之前。Claude Code 的真實配置（4 個 MCP + 外掛 + 同指令檔）則是大約 75,000 token。一個 85K token 的 bootstrap，直接吃掉 200K context window 的 40% 以上——在實際程式碼進來之前。

有一個對 Claude Code 有利的發現：在多步驟任務中，Claude Code 傾向批次處理 tool call（一次 parallel round trip），而 OpenCode 逐個呼叫。Claude Code 用 3 次請求完成的工作，OpenCode 用了 9 次。因為 baseline 每次請求都要重送，最終兩者的總輸入 token 趨於收斂。結論：大 baseline + 積極批次，和小 baseline + 序列化，可以落在同一個成本區間。

🔓 逆向分析：xAI Grok CLI 在你不知情下，把整份 repo 上傳到 GCS

資安研究者 @cereblab 發表了一份對 xAI 官方 Grok Build CLI（grok 0.2.93）的 wire-level 逆向分析。結論用一句話說完：Grok CLI 在你打字之前，就把整個 repository——包含 .env 裡的 API key 和密碼——打包上傳到 xAI 的 Google Cloud Storage bucket，且「改善模型」的開關關不掉這個行為。

以下是經過驗證的具體發現：

第一，讀過的檔案內容（含 .env）原封不動傳回 xAI。 研究者架設 mitmproxy 攔截 HTTPS 流量，證實當 Grok 讀取一個包含 API_KEY=CANARY... 和 DB_PASSWORD=CANARY... 的 .env 檔案時，這些內容出現在兩個通道中：即時模型請求（POST /v1/responses）的 body，以及打包進 session_state 壓縮檔後上傳到 POST /v1/storage 並收到 HTTP 200。沒有任何遮蔽。研究者強調 scope：只有 Grok 實際讀取的檔案才會進入模型請求通道（控制組中被告知「不要讀取」的檔案未出現在 /v1/responses 中），但 Grok 會讀取任何跟任務相關的檔案，包括 .env，且不對內容做任何過濾。

第二，整份 repo 被獨立上傳——跟模型有沒有讀取無關。 這是兩個獨立的通道。通道 A（/v1/responses）傳送模型讀取的檔案內容；通道 B（/v1/storage）傳送整個 workspace 的快照。在一個 12 GB 隨機檔案（模型從未讀取）的 repo 上，通道 A 只傳了 192 KB，通道 B 傳了 5.10 GiB——約 27,800 倍的差距。所有 82 次 /v1/storage POST 都回傳 200，唯一的失敗是模型用量配額（402/429），但 storage 上傳在配額耗盡後仍持續成功。

最致命的證據：研究者在 repo 中放置了一個 never_read_canary.txt，用 prompt 明確告訴 Grok 「回覆 OK，不要讀取任何檔案」，結果 Grok 將整份 repo 以 git bundle 形式上傳（POST /v1/storage → 200），git clone 該 bundle 後，那個被告知不要碰的檔案內容原封不動還原。在第二個獨立 repo 上重複實驗，結果相同。

第三，storage 目的地是 Google Cloud Storage bucket grok-code-session-traces。 研究者從 binary 的 strings 中提取到 crates/codegen/xai-data-collector/src/gcs.rs、grok-code-session-traces、storage.googleapis.com 等路徑，並從攔截到的 metadata.json 中確認檔案以 gs://grok-code-session-traces/... 路徑儲存。

第四，「改善模型」開關無法停止上傳。 研究者在關閉「Improve the model」設定後，/v1/settings 端點仍回傳 trace_upload_enabled: true。

研究者明確區分了「已證明」和「未證明」：已證明的是傳輸、接收和儲存；未證明的是 xAI 是否用這些資料訓練模型——這是政策問題，不是技術問題。但一個 CLI 工具在使用者不知情、且設定開關無效的情況下，將整份 repo（含 .env）傳回伺服器，已經是獨立的信任問題。

📐 陶哲軒用 AI agent 搬遷 20 年前 Java applet：「bug 比我自己寫的還少」

菲爾茲獎得主陶哲軒在部落格上記錄了他用 AI coding agent 搬遷舊專案的經驗。他從 1999 年就開始寫 Java applet 做數學視覺化——複分析、線性代數、honeycomb、Besicovitch 集——但 Java 1.0 早就被瀏覽器拋棄，這些 applet 也跟著死掉。

上週他決定用 AI agent 把這些 applet 移植到 JavaScript。結果：兩打以上的舊 applet，幾小時內全部復活，甚至多了圖形升級（原本黑白的 Besicovitch 集現在有彩色版）。他只找到一個小 bug（拖曳事件在視窗外的行為異常），而 agent 反過來發現了兩個他原本沒注意到的原始程式碼 bug——「淨 bug 數打平」。

陶哲軒對風險的評估值得注意。他明確說這些 applet 是「次要的視覺輔助，不是數學論證的關鍵組成」，因此 LLM 可能產生的 bug「下行風險相對低」。這個判斷框架跟他在學術論文上的嚴謹標準是分開的——對於非關鍵的輔助素材，他願意接受 AI 生成程式碼的不確定性。

移除了舊專案後，他順手做了兩件新東西：一個 1999 年就想做但「程式複雜度超出我能力範圍」的 Minkowski 空間狹義相對論視覺化工具（他形容為「Inkscape，但是 Minkowski 空間版」），以及一個 Gilbreath 猜想視覺化工具來搭配他當天發表的論文。兩者都是透過跟 AI agent「vibe coding」幾小時完成。他公開了完整的對話記錄（編輯掉大量技術實作報告）。

陶哲軒的結論：未來可能會把這類互動視覺化當成論文的補充素材。他用的判斷標準不是「AI 寫的 code 完不完美」，而是「這個素材如果不完美，對論文的傷害有多大」。對一個數學家來說，這個區分是認真的。

⚡ Flash-MSA：獨立開發者釋出 MiniMax 稀疏注意力的首個開源訓練 kernel

一篇技術部落格發表了 Flash-MSA——MiniMax Sparse Attention（MSA）的首個高效開源訓練 kernel，使用 CuTeDSL 撰寫，目標是 Hopper 和 Blackwell GPU 上的百萬 token 級訓練。開發者明確表示不是 MiniMax 的官方實作，所有開發在租用的 Spheron H100 和 B200 上完成，並參考了 FA4、MSA 推論 kernel 和 Codex。

MSA 跟 DeepSeek Sparse Attention（DSA）相似但有三個關鍵差異：採用 block-wise 稀疏性（以 128 為單位選取 KV block，不是個別 token）；主注意力用 GQA 而非 MLA（開發者指出西方實驗室尚未採用 MLA 訓練，這讓 MSA 的路線對現有 GQA 模型更可行）；以及 proxy head 的 group-wise 專業化（不同 proxy head 可以選擇不同 KV subset）。

Kernel 設計的核心挑戰是在 register 和 shared memory 中同時容納常規 flash attention 的暫存器（Q tile、KV tile、O accumulator、LSE accumulator）以及 streaming top-k accumulator（forward pass）或雙重 attention 合併計算（backward pass 需同時處理 main attention 和 proxy attention 梯度）。開發者利用 block 稀疏性的一個優勢：只需快取 block index 而非個別 token index，使得除了 proxy forward 之外的所有計算都是線性的。

正確性驗證：與 eager PyTorch 實作的 forward/backward 在 bf16 精度下進行 cosine similarity sweep，包含 KL loss 的梯度計算。KL divergence 的梯度被化簡為 proxy_prob - main_prob，避免了在 kernel 中完全展開 KL 計算。

目前的限制：backward pass 受限於低 tensor-pipe 利用率，理論 occupancy 僅 12.5%（Flash-Attention 為 18.75%），只能跑到 1 CTA/SM。開發者列出後續方向包含提升 fused backward 的平行度、index sharing（跨層共享 proxy head）、context parallelism 支援（ring-style），以及用現有 GQA 模型（如 Qwen3）進行 continue pre-training 的 MSA 轉換實驗。這項工作讓稀疏注意力的訓練不再是被幾家前沿實驗室壟斷的黑箱。

📡 其他值得關注

  • George Hotz：「我愛 LLM，我恨 hype」：geohot 發了一篇同時告白與開砲的部落格。他對 AI 技術本身極度興奮（「我在本機裝了 opencode + GLM-5.2，說『用 geohot 配置裝 tmux』就真的裝好了——Linux 桌面元年終於來了！」），但對兩件事開火：一是 SF 圈子不斷散播的「窗口正在關閉」焦慮敘事（「負面 valence hype，目的只是讓你覺得自己很糟然後搬到爛透的舊金山」），二是從「fancy autocomplete」直接跳到「掌控整個光錐」的稻草人論證。他的核心論點：AI 進步主要來自 Moore’s law 和整體運算進步，不是前沿實驗室的功勞——而前沿實驗室最怕你知道這件事，因為這樣你就不會給他們幾十億美元了。 → geohot.github.io

  • Ploy 將生產環境 AI agent 遷移到 GPT-5.6：2.2x 加速、27% 降本：Ploy 的網站建置 agent 從 Claude Opus 4.8 遷移到 GPT-5.6 Sol，紀綠了完整的踩坑過程。最關鍵的發現：GPT-5.6 會把 tool call 的所有 25 個參數全部填滿（包含發明的值如 offset: 0），導致 52% 的檔案讀取回傳空白——解法是把 optional 參數改成 anyOf: [T, null]，讓模型能明確表達「我不用這個」。另一個大坑：GPT-5.6 的 prompt cache 改用 explicit key 機制，預設跨 conversation 命中率為 0%，必須手動設計 workspace-scoped key 才能回到 83.7% 命中率。 → ploy.ai

  • 100 行 Lisp 寫一個 agent：一篇簡潔的技術展示，用純 Lisp 在 100 行以內實做了一個可以調用 tool 的 LLM agent，附完整程式碼。 → thebeach.dev

  • Mindwalk：在 3D 地圖上重播 coding agent session：Show HN 專案，把你的 codebase 變成 3D 地圖，在上面視覺化 agent 的 coding session 過程——哪個檔案被讀取、哪行被修改、工具呼叫的軌跡全部可回溯。 → github.com/cosmtrek/mindwalk

  • CACM：機制解釋性研究者將因果理論應用於 LLM：ACM 通訊刊登了一篇綜述，探討如何用因果推論的框架（反事實、結構因果模型）來理解 LLM 的內部運作機制，而非僅依賴相關性分析。 → cacm.acm.org