--- title: "Astra開xhigh反而更省？要比的是做完一件事的總成本" description: "高推理強度可能更省，但這是一個要測的假設，不是規則。額度條掉得慢只描述消耗速度，不證明效率；真正的比較單位是「每個驗收通過的成果，總共花了多少」。" canonical_url: https://www.datum.page/zh-tw/docs/decisions/reasoning-effort-total-cost site: "Datum" author: "CJ Mario" author_url: https://x.com/cjmario89 language: zh-TW published: 2026-09-10 last_updated: 2026-09-10 topic: "決策與取捨" kind: concept # 概念 level: intermediate # 中級 tags: [reasoning, cost, codex, openai, evaluation] cite_as: https://www.datum.page/zh-tw/docs/decisions/reasoning-effort-total-cost --- # Astra開xhigh反而更省？要比的是做完一件事的總成本 > 高推理強度可能更省，但這是一個要測的假設，不是規則。額度條掉得慢只描述消耗速度，不證明效率；真正的比較單位是「每個驗收通過的成果，總共花了多少」。 > **說明：適用範圍** > > 官方資料以2026-09-10查核的版本為準。文中的數字除非標明出處，否則都是純示意，用來說明算法，不是實測值。 為了省額度，把AI的推理強度（reasoning effort）調低，聽起來很合理：少想一點、快答一點，應該就能少花一點。 但一則關於Astra的使用分享提出了相反的觀察：平常開medium，額度消耗很快；切換成xhigh後連續工作一小時，額度只下降約1～2%。他的推測是，xhigh雖然每次思考較多，卻減少了反覆修改與無效操作，最後反而比較省。 這個解釋有可能成立。但單一使用者的一次紀錄，不足以證明「直接開xhigh最划算」——它連自己想證明的那件事都還沒量到。 真正值得帶走的是比較單位：**不要比較AI回答一次花多少，要比較它把同一件事做到驗收通過，總共花了多少。** ## 一次回答比較便宜，不代表整個任務比較便宜 推理強度是引導模型投入多少思考的設定。它不是固定的計費倍數，也不是把模型換成另一個版本。官方文件說得很明白：模型會跨推理強度自適應地推理，簡單任務用較少token、複雜任務想得更久（[Reasoning models](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-10）。所以同一個effort在不同任務上的消耗本來就不一樣。 想像你請AI修一個登入問題：使用者明明登入成功，重新整理頁面後卻又被登出。 medium可能很快就開始改前端狀態，改完發現沒用，再調整重新導向，最後才追查到真正的問題在後端設定。這一路上它讀了檔案、改了程式、跑了測試，也做了好幾次沒有解決問題的嘗試。xhigh則可能先釐清登入流程、確認問題發生在哪個環節，再動手。每次推理比較貴，整體卻少繞了一大圈。 用一組純示意數字：medium每輪1單位、10輪完成，總成本10；xhigh每輪1.6單位、5輪完成，總成本8。 這裡沒有矛盾。**只要多付的推理成本小於省下的探索與返工成本，較高的effort就可能更便宜。** 但反過來也成立。若只是把按鈕文字改掉，medium原本就能正確完成，提高effort並沒有返工可以省。額外思考能不能回本，取決於它實際改善了什麼，不是設定名稱看起來多厲害。 ## 額度掉得慢，也可能只是事情做得慢 那則分享最容易被誤讀的地方，是把「每分鐘消耗比較少」看成「完成任務比較省」。 原始紀錄提到medium每分鐘約產生4.7次回應、xhigh約1.5次。後者呼叫得比較慢，每分鐘的消耗自然可能下降。但我們還不知道最關鍵的一件事：這些回應裡，兩邊各完成了多少有效工作。 再用一組示意數字：medium每分鐘2單位、10分鐘完成，共20單位；xhigh每分鐘1單位，但花了30分鐘，共30單位。額度條下降得比較慢，完成同一件事卻更貴。 所以「跑了一小時只掉1～2%」只能描述消耗速度，不能單獨證明效率。還得問：**這一小時交付了什麼？成果有沒有達到相同標準？** 工具呼叫次數也一樣。少讀幾個不相關的檔案可能是改善，少跑幾個必要的測試就未必。不能因為某個設定回應較少、工具用得較少，就認定它比較會做事。要減少的是無效操作，不是所有操作。 > **注意：這是一則單一回報，不是實測** > > 本文引用的1～2%、4.7與1.5都出自那則使用分享，沒有公開的任務清單、驗收標準與重複次數，無法判斷兩邊是否在做同一件事、是否都做完了。把它當成值得測試的假設，不要當成結論——這篇後半就是在講怎麼把它測成結論。 ## 先分清楚：你省的是token、費用，還是訂閱額度 討論AI成本時，這三件事經常被混在一起。 **token是用量，不是統一單價的貨幣。**輸入、快取輸入與輸出適用不同費率；推理產生的reasoning token雖然在API裡看不到，但它們占用context window，而且按輸出token計費（[Reasoning models](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-10）。所以你看到的回答很短，不代表背後消耗一定很少。 **長對話不代表每輪都把全部歷史重新全額計費。**那則分享提到每次回應都帶著約104,000 token的歷史內容，但還要考慮提示快取（prompt caching）：當請求前段的prefix完全相同、長度達到最小可快取長度並命中時，這一段以較低的快取輸入費率計費，官方標示最多折抵九成（[Prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching)，擷取2026-09-10）。快取不是免費，也不是內容重複就保證命中。同樣少跑一輪，在不同的命中情況下省下的金額可能差很多——不能拿「上下文長度×回應次數」當帳單。 **訂閱額度的百分比又是另一種尺。**官方對Codex用量的說明是：看起來相似的任務可能消耗差很多，模型、context、推理、工具使用、檢索與快取都會影響用量，所以「光看prompt長度不是可靠的估計」（[Codex pricing](https://developers.openai.com/codex/pricing)，擷取2026-09-10）。既然如此，也不能只憑額度條下降多少反推token，更不宜拿不同方案的百分比互相比較。 實務上：用API就看完整的usage與適用費率；用訂閱方案就看同一方案下、完成同類任務的實際額度消耗。兩種資料都能幫助決策，但不要混成同一張帳。 ## 換effort這個動作本身，可能就有成本 這是最容易被忽略的一項，而且它剛好打在「我卡住了就往上調」這個直覺上。 在API裡，`reasoning.effort`會改寫模型端的推理指示，因此它是會影響快取prefix的設定之一：改了它，改動點之後的prefix就對不上既有的快取項目。GPT-6 Astra提供的解法是保持請求層的`reasoning.effort`不動，改用附加一個`configuration_update` input item來切換effort，這樣才能保住先前的prefix繼續命中快取（[Prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching)，擷取2026-09-10）。 換句話說，在一段已經很長的對話中途粗暴地把effort往上調，你可能同時付了兩筆錢：更貴的推理，以及一次快取落空。**要比較effort，最乾淨的做法是各自從頭開一段，而不是在同一段對話裡切來切去。** 速度設定也是獨立的一項變因：官方說明加速設定會提高適用模型的額度消耗，included limits也因此用得更快（[Codex pricing](https://developers.openai.com/codex/pricing)，擷取2026-09-10）。倍率與適用模型見[Codex Fast模式會多花多少用量](https://www.datum.page/zh-tw/docs/models/codex-fast-mode-cost)。一邊開加速一邊沒開，就同時改變了不只一個變因。 ## medium、high、xhigh該怎麼選 與其找一個永遠不必調整的設定，不如先判斷：這份工作最容易在哪裡出問題？ 下面是一套可以開始測試的分工，不是各設定的最低成本排名。各設定的完整分工與判斷方式，見[GPT的推理強度怎麼選](https://www.datum.page/zh-tw/docs/models/choosing-gpt-effort)。 | 工作情境 | 建議起點 | 主要觀察 | | --- | --- | --- | | 修改文案、局部樣式、規則明確的小改動 | low／medium | 能否直接正確完成，不必額外探索 | | 一般功能開發，需求與驗收條件清楚 | medium | 是否經常漏掉限制、需要人工補救 | | 跨模組除錯、複雜重構、需要權衡多個方案 | high | 是否減少錯誤方向與反覆修改 | | 困難問題、長時間自主執行、複雜審查 | 比較high與xhigh | 額外消耗是否換到更可靠的成果 | 官方對xhigh的建議本身就帶條件：用於深度研究、非同步工作流與需要長時間執行的agent任務，而且**只在你的eval顯示明確效益、足以正當化額外的延遲與成本時才用**（[Reasoning models](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-10）。它不是通用省錢模式。 兩個值得注意的細節。 **不要跳過high。**同一份文件對high的說明是「依任務複雜度，medium與high都要評估」（同上）。如果medium的思考不夠完整，不代表一定要直接切到xhigh；high可能已經足以解決主要問題，是否值得再往上，繼續看成果。 **也不必每次都從低effort開始。**如果你已經知道某類工作非常容易走錯方向，就直接用在這類任務上表現較穩定的設定。所謂逐步升級，不是要求每個困難問題都先付一次失敗的成本。 最有用的預設值來自你常做的工作，不是別人的單次經驗。 ## AI卡住時，先別急著把推理強度調高 假設AI一直修不好同一個問題，至少有兩種可能。 一種是它沒有把問題想清楚：只改表面症狀、無法整合不同檔案的限制，或一直忽略已經出現的反例。這時候提高effort值得一試。 另一種是它根本缺少必要條件：看不到錯誤紀錄、沒有執行權限、測試環境無法啟動，或需求本身互相矛盾。這些問題不是多想一會兒就會消失。 所以當你看到它重複做相似的修改、卻沒有取得新證據時，先把工作拉回診斷： > 先不要繼續修改程式碼。請整理目前可驗證的問題、已排除的原因，以及下一個能區分不同可能原因的檢查。若缺少關鍵資訊，請指出缺什麼、如何取得；不要重複嘗試已經失敗的方法。 這段指令的目的不是逼模型把思考過程全部寫出來，而是讓你看見：它現在到底掌握了什麼，下一步準備怎麼驗證。 整理後如果發現證據充足、但問題確實需要複雜推理，再提高effort。若發現缺的是資料或權限，就先補齊條件。**要升級的是解題能力，不是讓同一個卡點持續得更久。** ## 在調設定之前，先把「做到哪裡算完成」說清楚 比起反覆補一句「再仔細想想」，更值得先做的是界定範圍、限制與驗收標準。官方的推理模型建議其實反對那種口號：明確寫出你要的限制條件、非常具體地描述成功條件，而「請一步一步思考」這類chain-of-thought提示對推理模型是不必要的，有時甚至有害（[Reasoning best practices](https://developers.openai.com/api/docs/guides/reasoning-best-practices)，擷取2026-09-10）。 以登入問題為例，只說： > 幫我把登入功能修好。 留下了太多未定義的空間：它不知道問題怎麼重現，也不知道能不能改API、調資料結構，或順便重構整個登入流程。 可以改成： > 修正「登入成功後，重新整理頁面會被登出」的問題。先確認重現方式與原因，再做必要修改。 > > 保留現有API介面，不順便重構其他功能。完成後確認登入狀態能在重新整理後保留、登出仍能正常運作，並補上能防止問題再次發生的測試。 > > 若環境限制導致無法驗證，請明確說明哪些測試已執行、哪些尚未執行，以及阻礙是什麼。 這不是保證省額度的特殊prompt，而是把原本要靠猜測的部分說清楚。 提供資料時同理：優先交代相關入口、錯誤訊息、必要背景與已嘗試過的方法，而不是不分範圍地把所有東西塞進對話。官方的用量建議也是這個方向——控制prompt大小、只給相關檔案、縮小來源或日期範圍、界定輸出的對象與長度、把必要工作與可選改善分開（[Codex pricing](https://developers.openai.com/codex/pricing)，擷取2026-09-10）。 但不要為了追求短prompt而刪掉關鍵限制。要減少的是無關內容，不是必要資訊。 ## 用自己的工作，找出真正划算的設定 不需要先做大型研究才能改善日常使用。挑幾個經常遇到的任務，把medium、high、xhigh放到相近條件下比較就行。關鍵是讓起點和終點都一致。 **起點一致**，指的是相同程式碼版本、相同初始資料、相同工具與權限，速度設定也固定。不要先讓medium探索半小時，再把整理好的結果交給xhigh，然後把後者的表現全部歸功於設定——那可以是一種有效的工作流程，但不是公平的設定對照。 **終點一致**，指的是事前定義完成條件。程式任務不能只看模型說「完成了」，要看功能、測試與既有行為是否符合要求；研究或寫作任務則要用相同的事實正確性、完整性與可用性標準驗收。先定義成功條件、再收資料、再定指標，本來就是官方評估流程的第一步（[Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)，擷取2026-09-10）。 接著把同一套代表性任務重複跑幾次，依任務類型分開看，並把失敗、重試與人工修正都記下來。不要只挑最好的一次當答案。 一個實用的主要指標是： ```text 每個合格成果的平均成本 = 所有嘗試的總成本（含失敗與重試） ÷ 驗收通過的成果數 ``` 旁邊再記下完成時間，以及你實際花了多久檢查、補充說明與修復。 尤其要把**模型自行執行的等待時間**和**你被占用的時間**分開。模型多跑十分鐘、但你可以去做別的事，和你必須盯著它反覆修正十分鐘，是完全不同的成本。 同時保留期限這個限制：再便宜的設定，如果無法在需要的時間內交付，對那項工作就不是好選擇。 ## 最省的設定，不一定最低，也不一定最高 「xhigh比medium更省」是一個值得測試的可能性，不是一條能套用到所有工作的規則。對容易反覆返工的任務，多投入一點推理可能很划算；對規則明確、原本就能正確完成的工作，較高的effort未必帶來值得付費的改善。 該追求的不是讓額度條下降得最慢，也不是讓AI每次都想得最久，而是在可接受的時間內，用合理的模型消耗與人工投入，穩定交付合格成果。 **不是「思考越多，花得越少」，而是額外的思考必須省下更多無效工作，才真的值得。** --- ## 本文引用來源 - [Reasoning models](https://developers.openai.com/api/docs/guides/reasoning) - [Prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching) - [Codex pricing](https://developers.openai.com/codex/pricing) - [Reasoning best practices](https://developers.openai.com/api/docs/guides/reasoning-best-practices) - [Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)