Codex 中的 GPT-6 Astra：跨視窗筆記、投入等級，以及實際帳單

GPT-6 Astra 是一款 2026-09-03 的模型，而本頁並非發布報導——它是當它已全面開放後，讓你把 coding agent 指向它時所依據的參考文件。開發者之所以會轉換，原因在於一個特定的機制，而在你為它花任何錢之前，值得先理解這一點：每當視窗被填滿時，搭配 GPT-6 Astra 的 Co​dex 不會把冗長的 session 壓縮成一份有損的單一摘要，而是跨 context window 保留筆記，並讓較早的 context window 仍可搜尋，因此你在四十個回合前提出的需求，以及十個回合前失敗的測試輸出，兩者都仍可找回，而不是被摘要掉。Ope​nAI 稱這項功能為實驗性，只要在 Co​dex 的 config.toml 中加上一行即可啟用，並表示它將成為 Astra 的預設設定。以下所有內容——確切的 config、effort levels、實測結果，以及一份列出了 cached-input 那一行的完整 session 帳單——都是 2026-09-16 從 Ope​nAI 自家頁面讀到的，而每一項第三方數據都標明為第三方來源。

本週發生了兩件事，改變了採用它的盤算。在 2026 年 9 月 12 日，OpenAI 的 Codex 負責人發布了一份事後檢討，證實那個上下文管理實驗本身有 bug——它導致過早停止，以及對過時訊息做出回覆，並對大約 4,000–5,000 名使用該實驗的使用者予以停用——而 OpenAI 也在 9 月 12 日跨入 9 月 13 日的午夜，對 Codex 與 Astra 使用者發布了完整的用量重設。同一週，推出時預設關閉 Astra 的企業工作區，也變成可依各自的費率表進行管理。所以誠實的立場是：這個機制值得採用，但這套建置仍在你腳下變動，而你應該在分支上試用它，而不是趕在期限前。

Codex 搭配 GPT-6 Astra 究竟有什麼真正的新東西？

叫任何程式編寫代理連續工作六個小時，你都會撞上同一道牆。上下文視窗被填滿，代理框架為了騰出空間，把對話紀錄摘要成一大塊濃縮內容，而這種摘要有損，而且偏偏就在最要命的地方失真——先前某次修正為何失敗、某個失敗測試的確切樣貌、使用者在第三輪順口提過的一項限制。你真正想要的，是取回的細節，而不是被摘要過的細節。

Astra 的 Codex 整合改變了那件事的樣貌。OpenAI 的 Codex 說明文件直言：「Astra 會跨上下文視窗保留筆記，並可搜尋同一任務中較早的訊息與工具結果。」筆記具有持久性且可寫入；它們背後的歷史記錄仍可讀取，因此即使已寫下關於某項證據的筆記，較早的視窗仍可被搜尋以找出原始證據。來自較早訊息與工具輸出的需求與測試結果仍可找到。

OpenAI 明確表示這並非已完成的工作。其設定參考文件將這個旗標描述為「啟用實驗性上下文管理（預設為關閉）」，並表示這項功能「使用筆記與可搜尋的歷史記錄來保留累積的細節」。文件也指出，這項功能「在推出時不支援 Business、Enterprise 或 API 金鑰登入」。這也不是無限上下文——模型仍然是在有限的視窗內進行推理，而每一次回讀先前的筆記都會消耗該回合的輸入預算。根據 OpenAI 的模型文件，該視窗為 1,050,000 個 token，輸入 token 上限為 922,000 個；筆記機制是架構在其之上，而非取而代之。

這份設定，完全依照 Ope​nAI 文件所述

此設定是 [features] 表格中的子項，位於你的 Co​dex config.toml 中——除非你已覆寫 CODEX_HOME，否則該檔案位於 ~/.codex/。文件記載的鍵路徑是 features.context_management.experimental_mode，為布林值，且值為 true：

[features.context_management]
experimental_mode = true

如果檔案中已經有 [features] 表格，請在裡面加入相對應的鍵，而不要重複宣告該表格：

[features]
context_management.experimental_mode = true

使用其中一種形式。社群對該旗標的說明指出，若在根層級宣告點狀路徑，然後在同一檔案稍後開啟 [features] 表格，可能會因為被視為重複宣告的表格而解析失敗，這是 TOML 的規則，而非 Ope​nAI 的規則——但這會讓人吃虧，所以選定一種形式並堅持下去。編輯後，開始一個新任務：該設定不會回溯套用到已在執行的工作階段。

同一個檔案的模型部分沒什麼特別的，而 OpenAI 的參考文件直接說明了這些鍵——model 是「要使用的模型」，model_provider 預設為 openai：

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

關於閱讀文件版本的注意事項。Codex 設定參考文件將 model_reasoning_effort 列為接受 minimal、low、medium、high 和 xhigh，並註明 xhigh 取決於模型——而 OpenAI 針對 gpt-6-astra 的 API 模型頁面則將 reasoning.effort 記載為 low、medium、high、xhigh 和 max。客戶端滑桿與 API 所描述的並不是同一組選項，因此請明確設定 effort，並確認你的客戶端實際接受了什麼，而不是憑假設。

選擇模型——以及那條讓人栽跟頭的存取規則

OpenAI 的 Codex 模型文件直接給出 CLI 形式：codex -m gpt-6-astra。在互動式工作階段中，/model 會切換模型並調整推理強度；在單次執行中，codex exec -m gpt-6-astra "Review the current changes" 的運作方式也相同。在桌面應用程式與 IDE 擴充功能中，模型控制項位於撰寫區下方。

存取規則是大家常犯錯的地方，值得讀兩次，因為這兩個功能有不同的閘門：

• 該模型——已在 ChatGPT Work、Codex 與 API 中提供，同時也部署於 Microsoft Azure 和 AWS Bedrock 上。OpenAI 的發布頁面表示，Astra「今日起向有限的一組組織推出，並將在接下來幾天內開放給所有 ChatGPT Plus、Pro、Business 與 Enterprise 使用者」。

• 實驗性上下文管理——範圍較窄。Ope​nAI 的文件指出，它「需要以 Plus、Pro 或 Pro Lite 登入 ChatGPT」，且「推出時無法透過 Business、Enterprise 或 API 金鑰登入使用」。

第二行才是你該記進心裡的那一句。你可以用 API 金鑰呼叫 gpt-6-astra，也可以在 Business 方案上付費使用——但跨視窗筆記功能不會出現。如果筆記機制正是你改用它的原因，你需要在 Co​dex 用戶端以 Plus、Pro 或 Pro Lite 的 ChatGPT 身分登入，而不是用 API 金鑰。Ope​nAI 把這說成是可用性取決於「推送階段、你的登入方式，以及你的用戶端」，這只是同一件事的禮貌說法。

還有兩點但書，標示為「據報導」而非「供應商官方文件記載」。關於此次推出的報導指出，Astra 需要 Co​dex CLI 0.153.0 或更新版本；我們無法在 Ope​nAI 自家頁面上確認這個最低版本門檻。而 Co​dex 文件描述了模型選擇器預設集——Astra Light、Astra Medium、Astra Extra High，與推理滑桿一同提供給符合資格的 Pro、Business（$100）與 Enterprise 帳戶。那些是選擇器中的位置，不是獨立產品：Ope​nAI 記載的是一個模型 ID：gpt-6-astra，只有一組規格與一個價格，且未公布任何「Astra Pro」或「Astra Medium」配置的獨立規格或費率。任何針對具名 Astra 層級所引述的數字，都應視為未經證實。

如果你想在把正式生產路徑交給這個模型之前先試用看看，把它與你目前的模型一起透過同一個端點來路由，是最省錢的驗證方式—— GPT-6 Astra 已收錄於 OrcaRouter 型錄，因此跑一次比較只需要換一個模型字串，而不必再簽一份合約、再導入一套 SDK。

推理努力：五個等級，以及每個等級的代價

OpenAI 的 gpt-6-astra API 文件列出了五種 effort 等級——low、medium、high、xhigh 與 max——而 Codex 的指引對於該如何使用它們說得很直白：「使用能產生你所需結果的最低推理 effort」，並從預設值開始，當任務需要更深入的規劃時再往上提高。

這項建議之所以在這個模型上特別貴得不能忽視，原因在於推理 token 在帳單上被歸類的位置。推理 token 屬於輸出 token，而 Astra 的輸出價格是每百萬 $50.00——是輸入費率的十倍，也是快取輸入費率的五十倍。所以這筆取捨並不抽象：

• 在輸出費率下，每輪每增加 1,000 個推理 token 需花費 $0.05。

• 在一個 150 回合的工作階段中，每回合多保留 1,000 個額外推理 token 的成本約為 $7.50；多保留 5,000 個的成本約為 $37.50。

• 在下面的演練工作階段中，輸出已經是最大的單一項目：每回合 $0.200，相較於 $0.090 的快取讀取——推理增長才是讓總計變動最快的項目。

OpenAI 沒有公布的，是一份依投入程度分列的表格：供應商並未提供 xhigh 或 max 在程式編寫任務上相對於 medium 會輸出多少推理 token 的數字，也沒有按投入程度分開呈現的官方基準測試。任何人向你引述精確的「max 成本是 2 倍」比率，引用的都是他們自己的測量結果，而非 OpenAI 的。誠實的做法是：以兩個投入程度各跑一個具代表性的任務，然後讀取回應中的 usage 區塊——那個數字乘以每百萬 50 美元，就是你真正的投入溢價。

實測結果，每個都有各自的來源

編碼與終端機工作，除非另有標註，否則全數皆為 Ope​nAI 回報的數據。Terminal-Bench 4.0：GPT-6 Astra 為 57.9%，相較之下 GPT-5.6 Sol 為 37.3%、Claude Fable 5.1 為 55.8%——而 Ope​nAI 估計，相對於 GPT-5.6 Sol，每項任務的 API 成本約低 9%，相對於 Claude Fable 5.1 則低 63%。Datacurve 的 DeepSWE v1.1 將 Astra 在 Datacurve 自家基準測試上的成績列為 74.1%，Datacurve 形容這項數字為新紀錄，部分報導則將其四捨五入為 74%。在更廣泛的代理式測試集方面，Ope​nAI 回報 OSWorld 2.0 為 72.6%、每項任務約需 40 分鐘——每項任務所需時間比 GPT-5.6 Sol 少約 47%——同時 FrontierMath 第 4 級為 98%、ARC-AGI-3 為 99.9%、ExploitBench 為 100%，Ope​nAI 將這些全數形容為已飽和或實質上已飽和的層級。這些都是廠商提供的數字；我們並未重現這些結果，而 ARC Prize 對 ARC-AGI-3 該數字的獨立審查發現，它是在特殊的供應商轉接器環境下測得，且在標準條件下會下滑。

不是廠商數字的這部分，才是程式碼審查工作流程最該在意的事。CodeRabbit 在 2026-09-04 發表了自家對 Astra 的評估，而結果比標題所呈現的更為有限。在跨檔案 pull request——也就是需要把某項變更與程式碼庫其他地方所造成的後果連結起來的困難審查——方面，Astra 比 GPT-5.6 Sol 多抓到大約 20% 的錯誤，可採取行動的錯誤覆蓋率為 57.1%，對手則是 47.6%。在整體審查方面，這個增益大致消失：61.3% 對 59.0%，大約多 4%。CodeRabbit 把兩者都描述為「早期、方向性的結果」，無法藉此確立排名，並指出其方法並未隔離出改善的原因。OpenAI 的發布頁面把同一項工作描述為「在跨檔案 pull request 上超過兩倍」；CodeRabbit 自己的文章給出的則是上述的 20% 與覆蓋率百分比。要看的是百分比，不是摘要。

那個不對稱性是這一頁上最有用的單一數字，能決定該如何部署模型；而且它與價格指向同一個方向：收益集中在跨檔案推理，所以那就是你該投入模型的地方。

Codex 中的電腦操作功能會為你的工作流程帶來什麼改變

OpenAI 表示，更新後的 Codex 執行框架讓 GPT-6 Astra 在 Mind2Web 上的任務完成速度比目前的 GPT-5.6 Sol 體驗快 1.9 倍。Mind2Web 是網頁任務自動化，所以可以解讀為：必須接觸瀏覽器或 GUI 的代理工作能實質上更快完成，而當你操作 Codex 時，所執行的正是同一個更新後的執行框架。搭配的數據是上方的 OSWorld 2.0 結果——72.6%，每項任務約需 40 分鐘，比 Sol 每項任務少約 47% 的時間。

對開發者而言，實際後果是值得委派的工作改變了。過去太慢而無法端到端自動化的工作流程——在沒有 API 的情況下操作預備環境主控台、透過 UI 重現錯誤、走完多步驟表單以產生測試資料——現在落入了代理執行比手動處理更便宜的範圍。這也提高了 Ope​nAI 同步推出的企業端控制機制的價值：ChatGPT Work 與 Co​dex 新增了確認政策，也就是在會造成重大後果的動作前先取得核准，以及自動審查不安全或未經授權的工具呼叫。如果你讓代理在真實介面上逐一點選操作，那層審查就是擋在一次糟糕的執行與一個糟糕的下午之間的東西——而這也是為什麼企業版存取預設為關閉、由管理員依適用費率表啟用，是一項治理功能，而非障礙。

為工作流程定價，而非代幣

以下是價格，附有名稱與日期。取自 OpenAI 的定價頁面，讀取日期為 2026-09-16：gpt-6-astra 標準版為每百萬個輸入 token $10.00、每百萬個快取輸入 token $1.00、每百萬次快取寫入 $12.50，以及每百萬個輸出 token $50.00。Batch 和 Flex 以這些費率的一半計價；Fast 模式則加倍。在代理式迴圈中，決定你帳單的就是那條快取輸入計價項目，因為程式設計代理在每一輪都會重新傳送一大段大致未變的上下文，而快取輸入的成本只有全新輸入的十分之一。

在開始計算之前，有兩個門檻值得注意。OpenAI 的模型文件指出，超過 272,000 個輸入 token 的提示，其輸入與快取費率以 2 倍計價、輸出以 1.5 倍計價針對整個請求——而不只是超出的部分；定價頁面上的長上下文一列為輸入 $20.00、快取輸入 $2.00、輸出 $75.00。此外，每個推理 token 都按輸出費率計費，如上所述。

以一個實際的整夜重構為例：150 個模型回合，每回合平均 100,000 個輸入 token，其中 90,000 個是快取讀取、10,000 個是全新內容，而每回合有 4,000 個輸出 token（包含推理）。在 272K 門檻以下，以標準費率計算：

• 快取輸入 — 90,000 個 token × 每百萬 $1.00 = 每回合 $0.090

• 全新輸入 — 10,000 個 token × 每百萬 $10.00 = 每回合 $0.100

• 輸出 — 4,000 個詞元 × 每百萬 $50.00 = 每回合 $0.200

• 總計 — 每回合 $0.390，所以 150 回合的這次工作階段約為 $58.50

現在把同一個工作階段移過門檻。在每回合 300,000 個輸入 token 時——其中 270,000 個已快取、30,000 個全新——整個請求會重新計價，因此快取輸入加倍到 $2.00，全新輸入加倍到 $20.00，而輸出則提高到 $75.00：

• 快取輸入 — 270,000 × 每百萬 $2.00 = 每回合 $0.540

• 全新輸入 — 30,000 × 每百萬 $20.00 = 每回合 $0.600

• 輸出 — 4,000 × 每百萬 $75.00 = 每回合 $0.300

• 總計 — 每回合 $1.44，或 150 回合約 $216.00

同樣的任務型態，帳單大約是 3.7 倍，而全部的差異就在於你的逐字稿落在 272,000 個 token 的哪一側。這就是筆記機制的一句話論點：如果持久筆記與可搜尋的歷史紀錄能讓你維持更精簡的工作上下文，而不是把整份逐字稿一路拖著走，那麼這項功能在它對品質有任何幫助之前，光靠輸入 token 就能回本。這同樣也是不該讓無人看管的執行把逐字稿成長到沒有上限的論點。

為了提供規模感，在較便宜的層級上，相同 token 用量組合的同一場 150 回合工作階段：GPT-5.6 Terra 依其公布的 $2.00 輸入 / $0.20 快取 / $12.00 輸出價格計算，約為 $12.90；而 GPT-5.6 Luna 依 $0.20 / $0.02 / $1.20 計算，則約為 $1.29。這些只是根據 OpenAI 公布費率所做的算術，並不表示它們能完成同一項任務——而這正是接下來兩節的重點所在。

如果你正在跨供應商比較這一切，那麼值得知道的是，OrcaRouter 以 0% 加成將供應商定價原樣傳遞，因此供應商的價格變動會在同一天於路由端點上生效，而不是等到下一期帳單才反映。

設計時應考量的失效模式

Astra 是一款採用長上下文設計的長時程模型，而這描述中的兩個部分，正是問題所在。這些是社群發現與廠商事後檢討，並非我們的實測。

• 上下文管理實驗這週出了個錯誤。OpenAI 在 2026-09-12 的事後檢討報告中確認，這項自願加入的實驗「造成提早中止，以及回覆過時訊息」，影響約 4,000 至 5,000 名使用者，該實驗已被停用。同一份事後檢討報告還點出上線當週品質抱怨的另外兩項原因：為較早模型撰寫的技能發生誤觸，使 Astra 無法檢查自己的工作；以及設定錯誤的服務引擎導致一部分尾端流量品質下降。隨後在 09-12 跨入 09-13 的午夜進行了用量重置。

• 過度思考與測試蔓延。一個廣為流傳的 r/codex 討論串描述 Astra 在回應一個小型功能請求時，先建構層層的驗證、冒煙測試與雜湊檢查，以數種順序執行它們，並回報使用量計量器已接近耗盡，而這一切遠在該功能存在之前。這些回報是個人記述，而非受控測量，而且類似抱怨在前一個月也圍繞其他前沿模型流傳——因此應把它視為一個需要界定範圍的真實模式，而不是一個你可以據以規劃的比率。

• 不會終止的執行作業。Flask 的創作者 Armin Ronacher 描述，他曾讓 Astra 在無人監督下執行 35 小時，最後它產出了大約 75,000 淨行數、橫跨 79 次提交、約 1,400 則代理對代理訊息，以及約 1,200 美元的 API 費用——每次提交約 15.50 美元——而依他的評估，並未交付任何有價值的東西。關於 token 數量的說法不一，因此那個數字僅供參考。他將缺少停止條件定調為既是執行框架問題，也是模型問題；這是有可操作性的解讀：在開始前先定義完成條件。

• 相反方向的失敗也存在。社群回報指出，Astra 會在任務尚未完成時就停下來，等待提示才繼續；這是從另一側看到的同一個根本原因——對「完成」的定義不夠明確。明確界定「完成」是你任務提示中價值最高的一行。

• 長時間的工作階段可能變得無法復原。Open Co​dex 的未結案回報指出一種進退兩難的處境：上下文視窗被填滿、自動壓縮隨之觸發，而壓縮任務本身又耗盡了上下文，導致該對話串無法復原；另外，在某些設定下，Pro 版搭配 Astra 時，原生筆記與歷史紀錄路由會回傳 404，而切換視窗則可能捨棄任務狀態。這兩者都是尚未結案的回報，而非廠商官方說法，但它們都主張應將每次執行以檢查點形式保存在 git 中，而不是信任工作階段能自行存續。

• 過時筆記是一種設計特性，不是缺陷。沒有任何機制保證筆記能反映它所描述檔案的當前狀態，而且搜尋是字面子字串比對，而非語意比對。將來源路徑與筆記一併儲存，在變更時重新驗證，並把無人值守執行所產生的筆記視為待查核的證據，而非可依賴的真相。

• 用量上限是目前的主要抱怨。2026年9月14日當週的報告指出，上限比推出當週緊縮達四倍，以及一項尚未解決的抱怨：xhigh 投入消耗的額度比 medium 還少——如果此事屬實，代表投入與配額並未同步變動。OpenAI 尚未公布 Astra 各方案的具體數字上限。

當更便宜的模型才是正確選擇時

上述的實測結果已替你做出路由決策。Astra 的優勢集中在跨越檔案或跨越數小時的工作上：跨檔案審查、長時間跨度的代理式任務、電腦使用流程。在一般單檔編輯、機械式重構、測試骨架與格式化上，相較於 GPT-5.6 Sol 約 4% 的整體審查差異，並不足以合理化目前約 2.5 倍的每 token 價格——而 CodeRabbit 自身的結論也指向同一方向，建議採用智慧任務路由，而非全面替換。把昂貴的模型保留給其優勢能展現的任務，其餘則路由到較低階的模型。

具體來說，一個可行的分工方式是：跨檔案變更、不熟悉的程式碼庫、長達數小時的代理執行，以及任何涉及瀏覽器的工作，都交給 GPT-6 Astra；範圍明確的編輯、樣板程式碼和測試生成，交給 GPT-5.6 Terra；分類、擷取，以及大量機械化的處理，則交給 GPT-5.6 Luna。根據上述工作階段的計算，全部都用 Astra 執行，與只把其中三分之一交給 Astra 執行，差別在於同樣 150 回合下，費用大約是 $58.50 與大約 $28 之分。

要把這個切分做對，正是路由層存在的意義。OrcaRouter 讓 200 多個模型共用同一組 API，因此上述的切分只需改一項設定，而不是得做三套整合——而自動容錯移轉意味著某個實驗性功能表現不佳的一週（就像這次一樣）只會拖慢你的執行，而不是讓它直接中斷。對於一個其脈絡機制連 OpenAI 自己都仍標為實驗性、還曾短暫停用的模型來說，預先配置第二條路徑並非多疑，而是恰到好處的謹慎。

從這裡要關注什麼

有四件事會改變這個頁面，而這四件全都尚未定案。情境管理實驗是否會重新啟用、以及以何種形式回歸——OpenAI 表示它將成為 Astra 的預設值，這意味著上方那行設定最終將不再是你需要自行設定的項目。Pro 上的筆記與歷史紀錄 404 回報是否會結案，因為這決定了該機制是如文件所述般運作，還是只在某些路徑上運作。OpenAI 是否會公布任何依各 effort 層級區分的 token 或成本資料，而這正是現今每一項 effort 決策中缺失的那個數字。以及在上線週期間收緊的使用量上限，是否會在導致 2026-09-10 暫停新 $200 Pro 訂閱的需求被消化之後放寬。

在那之前，這套操作指南很短。用 codex -m gpt-6-astra 鎖定模型，只有在用戶端具備 Plus、Pro 或 Pro Lite 登入時才開啟這項實驗，明確設定 effort，而不要相信滑桿標籤，將工作上下文保持在 272,000 個 token 以下，因為超過那裡帳單就會翻倍，在離開前先定義好「完成」的標準，並把簡單的工作導向更便宜的地方。這個模型來自 2026-09-03，而且它不會消失；圍繞它的工具生態才是仍在穩定下來的部分。

出現的問題

對於一般規模的任務，跨視窗筆記功能值得啟用嗎？一般來說不值得。它的存在是為了解決跨越上下文視窗邊界的遺失問題，因此對於能容納於單一視窗的任務，它只會增加更多環節——包括一條在 2026-09-12 因某個錯誤而被停用的實驗性程式碼路徑——卻沒有消除任何痛點。長時間跨度的作業請開啟它，而範圍明確的編輯則保持關閉。

1,050,000 token 的視窗能取代我設定中的檢索嗎？ 就成本而言並不能。每一回合都把龐大的上下文重新讀取一遍，就會每一回合都計費，而且輸入一旦超過 272,000 個 token，整筆請求就會重新計價為輸入 $20.00、輸出 $75.00。能讓工作上下文維持較小的檢索步驟，通常是更省錢的設計，這也是筆記機制之所以有意思的原因：它是內建在執行框架裡的檢索。

任務結束時，這些筆記會怎麼樣？OpenAI 的文件將這個機制的適用範圍限定在同一個任務內，而社群的相關文章則描述這些筆記是儲存在該任務之下，而不是自動延續下去。不要假設新的任務會繼承前一個任務的筆記；任何必須留存下來的內容都應該放在你的儲存庫裡，而不是代理的記憶中。