Claude Code 在代碼執行前主動發送 33K tokens，遠超 OpenCode 的 7K。Hacker News 上有開發者實測確認：這不是偶發抖動，而是穩定復現的通信模式。

比如你提交一個 50 行 Python 函數的修改請求，Claude Code 客戶端向 Anthropic API 發出的第一個請求就攜帶 32,841 tokens——包含完整項目結構樹、最近 12 個文件的摘要、Git diff 上下文，以及三層嵌套的 AST 注釋。OpenCode 同樣場景只發 6,921 tokens。這叫上下文預填充（context pre-filling），不是推測性解碼，也不是緩存回填。日志清楚顯示：這個 payload 在任何代碼生成動作開始前就已完整發出，不依賴模型響應觸發。它跳過標準 RAG 流程，直接把本地工程元數據序列化成 prompt 前綴，強迫模型“先讀檔案，再看代碼”。

預加載不是優化，是成本黑洞

33K tokens 中只有 11% 參與最終生成（實測平均 token 利用率 10.7%），其余 29K 用于構建“偽全局上下文”。OpenCode 采用按需切片：只加載當前文件 + 引用鏈 ≤3 跳的依賴。Claude Code 的預加載讓單次編輯請求的 API 費用飆升 4.2 倍（按 Claude-3.5-Sonnet $3/M input tokens 計算）。延遲更致命：33K payload 觸發 Anthropic 服務端自動啟用流式分塊校驗，首 token 延遲從 OpenCode 的 1.8s 拉長到 4.7s。對高頻迭代的 Agent 系統（比如龍蝦的 /dev/run 實時調試模式），交互節奏直接被打斷。

響應延遲背后是可觀測性斷層

Hacker News 帖子里有開發者一針見血：“我們以為慢在模型，結果發現 90% 時間花在客戶端序列化 project.json + .git/index + pyproject.toml 的哈希計算上。” 日志證實：Claude Code 客戶端調用 API 前會重建完整本地索引——掃描 .venv 目錄、排除二進制文件，全程無進度提示。后果很實在：

• 工程師無法判斷是網絡卡、模型慢，還是本地預處理堵住了；
• CI/CD 流水線里集成 Claude Code 后，token 計費和實際代碼產出嚴重脫鉤；
• Agent 系統調試時，傳統 llm.request_time 監控完全失效——真正瓶頸在 pre_context.build() 階段。

對 AI 編碼工作流的真實影響

這不是功能差異，是設計哲學沖突。OpenCode 把上下文裁剪權交給開發者：支持 --context-depth=1，也支持手動 .codecontext 配置。Claude Code 默認開啟“全棧鏡像”模式。實測 Django 項目中修改 views.py，它會靜默上傳 manage.py、settings/base.py、requirements.txt 全文，還有 migrations/ 目錄結構摘要——哪怕改動只是一行 @login_required。這種冗余直接抬高中小團隊的 AI 運維門檻：某 SaaS 公司反饋，切換到 Claude Code 后，月度 Anthropic 賬單里“非生成類 token”占比從 12% 躍升至 63%，且沒有審計日志能追溯來源。

龍蝦生態的應對實踐

AI Agent平臺 v0.8.3 已將該現象納入 agent-tracer 模塊默認檢測規則（rule:context-bloat）。當檢測到單請求 input >20K tokens 且 X-Request-Source: claude-code 時，自動觸發上下文壓縮代理：剝離注釋、折疊長字符串、替換路徑為符號哈希。實測降低 token 消耗 37%，首 token 延遲回落至 2.1s。更重要的是，龍蝦 CLI 新增 --trace-context-flow 開關，可實時輸出每毫秒的 token 流向圖——讓“看不見的預加載”變成可調試的信號流。

下次遇到“Claude 突然變慢”，別急著調模型參數。先抓包看 POST /v1/messages 的 body size。那 33K tokens 里，可能有 28K 是你從未授權上傳的工程快照。

立刻驗證：

curl -v https://api.anthropic.com/v1/messages \
  -H "x-api-key: ..." \
  -d '{"model":"claude-3-5-sonnet-20241022","messages":[{"role":"user","content":"..."}]}' 2>&1 | grep -A 10 "Content-Length"

再用 jq 統計實際負載：

# 假設你已保存請求體到 request.json
jq '.content | length' request.json

看清它發了什么、何時發、為什么發——再決定要不要讓預加載替你做主。