GPT-6.1 Sol 的 76 倍瀏覽器代理結果：Asana 實際測量了什麼

Asana 於 2026 年 10 月 8 日發表了一份瀏覽器代理成本研究，而 GPT-6.1 Sol 的開發者在隔天以標題「Asana 在瀏覽器測試中將模型成本削減 76 倍，使用 GPT-6.1 Sol。」76 倍這個數字在某種意義上是真實的，因為有人測量過，但這並不是關於 GPT-6.1 Sol 價格的事實。這是關於當你修好瀏覽器代理上損壞的提示快取，然後替換其背後模型時會發生什麼事的事實。同樣的最佳化，套用在 Asana 已經在正式環境使用的模型——該公司稱之為 Model B 的模型——單獨就能將成本削減 29 倍。GPT-6.1 Sol 則提供了其餘的 2.6 倍。這些實驗是由在 Codex 中工作的 GPT-6 Astra 執行，而基準測試背後的模型是競爭對手的模型，Asana 稱之為 Model B，因此同一家供應商的兩個層級，以及一個未具名的競爭對手，都出現在這個故事裡。以下內容將區分出這項結果中你週一就能複製的部分，以及屬於 Asana 特定技術堆疊的部分。

確切陳述的比較

Asana 為此採用的技術堆疊是 StackAI，也就是它收購的工作流程自動化平台，執行一個瀏覽器代理程式，能在無需撰寫程式碼的情況下瀏覽網站、填寫表單並蒐集資訊。這項測試任務範圍狹窄且具體：從公開的示範目錄中，為 32 本書各蒐集六個欄位。這足以代表部分客戶實際執行的作業，而規模也小到讓一項 144 次執行的研究能在一週內完成。

這項設計是六種快取與螢幕截圖策略、兩種歷史預算、每種條件三次執行，橫跨四個模型——共 144 次執行，外加一組 12 次執行的後續測試。成本是依據各家供應商自家的權杖計數器計算得出，而每個答案都對照一份獨立準備的參考答案進行評分。這四個模型分別是三個未具名的前沿模型（模型 A、B 和 C）以及 GPT-6.1 Sol。模型 A 是來自另一家實驗室、較小且較便宜的模型，於 2025 年秋季發布，價格為 GPT-6.1 Sol 的一半。模型 B 是當時在正式環境中運作的模型，與 A 來自同一家實驗室，於 2026 年夏季發布，價格與 GPT-6.1 Sol 相同。模型 C 是模型 B 的較新版本，於 2026 年秋季發布，價格同樣與 GPT-6.1 Sol 相同。這三個模型在兩份報告中都未具名，因此讀者無法重現這項比較——在你把 29 倍當成關於別人模型的數字之前，這一點值得先了解。這些是 Asana 與 OpenAI 公布的數字，並非經獨立稽核的數據。

成果階梯，全部都是 Asana 自己的數字：

• 在 Model B 上的基準產出 — 每次執行至少 $36.21，每次執行至少 22.5 分鐘。有些基準執行在完成前就達到步數上限，因此平均值是下限，而非真正的平均數。

• 模型 B，最佳化代理 — 每次執行 $1.24，比基準快 4 倍，成本降低 29 倍。

• GPT-6.1 Sol，同樣的最佳化代理 — 每次執行 $0.47，約四分鐘，成本降低 76 倍、速度提升 5 倍。

• GPT-6.1 Sol，修正前後對比——每次執行從 $1.97 降至 $0.47，僅靠快取與剪枝變更就減少為四分之一。

因為基準線是下界，76 倍本身就是下限。誠實的解讀是「至少 76 倍」，而非「76 倍」。

實際上改變了什麼，以及為什麼它不是模型功能

這個機制就是提示快取機制，值得理解，因為它會套用到你在任何模型上運行的任何代理。瀏覽器代理在每次呼叫模型時，都會重新傳送它的工具、系統提示，以及不斷增長的頁面文字與螢幕截圖歷史記錄。提示快取會對重複的部分提供折扣，但只限於最長未變更的前綴——一旦請求中段有任何內容變更，從那一點起就無法繼續重用。

Asana 的生產環境代理程式有兩個相互加劇的缺陷。它快取了固定的指令與工具定義，卻未快取其瀏覽歷史。而且它幾乎在每一步都編輯那段歷史：每次都會丟棄先前的螢幕截圖，並修剪較舊的文字以符合歷史預算。每一次編輯都會使前綴失效，因此即使快取已開啟，也幾乎毫無用處。Asana 的報告指出，在受測的模型上，快取讀取的成本是標準輸入價格的 0.05 倍到 0.1 倍——所以獎賞很大，而該代理程式卻系統性地拒絕它。

這個修正分為兩部分。首先，也要快取歷史記錄，並在最新的工具結果上加上快取標記。其次，不要每次呼叫都編輯它：保留螢幕截圖，並以 20 比 1 的比例分批修剪，讓 agent 最多保留 20 個，然後再縮減回最近的那一個。如此一來，大約連續 19 次呼叫都會重複使用未變更的前綴。把歷史記錄預算從 120,000 個字元提高到 480,000 個字元，讓舊文字不再被裁掉，算術就對得上了：在 GPT-6.1 Sol 上，每次呼叫的成本大約降為三分之一，因為 89% 的輸入來自快取。

這裡最重要的發現是一個否定性的結果。在不做批次修剪的情況下快取歷史記錄，在較大的預算下，於四個模型中的三個上，成本反而高於完全不快取——快取不斷被重寫，卻鮮少被讀取。啟用了快取基礎設施卻沒有僅附加（append-only）的歷史記錄紀律，等於是白白付出一筆寫入溢價。這種失效模式與模型無關，而這正是同一個修正讓模型 B 提升 29 倍的原因。

模型選擇真正發揮作用的地方

把工作流程修正拿掉，做同類比較：在相同的最佳化代理下，GPT-6.1 Sol 的執行成本比 Model B 便宜 2.6 倍，而標價相同。額外的因素是快取命中行為，而非價目表。Sol 有 89% 的輸入是從快取讀取；Asana 並未公布 Model B 的對應比例，因此 2.6 倍是一項實測結果，但沒有已公布的拆解。應將其視為「這個模型、在這個工作負載上，更妥善地運用了它的快取」，而不是對一個我們無法指名的模型具有普遍的 2.6 倍優勢。

執行階段方面毫無疑問：比基準快 5 倍，最佳化的 Sol 工作流程大約四分鐘，而基準至少 22.5 分鐘。對按 token 計費的代理來說，速度會影響成本，因為會陷入迴圈的慢速模型得為其迴圈付費。

對任何正在估算這筆成本的人來說：GPT-6.1 Sol 的標準 API 費率為每百萬輸入 token 2.00 美元、每百萬快取輸入 token 0.10 美元，以及每百萬輸出 token 10.00 美元，而其快取讀取折扣為輸入費率的 0.05 倍——是 OpenAI 目前價目表上最深的折扣。在 Codex 中負責工程工作的模型 GPT-6 Astra，輸入為 10.00 美元、輸出為 50.00 美元，這正是 OpenAI 發布時所倚重宣傳的五倍差距。這項研究之所以產生每次 0.47 美元而非 2 美元的執行成本，原因不在於價目表；而是在於一個極為重複的請求有 89% 是以輸入費率的二十分之一計費。在快取用量龐大的代理上，折扣項目所發揮的作用比頭條價格更大，而在我們自家的目錄中，供應商標價是以 0% 加價直接傳遞，因此供應商一旦更動快取輸入的計價，當天就會反映在你的帳單上。

研究中的另一個數字：歷史預算決定了代理究竟有沒有回答。

每次執行的成本是大家都會引用的數字，但這份研究更有用的結果在於可靠性，而這正是操作人員應該優先閱讀的部分。

• 在 120,000 字元的預算下，Model C 在其 18 次執行中均未作答，而 GPT-6.1 Sol 在 18 次中有 3 次作答——大多數執行都達到步驟上限，卻未產生答案。

• 在 480,000 個字元時，兩個模型上的每一次執行都作出了回答，且每次都給出正確答案。

• 較新的模型更快耗盡較小的預算：Model C 在第 10 次呼叫時首次精簡其歷史，Model A 則在第 64 次呼叫時。

• 在最佳化的工作流程中，每一次執行都完成了任務並回傳正確答案，而每個模型在最佳條件下的每一次執行，都遇到了它應該蒐集的全部 192 項事實。

這與「更便宜」是兩回事。在一個能力足夠的模型上設定過小的歷史預算，會產生一個因為空間不足而失敗的代理，而且它會以撞上步驟上限的方式失敗，這是最昂貴的失敗方式——你付了整趟執行的錢，卻什麼也沒得到。提高預算會提高每次呼叫的成本，卻降低每個答案的成本，而後者才是生產環境負責人唯一該追蹤的數字。如果你正在為這樣的代理評估一個未經實證的模型，低風險的做法是讓你的正式環境路由繼續使用你信任的模型，並把新的模型放在容錯切換或分流路由之後，這樣一來，步驟上限的失敗就會呈現為一項路由事實，而不是一起事故。這份比較中的每一個模型，都能透過一個涵蓋 200+ 模型的 API存取，且供應商的定價表會原樣傳遞，這也讓快取讀取折扣可以在同一張帳單上跨供應商比較，而不必分散在五個儀表板上。

要從這之中依序得到什麼

如果你執行的是瀏覽器或電腦使用代理，在查看價目表之前，Asana 研究中有三個槓桿值得運用：

• 讓請求前綴只能附加。任何在每次呼叫時對歷史中段的編輯，都會使從該點之後的快取重用歸零。

• 分批修剪。Asana 的後續研究發現，每次呼叫時保留每一張截圖的成本，比在 Model B 與 GPT-6.1 Sol 上最佳修剪條件的成本低1.2 倍，在 Model C 上則約低 5%。對於長時間任務、較小的上下文視窗以及昂貴的快取讀取而言，修剪依然重要——但 20:1 的批次比例著眼的是快取穩定性，而不是截圖本身。

• 依每個模型設定歷史預算，並對照你的步驟上限檢查。適合某個模型的預算，可能會讓下一個模型資源不足。

研究中的兩道護欄很容易被略過，但不該如此。沒有任何一次執行達到 480,000 字元的預算，所以預算從未限制這些執行——但一個逐漸漂移的代理會朝其上下文上限成長，而如果快取失效，每次呼叫都得付全額代價。對每次執行的步驟、符元和成本設上限，才能限制一次糟糕的執行。另外，該研究每個條件使用三到四次執行，且呼叫次數不一；Asana 自己說，這足以顯示大致模式，但不足以區分相差幾個百分點的條件。不要從中解讀出 5% 的差異，並據此重建你的管線。

真正嶄新的部分，以及並非如此的部分

這項實驗設定的注意事項值得直說：四個模型，其中三個未具名，一項狹窄的 32 本書任務，Asana 自家埋設的計數器，以及由供應商自己撰寫並刊登該結果的文章。這裡沒有任何結果在 Asana 之外被重現過。但機制已被完整說明——僅附加歷史、在最後一個工具結果上放置快取標記、批次修剪、更大的預算、用供應商的計數器測量快取讀取——而這是那種即使被錯誤歸因於別家實驗室也依然站得住腳的發現。76 倍是 Asana 在其自身工作負載上得出的數字。它值得一讀的原因在於，它展示了一條你花一個下午就能驗證的規則：一個每一步都在編輯自身歷史的代理，等於為一場它早已進行過的對話支付全額費用。