GPT-6 Astra API：模型 ID、端點，以及長程任務的真實成本

The short version: GPT-6 Astra is callable today at https://api.openai.com/v1 under a single model id, gpt-6-astra, at $10.00 per million input tokens, $1.00 cached input and $50.00 output — the figures Ope​nAI's own pricing page carried on September 16, 2026. The model itself is from September 3, 2026, thirteen days before this page was written, so nothing here is launch coverage and nothing here is framed as an announcement. This is the reference page for the developer question that comes after availability: what string to pass, which endpoint takes it, what the 1,050,000-token window really buys, what the account has to look like first, and what one genuine long-horizon agent run costs on a rate card that quietly reprices itself above 272,000 input tokens. GPT-5.6 Sol appears throughout only as the price baseline it is sold above, never as the subject.

一個十三天大的模型本週之所以值得佔有一頁篇幅，原因在於通往它的途徑在發布之後出現了變化，而 API 途徑如今已成為尋常的那一條。OpenAI 於 9 月 3 日推出 Astra 時，描述的是逐步推出，而非正式可用；到了 9 月 8 日，它表示該模型已在 Codex 與 ChatGPT Work 中向 Plus、Pro、Business 與 Enterprise 使用者全面推出；而到了 9 月 14 日當週，AWS 已將其列入 Bedrock，Microsoft Foundry 也將其列為正式可用。對 API 呼叫者而言，這個順序的重要性不如聽起來那麼高——該端點自始至終都已上線並有文件記載——但這確實意味著，圍繞它的採購問題如今有了在發布當天所沒有的答案。以下所有內容均於 2026 年 9 月 16 日讀取自 OpenAI 自家的模型文件、定價頁面與資料控制頁面；任何來自其他來源的內容，都會在承載它的句子中註明。

模型 ID，以及對快照問題的誠實回答

要傳入的字串是 gpt-6-astra——全小寫、以連字號連接、不含廠商前綴。這是 OpenAI 為此模型記載的唯一識別碼。

如果你在找一個帶日期、可以固定（pin）下來的快照，那是找不到的，我們也不會憑空編造一個看起來很合理的後綴。Ope​nAI 的 GPT-6 Astra 模型頁面在 Snapshots 底下只列了一個項目，就是單純的 gpt-6-astra。-2026-09-03 這種帶日期的形式並不存在，廠商端也沒有-latest 這樣的別名。我們在研究期間曾於某個路由器清單上看到 ~openai/gpt-astra-latest 這種形式的浮動別名；那是架在廠商 id 之上的閘道器（gateway）產物，並非 Ope​nAI 所發布，你不該把它當成官方 id 寫進你的設定裡。

實際影響不大，但值得說明。你可以取得模型物件，以確認你正在與什麼對話：

curl https://api.openai.com/v1/models/gpt-6-astra -H "Authorization: Bearer $OPENAI_API_KEY"

把裸 id 釘在設定值裡，而不是把它打進十幾個呼叫點。如果 Ope​nAI 之後新增了帶日期的快照，裸 id 就會變成移動中的目標，而你釘選的值也會開始在你底下變動——只需編輯一個地方，就是兩分鐘就能改完，還是要花一整個下午 grep 的差別。

端點：基底 URL、相容性，以及一個可執行的請求

The base URL is https://api.openai.com/v1. Per Ope​nAI's model documentation, GPT-6 Astra is supported on Responses (/v1/responses), Chat Completions (/v1/chat/completions) and Batch (/v1/batch). It is explicitly not supported on Realtime, Assistants, Fine-tuning, Embeddings, image generation and editing, video, audio, moderation, or the legacy Completions endpoint — and those absences matter as much as the presence list, because a team that planned around the Assistants API or a fine-tuned variant has to replan rather than rewrite.

關於相容性：這是 Ope​nAI 自家的第一方 API，也就是每個 Ope​nAI 相容 SDK 與用戶端在開發時所依據的傳輸格式。任何能使用該格式的程式，都能直接與 gpt-6-astra 溝通，無須任何轉接層——你只需更改模型字串，而如果你是從較舊的 Ope​nAI 模型移轉過來，還需更改下方的參數名稱。新的開發工作應使用 Responses API：Ope​nAI 正是在這個介面上說明此模型的推理控制，內建工具也位於此處，而就最新模型而言，Chat Completions 的支援一向是兩者中較為薄弱的一方。

一個最小化的串流呼叫，並設定推理強度：

curl https://api.openai.com/v1/responses \

-H "Authorization: Bearer $OPENAI_API_KEY" \

-H "Content-Type: application/json" \

-d '{"model": "gpt-6-astra", "input": "列出若要讓此服務脫離舊版驗證 API，你會變更哪些檔案。", "reasoning": {"effort": "high"}, "max_output_tokens": 16000, "stream": true}'

以及在 Python 裡做同樣的事，而這正是大多數讀者實際上會使用的地方：

from openai import OpenAI

client = OpenAI()

stream = client.responses.create(model="gpt-6-astra", input="列出你會為了將此服務從舊版驗證 API 移轉出去而修改的檔案。", reasoning={"effort": "high"}, max_output_tokens=16000, stream=True)

for event in stream:

if event.type == "response.output_text.delta": print(event.delta, end="")

關於那項要求，有三點是這個模型特有的，而不是從通用的快速入門指南複製而來。

• 推理強度是成本調節旋鈕，而不只是品質調節旋鈕。 Ope​nAI 的模型頁面將支援的值列為 low、medium、high、xhigh 與 max。請注意這份清單的起點：GPT-6 Astra 沒有 none 或 minimal，因此下限往上移了。推理 token 以每百萬 $50.00 美元的輸出 token 計費，這意味著把強度從 high 調到 max，是個附帶價格的決定，而不是免費的品質升級。

• 支援串流，而這是執行長時間回合的誠實做法。 對此模型發出單一請求，最多可產生 128,000 個輸出 token。等待它全部送達單一回應主體，卻無法得知是否正在進行，最後就會變成用猜測來設定逾時。

• 這裡的提示快取是明確的。Responses API 在文字、圖像與檔案內容上記錄了 prompt_cache_breakpoint，模式為 explicit，用以標示「可重複使用提示前綴的確切結尾」，並從請求的 prompt_cache_options.ttl 繼承其 TTL。在快取輸入費率只有未快取費率十分之一的模型上，你把這條界線放在哪裡，就是請求中槓桿效益最高的一行。

1,050,000 個 token 的視窗實際上代表什麼

文件記載的數字為 1,050,000 個 token 的上下文視窗、922,000 個 token 的最大輸入、128,000 個 token 的最大輸出，以及 2026 年 4 月 30 日的知識截止日期。

先從大家常忽略的算術說起：922,000 加 128,000 等於 1,050,000。這個視窗是由你送出的內容與模型可能回傳的內容共用，而輸出上限是從中保留出來的。你不可能送出 1,050,000 個 token 的輸入；單次請求的實際上上限是 922,000，而且如果你想留點空間給真正的回答，還得比這更少。

一百萬個 token 換算成你實際工作使用的單位，能換到什麼？token 對文字的換算只是近似值，而且這些數字是我們的，不是 OpenAI 的，但數量級是對的：以每個 token 約四個字元計算，1,050,000 個 token 大約相當於 750,000 個詞，或大約十萬行程式碼。這是一整座中型儲存庫，而且還留有餘裕，可容納代理程式在工作時產生的工具輸出。這個模型所主打的長時程情境正是如此：一個代理程式一小時前讀過某個檔案，現在仍能看見它當時的內容，而不是那種已經把整個上午壓縮成一段摘要的代理程式。

接著是屬於成本頁面、而非規格頁面的部分。Ope​nAI 的模型文件指出，輸入 token 超過272,000 個的提示，其整筆請求的輸入與快取費率以 2 倍計，輸出則以 1.5 倍計。定價頁面則以第二列呈現：GPT-6 Astra 的長上下文為輸入 $20.00、快取輸入 $2.00、輸出 $75.00。所以該視窗上方四分之三是一個價格區間，而不只是可用餘裕。一場逐字稿超過 272,000 個 token 的執行，整筆請求的每一個輸入 token——包括快取的那些——都得付雙倍價，而這是此模型經濟效益中單一最大的變動因素。以下將完整推演。

還有一個值得了解的機制，因為這是廠商自己承認單一視窗並非完整解答。針對 Co​dex，Ope​nAI 描述了一種隨 Astra 推出的實驗性脈絡做法：筆記會跨脈絡視窗持續保存，而不是反覆壓縮成單一摘要，且較早的視窗仍可搜尋，因此先前訊息與工具輸出中的需求和測試結果依然找得到。Ope​nAI 稱之為實驗性，表示它已在 Co​dex 的 config.toml 中啟用，並說它將成為 Astra 的預設做法。如果你要在 API 上自行打造對等的機制，那就是該效法的形態：持久的筆記加上可檢索的歷史，而不是靠一個英雄式的提示詞。

還有數字本身的限制：大視窗是一種容量，並不保證能涵蓋整個視窗的注意力。廠商報告的長時程數據，比 token 數更能作為行為的參考——Ope​nAI 回報 OSWorld 2.0 在每項任務約 40 分鐘時達到 72.6%，而 Terminal-Bench 4.0 為 57.9%，相較之下 GPT-5.6 Sol 為 37.3%。那些是 Ope​nAI 自家公布的數字，我們並未重現；而獨立評測的情況相近但不完全相同：Artificial Analysis 測得 Astra 在 Terminal-Bench v4.0 上為 59.1%，相較之下 Claude Fable 5.1 為 52.0%、GPT-5.6 Sol 為 39.9%。兩者都同意，相較前一代，長時程的差距確實存在；但兩者都不能取代你自己實際跑一遍任務。

輸入模態，以及坦誠保持開放的檔案問題

OpenAI 的模型頁面列出輸入模態為 文字與圖像，輸出為文字。此模型不支援音訊、視訊，也不支援圖像生成。

圖片輸入會以內容部分的形式放在使用者訊息中。該部分的類型為 input_image，而圖片可透過 image_url 以完整限定的 URL 或 base64 資料 URL 提供，或使用 Files API 的 file_id 提供。另有一個選用的 detail 參數，可設為 auto、low、high 或 original，預設為 auto。其結構如下：

{"model": "gpt-6-astra", "input": [{"role": "user", "content": [{"type": "input_text", "text": "這張截圖有什麼改變？"}, {"type": "input_image", "image_url": "data:image/png;base64,...", "detail": "high"}]}]}

OpenAI 的視覺功能說明文件將 PNG、JPEG、WEBP 和非動畫 GIF 列為可接受的格式，每次請求的總酬載上限為 512 MB，每次請求最多 1,500 張圖片；超過 30,000 個 patch 的圖片會遭到拒絕，而不是縮小尺寸。這些是平台的通用視覺限制，而非 Astra 專屬的限制；圖片會像任何其他輸入一樣以 token 計費。

現在來談讀者真正帶著來的問題，以及誠實的答案。你可以傳送檔案或 PDF 嗎？ 我們無法在 Ope​nAI 的文件中確認這個模型支援文件輸入，而我們也不會暗示它可行。Responses API 確實定義了 input_file 內容部分，所以這套管道機制在 API 中普遍存在；但 Ope​nAI 的 GPT-6 Astra 頁面將文字與圖像列為其輸入模態，並未列出檔案，而我們也沒找到任何 Ope​nAI 的說明記載此端點支援 PDF 輸入。同一模型的某個路由器列表確實顯示檔案與文字、圖像並列——請把那視為路由器自行回報的資訊，那是路由器對某條路由的記錄，而非供應商的保證。如果文件擷取對你的工作負載是關鍵支撐，請在據此建構之前，先對真實端點進行測試，並準備好 OCR 轉文字的備援方案。這就是花一個下午測試與整個重寫之間的差別。

完整價格明細，以及一次長遠期程的推演報價

本節的每一項數字都取自 OpenAI 自家的定價頁面，讀取時間為2026年9月16日，且除該行另有註明外，所有數字均為 Standard級別下每百萬個 token 的價格。

• 短上下文，輸入最高 272K — 輸入 $10.00、快取輸入 $1.00、快取寫入 $12.50、輸出 $50.00。

• 長上下文，輸入超過 272K — 輸入 $20.00、快取輸入 $2.00、快取寫入 $25.00、輸出 $75.00，適用於整筆請求。

• Batch 與 Flex——Standard 的一半：短上下文 $5.00 / $0.50 / $6.25 / $25.00，長上下文 $10.00 / $1.00 / $12.50 / $37.50。

• 快速模式 — 標準方案的兩倍：$20.00 / $2.00 / $25.00 / $100.00（短上下文），$40.00 / $4.00 / $50.00 / $150.00（長上下文）。Ope​nAI 指出，具備歐盟資料駐留的 GPT-6 Astra 無法使用快速模式。

• 資料落地 — 使用此功能的端點，對 2026 年 3 月 5 日（含）之後發布的模型需加收 10% 費用。GPT-6 Astra 符合資格，因此採用資料落地的部署，會比上述所有數字高出 10%。

要內化的數字是快取輸入費率。$1.00 對比 $10.00，等於對你再次送出的那部分提示詞省下 90%——而在代理工作負載中，那幾乎就是整段提示詞。快取寫入以 $12.50 計費，也就是未快取輸入費率的 1.25 倍，所以損益兩平很簡單：100,000 個 token 未經快取送出兩次要花 $2.00，而將該前綴寫入一次再讀回一次則花 $1.35。從第二次重複使用起，快取就開始划算，而代理若在同一份對話記錄上運作一百輪，就會重複使用它一百次。

這就帶我們進入真正決定這個模型是否可負擔的算術，因為宣傳費率並不是最終出現在帳單上的數字。以下是我們所做的模擬運行——根據 OpenAI 公布的費率建立，並非實測帳單——針對該模型所主打的那類任務：一個自主編碼代理在數小時內進行儲存庫規模的遷移，120 次模型呼叫，一份工作對話記錄，隨著累積，平均每次呼叫約有 500,000 個輸入 token，其中 80% 的輸入由快取提供，以及整個運行過程中包含推理在內共 400,000 個輸出 token。

按短上下文標準費率：

• 未快取輸入 — 1,200 萬個 token × $10.00 = $120.00

• 快取輸入 — 48M 詞元 × $1.00 = $48.00

• 輸出 — 0.4M tokens × $50.00 = $20.00

• 本次執行總計 ≈ $188.00

同一輪執行在長上下文區段，這正是每次呼叫超過 272,000 個 token 的逐字稿實際會得到的結果：

• 未快取輸入 — 1,200 萬個詞元 × $20.00 = $240.00

• 快取輸入 — 48M 詞元 × $2.00 = $96.00

• 輸出 — 0.4M 個詞元 × $75.00 = $30.00

• 本次執行總計 ≈ $366.00

由此可得出兩項結論，而兩者都無法從標題費率看出來。首先，你的對話紀錄存放在哪裡，和你選擇哪個模型一樣重要——同樣的任務會因為是否跨越 272K 門檻而成本大約翻倍，這使得上下文紀律（擷取正確的 100K，而不是帶著 600K）在這款模型上成為一種成本控制技巧，而不只是效能手段。其次，快取的價值比帳面折扣所顯示的更高：在完全沒有快取命中的情況下，第一個情境要背負 $600.00 的輸入成本，而非 $168.00，整次執行約花費 $620，而非 $188。在調高推理強度之前，先把快取打開。

就基準情境而言，在 Ope​nAI 定價頁面於 9 月 16 日顯示的費率下，GPT-5.6 Sol 上相同的 token 組合——短上下文為輸入 $4.00、快取輸入 $0.40、輸出 $20.00——大約是$75.20，而在 Sol 的長上下文級距（$8.00 / $0.80 / $30.00）下大約是$146.40。這使得這次執行在任一級距上都約為2.5 倍。關於這個倍數有兩點但書，因為它已在其他地方造成混淆：Sol 的數字是促銷費率——Ope​nAI 表示該促銷至少提供至 2026 年 11 月 21 日——而 Astra 的是牌價，因此這個倍數衡量的是今天的兩張價目表，而非關於這些模型的穩定事實，而且若促銷到期，這個倍數就會縮小。另外，外界流傳關於 Astra 的較舊「2.5 倍」，有時是對照 Sol 促銷前的牌價 $5.00/$30.00 計算，這樣得出輸入 2 倍、輸出約 1.67 倍。請說明你指的是哪個 Sol 費率，否則這個數字毫無價值。

再補一句：Batch 方案會把這些全部減半，讓首次執行降至大約 $94。你能不能使用它，取決於下一節。

零資料保留，以及那個會自我取消資格的折扣

Ope​nAI 指出，「零資料保留」（Zero Data Retention）適用於符合資格的 API 客戶，可在支援的端點上使用，但須經核准——而這句話的兩個部分都各有其實際作用。這不是自助式的切換開關：資格取決於 Ope​nAI 事先核准並接受額外要求，而且必須透過與業務團隊洽談才能啟用。一旦核准，即可在「設定 → 組織 → 資料控制」的「資料保留」分頁中，於組織或專案層級進行設定；專案可沿用組織預設值、明確設定 ZDR、選擇「修改後的濫用監控」，或將兩者一併停用。

實際上它改變了什麼：ZDR 會將客戶內容排除在濫用監控記錄之外，取代原本最多 30 天的預設保留期；而且即使請求試圖將 /v1/responses 和 /v1/chat/completions 上的 store 參數設為 true，該參數仍會被視為 false。

在一頁談成本的內容中，最要緊的細節是：/v1/batches 不在符合 ZDR 資格的端點清單上。 Ope​nAI 的資料控管頁面將其列為不符合資格，應用程式狀態會保留至刪除為止。因此在 GPT-6 Astra 上，Batch 層級的 50% 折扣與零資料保留（Zero Data Retention）彼此互斥——受法遵約束且需要 ZDR 的工作負載，應以 Standard 費率編列預算，而非 batch 費率，且上述的 94 美元數字並不適用於它。

還有三點但書要明白直說，因為一個過度吹捧 ZDR 的頁面，比完全略過不提的頁面更糟。ZDR 並非絕對：在「Eyes Off」下，OpenAI 保留權利，可事先書面通知後，讓特定客戶的模型不具 ZDR 資格；而在「Safety Retention」下，當分類器標記出嚴重風險時，內容可能會被保留並交由人工審查。被標記為可能涉及 CSAM 的圖片與檔案輸入，即使在 ZDR 下仍會保留以供人工審查。而且 ZDR 止於 OpenAI 的邊界——如果你的代理程式呼叫遠端 MCP 伺服器或其他供應商的 API，該流量受該方的保留政策規範，而非本政策。另外，資料落地是與 ZDR 不同的控制措施，需要獨立的核准，且在美國境外需簽訂「Modified Retention」增補條款，並附帶上述的 10% 加價。如果你在 ZDR 下依賴快取，請閱讀 OpenAI 的資料控制頁面，了解快取會保留什麼；我們不會為它印出一個我們自己在該頁面讀不到的保留數字。

如文件所述的速率限制，以及最先咬人的那一個

OpenAI 的模型頁面公布了 GPT-6 Astra 的這些各層級限制——每分鐘的請求數與權杖數，接著是批次佇列限制：

• 第 1 級 — 500 RPM、500,000 TPM、批次佇列 1,500,000

• 第 2 層 — 5,000 RPM、1,000,000 TPM，批次佇列 3,000,000

• Tier 3 — 5,000 RPM、2,000,000 TPM、批次佇列 100,000,000

• Tier 4 — 10,000 RPM、4,000,000 TPM，批次佇列 200,000,000

• 第 5 級 — 15,000 RPM，40,000,000 TPM，批次佇列 15,000,000,000

我們要把兩項限制標示為 未記載，而不是自行補上：沒有任何已公布的免費方案限制，因為 GPT-6 Astra 根本不在免費方案內；而且我們在 Tier 5 以上找不到任何已公布的上限，Fast 模式也沒有另立的限制表。若供應商未公布某項限制，請把這項空缺視為尚未有定論——不要假設它沒有限制。

在 agent 工作負載中最先咬住你的數字，就是 Tier 1 的 500,000 TPM。在這個模型上，單次呼叫就能承載一份 500,000 token 的對話紀錄，這意味著單一請求就可能吃掉你在入門層級整整一分鐘的 token 額度。如果該層級推不動這些 token，那麼對一個會在同一份對話紀錄上盤踞 120 個回合的 agent 來說，百萬 token 的上下文視窗也沒多大用處。請依據上述範例中的 token 量來規劃層級，而不是依據請求數量——並請注意，層級提升取決於消費金額與帳戶歷史，所以值得在截止期限之前就先搞定，而不是等到期限當下才處理。

Azure 與 AWS Bedrock，各一行

• Microsoft Azure — GPT-6 Astra 可在 Microsoft Foundry 中以相同的 gpt-6-astra id 部署，Foundry 的報導將正式推出時間訂於 2026 年 9 月初，並指出有 Global Standard 與 US Data Zone 部署，推出時沒有 EU Data Zone，費率與 Ope​nAI 的定價表相同或相近，另有一列長上下文。我們是從 Foundry 的報導讀到這項資訊，而非微軟自家的目錄頁面——我們今天無法存取該頁面——在規劃部署前，請先查閱微軟自家文件，以確認目前的部署清單、區域組合與費率。

• AWS Bedrock — 以 openai.gpt-6-astra 的名義列出，可透過受支援的 Bedrock API 使用，並經 AWS 於 2026 年 9 月 15 日的每週彙整確認，具備 Bedrock 自身的治理邊界（VPC 端點隔離、KMS 加密、Guardrails），以及 AWS 聲明推論資料不會用於模型訓練。據回報，Bedrock 上的區域內推論與地理跨區域推論，計費比基本費率高 10%；依我們的判讀，該數字屬於二手來源，請查閱 AWS 自家的定價頁面。

兩條路線都不會改變模型本身。兩者改變的都是採購方式，而對企業讀者來說，這正是關鍵所在：Foundry 或 Bedrock 的部署可以納入既有的雲端採購承諾之內，沿用其 IAM、日誌記錄與網路邊界，並落在財務部門早已核准的請款單上——這往往就是試辦方案與真正能上線交付之間的差別。代價是，你得接受該雲端的模型生命週期與該雲端的費率，而據報導，這兩家雲端的定價都等於或高於 OpenAI 的牌價，而非低於。

路由器適合的位置，包括那些反對它的部分

GPT-6 Astra 已收錄在 OrcaRouter 的型錄中，型號為 openai/gpt-6-astra，而 OrcaRouter 以 0% 加價如實轉嫁供應商定價 —— 供應商的價格就是我們的價格，供應商一旦調價，當天就會反映在你的帳單上，而不是等到續約時才調整。對於這個價位的模型而言，這可不是什麼無關痛癢的說法：上面那筆算術，和你直接向供應商付款時的算術完全相同。

在這裡採用路由的真正理由不是價格，而是可逆性。Astra 大約是其下一階模型的 2.5 倍，而它的成本取決於你架構所掌控的某個門檻，因此多數團隊會想先在真實流量的一小部分上試用，再決定是否投入正式生產路徑。透過一組金鑰，你就能把它放在與現有模型相同的端點之後，將部分流量導給它，並在它未能展現出差異價值時自動切換到更便宜的方案——這是設定變更，而非遷移；單一 API 涵蓋 200 多個模型，一套路由 DSL 能將多個模型組合成單次呼叫，還能在你希望多個模型共同作答時使用模型融合。

反對它的部分，直白地說。路由器是請求路徑上多一跳，也是資料流中多一個參與方——而在這套模式下，這並非假設，因為 ZDR 在 OpenAI 是依組織逐一核准的，而經過路由的請求不會自動納入你的 ZDR 核准範圍。如果你傳送的是受監管資料，傳送前先確認該路徑的資料條款，並準備好針對該工作負載直接致電供應商。路由也會增加一個可能故障或增加延遲的元件，而且它讓更換模型變得輕而易舉，以致有可能在未經審查的情況下改變替你的使用者回答的模型。對多數團隊來說，這些都不足以抵銷試用與可逆性的理由；但在你認定路由器免費之前，這一切都值得了解。我們在另一篇文章中讓這些路由平台相互對比，而不是在此重述那項比較。

三個無法以單一子句回答的問題

我可以微調 GPT-6 Astra，或是透過 Assistants API 來使用它嗎？不行，兩者皆不支援，而且這是設計上的界線，而不是你漏掉了某項設定。Ope​nAI 的模型頁面將 Chat Completions、Responses 與 Batch 列為支援的端點，並明確將 Fine-tuning 與 Assistants 列為不支援，而且在 Ope​nAI 的微調價格表中並沒有 GPT-6 Astra 這一列。如果你的架構依賴於某個微調過的旗艦模型，那麼 Astra 就只能改用提示的方式來運作，這會把成本從訓練轉移到輸入 token 上——而以大型系統提示每百萬 token 10.00 美元的價格來算，這是一筆實實在在的預算項目，而非可有可無的附註。

模型會拒絕我有權進行的安全工作嗎？有時候會，而這點值得在你著手開發前先了解。GPT-6 Astra 是首個在公司《Preparedness Framework》下達到「關鍵網路安全能力」門檻的 OpenAI 模型，而在出廠狀態下，它會拒絕撰寫概念驗證攻擊程式等進階網路任務。OpenAI 表示，計劃透過 Daybreak 計畫以較寬鬆的防護措施擴大使用權限。對防禦方而言，這會表現為一種拒絕——既不是速率限制，也不是程式錯誤——請在你的錯誤處理中為它編列預算，而不是不斷重試硬闖。

呼叫這個模型需要特別核准嗎？標準端點不需要——呼叫 gpt-6-astra 既沒有候補名單，也沒有核准步驟，只要有一個已設定帳單的帳號就行。你可能需要核准的，是圍繞它的一切：Zero Data Retention（零資料保留），這需要提出申請並經審核；美國境外的資料存放地（data residency），這需要另行簽署修訂條款；以及層級升級（tier bump），如果你打算透過 Tier 1 帳號推送代理規模的權杖用量。模型本身是這整樁採購裡最簡單的部分。

有哪些看點，以及誰現在該採取行動

如果你要在這個模型上打造應用，值得留意的四件事全都落在供應商端，而且全都與日期綁定。OpenAI 是否會為 gpt-6-astra 發布帶日期的快照——這會讓單純的 ID 變成移動目標，也讓固定版本變得有意義。272,000-token 門檻是否會變動，因為那一行對你的帳單的影響，比頁面上任何基準測試都大。Bedrock 與 Foundry 的費率是否會收斂到 OpenAI 的牌價，或持續高於它，因為這對採購途徑的決定性不亞於模型本身。以及 Daybreak 計畫是否會改變端點會拒絕什麼，這對資安團隊來說，就是可用工具與展示品之間的差別。

至於誰該採取行動，分界很清楚。如果你已經以促銷價為長時間跨度的代理工作支付 GPT-5.6 Sol，那 2.5 倍是真實的，問題也很明確：在你自己的工作負載上，任務完成率能否勝過這個價差？把它跑在真實流量的一小部分上，就能找出答案——上面的實作範例會在你開始之前告訴你這一部分要花多少錢。如果你的工作是短脈絡的聊天或大量分類，這不是你的模型；長脈絡的重新定價和 $50.00 的輸出費率，會讓它成為用昂貴方式做某件 GPT-5.6 Luna 只需一小部分價格就能完成的事。而如果你是有合規要求的企業，請先開始 ZDR 的對話，因為它會決定 Batch 折扣、駐地加價和你的路徑選擇——而這些都不是你能在需要它的當天才做的決定。