Astra開xhigh反而更省？要比的是做完一件事的總成本

為了省額度，把AI的推理強度（reasoning effort）調低，聽起來很合理：少想一點、快答一點，應該就能少花一點。

但一則關於Astra的使用分享提出了相反的觀察：平常開medium，額度消耗很快；切換成xhigh後連續工作一小時，額度只下降約1～2%。他的推測是，xhigh雖然每次思考較多，卻減少了反覆修改與無效操作，最後反而比較省。

這個解釋有可能成立。但單一使用者的一次紀錄，不足以證明「直接開xhigh最划算」——它連自己想證明的那件事都還沒量到。

真正值得帶走的是比較單位：不要比較AI回答一次花多少，要比較它把同一件事做到驗收通過，總共花了多少。

一次回答比較便宜，不代表整個任務比較便宜#

推理強度是引導模型投入多少思考的設定。它不是固定的計費倍數，也不是把模型換成另一個版本。官方文件說得很明白：模型會跨推理強度自適應地推理，簡單任務用較少token、複雜任務想得更久（Reasoning models（於新分頁開啟），擷取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%」只能描述消耗速度，不能單獨證明效率。還得問：這一小時交付了什麼？成果有沒有達到相同標準？

工具呼叫次數也一樣。少讀幾個不相關的檔案可能是改善，少跑幾個必要的測試就未必。不能因為某個設定回應較少、工具用得較少，就認定它比較會做事。要減少的是無效操作，不是所有操作。

先分清楚：你省的是token、費用，還是訂閱額度#

討論AI成本時，這三件事經常被混在一起。

token是用量，不是統一單價的貨幣。輸入、快取輸入與輸出適用不同費率；推理產生的reasoning token雖然在API裡看不到，但它們占用context window，而且按輸出token計費（Reasoning models（於新分頁開啟），擷取2026-09-10）。所以你看到的回答很短，不代表背後消耗一定很少。

長對話不代表每輪都把全部歷史重新全額計費。那則分享提到每次回應都帶著約104,000 token的歷史內容，但還要考慮提示快取（prompt caching）：當請求前段的prefix完全相同、長度達到最小可快取長度並命中時，這一段以較低的快取輸入費率計費，官方標示最多折抵九成（Prompt caching（於新分頁開啟），擷取2026-09-10）。快取不是免費，也不是內容重複就保證命中。同樣少跑一輪，在不同的命中情況下省下的金額可能差很多——不能拿「上下文長度×回應次數」當帳單。

訂閱額度的百分比又是另一種尺。官方對Codex用量的說明是：看起來相似的任務可能消耗差很多，模型、context、推理、工具使用、檢索與快取都會影響用量，所以「光看prompt長度不是可靠的估計」（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（於新分頁開啟），擷取2026-09-10）。

換句話說，在一段已經很長的對話中途粗暴地把effort往上調，你可能同時付了兩筆錢：更貴的推理，以及一次快取落空。要比較effort，最乾淨的做法是各自從頭開一段，而不是在同一段對話裡切來切去。

速度設定也是獨立的一項變因：官方說明加速設定會提高適用模型的額度消耗，included limits也因此用得更快（Codex pricing（於新分頁開啟），擷取2026-09-10）。倍率與適用模型見Codex Fast模式會多花多少用量。一邊開加速一邊沒開，就同時改變了不只一個變因。

medium、high、xhigh該怎麼選#

與其找一個永遠不必調整的設定，不如先判斷：這份工作最容易在哪裡出問題？

下面是一套可以開始測試的分工，不是各設定的最低成本排名。各設定的完整分工與判斷方式，見GPT的推理強度怎麼選。

官方對xhigh的建議本身就帶條件：用於深度研究、非同步工作流與需要長時間執行的agent任務，而且只在你的eval顯示明確效益、足以正當化額外的延遲與成本時才用（Reasoning models（於新分頁開啟），擷取2026-09-10）。它不是通用省錢模式。

兩個值得注意的細節。

不要跳過high。同一份文件對high的說明是「依任務複雜度，medium與high都要評估」（同上）。如果medium的思考不夠完整，不代表一定要直接切到xhigh；high可能已經足以解決主要問題，是否值得再往上，繼續看成果。

也不必每次都從低effort開始。如果你已經知道某類工作非常容易走錯方向，就直接用在這類任務上表現較穩定的設定。所謂逐步升級，不是要求每個困難問題都先付一次失敗的成本。

最有用的預設值來自你常做的工作，不是別人的單次經驗。

AI卡住時，先別急著把推理強度調高#

假設AI一直修不好同一個問題，至少有兩種可能。

一種是它沒有把問題想清楚：只改表面症狀、無法整合不同檔案的限制，或一直忽略已經出現的反例。這時候提高effort值得一試。

另一種是它根本缺少必要條件：看不到錯誤紀錄、沒有執行權限、測試環境無法啟動，或需求本身互相矛盾。這些問題不是多想一會兒就會消失。

所以當你看到它重複做相似的修改、卻沒有取得新證據時，先把工作拉回診斷：

先不要繼續修改程式碼。請整理目前可驗證的問題、已排除的原因，以及下一個能區分不同可能原因的檢查。若缺少關鍵資訊，請指出缺什麼、如何取得；不要重複嘗試已經失敗的方法。

這段指令的目的不是逼模型把思考過程全部寫出來，而是讓你看見：它現在到底掌握了什麼，下一步準備怎麼驗證。

整理後如果發現證據充足、但問題確實需要複雜推理，再提高effort。若發現缺的是資料或權限，就先補齊條件。要升級的是解題能力，不是讓同一個卡點持續得更久。

在調設定之前，先把「做到哪裡算完成」說清楚#

比起反覆補一句「再仔細想想」，更值得先做的是界定範圍、限制與驗收標準。官方的推理模型建議其實反對那種口號：明確寫出你要的限制條件、非常具體地描述成功條件，而「請一步一步思考」這類chain-of-thought提示對推理模型是不必要的，有時甚至有害（Reasoning best practices（於新分頁開啟），擷取2026-09-10）。

以登入問題為例，只說：

幫我把登入功能修好。

留下了太多未定義的空間：它不知道問題怎麼重現，也不知道能不能改API、調資料結構，或順便重構整個登入流程。

可以改成：

修正「登入成功後，重新整理頁面會被登出」的問題。先確認重現方式與原因，再做必要修改。

保留現有API介面，不順便重構其他功能。完成後確認登入狀態能在重新整理後保留、登出仍能正常運作，並補上能防止問題再次發生的測試。

若環境限制導致無法驗證，請明確說明哪些測試已執行、哪些尚未執行，以及阻礙是什麼。

這不是保證省額度的特殊prompt，而是把原本要靠猜測的部分說清楚。

提供資料時同理：優先交代相關入口、錯誤訊息、必要背景與已嘗試過的方法，而不是不分範圍地把所有東西塞進對話。官方的用量建議也是這個方向——控制prompt大小、只給相關檔案、縮小來源或日期範圍、界定輸出的對象與長度、把必要工作與可選改善分開（Codex pricing（於新分頁開啟），擷取2026-09-10）。

但不要為了追求短prompt而刪掉關鍵限制。要減少的是無關內容，不是必要資訊。

用自己的工作，找出真正划算的設定#

不需要先做大型研究才能改善日常使用。挑幾個經常遇到的任務，把medium、high、xhigh放到相近條件下比較就行。關鍵是讓起點和終點都一致。

起點一致，指的是相同程式碼版本、相同初始資料、相同工具與權限，速度設定也固定。不要先讓medium探索半小時，再把整理好的結果交給xhigh，然後把後者的表現全部歸功於設定——那可以是一種有效的工作流程，但不是公平的設定對照。

終點一致，指的是事前定義完成條件。程式任務不能只看模型說「完成了」，要看功能、測試與既有行為是否符合要求；研究或寫作任務則要用相同的事實正確性、完整性與可用性標準驗收。先定義成功條件、再收資料、再定指標，本來就是官方評估流程的第一步（Evaluation best practices（於新分頁開啟），擷取2026-09-10）。

接著把同一套代表性任務重複跑幾次，依任務類型分開看，並把失敗、重試與人工修正都記下來。不要只挑最好的一次當答案。

一個實用的主要指標是：

每個合格成果的平均成本
  = 所有嘗試的總成本（含失敗與重試）
  ÷ 驗收通過的成果數

旁邊再記下完成時間，以及你實際花了多久檢查、補充說明與修復。

尤其要把模型自行執行的等待時間和你被占用的時間分開。模型多跑十分鐘、但你可以去做別的事，和你必須盯著它反覆修正十分鐘，是完全不同的成本。

同時保留期限這個限制：再便宜的設定，如果無法在需要的時間內交付，對那項工作就不是好選擇。

最省的設定，不一定最低，也不一定最高#

「xhigh比medium更省」是一個值得測試的可能性，不是一條能套用到所有工作的規則。對容易反覆返工的任務，多投入一點推理可能很划算；對規則明確、原本就能正確完成的工作，較高的effort未必帶來值得付費的改善。

該追求的不是讓額度條下降得最慢，也不是讓AI每次都想得最久，而是在可接受的時間內，用合理的模型消耗與人工投入，穩定交付合格成果。

不是「思考越多，花得越少」，而是額外的思考必須省下更多無效工作，才真的值得。