GPT-6 Astra in Codex：クロスウィンドウノート、エフォートレベル、そして実際の請求額

GPT-6 Astraは2026-09-03のモデルであり、このページはローンチ時の報道ではない — 広く利用可能になった今、あなたのコーディングエージェントの向き先をこれにするためのリファレンスだ。開発者が乗り換える理由はある一つの具体的な仕組みにあり、それに費用をかける前に理解しておく価値がある。ウィンドウがいっぱいになるたびに長いセッションを単一の情報が失われる要約に圧縮する代わりに、GPT-6 Astraを搭載したCo​dexはコンテキストウィンドウをまたいでノートを保持し、以前のコンテキストウィンドウを検索可能なままにする。そのため、40ターン前に述べた要件も、10ターン前に失敗したテスト出力も、要約されて消えてしまうのではなく、どちらも依然として取り出せる。Ope​nAIはこの機能を実験的と呼び、Co​dexのconfig.tomlに一行書けば有効になり、Astraのデフォルトになる予定だという。以下のすべて — 正確な設定、エフォートレベル、計測された結果、そしてキャッシュ入力の行を明記したセッション請求の実例 — は、2026-09-16にOpe​nAI自身のページから読み取ったものであり、第三者の数値はすべてその旨が明記されている。

今週、それを採用する際の計算を変える2つの出来事があった。2026-09-12に、Ope​nAIのCo​dexリードは、コンテキスト管理実験自体にバグがあったことを確認するポストモーテムを公開した——それは早期停止と古いメッセージへの返信を引き起こし、その実験に参加していたおよそ4,000～5,000人のユーザーに対して無効化された——そしてOpe​nAIは09-12から09-13の真夜中にCo​dexとAstraユーザーの完全な使用量リセットを発行した。同じ週、ローンチ時にAstraがデフォルトでオフになっていたエンタープライズワークスペースが、独自のレートカードの下で管理可能になった。したがって、正直な立場はこうだ。メカニズムは採用する価値があり、ビルドはまだあなたの下で動いており、締め切りではなくブランチで試すべきである。

GPT-6 Astraを搭載したCo​dexで、実際に何が新しくなったのか

どんなコーディングエージェントでも6時間働かせようとすれば、必ず同じ壁にぶつかる。コンテキストウィンドウが埋まり、ハーネスは場所を空けるためにトランスクリプトを1つの高密度なブロックに要約し、その要約は、痛いところでちょうど情報を失う——以前の修正が失敗した理由、失敗しているテストの正確な形、ユーザーが第3ターンで何気なく口にした制約。実際に欲しいのは、要約された詳細ではなく、取り出された詳細なのだ。

AstraのCo​dex統合は、その形を変える。Ope​nAIのCo​dexドキュメントは明快に述べている。「Astraはコンテキストウィンドウをまたいでノートを保持し、同じタスクの以前のメッセージとツール結果を検索できる。」ノートは永続的かつ書き込み可能で、その背後にある履歴は読み取り可能なままなので、それについてのノートが書かれた後でも、以前のウィンドウを引き続き検索して元の証拠を探せる。以前のメッセージやツール出力に由来する要件とテスト結果も、引き続き見つけられる。

OpenAIは、これが未完成の取り組みであることを明言している。同社の構成リファレンスでは、このフラグを「実験的なコンテキスト管理を有効にする（デフォルトではオフ）」と説明し、この機能は「ノートと検索可能な履歴を使用して、蓄積された詳細を保持する」と述べている。ドキュメントはまた、提供開始時点では「Business、Enterprise、またはAPIキーによるサインインでは利用できない」とも述べている。これは無限のコンテキストでもない。モデルは依然として有限のウィンドウ内で推論し、以前のノートを読み戻すたびに、そのターンの入力予算を消費する。OpenAIのモデルドキュメントによると、ウィンドウは1,050,000トークンで、入力トークンは最大922,000である。ノートの仕組みはその上に位置するものであり、それを置き換えるものではない。

設定は、OpenAI が文書化しているとおりに、正確に

この設定は、あなたの Co​dex config.toml にある [features] テーブルの子です — このファイルは、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 to use」、model_provider のデフォルトは openai です：

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

ドキュメントのバージョンを読む際の注意点が1つあります。Co​dex 設定リファレンスでは、model_reasoning_effort が minimal、low、medium、high、xhigh を受け付けると記載され、xhigh はモデル依存であると注記されています。一方、gpt-6-astra に関する Ope​nAI の 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拡張機能では、モデルコントロールはコンポーザーの下にあります。

アクセスルールは人が間違えやすいところであり、2つの機能ではゲートが異なるため、2度読む価値があります：

• このモデルは、ChatGPT Work、Codex、API で利用可能なほか、Microsoft Azure と AWS Bedrock でも提供されています。OpenAI のローンチページによると、Astra は「本日、限られた組織向けに順次提供を開始しており、今後数日以内にすべての ChatGPT Plus、Pro、Business、Enterprise ユーザーが利用できるようになる」とのことです。

• 実験的なコンテキスト管理 ── より限定的。OpenAIのドキュメントには「Plus、Pro、Pro LiteでのChatGPTサインインが必要」と記されており、「ローンチ時点ではBusiness、Enterprise、APIキーでのサインインでは利用できない」と述べられている。

その2行目こそ、自分のものにすべきものだ。gpt-6-astra は API キーで呼び出せるし、Business プランで料金を支払うこともできる——だが、クロスウィンドウのノート機能はそこにはない。ノートの仕組みが乗り換えの理由なら、C​odex クライアントでは API キーではなく、Plus、Pro、または Pro Lite の ChatGPT サインインが必要だ。Ope​nAI はそれを、利用可否が「ロールアウト、あなたのサインイン方法、あなたのクライアント」次第だと説明しているが、これは同じことの丁寧な言い方だ。

さらに2点の注意事項があり、いずれもベンダーが文書化したものではなく、報告されたものとして扱われています。ロールアウトに関する報道では、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の1つだけで、仕様も価格も1組であり、「Astra Pro」や「Astra Medium」構成に関する個別の仕様や料金は公表していません。Astraの名称付きティアについて引用されている数値は、すべて未確認として扱ってください。

本番環境の経路としてコミットする前にモデルを試したいなら、現行のモデルと並べて1つのエンドポイント経由でルーティングするのが、手っ取り早く確かめる方法です — GPT-6 Astra は OrcaRouter のカタログにあるので、比較実行のコストは2つ目の契約と2つ目の SDK ではなく、モデル文字列1つ分で済みます。

推論エフォート：5つのレベルと、それぞれにかかるコスト

OpenAIのgpt-6-astraに関するAPIドキュメントには、5つのエフォートレベル — low、medium、high、xhigh、max — が記載されており、Codexのガイダンスはその使い方について率直だ。「必要な結果を生み出す最も低い推論エフォートを使い」、デフォルトから始めて、タスクにもっと深い計画が必要なときはそれを引き上げる。

その助言を無視するのが特にこのモデルで高くつく理由は、推論トークンが請求書のどこに載るかにある。推論トークンは出力トークンであり、Astra の出力は100万トークンあたり $50.00 ——入力料金の10倍、キャッシュ済み入力料金の50倍だ。つまり、このトレードオフは抽象的な話ではない：

• ターンごとに追加の推論トークン1,000個につき、出力レートで$0.05のコストがかかります。

• 150ターンのセッション全体で、1ターンあたり1,000個の追加推論トークンを保持すると約$7.50、5,000個追加で保持すると約$37.50のコストがかかります。

• 以下の実例セッションでは、出力はすでに1ターンあたり$0.200で、キャッシュ読み取りの$0.090に対して最大の単一明細です — 合計を最も速く動かす項は推論の増加です。

OpenAI が公表していないのは、エフォート別の表です。つまり、xhigh や max がコーディングタスクで medium と比べて推論トークンを何個出力するかについてのベンダー数値はなく、エフォート別に内訳されたベンダーベンチマークもありません。あなたに正確な「max は 2 倍のコスト」という比率を引用している人は、OpenAI の測定値ではなく、自分自身の測定値を引用しています。誠実な方法は、代表的なタスクを 1 つ、2 つのエフォートレベルで実行し、レスポンス内の usage ブロックを読むことです — その数値に 100 万あたり 50 ドルを掛けたものが、あなたの実際のエフォートプレミアムです。

測定結果、それぞれに独自のソースがある

コーディングおよびターミナル作業。特に断りのない限り、すべてOpenAIによるベンダー報告です。Terminal-Bench 4.0：GPT-6 Astraが57.9%で、GPT-5.6 Solの37.3%、Claude Fable 5.1の55.8%に対します——OpenAIは、タスクあたりのAPIコストがGPT-5.6 Sol比で約9%低く、Claude Fable 5.1比で63%低いと推定しています。DatacurveのDeepSWE v1.1では、Datacurve独自のベンチマークでAstraが74.1%となり、Datacurveはこれを新記録と表現しており、一部の報道では74%に四捨五入されています。より広いエージェント系セットでは、OpenAIはOSWorld 2.0が72.6%でタスクあたり約40分——GPT-5.6 Solよりタスクあたり約47%短時間——と報告し、FrontierMath Tier 4が98%、ARC-AGI-3が99.9%、ExploitBenchが100%であることも合わせて報告しています。これらはすべてOpenAIが飽和または実質的に飽和したティアと説明しています。これらはベンダーの数値であり、私たちは再現していません。また、ARC PrizeによるARC-AGI-3の数値の独立した精査では、特別なプロバイダーアダプター環境で測定されたものであり、標準条件では低下することが判明しました。

ベンダーが出した数字ではない部分こそ、コードレビューのワークフローが最も気にすべきものだ。CodeRabbit は 2026-09-04 に Astra に関する独自評価を公開したが、その結果は見出しよりも控えめだ。ファイル横断型プルリクエスト——変更をコードベースの他の場所への影響と結びつける必要がある難しいレビュー——では、Astra は GPT-5.6 Sol より約20%多くのバグを捕捉し、対処可能なバグのカバレッジは 57.1% 対 47.6% だった。全体レビューでは利得はほぼ消える。61.3% 対 59.0% で、約4%増だ。CodeRabbit は両方を、順位を確立するものではない「初期段階の方向性を示す結果」と表現し、その手法は改善の原因を切り分けていないと注記している。OpenAI のローンチページは同じ取り組みを「ファイル横断型プルリクエストで2倍超」と表現している。CodeRabbit 自身の記事は、先ほどの20%とカバレッジの百分率を示している。要約ではなく、百分率を読め。

その非対称性は、このページでモデルをどう配備するかを決めるうえで最も有用な単一の数値であり、価格と同じ方向を指している。つまり、利得はファイル横断的な推論に集中しているので、そこにこそモデルを投じるべきだ。

Co​dexでのコンピュータ操作は、あなたのワークフローにどのような変化をもたらしますか

OpenAIによると、更新されたCodexハーネスにより、GPT-6 AstraはMind2Webでのタスク完了において、現行のGPT-5.6 Sol体験より1.9倍高速になります。Mind2WebはWebタスク自動化なので、つまりこう解釈してください。ブラウザやGUIに触れる必要があるエージェント作業が実質的により速く完了し、Codexを少しでも動かすときには、この同じ更新済みハーネスを使っているということです。対になる数値は上記のOSWorld 2.0の結果です——タスクあたり約40分で72.6%、Solよりタスクあたり約47%短い時間です。

開発者にとって実際的な意味は、委任する価値のある作業が変わるということだ。以前はエンドツーエンドで自動化するには遅すぎたワークフロー——APIのないステージングコンソールを操作する、UIを通してバグを再現する、多段階フォームをたどってフィクスチャを生成する——が、手作業で行うよりエージェント実行のほうが安く済む範囲に入ってくる。さらにこれは、OpenAIが併せて提供したエンタープライズ側の制御の価値も高める。ChatGPT WorkとCodexは確認ポリシー、つまり重大なアクションの前の承認と、安全でない、または許可されていないツール呼び出しの自動レビューを追加する。実際のインターフェースをエージェントにクリックさせているなら、そのレビュー層こそが、悪い実行と悪い午後を隔てるものだ。そして、エンタープライズアクセスがデフォルトでオフになっており、管理者が該当する料金表の下で有効化するということが、障壁ではなくガバナンス機能である理由でもある。

ワークフローに対して価格設定をし、トークンに対してではない

名称と日付を明記した価格はこちらです。OpenAIの料金ページ（2026-09-16閲覧）によると、gpt-6-astra standardは、入力トークン100万あたり$10.00、キャッシュ済み入力トークン100万あたり$1.00、キャッシュ書き込み100万あたり$12.50、出力トークン100万あたり$50.00です。BatchとFlexはこれらの料金の半額で実行され、Fastモードは倍額になります。そのキャッシュ済み入力の行こそが、エージェントループで請求額を決める項目です。なぜなら、コーディングエージェントは毎ターン必ず、大きくてほとんど変化しないコンテキストを再送信し、キャッシュ済み入力のコストは新規入力の10分の1だからです。

計算に入る前に、押さえておくべき閾値が2つあります。Ope​nAIのモデルドキュメントには、272,000入力トークンを超えるプロンプトは、入力とキャッシュのレートが2倍、出力が1.5倍で価格設定されると記載されていますリクエスト全体に対して — 超過分だけではなく — また、価格ページには長コンテキストの行が入力$20.00、キャッシュ入力$2.00、出力$75.00として掲載されています。そして前述のとおり、すべての推論トークンは出力レートで課金されます。

現実的な一晩のリファクタリングを考えてみましょう。150モデルターン、1ターンあたり平均100,000入力トークン（うち90,000がキャッシュ読み取り、10,000が新規）、および推論を含む4,000出力トークンです。272Kのしきい値未満では、標準料金で：

• キャッシュ済み入力 — 90,000トークン × 100万あたり$1.00 = 1ターンあたり$0.090

• 新規入力 — 10,000トークン × 100万トークンあたり$10.00 = 1ターンあたり$0.100

• 出力 — 4,000トークン × 100万あたり$50.00 = 1ターンあたり$0.200

• 合計 — 1ターンあたり$0.390、つまり150ターンでセッションあたり約$58.50

では、同じセッションをしきい値の向こう側に移しましょう。1ターンあたり300,000入力トークン — 270,000がキャッシュ済み、30,000が新規 — になると、リクエスト全体が再価格設定され、キャッシュ済み入力は2倍の$2.00、新規入力は2倍の$20.00、出力は$75.00になります：

• キャッシュされた入力 — 270,000 × 100万あたり$2.00 = 1ターンあたり$0.540

新規入力 — 30,000 × 100万あたり$20.00 = 1ターンあたり$0.600

• 出力 — 4,000 × 100万あたり$75.00 = 1ターンあたり$0.300

• 合計 — 1ターンあたり$1.44、150ターンで約$216.00

同じタスク形状で、請求額はおよそ3.7倍。その違いはすべて、あなたのトランスクリプトが272,000トークンのどちら側にあるかだけだ。これがノート機構を支持する主張を一行で表している。もし永続的なノートと検索可能な履歴によって、トランスクリプト全体を引きずるのではなく作業コンテキストをよりスリムに保てるなら、その機能は品質に役立つ前に、入力トークンの面で元が取れる。また、無人実行でトランスクリプトを上限なく肥大化させないべきだという主張でもある。

規模感を示すと、同じトークンプロファイルで同じ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 になります。これらは Ope​nAI が公表している料金に基づく計算であり、同じタスクを完了できるという主張ではありません — それこそが次の2つのセクションの要点です。

これらすべてをプロバイダー間で比較しているなら、知っておくとよいのは、OrcaRouter がプロバイダーの定価を 0% のマークアップでそのまま通しているということです。そのため、ベンダーの価格変更は、次の請求書の時点ではなく、当日にルーティングされたエンドポイントで反映されます。

設計で考慮すべき故障モード

Astraは長期コンテキスト設計に基づく長期的視野モデルであり、その説明の両方の部分こそが問題のありかだ。これらはコミュニティの知見とベンダーのポストモーテムであり、私たちの測定結果ではない。

• 今週、コンテキスト管理の実験にバグがあった。Ope​nAIの2026-09-12のポストモーテムは、オプトイン実験が「早期停止と古いメッセージへの返信を引き起こした」ことを確認しており、約4,000–5,000人のユーザーに影響を与え、無効化された。同じポストモーテムは、ローンチ週の品質苦情に関する他の2つの原因も挙げている。以前のモデル向けに書かれたスキルが誤作動してAstraが自身の作業を確認できなくなっていたこと、そして設定が誤ったサービングエンジンがトラフィックのテールの品質を低下させていたことだ。その後、09-12から09-13に日付が変わる深夜0時に使用量のリセットが行われた。

• 考えすぎとテストの乱立。広く共有された r/codex のスレッドでは、Astra が小さな機能リクエストに応答する際、まず検証の層、スモークテスト、ハッシュチェックを積み上げ、それらをいくつもの順序で実行し、その機能が存在するずっと前に使用量メーターがほぼ枯渇したと報告した、と述べられている。これらの報告は管理された測定ではなく個々の体験談であり、前月には他のフロンティアモデルについても同様の不満が出回っていた——したがって、これは計画の拠り所にできる発生率ではなく、対策を検討すべき実際のパターンとして扱うこと。

• 終了しない実行。Flaskの作者であるArmin Ronacherは、Astraを35時間にわたる監視なしの実行に放置したと述べた。その終了時点で、79コミットにわたる約75,000正味行、約1,400件のエージェント間メッセージ、約$1,200のAPI費用——コミットあたり約$15.50——を生み出していたが、彼の評価では、価値のあるものは何も提供されなかった。トークン数の報告はまちまちなので、その数字は大まかに捉えてほしい。彼は、欠けている停止条件を、モデルの問題であると同時にハーネスの問題でもあると位置づけた。これが実行に移せる解釈だ。開始する前に完了を定義せよ。

• 逆の失敗も存在します。コミュニティの報告では、Astra がタスクを完成させる手前で止まり、続行のためのプロンプトを待つという事例が語られています。これは同じ根本原因を反対側から見たもので、「完了」の定義が不十分であることに起因します。タスクプロンプトにおいて「完了」を明示的に定義することが、最も価値の高い一行です。

• 長時間のセッションは復旧不能になり得る。オープンな Co​dex issue では、コンテキストウィンドウが埋まると自動コンパクションが作動し、そのコンパクション処理自体がコンテキストを使い果たし、スレッドを復旧できなくなるというキャッチ22が報告されている。また別途、一部の構成ではネイティブのノートと履歴のルートが Pro with Astra で 404 を返し、ウィンドウを切り替えるとタスク状態が破棄される可能性があるとも報告されている。どちらもベンダーの公式声明ではなくオープンな報告だが、セッションが生き残ることを信頼するより、実行を git でチェックポイント化しておくべきだという論拠になる。

• 古くなったノートは設計上の性質であり、バグではない。ノートが、それが記述するファイルの現在の状態を反映していることを保証するものは何もなく、検索は意味に基づくものではなくリテラルな部分文字列一致である。ノートと一緒にソースパスを保存し、変更時に再検証し、無人実行のノートは、依拠すべき真実としてではなく、確認すべき証拠として扱う。

• 使用上限が現在の不満点です。2026-09-14の週の報告には、ローンチ週より最大4倍厳しい上限や、xhigh effortがmediumよりも許容量の消費が少ないという未解決の不満が含まれています — もしそれが正しければ、effortとクォータは連動していないことを意味します。Ope​nAIはAstraについてプラン別の数値上限を公表していません。

安価なモデルが正しい選択となるのはどんなときか

上記の測定結果は、あなたに代わってルーティングの判断を下します。Astra の優位性は、ファイルをまたぐ作業や長時間にわたる作業、つまりファイル横断的なレビュー、長期的なエージェントタスク、コンピュータ操作フローに集中しています。通常の単一ファイル編集、機械的なリファクタリング、テストのスキャフォールディング、フォーマットでは、GPT-5.6 Sol に対するレビュー全体で約4%の差は、現在のトークンあたり価格の約2.5倍を正当化しません。また、CodeRabbit 自身の結論も同じ方向を示しており、全面的な置き換えではなく、インテリジェントなタスクルーティングを推奨しています。高価なモデルは、その強みが現れるタスクのために取っておき、それ以外は下位へルーティングしてください。

具体的には、有効な分担は次のとおりです。GPT-6 Astra はファイル横断的な変更、不慣れなコードベース、数時間に及ぶエージェント実行、ブラウザを操作するあらゆる用途向け。GPT-5.6 Terra は範囲を限定した編集、定型的なコードとテストの生成向け。GPT-5.6 Luna は分類、抽出、大量の機械的処理パス向け。上記のセッション計算では、すべてを Astra で実行する場合と、その 3 分の 1 を Astra で実行する場合の差は、同じ 150 ターンで約 $58.50 と約 $28 の差になります。

その振り分けを正しく行うことこそが、ルーティングレイヤーの役割です。OrcaRouter は 200 以上のモデルを単一の API の背後にまとめます。だからこそ、上記の振り分けは 3 つの統合ではなく設定変更だけで済みます。さらに自動フェイルオーバーにより、ある実験的機能が——今回のように——調子を崩しても、あなたの実行が終了させられるのではなく、性能が低下するだけで済みます。コンテキストの仕組みを Ope​nAI 自身が今なお実験的と位置づけ、一時的に無効化したこともあるモデルにとって、第二の経路を構成しておくことは偏執的ではありません。それは適切な警戒心です。

ここから何に注目すべきか

このページを変える可能性があるのは4つのことで、その4つはいずれも未解決だ。コンテキスト管理の実験が再び有効になるかどうか、そしてどのような形で有効になるか — Ope​nAIはそれがAstraのデフォルトになると述べている。つまり、上の設定行はやがて自分で設定するものではなくなる。Proにおけるノートと履歴の404報告が解決するかどうか。なぜならそれは、この仕組みが文書どおりに機能しているのか、一部のルートでしか機能していないのかの違いだからだ。Ope​nAIがエフォート別のトークンまたはコストデータを公開するかどうか。それは今日のあらゆるエフォート判断で欠けている数字だ。そして、2026-09-10に新規の$200 Proサブスクリプションを一時停止させた需要が吸収されたら、ローンチ週を通じて厳しくなった利用上限が緩和されるかどうか。

それまでは、プレイブックは短い。モデルは codex -m gpt-6-astra で固定し、実験はクライアントに Plus、Pro、または Pro Lite のサインインがある場合にのみオンにし、スライダーのラベルを信用せずに effort を明示的に設定し、作業コンテキストは 272,000 トークン未満に保つ——そこが請求額が倍になるところだからだ。そして、離席する前に完了条件を定義し、簡単な作業はもっと安い場所へ回す。このモデルは 2026-09-03 のもので、どこにも行かない。まだ落ち着いていないのは、その周辺のツール群のほうだ。

出てくる疑問

クロスウィンドウ・ノート機能は、通常サイズのタスクで有効にする価値がありますか？一般的にはいいえ。これはコンテキストウィンドウの境界をまたぐ損失を解決するために存在するもので、1つのウィンドウに収まるタスクでは、苦痛を何も取り除かないまま構成要素を増やすだけです — 2026-09-12のバグのために無効化された実験的なコードパスも含めて。長期的な作業ではオンにし、範囲を限定した編集ではオフのままにしてください。

1,050,000トークンのウィンドウは、私の構成で検索を置き換えられますか？コストの面では、置き換えられません。大きなコンテキストを毎ターン読み戻すと、毎ターン課金されます。しかも272,000入力トークンを超えると、リクエスト全体の価格が入力$20.00、出力$75.00に変わります。作業コンテキストをより小さく保つ検索ステップのほうが、通常は安上がりな設計です。だからこそノートの仕組みが興味深いのです。それはハーネスに組み込まれた検索なのですから。

タスクが終了すると、ノートはどうなるのか？ OpenAIのドキュメントでは、この仕組みは同じタスクに限定されており、コミュニティの解説記事では、ノートは自動的に引き継がれるのではなく、そのタスクに対して保存されると説明されています。新しいタスクが前のタスクのノートを継承すると想定しないでください。残しておく必要があるものは、エージェントのメモリではなく、リポジトリに入れるべきです。