【2026 最新】RTK Claude Code A/B 評測：Token 變少真的更省錢嗎？

你可能看過 RTK 把 git、測試與 lint 輸出大幅壓短，直覺就把「終端文字少很多」翻成「Claude Code 帳單也等比例變少」。但在真正的 RTK Claude Code A/B 評測裡，輸出變短只是中間指標：如果 Claude 因為少看到一行關鍵錯誤而重跑三次，最後可能更貴。

這篇專為第一次替 coding agent 做成本評測的讀者寫。我們不把第三方 benchmark 冒充本站實測，也不要求你先懂統計；你會拿到一套可在同一個 Repo 重跑的流程，從安全安裝、with／without 對照、故障注入，到 success-adjusted cost（成功一次要花多少錢）的判讀。先記住本文的核心：RTK 任務級淨收益＝OFF 組每次成功成本－ON 組每次成功成本；rtk gain只解釋差異，不決定勝負。

先說結論：RTK 可能省，也可能只讓數字看起來很漂亮

• RTK 省的是被它改寫的 Bash 命令輸出，不是整段對話。Claude Code 內建的 Read、Grep、Glob 等工具不會因 Bash hook 自動變短。
• rtk gain 不是帳單。它用本機輸出量估算減少的 token；真正成本還包含提示、模型回答、cache read／write、額外 turns 與重跑。
• 先過任務，再比成本。ON 組若漏掉 root cause、改錯檔案或測試沒過，即使 token 最少也不能判勝。
• 最實用的答案不是一個百分比，而是一張命令決策表。記下哪些命令確實省錢；高風險路徑放進 exclude_commands，或用 recall／bypass 取回原文。

RTK 是什麼？它像 Shell 輸出的「行李壓縮袋」

Claude Code 叫 Bash 跑 git diff、npm run test 或 docker logs時，終端機回傳的文字會進入模型可見的對話內容。RTK 官方網站描述的做法，是透過 Claude Code 的 Bash hook 改寫支援的命令，再把較精簡、較適合模型閱讀的輸出送回去。

把它想成行李壓縮袋：衣服沒有變成免費機票，只是同一個箱子少佔空間。壓得好，Claude 少讀重複 log；壓錯地方，錯誤上下文也可能一起被折進袋底。RTK 提供 recall 模式保存可回查的原始輸出，正是因為「短」和「夠用」不是同一件事。

RTK 0.49.0 的命令探索規則只改寫辨識到、且符合安全形狀的命令；未知命令、部分複雜 pipe／redirection 會保留原路徑。被 wrapper 執行的 child exit status 也會保留。這代表測試不能只問「畫面短不短」，還要核對 raw command、rewrite、stdout、stderr、exit status 與 grader 結果是否語義等價。

想先理解更大的系統位置，可讀 AI Agent Harness 是什麼：hook 就是 harness 裡的一個攔截層。若你只想先做一般性節流，則從 Claude 省 Token 教學開始。

安裝 RTK 前，先建立可回滾的安全邊界

截至 2026 年 9 月 13 日，RTK GitHub 的最新正式 release 是 v0.49.0，發布於 2026 年 9 月 11 日。這是一個會介入本機命令路徑的第三方工具；先在沒有真實憑證的 Repo 副本測試，並把版本寫進結果頁。

# 1. 透過 RTK 官方 tap 安裝 binary
brew install rtk-ai/tap/rtk

# 2. 記錄版本，先預覽全域 hook 會改什麼
rtk --version
rtk init --global --dry-run

# 3. 先不啟用，直接看兩個命令會不會被改寫
rtk hook check 'git diff --stat'
rtk hook check 'npm run test'

rtk init --global會把 hook 放進使用者層，影響之後開啟的所有專案，也可能影響 subagent；Repo 副本不是權限沙箱。因此評測先只裝 binary，ON 組再用下文的明示 settings 載入 hook。正式採用後才執行 rtk init --global，用 rtk init --show核對，回滾則是 rtk init --global --uninstall。

安全底線：測試副本不要放正式 .env、SSH key 或雲端憑證；不要把「只改輸出」理解成「不會執行命令」。Claude Code 的官方 hooks 指南也說明 hook 會在工具生命週期中執行，既有權限規則仍然要保留。

也不要拿舊 binary 直接做結論：RTK 0.32.0 已修補 CVE-2026-45792，把自訂 .rtk/filters.toml改成內容 hash 綁定的明示 trust；本文核對的 0.49.0 在修補版本之後。這個 trust 是變更同意紀錄，不是 OS sandbox，每次升級仍要重跑下文的 semantic probes。

先看原生 Bash：RTK 不是從零開始壓縮

Claude Code 自己就會處理過長 Bash 結果。依官方工具參考，有效的 Bash result 超過 inline 上限時可改存 session 檔並回傳預覽，失敗命令則走另一套較短的 head／tail 截斷。因此 baseline 不是「所有 log 原封不動塞進模型」，而是同版本 Claude Code 的原生行為；bashOutputMaxChars也要鎖定。

新 claude -p process 只會清掉對話歷史，不能證明供應商端 prompt cache 為零。請交替 AB／BA 並分開記錄 cache_read_input_tokens與 cache_creation_input_tokens。一般 A/B 統計底座可參考 Claude Code Token A/B Test；下文只深挖 RTK 特有的命令 rewrite、權限、exit code 與 recall 邊界。

RTK Claude Code A/B 評測：6 步建立同 Repo 對照

以下是讀者可自行執行的空白工作簿，不是 AlphaLab 已跑出的 benchmark，也沒有預設哪一組會贏；所有判定都要由你的 grader 與 run receipts 填入。

① 先寫 grader：成功不是「回答看起來合理」

痛點：最便宜的失敗答案永遠會贏成本榜。解法：每題都先建立機器可驗證的 receipt，例如測試全過、指定檔案的 hash 符合、找出的行號集合完全一致。操作上讓 ./evals/grade.sh runs/A-01只回傳 pass／fail 與原因。你要先看到兩組品質相當，才有資格比較成本。

② 用兩份明示 settings 切 A／B，不靠啟動變數猜

RTK 0.49.0 的 RTK_DISABLED=1要出現在「被 hook 檢查的 Bash 命令字串」裡才會 bypass；把它放在 claude -p前面，hook 仍可能改寫之後的命令。因此不要用 RTK_DISABLED=1 claude ...當 control。先用 command -v rtk找出 binary 的絕對路徑，再建立 evals/settings-off.json與 evals/settings-on.json；兩份檔案只有以下 PreToolUse hook 不同，並務必把範例 placeholder 換成剛才取得的路徑：

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "/ABSOLUTE/PATH/TO/rtk hook claude"}]
    }]
  }
}

OFF 檔不含 hooks，ON 檔才加入上面這段。兩份檔案其餘的 permissions 必須完全相同；而且 RTK 會把 git diff改成 rtk git diff，所以同一 allow 規則要同時列出 raw 與 rtk hook check回報的 rewrite 形式。任何 permission_denials都要把該 run 判為 wiring failure，不能混進成本比較。

③ 每個 arm 都用全新 worktree 與相同旗標

先停一下：claude -p不會跳出 workspace trust 或 MCP 核准畫面，而 command hook 會以你的使用者權限執行。下面採用--bare模式，只載入指定 settings；它會略過訂閱 OAuth／keychain，所以僅適合已經有授權 API key、apiKeyHelper或雲端供應商憑證的受控環境。組織的 managed policy 仍可能載入，評測前要在受控機器或容器核對政策；不要把金鑰寫進 Prompt、Repo 或結果檔。

MODEL_ID="填入完整模型 ID，不要用 latest alias"
EFFORT="high"
MAX_TURNS="20"
COMMIT=$(git rev-parse HEAD)
ROOT=$(mktemp -d /tmp/rtk-ab.XXXXXX)
PROMPT_FILE="$PWD/evals/task-01.md"
SETTINGS_OFF="$PWD/evals/settings-off.json"
SETTINGS_ON="$PWD/evals/settings-on.json"

git worktree add --detach "$ROOT/A" "$COMMIT"
git worktree add --detach "$ROOT/B" "$COMMIT"

(cd "$ROOT/A" && claude --bare -p "$(cat "$PROMPT_FILE")" \
  --settings "$SETTINGS_OFF" --model "$MODEL_ID" --effort "$EFFORT" \
  --max-turns "$MAX_TURNS" --permission-mode dontAsk --tools "Bash,Read" \
  --allowedTools "Read" "Bash(git diff *)" "Bash(rtk git diff *)" \
  --output-format stream-json --include-hook-events --verbose --no-session-persistence \
  > "$ROOT/A.ndjson" 2> "$ROOT/A.stderr")
A_EXIT=$?
printf '%s\n' "$A_EXIT" > "$ROOT/A.process-exit"

(cd "$ROOT/B" && claude --bare -p "$(cat "$PROMPT_FILE")" \
  --settings "$SETTINGS_ON" --model "$MODEL_ID" --effort "$EFFORT" \
  --max-turns "$MAX_TURNS" --permission-mode dontAsk --tools "Bash,Read" \
  --allowedTools "Read" "Bash(git diff *)" "Bash(rtk git diff *)" \
  --output-format stream-json --include-hook-events --verbose --no-session-persistence \
  > "$ROOT/B.ndjson" 2> "$ROOT/B.stderr")
B_EXIT=$?
printf '%s\n' "$B_EXIT" > "$ROOT/B.process-exit"

這段 runner 只對應唯讀的 task-01 Git diff probe。下一次重複要反轉 B／A 順序，並各自建立新 worktree；絕不能讓第一組改過的 checkout 直接交給第二組。完整模型 ID、effort、最大 turns、原生 bashOutputMaxChars、tool surface、permissions、Prompt、commit 與依賴 lockfile 都要寫進同一份 manifest。

Claude Code 的程式化模式文件說明 result 可帶 usage、total_cost_usd與 per-model 明細。保存含 hook events 的整份 NDJSON，不要只留下加總：至少抽出 subtype、is_error、total_cost_usd、usage、modelUsage、num_turns、duration_ms、duration_api_ms與 permission_denials，另存剛才的 shell process exit，並保留 Bash／recall／retry 軌跡。usage只涵蓋主 loop 當前口徑時，不能拿它代替含 subagent 的累計成本；若 crash 的成本空白或異常歸零，先從可信的計費紀錄補回，否則重跑或把整個配對觀察值對稱排除，不能當成免費成功。

④ 用 4 類 semantic probe 測命令有沒有被改壞

不要只跑會成功的 git status。先用 rtk hook check '<command>'保存 rewrite，再讓同一 Repo 通過四類 RTK semantic probe：

• Rewrite 等價性：對固定大型 diff 保存 raw／rewritten command、stdout、stderr 與 exit status；grader 核對檔案集合和 git diff --check結果。
• Failed output＋recall：把線索放在長 stack trace 中段，要求先保留非零 exit status，再用 rtk recall <hash> --full找回 root cause 並修到測試通過。
• Pipe＋quoting：用固定答案驗證 grep pattern files | wc -l、帶空白／Unicode 的路徑與唯一正解，專抓 rewrite 改變 shell semantics。
• 未知／binary／loop：加入較少見的 findflag、stderr-only 與 binary fixture；成功條件是正確 passthrough／退出或觸發止損線，不把亂碼當答案。

每種 probe 都要建立一組成對且完全相同的 tool／permission 清單。Failed-test 題把兩組都擴成 Bash,Read,Edit，同時允許 Edit、raw npm run test、rewritten rtk npm run test與 rtk recall *；find／grep／pipe 題則把 rtk hook check實際回報的 raw 與 rewrite 形式逐條加入兩組。不要沿用上面的唯讀 git-diff 清單，也不要讓未預期的權限拒絕繼續跑。

這四題正是 RTK 與一般 context 管理工具的分界。想比較更廣的外部摘要／索引路徑，可另讀 context-mode A/B 評測，但不要把兩種工具的百分比放進同一張排行榜。

⑤ 同時記帳單、turns、retry 與 recall

痛點：rtk gain的 saved token 很醒目，很容易變成唯一 KPI。解法：每個 run 至少記錄 task success、估算成本、input/output/cache token、turns、Bash 呼叫數、重試數、recall 次數與完成時間。依照RTK 官方 Repo目前的 CLI，文字模式可另存最近命令歷史：

rtk gain --history > runs/rtk-gain.txt
# 若要 JSON，這個命令匯出的是期間彙總，不是逐命令 history
rtk gain --all --format json > runs/rtk-gain-summary.json

若要保留出錯後的原始輸出，先選擇 recall 後端，再在失敗情境測一次回查：

rtk config recall sqlite
# 依壓縮輸出提示的 hash 回查完整儲存內容
rtk recall <hash> --full

回查成功不代表免費：Claude 必須再發起工具呼叫、讀入原文，這些都屬於 treatment 成本。若 ON 組經常 recall，代表該命令或 fixture 可能不適合積極壓縮。

⑥ 用成功率＋配對成本下決策

每題最重要的式子是：每次成功成本＝該組所有重複 run 的總成本 ÷ 通過的 run 數。若五次全部失敗，結果不是 0 美元，而是無法完成（可視為無限大）。接著才比較中位成本、p90 完成時間與 retry。

• 保留 RTK：成功率沒有實質下降，成功成本與 p90 時間也穩定改善。
• 縮小使用面：只有 Git 或特定 test runner 受益，就只保留那一類，不追求全域百分比。
• 停用或 bypass：成功率下降、重試變多，或省下的輸出量沒有反映在成功成本。

第三方 benchmark 告訴我們什麼？模型與任務會改寫答案

以下挑兩份設定揭露較完整、且最直接回答本文問題的獨立測試。Quesma 的 Terminal-Bench 2.1 測試使用 RTK 0.45.0：Claude Code 2.1.220／Fable 5.0 的 85 題，以及 OpenCode 1.18.25／DeepSeek V4 Pro 0813 via OpenRouter 的 89 題，每題每 arm 5 次，合計 1,740 次嘗試、支出 US$1,534.48；Fable 原先的 89 題有 4 題因 security refusal 在跑後排除。前一組 aggregate spend／attempt 下降 4.52%，raw pass rate 從 358／425 降至 352／425；但 Quesma 報告的每題等權成本效果是約增加 1%，95% 信賴區間為 -3% 至 +5%。後一組 aggregate spend／attempt 約增加 5%，raw pass rate 從 316／445 降至 309／445；Quesma 報告的每題等權成本增加 17%，95% 信賴區間為 +8% 至 +28%。跨組態同時換了模型、agent 與供應商路徑，不能把差異單獨歸因給某個模型。

JetBrains 的 425 個 billed trials包含 wiring、smoke 與 full campaign，測的是 SkillsBench 87 題中的 86 題、RTK 0.43.0、Claude Code 2.1.201 與 claude-sonnet-5。low effort 的 80 個 clean task pairs，其跨題配對成本變化中位數為 +7.6%（修正 cost-accounting gap 後，p=.004）；high effort 為 +0.1%（p=.99），而 full campaign 每題每 arm 只有一次。clean pairs 上未檢出品質差異，但這不是 non-inferiority 或等效證明。

這些百分比都是作者在特定 task、版本與排除規則下報告的快照。Quesma 沒有公開可重建信賴區間的 attempt-level trajectories，JetBrains 的 full run 重複數又很低；它們適合告訴你「壓縮率不能代替端到端成本」，不適合當作所有 Repo 的平均效果。

Quesma 還記錄到一個 RTK 0.45.0 的 rewrite 執行異常：某個 find用法連續報錯 339 次後 timeout，grader 最終仍通過，但成本約為同題 matching baseline attempt 的 9 倍；修正已進入 RTK 0.46.0。這不是說新版仍有同一 bug，而是說你的評測必須保留「未知命令＋錯誤迴圈」case，並把版本與修復狀態綁在結果上。

RTK 的 3 個專屬錯配：gain、recall、permission

錯配一：rtk gain的 bytes／4 ≠ 模型帳單

RTK 以輸出 bytes／4 估算 token，回答的是「被處理的終端輸出少了多少」；它不使用模型 tokenizer，也不會替你扣掉新增 turns、模型回答或 cache 成本。修正方式是把 gain 放在 activation／diagnostic 欄，不放在勝負欄。

錯配二：compact view ≠ recall 的完整儲存內容

普通的 rtk recall <hash>可回傳省略片段；如果 grader 需要整份已儲存 capture，明確用 --full。目前穩健的保留承諾綁在失敗或 RTK 截斷的輸出，不要假定每個成功命令都永久留下全文。回查動作與讀回 token 一律算進 ON 組。

錯配三：raw allow rule ≠ rewrite 後的 permission rule

PreToolUse 改寫後，Claude Code 看到的可能是 rtk git diff，原本只允許 git diff的規則不一定命中。兩組都要同時列 raw／rewritten 形式，並把 permission denial 當 wiring failure；同一命令連續失敗則 recall、bypass 或止損。更完整的 stop condition 可接著看 30 行 AI Agent Harness 教學。

RTK Claude Code A/B 評測的最小工作簿

你不需要先做 1,740 次。先用 4 類任務、每題 AB／BA 各跑數次，讓試算表每列代表一個 run，欄位至少包含：

run_id, task_id, order, rtk_on, claude_version, rtk_version,
model_id, success, failure_reason, subtype, is_error, process_exit,
cost_missing, total_cost_usd, input_tokens, output_tokens,
cache_read_input_tokens, cache_creation_input_tokens, modelUsage,
num_turns, duration_ms, duration_api_ms, permission_denials,
bash_calls, retries, recalls

modelUsage與 permission_denials是巢狀資料，實作時用 JSONL 比硬塞 CSV 安全。先按 task_id比較配對結果，再看整體；不要讓一個超大型任務掩蓋其餘題目。輸出壓縮率高但成功成本不降，判定為「沒有可觀察的任務級收益」，而不是硬找理由宣布省錢。這套思路也適用於其他 coding-agent middleware；想理解 Claude Code 與不同 agent 執行環境的差異，可讀 Claude Code vs Codex 客觀比較。

常見問題 FAQ

1. RTK 一定會讓 Claude Code 更省錢嗎？

不一定。它能縮短部分 Bash 輸出，但任務總成本還受模型、Prompt、cache、重試與成功率影響。現有獨立測試也呈現不同路線、不同設定得到不同結果。

2. rtk gain顯示省 90%，帳單就會少 90% 嗎？

不會這樣換算。它衡量的是 RTK 處理到的本機輸出估算，不是整個 session 的供應商帳務。

3. 為什麼要看 success-adjusted cost？

因為失敗的便宜答案沒有產出。用總成本除以成功次數，才能把漏錯、重跑與未完成一起算進決策。

4. 一定要完全清空 prompt cache 嗎？

不必假裝能做到。每次用新 session、交替 AB／BA，並記錄 cache read／write，就能降低與觀察順序偏差；新 process 本身不證明供應商 cache 為零。

5. RTK 會壓縮 Claude Code 的 Read、Grep、Glob 嗎？

Bash hook 不會自動改寫這些內建工具。本文的評測範圍是經 Bash 執行、且被 RTK 支援與改寫的命令；若模型主要走內建工具，可影響的輸出占比自然較小。

6. 壓縮後找不到錯誤原文怎麼辦？

先 recall，再 bypass。啟用 recall 後用輸出提示的 hash 取回原文；緊急情況則用 RTK_DISABLED=1 <原始命令>重跑，並把這次回查列入成本。不要把變數放在 claude啟動命令前，兩者不是同一條控制路徑。

7. 要跑幾次才算有答案？

次數取決於變異與你想宣稱的精度。小型工作簿先重複到你看得出結果是否被單次異常支配；要對外宣稱百分比，則需要更多任務、重複、信賴區間與完整版本設定。

8. 最後應該全開、全關，還是局部使用？

多數團隊應從局部使用開始。先保留能穩定降低成功成本的命令；錯誤密集、常 recall 或資訊損失高的路徑，就走原始輸出。

給新手的 5 個重點

1. RTK 壓縮的是部分 Shell 輸出，不是整張 Claude Code 帳單。
2. 同 Repo、同 Prompt、同模型、同 grader，只切 RTK ON／OFF。
3. 故意放 failing test、長 stack trace、廣泛搜尋與 binary fixture。
4. 先看 task success，再算每次成功成本；rtk gain只做診斷。
5. 把 recall、retry 與 bypass 當成成本，不要從報表中刪掉。

若你想把這套評測方法延伸成完整 AI 工作流，可查看 AlphaLab 課程，從需求拆解、驗收條件到 Agent 自動化逐步建立。