GPT-6 Astra i Codex: Anteckningar mellan fönster, ansträngningsnivåer och den verkliga kostnaden

GPT-6 Astra är en modell från 2026-09-03, och den här sidan är inte lanseringsbevakning – den är referensen för att peka din kodningsagent mot den nu när den är allmänt tillgänglig. Anledningen till att en utvecklare skulle byta är en specifik mekanik, och det är värt att förstå innan du spenderar något på den: i stället för att komprimera en lång session till en enda förlustbringande sammanfattning varje gång fönstret fylls, behåller Codex med GPT-6 Astra anteckningar mellan kontextfönster och lämnar tidigare kontextfönster sökbara, så ett krav du angav för fyrtio turer sedan och testutdata som misslyckades för tio turer sedan är båda fortfarande hämtningsbara i stället för att sammanfattas bort. OpenAI kallar funktionen experimentell, aktiverar den med en rad i din Codex config.toml och säger att den kommer att bli standard för Astra. Allt nedan – den exakta konfigurationen, ansträngningsnivåerna, de uppmätta resultaten och en genomräknad sessionsräkning som namnger raden för cachad indata – lästes från OpenAI:s egna sidor den 2026-09-16, och varje tredjepartssiffra är märkt som sådan.

Två saker hände den här veckan som förändrar kalkylen för att införa det. Den 2026-09-12 publicerade OpenAI:s Codex-ledare en postmortem som bekräftade att själva kontexthanteringsexperimentet hade en bugg – den orsakade för tidiga stopp och svar på inaktuella meddelanden, och inaktiverades för de ungefär 4 000–5 000 användare som omfattades av det – och OpenAI utfärdade en fullständig återställning av användningen för Codex- och Astra-användare vid midnatt den 09-12 till 09-13. Samma vecka blev företagsarbetsytor som hade Astra avstängt som standard vid lanseringen administrerbara enligt sin egen prislista. Så den ärliga positionen är: mekanismen är värd att införa, bygget rör sig fortfarande under fötterna på dig, och du bör prova det i en branch snarare än mot en deadline.

Vad är egentligen nytt i Co​dex med GPT-6 Astra

Ber du vilken kodagent som helst att arbeta i sex timmar stöter du på samma vägg. Kontextfönstret fylls, ramverket sammanfattar transkriptet till ett tätt block för att göra plats, och sammanfattningen är förlustbärande på precis det sätt som gör ont – anledningen till att en tidigare fix misslyckades, den exakta formen på ett misslyckat test, en begränsning som användaren nämnde i förbigående i tredje turen. Hämtad detalj, inte sammanfattad detalj, är det du faktiskt ville ha.

Astras Codex-integration förändrar formen på det. OpenAIs Codex-dokumentation säger det rakt ut: "Astra håller anteckningar över kontextfönster och kan söka i tidigare meddelanden och verktygsresultat från samma uppgift." Anteckningar är beständiga och skrivbara; historiken bakom dem förblir läsbar, så ett tidigare fönster kan fortfarande genomsökas efter det ursprungliga underlaget även efter att anteckningen om det skrevs. Krav och testresultat från tidigare meddelanden och verktygsutdata förblir hittbara.

OpenAI säger uttryckligen att detta inte är färdigt arbete. I sin konfigurationsreferens beskriver de flaggan som "Aktivera experimentell kontexthantering (avstängt som standard)" och säger att funktionen "använder anteckningar och sökbar historik för att bevara ackumulerade detaljer". Dokumentationen anger också att den "inte är tillgänglig med Business, Enterprise eller API-nyckel-inloggning vid lansering". Detta är inte heller oändlig kontext — modellen resonerar fortfarande inom ett ändligt fönster, och varje återläsning av en tidigare anteckning förbrukar indatabudgeten för den turen. Fönstret är 1 050 000 tokens med maximalt 922 000 indata-token, enligt OpenAI:s modelldokumentation; anteckningsmekanismen ligger ovanpå detta, den ersätter det inte.

Konfigurationen, exakt som Ope​nAI dokumenterar den

Inställningen är underordnad tabellen [features] i din Codex config.toml — filen finns i ~/.codex/ om du inte har åsidosatt CODEX_HOME. Den dokumenterade nyckelsökvägen är features.context_management.experimental_mode, en boolean, och värdet är true:

[features.context_management]
experimental_mode = true

Om du redan har en [features]-tabell i filen lägger du till motsvarande nyckel i den i stället för att deklarera tabellen två gånger:

[features]
context_management.experimental_mode = true

Använd en form eller den andra. Gemenskapsinlägg om flaggan rapporterar att om du deklarerar den punktade sökvägen i roten och sedan öppnar en [features]-tabell senare i samma fil, kan det misslyckas med att tolkas som en återdeklarerad tabell, vilket är en TOML-regel snarare än en Ope​nAI-regel — men det drabbar folk, så välj en form och håll dig till den. När du har redigerat, starta en ny uppgift: inställningen tillämpas inte i efterhand på en session som redan körs.

Modelldelen av samma fil är föga anmärkningsvärd, och OpenAI:s referensdokumentation dokumenterar dessa nycklar direkt – model är "Modell att använda", model_provider har standardvärdet openai:

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

En varning när du läser dokumentationsversioner. Codex konfigurationsreferens listar model_reasoning_effort med värdena minimal, low, medium, high och xhigh, och noterar att xhigh är modellberoende – medan OpenAI:s API-modelsida för gpt-6-astra dokumenterar reasoning.effort som low, medium, high, xhigh och max. Klientens skjutreglage och API:t beskriver inte samma uppsättning, så ange effort explicit och bekräfta vad din klient accepterade i stället för att anta.

Att välja modellen – och åtkomstregeln som får många på fall

OpenAI:s Codex-modeldokumentation anger CLI-formuläret direkt: codex -m gpt-6-astra. I en interaktiv session byter /model modell och justerar resonemangsinsatsen; vid en engångskörning fungerar codex exec -m gpt-6-astra "Review the current changes" på samma sätt. I skrivbordsappen och IDE-tillägget sitter modellkontrollen under kompositören.

Åtkomstregeln är där folk gör fel, och den är värd att läsa två gånger eftersom de två funktionerna har olika grindar:

• Modellen – tillgänglig i ChatGPT Work, Codex och API:et och tillhandahålls även via Microsoft Azure och AWS Bedrock. OpenAI:s lanseringssida säger att Astra ”rullas ut i dag till ett begränsat antal organisationer och kommer under de kommande dagarna att bli tillgänglig för alla ChatGPT Plus-, Pro-, Business- och Enterprise-användare”.

• Den experimentella kontexthanteringen – snävare. OpenAI:s dokumentation anger att den "kräver inloggning med ChatGPT på Plus, Pro eller Pro Lite" och att den "inte är tillgänglig med inloggning via Business, Enterprise eller API-nyckel vid lanseringen".

Den där andra raden är den du bör ta till dig. Du kan anropa gpt-6-astra med en API-nyckel, och du kan betala för det via en Business-plan — men funktionen för anteckningar mellan fönster kommer inte att finnas där. Om anteckningsmekanismen är anledningen till att du byter, behöver du en Plus-, Pro- eller Pro Lite-inloggning för ChatGPT i Co​dex-klienten, inte en API-nyckel. Ope​nAI beskriver det som att tillgängligheten beror på "utrullningen, din inloggningsmetod och din klient", vilket är den artiga versionen av samma sak.

Ytterligare två förbehåll, märkta som rapporterade snarare än leverantörsdokumenterade. Rapporteringen om utrullningen anger att Co​dex CLI version 0.153.0 eller senare krävs för Astra; vi kunde inte bekräfta den lägsta versionen på Ope​nAI:s egna sidor. Och Co​dex-dokumentationen beskriver förval i modellväljaren – Astra Light, Astra Medium, Astra Extra High – som erbjuds behöriga Pro-, Business- ($100) och Enterprise-konton tillsammans med resonemangsreglaget. Det är val i modellväljaren, inte separata produkter: Ope​nAI dokumenterar ett modell-id, gpt-6-astra, med en uppsättning specifikationer och ett pris, och publicerar ingen separat specifikation eller pris för någon "Astra Pro"- eller "Astra Medium"-konfiguration. Betrakta varje siffra som anges för en namngiven Astra-nivå som obekräftad.

Om du vill prova modellen innan du binder en produktionsväg till den är det billiga sättet att ta reda på det att dirigera den genom en endpoint tillsammans med din nuvarande modell – GPT-6 Astra finns i OrcaRouter-katalogen, så en jämförelsekörning kostar dig en modellsträng i stället för ett andra avtal och ett andra SDK.

Resonemangsansträngning: fem nivåer, och vad var och en kostar

Ope​nAIs API-dokumentation för gpt-6-astra listar fem ansträngningsnivåer – low, medium, high, xhigh och max – och Co​dex-vägledningen är tydlig om hur de ska användas: "Använd den lägsta resonemangsansträngningen som ger det resultat du behöver," och börja på standardvärdet, höj det när en uppgift kräver djupare planering.

Anledningen till att rådet är dyrt att ignorera just för den här modellen är var resonemangstoken hamnar på räkningen. Resonemangstoken är utdatatoken, och utdata på Astra kostar $50.00 per miljon — tio gånger indatapriset och femtio gånger priset för cachad indata. Så avvägningen är inte abstrakt:

• Varje ytterligare 1 000 resonemangstoken per tur kostar $0,05 enligt utdatapriset.

• Under en session på 150 turer kostar det cirka 7,50 $ att hålla 1 000 extra resonemangstoken per tur; att hålla 5 000 extra kostar cirka 37,50 $.

• I den genomgångna sessionen nedan är output redan den största enskilda radposten på $0.200 per tur mot $0.090 i cacheläsningar – reasoning-tillväxten är den term som flyttar totalen snabbast.

Vad Ope​nAI inte publicerar är en tabell per effort: det finns ingen siffra från leverantören för hur många resonemangstokens xhigh eller max avger på en kodningsuppgift jämfört med medium, och ingen leverantörsbenchmark uppdelad efter effort. Den som citerar ett exakt "max kostar 2x"-förhållande till dig citerar sin egen mätning, inte Ope​nAI:s. Den ärliga metoden är att köra en representativ uppgift på två effortnivåer och läsa usage-blocket i svaret — den siffran, multiplicerad med $50 per miljon, är din verkliga effort-premie.

De uppmätta resultaten, vart och ett med sin egen källa

Kodnings- och terminalarbete, allt leverantörsrapporterat av OpenAI om inte annat anges. Terminal-Bench 4.0: GPT-6 Astra på 57,9 % mot 37,3 % för GPT-5.6 Sol och 55,8 % för Claude Fable 5.1 — där OpenAI uppskattar cirka 9 % lägre API-kostnad per uppgift jämfört med GPT-5.6 Sol och 63 % lägre jämfört med Claude Fable 5.1. Datacurves DeepSWE v1.1 placerar Astra på 74,1 % i Datacurves eget benchmark, en siffra som Datacurve beskriver som ett nytt rekord och som viss bevakning avrundar till 74 %. På den bredare agentiska uppsättningen rapporterar OpenAI OSWorld 2.0 på 72,6 % vid ungefär 40 minuter per uppgift — cirka 47 % mindre tid per uppgift än GPT-5.6 Sol — tillsammans med FrontierMath Tier 4 på 98 %, ARC-AGI-3 på 99,9 % och ExploitBench på 100 %, alla beskrivna av OpenAI som mättade eller i praktiken mättade nivåer. Det är leverantörens siffror; vi har inte reproducerat dem, och en oberoende granskning av ARC-AGI-3-siffran av ARC Prize fann att den mättes i en särskild leverantörsadaptermiljö och sjönk under standardförhållanden.

Den del som inte är ett leverantörsnummer är den som ett arbetsflöde för kodgranskning borde bry sig mest om. CodeRabbit publicerade sin egen utvärdering av Astra den 2026-09-04, och resultatet är snävare än rubriken. På pull requests över filer — de svåra granskningarna som kräver att man kopplar en ändring till konsekvenser någon annanstans i kodbasen — fångade Astra cirka 20 % fler buggar än GPT-5.6 Sol, med åtgärdbar buggtäckning på 57,1 % mot 47,6 %. På övergripande granskningar försvinner vinsten till stor del: 61,3 % mot 59,0 %, ungefär 4 % mer. CodeRabbit karakteriserar båda som "tidiga, riktningsgivande resultat" som inte fastställer en rangordning, och noterar att dess metod inte isolerar orsaken till förbättringen. OpenAIs lanseringssida karakteriserar samma arbete som "mer än dubbelt på pull requests över filer"; CodeRabbits egen sammanställning anger 20 % och täckningsprocenten ovan. Läs procenttalen, inte sammanfattningen.

Den asymmetrin är det enskilt mest användbara talet på den här sidan för att avgöra hur modellen ska driftsättas, och den pekar åt samma håll som priset: vinsten är koncentrerad till filöverskridande resonemang, så det är där du ska lägga modellresurserna.

Vad computer use i Co​dex förändrar för ditt arbetsflöde

Ope​nAI säger att det uppdaterade Co​dex-harnesset gör GPT-6 Astra 1,9x snabbare på att slutföra uppgifter i Mind2Web än den nuvarande GPT-5.6 Sol-upplevelsen. Mind2Web är automatisering av webbuppgifter, så tolka det som: agentarbete som måste komma åt en webbläsare eller ett GUI slutförs väsentligt snabbare, och samma uppdaterade harness är vad du kör när du överhuvudtaget använder Co​dex. Den åtföljande siffran är OSWorld 2.0-resultatet ovan — 72,6 % vid ungefär 40 minuter per uppgift, cirka 47 % mindre tid per uppgift än Sol.

För en utvecklare är den praktiska konsekvensen en förändring av vad som är värt att delegera. Arbetsflöden som tidigare var för långsamma för att automatisera från början till slut – att styra en stagingkonsol utan API, att återskapa en bugg via ett användargränssnitt, att stega igenom ett formulär i flera steg för att generera en fixture – hamnar nu inom det intervall där en agentkörning är billigare än att göra det för hand. Det ökar också värdet av de företagsinriktade kontroller som Ope​nAI levererade vid sidan om: ChatGPT Work och Co​dex lägger till bekräftelseprinciper, det vill säga godkännande före konsekvensfyllda åtgärder, och automatiserad granskning av osäkra eller obehöriga verktygsanrop. Om du låter en agent klicka sig igenom ett verkligt gränssnitt är det granskningslagret det som står mellan en dålig körning och en dålig eftermiddag – och det är anledningen till att företagsåtkomst som är avstängd som standard, med en administratör som aktiverar den enligt gällande prislista, är en styrningsfunktion snarare än ett hinder.

Prissätt arbetsflödet, inte token

Här är priset, namngivet och daterat. Från Ope​nAI:s prissida, läst 2026-09-16, är gpt-6-astra standard $10.00 per miljon indatatoken, $1.00 per miljon cachade indatatoken, $12.50 per miljon cacheskrivningar och $50.00 per miljon utdatatoken. Batch och Flex körs till halva dessa priser; Fast-läget fördubblar dem. Den där raden för cachad indata är den som avgör din nota i en agentisk loop, eftersom en kodningsagent skickar om en stor, mestadels oförändrad kontext varje enskild tur, och cachad indata kostar en tiondel av färsk indata.

Två tröskelvärden spelar roll innan beräkningen. OpenAIs modelldokumentation anger att prompter över 272 000 indatatokens prissätts med 2x input- och cachepriser samt 1,5x output för hela begäran – inte bara överskottet – och prissidan har långkontextraden med 20,00 $ för input, 2,00 $ för cachad input och 75,00 $ för output. Och varje resonemangstoken debiteras enligt outputpriset, som täcks ovan.

Ta en realistisk nattlig refaktorering: 150 modellturer, i genomsnitt 100 000 indatatoken per tur, varav 90 000 är cacheläsning och 10 000 är nya, och 4 000 utdatatoken per tur inklusive resonemang. Under tröskelvärdet på 272K, till standardpriser:

• Cachelagrad indata — 90 000 tokens × 1,00 USD per miljon = 0,090 USD per vända

• Ny indata — 10 000 tokens × 10,00 USD per miljon = 0,100 USD per tur

• Utdata — 4 000 tokens × $50,00 per miljon = $0,200 per tur

• Totalt — 0,390 $ per tur, så 150 turer är ungefär 58,50 $ för sessionen

Flytta nu samma session över tröskeln. Vid 300 000 indatatoken per tur – 270 000 cachade, 30 000 färska – omprissätts hela begäran, så cachad indata fördubblas till 2,00 $, färsk indata fördubblas till 20,00 $ och utdata går till 75,00 $:

• Cachad indata — 270 000 × 2,00 USD per miljon = 0,540 USD per tur

• Ny indata — 30 000 × 20,00 USD per miljon = 0,600 USD per tur

Utdata — 4 000 × 75,00 USD per miljon = 0,300 USD per tur

• Totalt — 1,44 $ per tur, eller cirka 216,00 $ för 150 turer

Samma uppgiftsform, ungefär 3,7 gånger notan, och hela skillnaden är på vilken sida om 272 000 tokens ditt transkript ligger. Det är argumentet för anteckningsmekanismen på en rad: om varaktiga anteckningar och sökbar historik låter dig hålla en arbetskontext smalare i stället för att släpa hela transkriptet framåt, betalar funktionen sig själv i indatatokens innan den ens hjälper till med kvaliteten. Det är också argumentet för att inte låta en obevakad körning få ett transkript att växa utan tak.

För att sätta det i perspektiv: samma session på 150 turer med samma tokenprofil på de billigare nivåerna: GPT-5.6 Terra med sina publicerade $2,00 för indata / $0,20 för cachad / $12,00 för utdata landar på omkring $12,90, och GPT-5.6 Luna med $0,20 / $0,02 / $1,20 landar på ungefär $1,29. Det är aritmetik utifrån OpenAIs publicerade priser, inte ett påstående att de skulle slutföra samma uppgift – vilket är hela poängen med de nästa två avsnitten.

Om du jämför allt detta mellan leverantörer är det värt att veta att OrcaRouter för vidare leverantörens listpris med 0 % påslag, så en ändring av leverantörens pris gäller på den routade endpointen samma dag i stället för vid nästa faktura.

Felmoderna att designa runt

Astra är en modell för lång horisont med långkontextdesign, och båda halvorna av den beskrivningen är där problemen ligger. Det här är fynd från communityn och leverantörernas efteranalyser, inte våra mätningar.

• Kontexthanteringsexperimentet hade en bugg den här veckan. Ope​nAIs postmortem från 2026-09-12 bekräftar att det opt-in-experimentet "orsakade tidiga stopp och svar på inaktuella meddelanden", vilket påverkade ungefär 4 000–5 000 användare, och det inaktiverades. Samma postmortem pekar ut två andra orsaker till kvalitetsklagomålen under lanseringsveckan: skills skrivna för tidigare modeller som utlöstes fel och hindrade Astra från att kontrollera sitt eget arbete, och felkonfigurerade serving-motorer som försämrade en svans av trafiken. En återställning av användningen följde vid midnatt mellan 09-12 och 09-13.

• Övertänkande och testspridning. En vitt spridd r/codex-tråd beskriver hur Astra svarar på en liten funktionsförfrågan genom att först bygga lager av verifiering, smoke-tester och hash-kontroller, köra dem i flera olika ordningsföljder och rapportera att användningsmätaren är nära uttömning långt innan funktionen fanns. Rapporterna är enskilda redogörelser snarare än kontrollerade mätningar, och liknande klagomål cirkulerade om andra frontiermodeller månaden innan – så behandla det som ett verkligt mönster att förhålla sig till, inte en frekvens du kan räkna med.

• Körningar som inte avslutas. Armin Ronacher, skaparen av Flask, beskrev hur han lät Astra köra oövervakat i 35 timmar, och vid slutet av det hade den producerat ungefär 75 000 nettorader över 79 commits, omkring 1 400 agent-till-agent-meddelanden och cirka 1 200 USD i API-avgifter — omkring 15,50 USD per commit — med, enligt hans bedömning, inget av värde levererat. Rapporterna om antalet tokens varierar, så betrakta den siffran som ungefärlig. Han beskrev avsaknaden av ett stoppvillkor som lika mycket ett ramverksproblem som ett modellproblem, vilket är den tolkning som går att agera på: definiera slutförandet innan du börjar.

• Även det motsatta misslyckandet förekommer. Rapporter från communityn beskriver att Astra stannar innan en uppgift är slutförd och väntar på en prompt för att fortsätta, vilket är samma grundorsak sedd från andra hållet — en underspecificerad föreställning om vad som är klart. Att uttryckligen definiera "klart" är den enskilt mest värdefulla raden i din uppgiftsprompt.

• Långa sessioner kan bli omöjliga att återställa. Öppna Co​dex-ärenden rapporterar ett moment 22 där kontextfönstret fylls, automatisk komprimering utlöses, själva komprimeringsuppgiften får slut på kontext och tråden inte kan återställas — och separat, att de inbyggda notes- och history-rutterna returnerar 404 på Pro med Astra i vissa konfigurationer, medan växling av fönster kan förkasta uppgiftstillstånd. Båda är öppna rapporter snarare än leverantörsuttalanden, men de talar för att hålla körningar checkpointade i git i stället för att lita på att sessionen överlever.

• Inaktuella anteckningar är en designegenskap, inte en bugg. Ingenting garanterar att en anteckning återspeglar det aktuella tillståndet hos en fil som den beskriver, och sökning är bokstavlig delsträngsmatchning snarare än semantisk. Lagra källsökvägen tillsammans med anteckningen, verifiera igen vid ändring, och behandla anteckningar från en obevakad körning som bevis att kontrollera snarare än sanning att lita på.

• Användningstak är det aktuella klagomålet. Rapporter från veckan den 2026-09-14 inkluderar tak upp till fyra gånger stramare än lanseringsveckan och ett olöst klagomål om att xhigh-ansträngning förbrukar mindre av kvoten än medium — vilket, om det stämmer, innebär att ansträngning och kvot inte rör sig tillsammans. Ope​nAI har inte publicerat numeriska tak per plan för Astra.

När en billigare modell är rätt val

De uppmätta resultaten ovan fattar routningsbeslutet åt dig. Astras fördel är koncentrerad till arbete som sträcker sig över flera filer eller över timmar: granskning över flera filer, agentiska uppgifter med lång horisont, datoranvändningsflöden. Vid vanliga redigeringar i en enda fil, mekaniska refaktoreringar, testscaffolding och formatering motiverar den totala granskningsdeltan på ~4 % mot GPT-5.6 Sol inte ungefär 2,5 gånger det nuvarande priset per token — och CodeRabbits egen slutsats pekar i samma riktning och rekommenderar intelligent uppgiftsroutning snarare än att ersätta allt. Reservera den dyra modellen för de uppgifter där dess försprång syns, och routa resten nedåt.

Konkret: en fungerande uppdelning: GPT-6 Astra för ändringar över flera filer, obekanta kodbaser, agentkörningar som pågår i flera timmar och allt som rör en webbläsare; GPT-5.6 Terra för avgränsade redigeringar, standardkod och testgenerering; GPT-5.6 Luna för klassificering, extrahering och mekaniska bearbetningar i hög volym. Utifrån sessionsaritmetiken ovan är skillnaden mellan att köra allt på Astra och att köra en tredjedel av det på Astra skillnaden mellan ungefär 58,50 dollar och ungefär 28 dollar för samma 150 turer.

Att få den uppdelningen rätt är precis vad ett routningslager är till för. OrcaRouter lägger 200+ modeller bakom ett enda API, så uppdelningen ovan är en konfigurationsändring i stället för tre integrationer — och automatisk failover innebär att en experimentell funktion som har en dålig vecka, som den här hade, försämrar din körning i stället för att avsluta den. För en modell vars kontextmekanism OpenAI själva fortfarande betecknar som experimentell och tillfälligt inaktiverad är det inte paranoia att ha en andra väg konfigurerad; det är rätt mängd försiktighet.

Vad att se upp för härifrån

Fyra saker skulle förändra den här sidan, och alla fyra är öppna. Huruvida kontexthanteringsexperimentet slås på igen och i vilken form — OpenAI säger att det kommer att bli standard för Astra, vilket innebär att konfigurationsraden ovan så småningom slutar vara något du ställer in. Huruvida 404-rapporterna för anteckningar och historik på Pro stängs, eftersom det är skillnaden mellan att mekanismen fungerar som dokumenterat och att den fungerar på vissa rutter. Huruvida OpenAI publicerar några token- eller kostnadsdata per effort, vilket är den saknade siffran i varje effort-beslut idag. Och huruvida användningsgränserna som skärptes under lanseringsveckan lättar när efterfrågan som pausade nya $200 Pro-prenumerationer den 10 september 2026 har absorberats.

Fram till dess är spelboken kort. Lås modellen med codex -m gpt-6-astra, slå bara på experimentet om du har en Plus-, Pro- eller Pro Lite-inloggning i klienten, sätt effort explicit i stället för att lita på etiketten på ett skjutreglage, håll din arbetskontext under 272 000 tokens, för det är där räkningen fördubblas, definiera vad som är klart innan du går därifrån, och skicka det lätta arbetet någonstans billigare. Modellen är från 2026-09-03 och den försvinner inte; det är verktygen runt den som fortfarande håller på att sätta sig.

Frågorna som dyker upp

Är funktionen för anteckningar mellan fönster värd att aktivera för uppgifter av vanlig storlek?I allmänhet nej. Den finns för att lösa förlust över gränser mellan kontextfönster, så på en uppgift som ryms i ett enda fönster tillför den rörliga delar – inklusive en experimentell kodväg som inaktiverades på grund av en bugg 2026-09-12 – utan att undanröja någon olägenhet. Aktivera den för arbete med lång tidshorisont och låt den vara av för en avgränsad ändring.

Kan fönstret på 1 050 000 token ersätta hämtning i min uppsättning? Inte av kostnadsskäl. Att läsa tillbaka en stor kontext vid varje tur debiteras varje tur, och över 272 000 indatatoken omprissätts hela begäran till $20.00 för indata och $75.00 för utdata. Ett hämtningssteg som håller arbetskontexten mindre är vanligtvis den billigare designen, vilket är anledningen till att notes-mekanismen är intressant: den är hämtning inbyggd i ramverket.

Vad händer med anteckningarna när en uppgift avslutas? OpenAIs dokumentation avgränsar mekanismen till samma uppgift, och gemenskapsinlägg beskriver att anteckningarna lagras kopplade till den uppgiften i stället för att föras vidare automatiskt. Anta inte att en ny uppgift ärver den tidigare uppgiftens anteckningar; allt som måste finnas kvar hör hemma i ditt kodförråd, inte i agentens minne.