GPT-6 Astra in Codex: notities tussen vensters, inspanningsniveaus en de echte rekening

GPT-6 Astra is een model van 2026-09-03, en deze pagina is geen lanceringsverslaggeving — het is de referentie om je coding agent erop te richten nu het algemeen beschikbaar is. De reden waarom een developer zou overstappen is één specifiek mechanisme, en het is de moeite waard om dat te begrijpen voordat je er iets aan uitgeeft: in plaats van een lange sessie telkens wanneer het venster vol raakt te comprimeren tot één lossy samenvatting, houdt Co​dex met GPT-6 Astra notities bij over contextvensters heen en laat het eerdere contextvensters doorzoekbaar, zodat een eis die je veertig beurten geleden hebt gesteld en de testuitvoer die tien beurten geleden faalde, beide nog steeds op te halen zijn in plaats van weggesummariseerd. Ope​nAI noemt de functie experimenteel, schakelt deze in met een regel in je Co​dex config.toml, en zegt dat het de standaard voor Astra wordt. Alles hieronder — de exacte config, de inspanningsniveaus, de gemeten resultaten en een uitgewerkte sessierekening die de regel voor gecachte input vermeldt — is op 2026-09-16 gelezen van Ope​nAI's eigen pagina's, en elk cijfer van derden is als zodanig gelabeld.

Twee dingen gebeurden deze week die de rekensom voor het adopteren ervan veranderen. Op 2026-09-12 publiceerde de Co​dex-lead van Ope​nAI een postmortem waarin werd bevestigd dat het contextbeheerexperiment zelf een bug had — het veroorzaakte voortijdige stops en antwoorden op verouderde berichten, en werd uitgeschakeld voor de ongeveer 4.000–5.000 gebruikers die het gebruikten — en Ope​nAI voerde om middernacht van 09-12 naar 09-13 een volledige gebruiksreset door voor Co​dex- en Astra-gebruikers. Dezelfde week werden enterprise-workspaces die Astra bij de lancering standaard uit hadden, beheerbaar onder hun eigen tariefkaart. Dus de eerlijke positie is: het mechanisme is het adopteren waard, de build verandert nog steeds onder je, en je zou het op een branch moeten proberen in plaats van tegen een deadline.

Wat is er eigenlijk nieuw in Co​dex met GPT-6 Astra?

Vraag een willekeurige coding agent zes uur te werken en je loopt tegen dezelfde muur aan. Het contextvenster raakt vol, de harness vat het transcript samen in één compact blok om ruimte te maken, en de samenvatting is met verlies op precies de manier die pijn doet — de reden waarom een eerdere oplossing faalde, de exacte vorm van een falende test, een beperking die de gebruiker terloops noemde in beurt drie. Opgehaald detail, niet samengevat detail, is wat je eigenlijk wilde.

De Codex-integratie van Astra verandert de vorm daarvan. In de Codex-documentatie van OpenAI staat het ronduit: "Astra houdt notities bij over contextvensters heen en kan eerdere berichten en toolresultaten van dezelfde taak doorzoeken." Notities zijn duurzaam en beschrijfbaar; de geschiedenis erachter blijft leesbaar, zodat een eerder contextvenster nog steeds kan worden doorzocht op het oorspronkelijke bewijs, zelfs nadat de notitie daarover is geschreven. Vereisten en testresultaten uit eerdere berichten en tool-uitvoer blijven vindbaar.

Ope​nAI zegt expliciet dat dit geen afgerond werk is. De configuratiereferentie ervan beschrijft de flag als "Experimenteel contextbeheer inschakelen (standaard uit)" en zegt dat de functie "notities en doorzoekbare geschiedenis gebruikt om verzamelde details te behouden". De documentatie vermeldt ook dat deze "bij de lancering niet beschikbaar is met aanmelding via Business, Enterprise of API-sleutel". Dit is ook geen oneindige context — het model redeneert nog steeds binnen een eindig venster, en elke teruglezing van een eerdere notitie verbruikt het invoerbudget van die beurt. Het venster is 1.050.000 tokens met een maximum van 922.000 invoertokens, volgens de modeldocumentatie van Ope​nAI; het notitiemechanisme komt daarbovenop, het vervangt dat niet.

De config, precies zoals Ope​nAI die documenteert

De instelling is een kind van de [features]-tabel in je Co​dex config.toml — het bestand staat in ~/.codex/, tenzij je CODEX_HOME hebt overschreven. Het gedocumenteerde sleutelpad is features.context_management.experimental_mode, een boolean, en de waarde is true:

[features.context_management]
experimental_mode = true

Als je al een [features]-tabel in het bestand hebt, voeg dan de relatieve sleutel erin toe in plaats van de tabel twee keer te declareren:

[features]
context_management.experimental_mode = true

Gebruik de ene of de andere vorm. Communityberichten over de flag melden dat het declareren van het gestippelde pad in de root en vervolgens het openen van een [features]-tabel verderop in hetzelfde bestand kan mislukken bij het parsen als een opnieuw gedeclareerde tabel, wat een TOML-regel is en niet iets van Ope​nAI — maar het levert mensen problemen op, dus kies één vorm en houd je daaraan. Start na het bewerken een nieuwe taak: de instelling wordt niet met terugwerkende kracht toegepast op een sessie die al draait.

Het modelgedeelte van hetzelfde bestand is niets bijzonders, en de referentie van OpenAI documenteert deze sleutels rechtstreeks — model is "Model to use", model_provider is standaard openai:

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

Een waarschuwing bij het lezen van documentatieversies. De Co​dex-configuratiereferentie vermeldt model_reasoning_effort als waarden minimal, low, medium, high en xhigh, met de opmerking dat xhigh modelafhankelijk is — terwijl de API-modelpagina van Ope​nAI voor gpt-6-astra reasoning.effort documenteert als low, medium, high, xhigh en max. De client-slider en de API beschrijven niet dezelfde set, dus stel effort expliciet in en bevestig wat je client heeft geaccepteerd in plaats van aan te nemen.

Het model selecteren — en de toegangsregel die mensen erin laat lopen

De modeldocumentatie van OpenAI's Codex geeft de CLI-vorm direct: codex -m gpt-6-astra. In een interactieve sessie wisselt /model van model en wordt de reasoning-inspanning aangepast; bij een eenmalige run werkt codex exec -m gpt-6-astra "Review the current changes" op dezelfde manier. In de desktopapp en de IDE-extensie bevindt de modelinstelling zich onder de composer.

De toegangsregel is waar mensen de fout in gaan, en het is de moeite waard om die twee keer te lezen, omdat de twee functies verschillende poorten hebben:

• Het model — beschikbaar via ChatGPT Work, Codex en de API, en ook aangeboden op Microsoft Azure en AWS Bedrock. De lanceringspagina van OpenAI zegt dat Astra "vandaag wordt uitgerold naar een beperkte groep organisaties en de komende dagen beschikbaar zal komen voor alle ChatGPT Plus-, Pro-, Business- en Enterprise-gebruikers".

• Het experimentele contextbeheer — beperkter. De documentatie van OpenAI stelt dat het "Vereist ChatGPT-aanmelding op Plus, Pro of Pro Lite" en dat het "bij de lancering niet beschikbaar is met Business-, Enterprise- of API-sleutelaanmelding".

Die tweede regel is degene die je je eigen moet maken. Je kunt gpt-6-astra aanroepen met een API-sleutel, en je kunt ervoor betalen via een Business-abonnement — maar de functie voor notities tussen vensters zal er niet zijn. Als het notitiemechanisme de reden is dat je overstapt, dan heb je een Plus-, Pro- of Pro Lite ChatGPT-aanmelding nodig in de Co​dex-client, niet een API-sleutel. Ope​nAI framet het als beschikbaarheid die afhangt van "de uitrol, je aanmeldmethode en je client", wat de beleefde versie van hetzelfde is.

Twee verdere kanttekeningen, aangeduid als gerapporteerd in plaats van door de leverancier gedocumenteerd. In de berichtgeving over de uitrol staat dat Co​dex CLI-versie 0.153.0 of later vereist is voor Astra; we konden die minimumversie niet bevestigen op de eigen pagina's van Ope​nAI. En de Co​dex-documentatie beschrijft presets voor de modelkiezer — Astra Light, Astra Medium, Astra Extra High, die naast de redeneerschuifregelaar worden aangeboden aan in aanmerking komende Pro-, Business- ($100) en Enterprise-accounts. Dat zijn posities in de kiezer, geen afzonderlijke producten: Ope​nAI documenteert één model-id, gpt-6-astra, met één set specificaties en één prijs, en publiceert geen afzonderlijke specificatie of tarief voor enige "Astra Pro"- of "Astra Medium"-configuratie. Behandel elk cijfer dat voor een benoemde Astra-tier wordt genoemd als niet-geverifieerd.

Als je het model wilt uitproberen voordat je er een productiepad aan vastlegt, is het routeren ervan via één endpoint naast je huidige model de goedkope manier om daarachter te komen — GPT-6 Astra staat in de OrcaRouter-catalogus, dus een vergelijkingsrun kost je een modelstring in plaats van een tweede contract en een tweede SDK.

Redeneerinspanning: vijf niveaus, en wat elk niveau kost

De API-documentatie van Ope​nAI voor gpt-6-astra noemt vijf inspanningsniveaus — low, medium, high, xhigh en max — en de Co​dex-richtlijn is onverbloemd over hoe je ze moet gebruiken: "Gebruik de laagste redeneerinspanning die het resultaat oplevert dat je nodig hebt," en begin bij de standaardwaarde en verhoog die wanneer een taak diepere planning vereist.

De reden dat het duur is om dat advies te negeren, specifiek op dit model, is waar redeneertokens op de factuur terechtkomen. Redeneertokens zijn outputtokens, en output op Astra kost $50,00 per miljoen — tien keer het inputtarief en vijftig keer het tarief voor gecachte input. Dus de afweging is niet abstract:

• Elke extra 1.000 reasoningtokens per beurt kost $0,05 tegen het outputtarief.

• Over een sessie van 150 beurten kost het vasthouden van 1.000 extra redeneertokens per beurt ongeveer $7,50; het vasthouden van 5.000 extra kost ongeveer $37,50.

• In de uitgewerkte sessie hieronder is output al de grootste afzonderlijke regel: $0,200 per beurt tegenover $0,090 aan cache-leesbewerkingen — redeneergroei is de term die het totaal het snelst doet stijgen.

Wat Ope​nAI niet publiceert, is een tabel per effort: er is geen leverancierscijfer voor hoeveel redeneertokens xhigh of max bij een coderingstaak uitsturen ten opzichte van medium, en geen benchmark van de leverancier uitgesplitst naar effort. Iedereen die u een precieze verhouding "max kost 2x" voorhoudt, citeert zijn eigen meting, niet die van Ope​nAI. De eerlijke methode is om één representatieve taak op twee effortniveaus uit te voeren en het usage-blok in de respons te lezen — dat getal, vermenigvuldigd met $50 per miljoen, is uw werkelijke meerprijs voor effort.

De gemeten resultaten, elk met zijn eigen bron

Programmeer- en terminalwerk, allemaal door leverancier OpenAI gerapporteerd tenzij anders vermeld. Terminal-Bench 4.0: GPT-6 Astra op 57,9%, tegenover 37,3% voor GPT-5.6 Sol en 55,8% voor Claude Fable 5.1 — waarbij OpenAI naar schatting ongeveer 9% lagere API-kosten per taak raamt ten opzichte van GPT-5.6 Sol en 63% lager ten opzichte van Claude Fable 5.1. Datacurve's DeepSWE v1.1 zet Astra op 74,1% op de eigen benchmark van Datacurve, een cijfer dat Datacurve beschrijft als een nieuw record en dat sommige berichtgeving afrondt naar 74%. Op de bredere agentische set rapporteert OpenAI OSWorld 2.0 op 72,6% bij ongeveer 40 minuten per taak — ongeveer 47% minder tijd per taak dan GPT-5.6 Sol — naast FrontierMath Tier 4 op 98%, ARC-AGI-3 op 99,9% en ExploitBench op 100%, allemaal door OpenAI beschreven als verzadigde of effectief verzadigde tiers. Dat zijn de cijfers van de leverancier; we hebben ze niet gereproduceerd, en onafhankelijke toetsing van het ARC-AGI-3-cijfer door ARC Prize wees uit dat het gemeten was in een speciale provider-adapteromgeving en dat het onder standaardomstandigheden terugvalt.

Het gegeven dat geen leverancierscijfer is, is het gegeven waar een code-reviewworkflow het meest om zou moeten geven. CodeRabbit publiceerde op 4 september 2026 zijn eigen evaluatie van Astra, en het resultaat is beperkter dan de kop. Bij pull requests over meerdere bestanden — de moeilijke reviews waarbij een wijziging moet worden verbonden met gevolgen elders in de codebase — ving Astra ongeveer 20% meer bugs dan GPT-5.6 Sol, met een bruikbare bugdekking van 57,1% tegenover 47,6%. Bij algemene reviews verdwijnt de winst grotendeels: 61,3% tegenover 59,0%, ongeveer 4% meer. CodeRabbit typeert beide als "vroege, richtinggevende resultaten" die geen rangorde vaststellen, en merkt op dat zijn methode de oorzaak van de verbetering niet isoleert. De lanceringspagina van OpenAI typeert hetzelfde werk als "meer dan een verdubbeling bij pull requests over meerdere bestanden"; CodeRabbits eigen verslag noemt de 20% en de bovenstaande dekkingspercentages. Lees de percentages, niet de samenvatting.

Die asymmetrie is het meest nuttige getal op deze pagina om te bepalen hoe je het model inzet, en ze wijst in dezelfde richting als de prijs: de winst is geconcentreerd in het redeneren over meerdere bestanden, dus daar zet je het model in.

Wat verandert computergebruik in Co​dex voor je workflow?

Ope​nAI zegt dat de bijgewerkte Co​dex-harness GPT-6 Astra 1,9x sneller maakt bij taakvoltooiing op Mind2Web dan de huidige GPT-5.6 Sol-ervaring. Mind2Web is webtaakautomatisering, dus lees dat als: agentwerk dat een browser of een GUI moet aanraken, wordt wezenlijk sneller afgerond, en dezelfde bijgewerkte harness is wat je draait wanneer je Co​dex überhaupt aanstuurt. De bijbehorende figuur is het OSWorld 2.0-resultaat hierboven — 72,6% bij ongeveer 40 minuten per taak, ongeveer 47% minder tijd per taak dan Sol.

Voor een ontwikkelaar is het praktische gevolg een verandering in wat het waard is om te delegeren. Workflows die voorheen te traag waren om end-to-end te automatiseren — een stagingconsole aansturen zonder API, een bug reproduceren via een UI, een formulier met meerdere stappen doorlopen om een fixture te genereren — komen binnen het bereik waarin een agent-run goedkoper is dan het handmatig doen. Het verhoogt ook de waarde van de enterprise-controls die Ope​nAI meeleverde: ChatGPT Work en Co​dex voegen bevestigingsbeleid toe, wat goedkeuring vóór ingrijpende acties betekent, plus geautomatiseerde controle van onveilige of ongeautoriseerde tool-aanroepen. Als je een agent door een echte interface laat klikken, is die reviewlaag hetgeen tussen een slechte run en een slechte middag staat — en het is de reden dat enterprise-toegang standaard uitgeschakeld staat, waarbij een beheerder die inschakelt volgens de geldende tariefkaart, een governancefunctie is en geen obstakel.

De workflow beprijzen, niet het token

Hier is de prijs, met naam en datum. Van de prijzenpagina van OpenAI, gelezen op 2026-09-16, is gpt-6-astra standard $10,00 per miljoen inputtokens, $1,00 per miljoen gecachte inputtokens, $12,50 per miljoen cachewrites en $50,00 per miljoen outputtokens. Batch en Flex draaien tegen de helft van die tarieven; Fast-modus verdubbelt ze. Die regel voor gecachte input bepaalt je rekening in een agentische lus, want een codingagent verzendt bij elke afzonderlijke beurt een grote, grotendeels onveranderde context opnieuw, en gecachte input kost een tiende van nieuwe input.

Twee drempels zijn van belang voordat we aan de rekensom beginnen. In de modeldocumentatie van Ope​nAI staat dat prompts boven 272.000 inputtokens worden geprijsd tegen 2x de input- en cachetarieven en 1,5x de output voor het volledige verzoek — niet alleen het overschot — en de prijzenpagina bevat de rij voor lange context tegen $20,00 input, $2,00 gecachte input en $75,00 output. En elke redeneertoken wordt tegen het outputtarief gefactureerd, zoals hierboven uiteengezet.

Neem een realistische nachtelijke refactor: 150 modelbeurten, gemiddeld 100.000 invoertokens per beurt, waarvan 90.000 uit cache wordt gelezen en 10.000 nieuw is, en 4.000 uitvoertokens per beurt, inclusief redenering. Onder de 272K-drempel, tegen standaardtarieven:

• Gecachte invoer — 90.000 tokens × $1,00 per miljoen = $0,090 per beurt

• Nieuwe input — 10.000 tokens × $10,00 per miljoen = $0,100 per beurt

• Uitvoer — 4.000 tokens × $50,00 per miljoen = $0,200 per beurt

• Totaal — $0,390 per beurt, dus 150 beurten is ongeveer $58,50 voor de sessie

Verplaats nu dezelfde sessie over de drempel. Bij 300.000 invoertokens per beurt — 270.000 gecacht, 30.000 nieuw — wordt het hele verzoek opnieuw geprijsd, dus gecachte invoer verdubbelt naar $2,00, nieuwe invoer verdubbelt naar $20,00 en uitvoer gaat naar $75,00:

• Gecachte input — 270.000 × $2,00 per miljoen = $0,540 per beurt

• Nieuwe invoer — 30.000 × $20,00 per miljoen = $0,600 per beurt

• Output — 4.000 × $75,00 per miljoen = $0,300 per beurt

• Totaal — $1,44 per beurt, of ongeveer $216,00 voor 150 beurten

Dezelfde taakvorm, ongeveer 3,7x de rekening, en het hele verschil is aan welke kant van 272.000 tokens je transcript zich bevindt. Dat is de argumentatie voor het notitiemechanisme in één regel: als duurzame notities en doorzoekbare geschiedenis je een werkcontext slanker laten houden in plaats van het hele transcript mee te slepen, verdient de functie zichzelf terug in invoertokens voordat hij ook maar iets aan kwaliteit bijdraagt. Het is ook het argument om te voorkomen dat een onbeheerde run een transcript zonder plafond laat groeien.

Ter vergelijking: dezelfde sessie van 150 beurten met hetzelfde tokenprofiel op de goedkopere niveaus: GPT-5.6 Terra komt bij zijn gepubliceerde tarieven van $2,00 input / $0,20 gecachet / $12,00 output uit op ongeveer $12,90, en GPT-5.6 Luna komt bij $0,20 / $0,02 / $1,20 uit op ruwweg $1,29. Dat is rekenwerk op basis van de gepubliceerde tarieven van OpenAI, geen bewering dat ze dezelfde taak zouden voltooien — wat precies het punt is van de volgende twee secties.

Als je dit allemaal bij verschillende aanbieders vergelijkt, is het goed om te weten dat OrcaRouter de lijstprijs van de aanbieder doorgeeft met 0% opslag, zodat een prijswijziging van een leverancier dezelfde dag live staat op het gerouteerde endpoint in plaats van op de volgende factuur.

De faalwijzen waarmee rekening te houden bij het ontwerp

Astra is een langetermijnmodel op een langcontextontwerp, en beide helften van die beschrijving zijn waar de problemen zitten. Dit zijn bevindingen uit de community en postmortems van leveranciers, niet onze metingen.

• Het contextbeheerexperiment had deze week een bug. De postmortem van Ope​nAI van 2026-09-12 bevestigt dat het opt-in-experiment "vroegtijdige stops en antwoorden op verouderde berichten veroorzaakte", wat ongeveer 4.000–5.000 gebruikers trof, en het werd uitgeschakeld. Dezelfde postmortem noemt nog twee andere oorzaken van de kwaliteitsklachten in de lanceringsweek: skills die voor eerdere modellen waren geschreven en die misgingen en Astra beletten zijn eigen werk te controleren, en verkeerd geconfigureerde serveerengines die een staart van het verkeer verslechterden. Om middernacht van 09-12 naar 09-13 volgde een gebruiksreset.

• Overdenken en uitdijende tests. Een breed gedeelde draad op r/codex beschrijft hoe Astra op een klein featureverzoek reageerde door eerst lagen verificatie, smoke tests en hashcontroles te bouwen, die in verschillende volgordes uit te voeren, en te melden dat de verbruiksmeter bijna uitgeput was nog voordat de feature bestond. De meldingen zijn individuele accounts, geen gecontroleerde metingen, en de maand ervoor deden vergelijkbare klachten de ronde over andere frontier-modellen — dus behandel het als een reëel patroon om tegen af te bakenen, niet als een tempo waarop je kunt plannen.

• Runs die niet stoppen. Armin Ronacher, de maker van Flask, beschreef hoe hij Astra 35 uur lang onbeheerd liet draaien, aan het einde waarvan het ongeveer 75.000 netto regels verdeeld over 79 commits had geproduceerd, ongeveer 1.400 agent-tot-agentberichten en ongeveer $1.200 aan API-kosten — ongeveer $15,50 per commit — terwijl er volgens zijn inschatting niets waardevols was opgeleverd. De meldingen over het tokenaantal lopen uiteen, dus neem dat cijfer niet al te letterlijk. Hij presenteerde het ontbreken van een stopconditie als evenzeer een harness-probleem als een modelprobleem, wat de bruikbare les is: definieer voltooiing voordat je begint.

• Het tegenovergestelde falen bestaat ook. Communityrapporten beschrijven dat Astra stopt voordat een taak is afgerond en wacht op een prompt om verder te gaan, wat dezelfde grondoorzaak is, maar dan vanaf de andere kant bekeken — een onvoldoende gespecificeerd begrip van "klaar". Expliciet "klaar" definiëren is de enkele regel met de hoogste waarde in je taakprompt.

• Lange sessies kunnen onherstelbaar worden. Open Co​dex-issues melden een catch-22 waarbij het contextvenster volloopt, automatische compactie wordt geactiveerd, de compactietaak zelf zonder context komt te zitten, en de thread niet kan worden hersteld — en afzonderlijk, dat de native notes- en historyroutes 404 retourneren op Pro met Astra in sommige configuraties, terwijl het wisselen van vensters de taakstatus kan weggooien. Beide zijn open meldingen in plaats van verklaringen van de leverancier, maar ze pleiten ervoor om runs gecheckpoint in git te houden in plaats van erop te vertrouwen dat de sessie het overleeft.

• Verouderde notities zijn een ontwerpeigenschap, geen bug. Niets garandeert dat een notitie de huidige staat weerspiegelt van een bestand dat ze beschrijft, en zoeken is letterlijke substring-matching in plaats van semantisch. Sla het bronpad op bij de notitie, verifieer opnieuw bij wijziging, en beschouw de notities van een onbeheerde run als bewijs om te controleren, niet als waarheid om op te vertrouwen.

• Gebruikslimieten zijn de actuele klacht. Rapporten uit de week van 2026-09-14 bevatten limieten die tot vier keer strenger zijn dan in de lanceringsweek, en een onopgeloste klacht dat xhigh effort minder van de limiet verbruikt dan medium — wat, als het standhoudt, betekent dat effort en quotum niet gelijk oplopen. Ope​nAI heeft geen numerieke limieten per abonnement voor Astra gepubliceerd.

Wanneer een goedkoper model de juiste keuze is

De hierboven gemeten resultaten nemen de routeringsbeslissing voor je. Astra's voordeel is geconcentreerd in werk dat meerdere bestanden of uren beslaat: review over bestanden heen, langdurige agentische taken, computer-use-flows. Bij gewone bewerkingen van één bestand, mechanische refactors, testscaffolding en opmaak rechtvaardigt het totale reviewdelta van ~4% tegenover GPT-5.6 Sol niet dat je ongeveer 2,5x de huidige prijs per token betaalt — en CodeRabbit's eigen conclusie wijst in dezelfde richting: intelligente taakroutering aanbevelen in plaats van volledige vervanging. Reserveer het dure model voor de taken waar zijn voorsprong zichtbaar wordt, en routeer de rest omlaag.

Concreet: een werkbare verdeling: GPT-6 Astra voor wijzigingen over meerdere bestanden, onbekende codebases, agent-runs van meerdere uren en alles wat een browser raakt; GPT-5.6 Terra voor afgebakende bewerkingen, boilerplate en het genereren van tests; GPT-5.6 Luna voor classificatie, extractie en mechanische passes met een hoog volume. Met de sessieberekening hierboven is het verschil tussen alles op Astra draaien en een derde ervan op Astra draaien het verschil tussen ongeveer $58,50 en ongeveer $28 voor dezelfde 150 beurten.

Die splitsing goed uitvoeren is precies waar een routeringslaag voor dient. OrcaRouter zet 200+ modellen achter één API, dus de splitsing hierboven is een configuratiewijziging in plaats van drie integraties — en automatische failover betekent dat een experimentele functie die een slechte week heeft, zoals deze, je run degradeert in plaats van hem te beëindigen. Voor een model waarvan Ope​nAI zelf het contextmechanisme nog steeds als experimenteel bestempelt en kortstondig uitschakelde, is een tweede pad geconfigureerd hebben geen paranoia; het is de juiste mate van voorzichtigheid.

Wat u vanaf hier kunt kijken

Vier dingen zouden deze pagina veranderen, en alle vier staan nog open. Of het contextmanagement-experiment weer wordt ingeschakeld en in welke vorm — Ope​nAI zegt dat het de standaard voor Astra wordt, wat betekent dat de configuratieregel hierboven uiteindelijk niet meer iets is dat je zelf instelt. Of de 404-meldingen over notities en geschiedenis op Pro worden gesloten, want dat is het verschil tussen dat het mechanisme werkt zoals gedocumenteerd en dat het op sommige routes werkt. Of Ope​nAI token- of kostengegevens per effort publiceert, het ontbrekende getal in elke effortbeslissing van vandaag. En of de gebruikslimieten die tijdens de lanceringsweek werden aangescherpt, worden versoepeld zodra de vraag die ertoe leidde dat nieuwe $200 Pro-abonnementen op 2026-09-10 werden gepauzeerd, is opgevangen.

Tot dan is het draaiboek kort. Pin het model met codex -m gpt-6-astra, zet het experiment alleen aan als je een Plus-, Pro- of Pro Lite-aanmelding in de client hebt, stel effort expliciet in in plaats van een schuifregelaarlabel te vertrouwen, houd je werkcontext onder 272.000 tokens, want daar verdubbelt de rekening, definieer wat klaar betekent voordat je wegloopt, en leid het makkelijke werk naar iets goedkopers. Het model is van 2026-09-03 en het gaat nergens heen; de tooling eromheen is wat zich nog moet zetten.

De vragen die opkomen

Is het de moeite waard om de notitiefunctie tussen vensters in te schakelen voor taken van normale omvang?Over het algemeen niet. Die functie bestaat om verlies over de grenzen van contextvensters op te lossen, dus bij een taak die in één venster past, voegt deze bewegende onderdelen toe — inclusief een experimenteel codepad dat op 2026-09-12 vanwege een bug is uitgeschakeld — zonder enige pijn weg te nemen. Schakel het in voor werk met een lange horizon en laat het uit voor een afgebakende bewerking.

Kan het venster van 1.050.000 tokens retrieval in mijn setup vervangen? Niet op basis van kosten. Het bij elke beurt teruglezen van een grote context wordt elke beurt in rekening gebracht, en boven 272.000 invoertokens wordt de hele aanvraag opnieuw geprijsd naar $20,00 voor input en $75,00 voor output. Een retrievalstap die de werkcontext kleiner houdt, is meestal het goedkopere ontwerp. Daarom is het notitiesmechanisme interessant: het is retrieval die in de harness is ingebouwd.

Wat gebeurt er met de notities wanneer een taak eindigt? De documentatie van Ope​nAI beperkt het mechanisme tot dezelfde taak, en communitybeschrijvingen geven aan dat de notities bij die taak worden opgeslagen in plaats van automatisch te worden doorgegeven. Ga er niet van uit dat een nieuwe taak de notities van de vorige erft; alles wat moet blijven bestaan, hoort in je repository, niet in het geheugen van de agent.