←返回 AI 專欄列表
2026-10-12•9 min read · 9 分鐘閱讀•Joseph Cheung

AI 日報|Codex 28 日更新 Day 7:GPT-6.1 Sol 預設上下文升至 500k,訂閱用量免長上下文附加費

OpenAI Codex/ChatGPT Work 28 日更新第 7 日:GPT-6.1 Sol 在 Codex 與 Work 的預設上下文由 272k 提升至 500k(約 80%),上限仍為 1M;以訂閱扣用量時不再收長上下文附加費。本文整理官方資料,並分析香港企業可以怎樣跟進。

#AI 日報#AI 工具#香港企業 AI

OpenAI 的 Tibo(Thibault Sottiaux)承諾,28 日內每日為 Codex/ChatGPT Work 用戶推出一項明確改善,否則送一次完整重置。第 7 日(美國時間 10 月 11 日,星期日)在香港時間 10 月 12 日 07:45 公佈:把 GPT-6.1 Sol 在 Codex 與 Work 的預設上下文長度由 272k 提升至 500k,並在兩分鐘後補充,以訂閱扣用量時不再收取長上下文附加費。

以下只整理 OpenAI 官方帳號已公佈的內容,再談香港團隊可以怎樣用。

第 7 日公佈了甚麼?

GPT-6.1 Sol 預設上下文:272k → 500k(約 +80%)

  • Tibo 在香港時間 10 月 12 日 07:45 發出 Day 7 帖文:透過 Codex 與 ChatGPT Work 使用 GPT-6.1 Sol 時,預設上下文長度由 272k 提升至 500k,約增加 80%。
  • 他表示,未來還會再提高;今次調整經過仔細測試,認為是多數用戶目前的「甜蜜點」。主要好處是減少 compaction(上下文壓縮/摘要)發生次數,以及較適合需要長時間保留大量上下文與細節的任務。
  • 用戶仍可自行調高或調低;GPT-6.1 Sol 的最大上下文長度為 1M。截至發稿,官方未有說明桌面版或 CLI 的具體調校路徑,亦未說明是否即時對全部帳戶生效。
  • 帖文只針對 GPT-6.1 Sol 在 Codex & Work;沒有寫明 GPT-6 Astra、其他模型,或一般 Chat 是否同步改預設。

訂閱用量:不再收長上下文附加費

  • 香港時間 07:48,Tibo 回覆補充:「With this change, we are not charging long context fees for GPT-6.1 Sol when drawing usage from the subscription.」即:從訂閱方案扣用量時,GPT-6.1 Sol 不再收取長上下文附加費。
  • 這與 API 按量計費是兩套邏輯。官方 API 文件與 changelog 早前仍以約 272k 輸入作為標準價與長上下文定價的分界;今次帖文明確說的是訂閱用量。截至發稿,官方未有說明 API key 用量是否仍按長上下文加價,亦未說明各訂閱方案是否全部適用。

官方其他渠道(截至本文截稿)

  • 截至香港時間 10 月 12 日上午,OpenAI Developers、ChatGPT、OpenAI 官方帳號,以及 Help Center Release Notes、developers changelog,都未見為 Day 7 另發說明。今次以 Tibo 的 Day 7 帖文及回覆為主要來源。

對香港中小企及團隊有甚麼實際意義?

DEPTAI 的看法:預設 500k 夠用就好——唔好一開始拉滿 1M 食爆額度。 香港團隊做長任務、多檔重構,先用預設 500k 跑就足夠;Tibo 都講咗呢個係經測試嘅「甜蜜點」。一開始拉滿 1M,每輪都要帶住大量舊內容,額度燒得快,亦更易夾雜過期指示同錯檔。我哋建議先記低一週 compaction 次數同人手介入點,真係經常撞到壓縮先逐步調高,並繼續保留權限同結果驗收。

先處理使用資格。 我們在 10 月 12 日再次查閱 OpenAI 官方的 ChatGPT 支援地區名單,仍然沒有列出香港。香港公司在評估前,應先確認可合規使用的途徑及數據條款。截至發稿,官方未有說明香港企業目前可用的官方或企業渠道。

確認使用資格後,這日更新對「長任務、多檔案、少中途被壓摘要」的團隊特別有用:

  1. 長 Agent 任務少一次被迫壓縮。 預設從 272k 拉到 500k,意味著同一條多檔重構、跨模組除錯,或連同規格/測試紀錄一起跑的流程,較少因為上下文滿而自動 compaction。設計 AI 員工方案 時,仍要保留人工驗收點:上下文變長,不代表可以省掉權限與結果覆核。
  2. 訂閱內長上下文的成本模型變了。 以前超長對話可能觸及長上下文附加費;現在 Tibo 寫明訂閱扣用量不再收這筆。適合把「本來想轉 API 硬撐長 session」的工作,先改回在 Codex/Work 訂閱額度內試跑,再對比延遲與品質。API 專案仍要按自己的帳單核對。截至發稿,官方未有說明 API 長上下文價目是否同日有變。
  3. 500k 是預設,不是上限。 需要時可調到最高 1M,亦可以調低以節省用量或加快回應。建議團隊先用預設跑一週,只在「真的經常撞到 compaction」或「任務明確要更大視窗」時再改設定,避免一開始就拉滿 1M 耗光額度。
  4. 跟近日功能一併驗收。 Day 4 的 steering、Day 5 的 Composer predictions、Day 6 的重置額度,都適合在更大預設上下文下做一輪對比:同一條 自動化流程 記低 compaction 次數、人手介入次數和完成時間,再決定寫入 SOP。

延續我們在第一篇 28 日更新文章的建議:每項更新分「已公佈」、「帳戶已可用」和「團隊已驗收」三欄;今次要驗的是預設是否已變 500k、訂閱帳單有沒有長上下文加價,以及長任務的 compaction 是否明顯減少。

想知道這些更新怎樣用在你的公司?

DEPTAI 可以幫你評估長任務該用多大的上下文、怎樣在訂閱額度內安排可驗收的 Agent 流程。了解我們的 AI 員工方案,或預約 AI 諮詢。

本文未有在香港帳戶上驗證預設是否已改為 500k,亦未核對訂閱帳單。實際可用情況請以你的帳戶及 OpenAI 官方後續說明為準。

資料來源

JC
Joseph Cheung

Deptai 生成式 AI 顧問團隊 · 專注於香港中小企 AI 自動化、智能 Agent 開發與企業內訓,致力協助在地品牌以低成本快速升級為 AI 驅動企業。

預約您的免費30 分鐘業務診斷

帶著您最複雜的工作流程前來。我們會清楚說明 AI 系統能接手哪些部分,以及哪些部分暫不適合。

WHATSAPP 聯絡