RxAi AMP · Benchmarks ·
測試方法就像測試一個新的讀書技巧：兩個一模一樣的 AI 助手拿到同一份作業，其中一個另外拿到一張來自共享記憶的便利貼。然後，我們把兩個助手讀進和寫出的每一個字都算清楚。這一頁說明它怎麼運作：簡單到十歲小孩也看得懂，精確到你可以自己重跑一次。
每一次測試都是一對全新的工作階段，使用同一個 AI 模型。兩者只差一件事：AMP 的 hook 是否可以把跟這份作業相關的記憶交給助手。
AMP_DISABLE=1：同樣的 hook 保持沉默提示、模型、工具白名單、專案都一樣。兩個助手之間唯一的差別，就是記憶開關。
AMP_DISABLE=1這一對由有記憶的助手先跑，下一對換另一個先跑。這樣沒有任何一方總是佔到「快取已經熱好」的便宜。
(pair + model) % 2只試一次可能只是運氣，所以題目在不同的配對之間輪替，每一題都會問不只一次。
--cases 16 → 8 pairs對照題是沒有任何記憶涵蓋的題目。它檢查記憶在幫不上忙的時候，會不會乖乖保持安靜、不多花成本。
"expectedIssue": null記憶的權重會隨著每次編譯改變。助手讀的是一份固定的副本，並移除了遠端，所以每一輪看到的記憶都一樣。
--memory-repo <snapshot>工作階段只能讀檔、執行唯讀指令，其他一律不行。個人的外部連接器全部關閉，所以受測的記憶只有 AMP。
--strict-mcp-configtoken 是一小段字。助手讀進的每一個 token、寫出的每一個 token，都要付費。
它不會一口氣寫完作業，而是一步一步來：想一想、打開一個檔案、再想一想、再打開另一個檔案。每一步都是對模型的一次呼叫，而且每一次呼叫，它都會把整段對話從頭再讀一遍，就像每寫下一句話之前，都要把整本筆記從頭讀一次。這就是為什麼「讀的量」長得那麼快。
這是示意圖，不是實測數據。第 1 次呼叫裝著系統提示、題目，以及（助手 A 才有的）便利貼。之後每一次呼叫，都帶著前面所有內容，再加上剛打開的檔案。把所有長條加起來，就是「context token 總量」。
執行器用 --output-format stream-json 啟動 Claude Code，每次模型呼叫都會印出一行，內含一個 usage 區塊。benchmark 把整個工作階段的這些欄位加總起來。
| 收據上的欄位 | 意思 |
|---|---|
| input_tokens | 全新的頁面，第一次讀 |
| cache_creation_input_tokens | 讀過並夾上書籤，下次可以便宜地跳過的頁面 |
| cache_read_input_tokens | 已經夾好書籤的頁面；大約原價的一成 |
| output_tokens | 它寫出的字，包含內部思考 |
Read、Grep、Glob）。
result 事件中回報的牌價（total_cost_usd）。
這些都是模型自己收據上的精確數字，不是猜的。監測工具的 npm run scan 是用 tokenizer 加校正係數來估算 token；benchmark 從來不用估的。
答案如果錯了，再便宜也沒有意義。每個答案都要經過三道檢查：一道看內容，一道看模型說自己用了什麼，一道看 hook 實際送出了什麼。
每一題都列出「訊號」：正確答案應該提到的檔名和函式名稱。執行器檢查哪些有出現。這是固定規則的比對，不是品質評分。
"signals": [ … ]每個答案結尾都必須有一行，列出它用到的記憶。答對的意思是：列出了預期的那則記憶；陷阱題則要回答 none。
hook 會寫一本日誌，記下它注入了什麼、注入了多少：只有標題，還是一段簡短摘要。執行器把這本日誌複製到每筆結果旁邊。
ledger · pointer | summary第 2 和第 3 道檢查刻意分開。2026 年 9 月的一次測試中，有兩個工作階段明明看到了正確的摘要，卻還是寫了 Recall used: none。如果只有一個「記憶命中」數字，會被誤判成沒有取到記憶；日誌則證明記憶確實送到了，只是沒有被標註出來。
每一項數字都是把該組所有成功的工作階段加總。負數代表有記憶的助手用得比較少。「比較便宜的配對」計算有記憶的助手贏過自己雙胞胎的次數。
| 項目 | 有記憶時的變化 |
|---|---|
| 總閱讀量context tokens | −13.6% |
| 全價閱讀量uncached input | +21.2% |
| 從檔案挖出的東西tool output | −14.9% |
| 工具呼叫次數 | −11.1% |
| 時間 | −9.0% |
| 成本8 對中有 4 對比較便宜 | +4.9% |
| 關鍵字檢查有記憶 vs 無記憶 | 34/34 · 34/34 |
用小朋友的話說：有了便利貼，助手整體讀得比較少、挖得比較少，也稍微快一點寫完。但便利貼本身是新的、全價的文字，所以總帳單差不多，平均還稍微高一點。兩個助手的作業正確度一樣好。
| 同一個測試、同一天 | 閱讀量 | 挖出量 | 時間 | 成本 |
|---|---|---|---|---|
| 之前：便利貼是一大段摘錄 | +27.9% | +19.2% | +7.1% | +27.1% |
| 之後：簡短摘要，而且只在題目相關時才給 | −13.6% | −14.9% | −9.0% | +4.9% |
| 之後，再跑一次並加嚴比對（B2） | −6.5% | −4.6% | −3.9% | +14.1% |
兩列「之後」照理應該一致，卻有落差：每題只有兩對時，一個多挖了 8 KB 的對照題工作階段，加上一個快取還沒熱的第一個工作階段，就足以讓成本差十個百分點。請看方向——記憶讓它讀得少、成本略高——不要看小數點。
第一版的便利貼把某人的決定一條一條列出來。助手把這張清單當成自己的作業，逐項去檢查，結果記憶反而讓它讀得更多。修正方法是只交出一段簡短的「目標加現況」摘要，而且只在題目和記憶相關時才給；完整紀錄需要時再去取。同一個模型、同樣的題目：閱讀量從 +28% 翻轉為 −14%。
總覽頁上的數字來自更早一輪的 Opus 5 測試：從檔案挖出的量少 18%、成本低 5%、快 14%。本來就讀得少的模型，在那一輪沒有得到好處。記憶省下的是「盲目探索」，所以模型越愛探索，記憶越划算。
Codex 跑的是同一個實驗，用同一張題目表與排程。它的收據來自每一回合結束時的 turn.completed 事件：
| 收據上的欄位 | 意思 |
|---|---|
| input_tokens | 全部讀進的量，包含有書籤的頁面 |
| cached_input_tokens | 其中有書籤的部分；未快取 = input − cached |
| output_tokens | 全部寫出的量，包含推理 |
| reasoning_output_tokens | 其中思考的部分；可見輸出 = output − reasoning |
config/prices.json）算出來的：未快取輸入 × 輸入單價 ＋ 快取輸入 × 快取單價 ＋ 輸出 × 輸出單價。ChatGPT 方案不是按 token 計費；這個數字代表同樣的流量在 API 上要花多少錢。--ignore-rules 和 --disable memories 關掉 Codex 自己存下的核准規則與內建記憶，讓受測的記憶只有 AMP。--rollouts 時，執行器還會讀每個工作階段的 rollout 檔，取得逐次呼叫的數字：每題的呼叫次數、第一次呼叫的大小、最大的一次呼叫，以及冷啟動次數。每一列都是同一份固定記憶快照、同一個專案 commit 上「有記憶 vs 無記憶」的比較，提示措辭 v2。「有說出對的便利貼」是模型自己在三題有記憶的題目上寫的 Recall used:。成本是用價目表換算的 API 等價值；astra 還沒有價目。
| 回合 | 閱讀量input tokens | 挖出量 | 時間 | 成本 | 有說出對的便利貼 |
|---|---|---|---|---|---|
| GPT-6 Sol · xhigh8 pairs · 2026-09-23 | +0.7% | −18.4% | −4.2% | +4.2% | 4/6 |
| GPT-6 Luna · xhigh8 pairs · 2026-09-23 | −12.3% | −8.1% | +8.5% | 0.0% | 4/6 |
| GPT-6 Sol · xhigh4 pairs · 2026-09-24 · Codex memory off | −17.1% | +8.5% | −25.5% | −10.6% | 3/3 |
| GPT-6 Luna · xhigh4 pairs · 2026-09-24 · Codex memory off | +26.1% | +49.1% | +41.9% | +11.4% | 2/3 |
| gpt-6-astra · medium4 pairs · 2026-09-24 · Codex memory off | +9.9% | −4.5% | −1.7% | — | 2/3 |
| gpt-6-astra · xhigh4 pairs · 2026-09-24 · Codex memory off | −3.4% | −13.6% | −10.7% | — | 3/3 |
每個模型 4 對只有一般測試的一半。Sol 的 4 對 −17% 旁邊，就是前一天 8 對的 +0.7%，Luna 則往反方向翻轉，所以兩者都還不能當標題；要等加上隔離旗標重跑 8 對才能定案。在 Codex 上站得住的結論，和 Claude Code 上一樣：模型想得越用力就讀得越多，記憶能替代的探索也越多——astra 在 xhigh 時少挖 13.6%、早 10.7% 完成，在 medium 時打平。每個工作階段的日誌都顯示同樣三張便利貼確實送到。
Prompt rules: vN。id、question、好答案應該提到的 signals，以及應該想起的 expectedIssue（陷阱題填 null）。
cd tokenMonitor
cp config/tasks.example.json config/tasks.json # then edit
git clone <memory-repo> ../memory-snapshot git -C ../memory-snapshot remote remove origin
--cases 算的是工作階段數，不是配對數，而且每一個 case 都是一次完整、要付費的工作階段。
npm run benchmark:claude -- --cases 16 \ --models claude-opus-5-5 --effort xhigh \ --project /path/to/target-project \ --memory-repo ../memory-snapshot npm run benchmark:codex -- --cases 20 --hooks \ --models <model-a>,<model-b> --reasoning medium \ --project /path/to/target-project \ --memory-repo ../memory-snapshot
report.md 與 summary.json，並在旁邊保留每個工作階段的原始輸出。中斷的測試會從 results.ndjson 接續。
完整選項與注意事項：tokenMonitor/README.md。