摘要： Firecrawl 在 2026 年 10 月 13 日發表一篇把九個 token 省法按「先做哪個」排序的指南：先量測、再從輸入來源下手、把 prompt 排成可快取的形狀，最後才考慮批次、路由與壓縮。對跑 agent 的人來說，順序錯了往往白費力氣——因為 agent 的帳單大頭多半是它已經寄過一遍又一遍的內容。
為什麼帳單會失控：每回合都在重寄舊東西
Model API 是無狀態的，所以每個回合都把整段對話重送一次：system prompt、tool 定義、先前的回覆、抓下來的頁面。Firecrawl 舉的例子很直觀：一個八回合的 agent，每回合讀一頁 12,000 token 的頁面、寫 800 token，加上 12,000 token 的前綴，一個任務要處理 55 萬多個輸入 token——其中真正「新」的頁面內容只有 96,000。
引述的 Michigan 大學博士研究員 Longju Bai 等人的系統性研究顯示，agentic coding 任務的 token 消耗比 code chat 高出一千倍，而且大部分來自輸入端。價目表也說明了該省哪一邊：兩大供應商所有現行模型，輸出價都是輸入的五倍；cache read 只要新輸入的十分之一到四十分之一。順帶一提，模型價格本身差距可達一百倍，這與先前談過的 Haiku 5.5 分層計價邏輯一致。
前三招沒有品質風險，先做
第一招是量測：從 API response 的 usage 欄位記下每個任務的 input、output、cache read，按功能與任務 ID 打標。三個數字決定起手式——輸入按層拆分、每任務輸出量、cache 命中率。Anthropic 的 Claude Code 團隊成員 Thariq Shihipar 提過，團隊對 cache 命中率設了告警，掉太低會開 incident。
第二招是從源頭砍輸入。Firecrawl 自己的量測：同一批十五個頁面，raw HTML 要四百多萬個 GPT token，乾淨的 markdown 只要約 19 萬，差 21.5 倍。而 agent 只需要一個事實時，直接回答案更狠——同一個 AAPL 股價查詢，他們的 answer 格式回 6 個字元，Claude Code 的 WebFetch 摘要路徑對應的是一百多萬 bytes 的 fetch 摘要。在他們引用的 Openbenchmarks 排行上，同一組 coding agent 走不同搜尋供應商，每任務中位數 token 從 7,456 到 24,057 不等。這招的重點是：工具回傳的三列查詢結果，會在之後每個回合被重複計費。
第三招是讓快取打得到。兩大供應商都按前綴快取，request 前段只要有一個 byte 不同就作廢。所以靜態前綴放最前，會變動的內容放最後。Firecrawl 引用的數字是 500 多個 agent session 中省下 41–80% 的 API 成本。
後面幾招各有代價
限制輸出與 reasoning 長度排在第四：輸出計價是輸入的五倍，囉嗦的模型可能比長 prompt 還貴。能等的任務走 batch，兩家供應商都打五折，而且和快取疊加。之後才是路由到便宜模型、壓縮歷史這類需要評估驗證的手段——壓縮時機什麼時候該交給模型自己判斷，我之前寫過 Apple 那篇研究的想法（見 這篇）。
Firecrawl 最後用一個模型估算收尾：把這些手段全疊上去，一個每月 10,000 個任務的研究 agent，成本從 $11,648 降到 $425。這是工作模型不是實測數字，但方向夠清楚。
一句話帶走：先砍輸入、排好快取、別讓模型寫得比你讀的還多。路由與壓縮留到最後，而且每個改動背後要有 eval——一個變便宜但失敗的 request，比一個貴但成功的更花錢。