GPT-6 Astra review: winst in code review, privacy en kosten

Een deel van het moeilijkste werk bij code reviews vindt plaats buiten de gewijzigde regels. Een wijziging kan op zichzelf correct lijken, maar toch elders in het systeem code breken.

Dat is wat onze vroege resultaten voor OpenAI's GPT-6 Astra zo interessant maakt. In onze evaluatie vond Astra ongeveer 4% meer gelabelde bugs via actiegerichte bevindingen dan GPT-5.6 Sol, en 22% meer dan Opus 5.

De grootste sprong is te zien bij complexere reviews over meerdere bestanden (cross-file reviews), waar de winst van Astra oploopt tot 20% ten opzichte van Sol en 33% ten opzichte van Opus 5. Het gebruik van deze capaciteit op klantniveau betekent ook dat klantgegevens beschermd moeten worden en de prijzen van de publieke API van het model beoordeeld moeten worden.

Wat Astra toevoegt aan code review

Onze maatstaf hier is de actiegerichte bug-dekking (actionable bug coverage), wat betekent hoeveel gelabelde bugs een model vindt via bevindingen waar een ontwikkelaar daadwerkelijk actie op kan ondernemen.

In deze eerste evaluatiemeting lijkt de algehele winst ten opzichte van GPT-5.6 Sol bescheiden. Deze evaluatie bevat namelijk ook eenvoudigere reviews, waarbij er mogelijk minder ruimte is voor een sterker model om zich te onderscheiden. Het grotere voordeel van Astra wordt zichtbaar in de moeilijkere subset van reviews over meerdere bestanden. Dit is een vroeg, richtinggevend resultaat.

De vergelijking van de complexere cross-file reviews is bemoedigender. Het relatieve voordeel van Astra groeit naar 20% ten opzichte van Sol en 33% ten opzichte van Opus 5. Dit suggereert waarde in het verbinden van de intentie van een wijziging met de consequenties die verspreid zijn over een codebase.

Deze resultaten beschrijven één aspect van de prestaties bij reviews. Ze vormen geen algemene ranglijst van reviewkwaliteit, voorspellen niet het aantal defecten van een team en garanderen niet dezelfde winst voor elke pull request.

Context optimaal benutten

Een groot contextvenster creëert ruimte voor informatie. Nuttig redeneren vereist echter dat het model identificeert welke delen relevant zijn, deze met elkaar verbindt en tot een conclusie komt die wordt ondersteund door bewijslast.

Onze interpretatie is dat de meest interessante vooruitgang van Astra ligt in het verbinden van de juiste informatie. De grotere winst bij moeilijkere cross-file reviews suggereert vooruitgang op het gebied van werk waarbij relevante informatie verspreid is. Dit isoleert niet de oorzaak van die vooruitgang en bewijst niet dat meer context alleen de prestaties van een model verbetert.

OpenAI positioneert Astra voor werk met meerdere stappen over code, browsers en professionele software.

Voor teams die met modellen bouwen, is de nuttige vraag waar de extra redeneercapaciteit de uitkomst genoeg verandert om de kosten te rechtvaardigen. Een moeilijke taak met verspreide bewijslast is een betere kandidaat voor onderzoek dan een routineklus die een goedkoper model al betrouwbaar afhandelt. Dat betekent niet dat elke sessie moet worden omgezet naar Astra, met maximale redeneerinspanning.

Betere redenering brengt hogere kosten met zich mee

Volgens de gepubliceerde prijzen zijn de standaard API-tarieven van Astra $10 per miljoen inputtokens en $50 per miljoen outputtokens. Fable 5.1 heeft dezelfde basistarieven voor input en output, hoewel de prijzen voor caching verschillen.

Om deze prijzen in context te plaatsen, beschouwen we een illustratieve taak met 100.000 niet-gecachede inputtokens en 10.000 belastbare outputtokens (inclusief redeneer-tokens). Door het tokengebruik constant te houden, zijn de gepubliceerde tarieven gemakkelijker te vergelijken; werkelijke taakkosten variëren per gebruik.

Alle cijfers zijn gebaseerd op publiek vermelde standaard API-prijzen, gecontroleerd op 4 september 2026. Voor OpenAI zijn korte-context tarieven gebruikt. De promotionele prijsstelling van Sol is beschikbaar tot ten minste 21 november 2026. Het voorbeeld sluit caching, cache-schrijfacties, tools, retries, regionale toeslagen en service-tier aanpassingen uit.

Bij dit vaste verbruik kost Astra 2,5 keer zoveel als Sol, ongeveer 4,7 keer zoveel als Terra en ongeveer 47 keer zoveel als Luna. Dit zijn aanzienlijke toeslagen. Ze zijn echter geen voorspelling van het verschil in kosten per voltooide taak. Een model dat minder tokens of minder pogingen nodig heeft, zou het gat kunnen verkleinen.

OpenAI rapporteert in sommige eigen evaluaties lagere geschatte taakkosten voor Astra, ondanks de hogere tokenprijzen. Dat maakt de totale kosten per succesvolle uitkomst een belangrijke maatstaf voor jouw eigen werk, in plaats van aan te nemen dat alleen de tokenprijs of een capaciteitsscore de doorslag geeft.

Toepassingen buiten code review

Het overdraagbare idee is het redeneren over relaties tussen verschillende bronnen. Onze bevindingen suggereren verschillende toepassingen die het waard zijn om te evalueren (wij hebben Astra nog niet op deze specifieke taken getest):

• Synthese van onderzoek: tegenstrijdige rapporten verzoenen, claims verbinden aan bewijzen en hiaten identificeren die een samenvatting van elk document zou missen.
• Operationeel onderzoek: een samenhangende verklaring opstellen uit logs, incidentrapporten en runbooks, waarbij waarnemingen worden gescheiden van hypothesen.
• Analyse van vereisten en beleid: een voorgestelde wijziging volgen via specificaties, intern beleid en implementatieplannen om inconsistenties te signaleren voor expert-review.
• Document- en spreadsheetwerk: controleren of aannames, formules en narratieve conclusies overeenstemmen in een rapport en de ondersteunende materialen.

De gemeenschappelijke structuur is verspreide bewijslast met afhankelijkheden tussen de delen. Begin met afgebakend werk waarvan het antwoord gecontroleerd kan worden. De makkelijkste manier om te testen of Astra geschikt is voor jouw workflows of producten, is door het model naast je huidige model te draaien op dezelfde taken en vervolgens de antwoordkwaliteit, verificatietijd en totale kosten te vergelijken.

De bouw en balans van NIGHTSHIFT

We hebben Astra ook gebruikt om een volledig spel te bouwen: NIGHTSHIFT, een action RPG gemaakt met Godot en GDScript. Het moeilijkste probleem was het balanceren van de interacties tussen systemen, en die balans opnieuw te herzien wanneer het spel veranderde.

Dit betekende redeneren over zeven karakterklassen, een passieve vaardigheidsboom van 988 nodes (geïnspireerd door de legendarische Path of Exile passieve node-boom), actieve vaardigheden, runes en inzetbare upgrades, vaardigheidsevoluties en co-op. Over 40 zones verdeeld over 10 acts introduceert de campagne steeds complexere vijandenswermen en combinaties. Het wijzigen van één klasse kan beïnvloeden welke upgrades nuttig zijn, hoe een vaardigheid zich ontwikkelt en wat een party kan aan kunnen.

Tijdens de ontwikkeling hebben we fundamentele wijzigingen aangebracht in de kernsystemen en Astra gevraagd de consequenties uit te werken en deze opnieuw te balanceren. "Balans" in een spel als dit is de moeilijkste creatieve uitdaging voor boeiende gameplay: hoe kun je ingrijpende wijzigingen doorvoeren of volledig nieuwe gamesystemen en mechanieken introduceren, terwijl progressie, gevechten en moeilijkheidsgraad coherent blijven?

We wilden ook dat spelers overpowered endgame-builds konden ontdekken door slimme combinaties van klassen, statistieken, items, passives en actieve vaardigheden. De uitdaging was het vormgeven van een progressie waarbij zelfs het bereiken van het mid-game onzeker was, maar waarbij creativiteit en experimenteren spectaculair beloond konden worden.

Het proces betekende dat we tussen ander werk door terugkeerden naar het spel, Astra feedback gaven en het model volledige autonomie gaven om zijn eigen oordeel te gebruiken bij het verfijnen van die balans. Astra bouwde daarnaast native PS5- en Xbox-controllerondersteuning, native macOS-, web- en Linux-builds en co-op. Co-op was bijzonder interessant, omdat Astra dit kon uitbouwen voor spelen op dezelfde compute en LAN. Omdat we dit wilden distribueren naar collega's die macOS gebruiken, vereiste dit het genereren van een nieuw Xcode-project, een App Store Connect-account, het instellen van meerdere certificaten en entitlements, en notarisatie.

Astra handelde dit alles autonoom af en pauzeerde alleen af en toe om te vragen om autorisaties en permissies die het nog niet had. Als leuke bonus werd het spel ook zo gebouwd dat agents zelf spelers konden zijn; het was enigszins surrealistisch om live co-op sessies te spelen met Astra als teamgenoot. "Ik ben bezig met model-evaluaties" werd een handige verklaring voor het open hebben van een spel wanneer een manager langskwam.

Het spel bood ons een creatieve setting om dezelfde capaciteit te verkennen die opviel bij de code reviews: Astra moest redeneren over hoe elke wijziging de rest van het systeem beïnvloedde.

Toekomstverwachtingen

De volgende spannende stap zou zijn om deze diepgang van redeneren betrouwbaar genoeg te maken om vaker te gebruiken. Dat betekent consistente winst bij moeilijk werk, conclusies die mensen kunnen verifiëren en lagere totale kosten voor een succesvolle uitkomst.

Dat vereist een betere selectie van relevante context, duidelijkere ondersteunende bewijslast en minder onnodige stappen. Het betekent ook privacy-bewarende implementatiepaden die geavanceerde mogelijkheden bruikbaar maken onder echte klantbeloften.

Astra geeft ons een bemoedigend signaal over cross-file redeneren. De praktische kans is om die capaciteit om te zetten in werk dat zowel nuttiger is als gemakkelijker te vertrouwen. Zoals bij het online brengen van elk nieuw model bij CodeRabbit, is de evaluatie slechts één onderdeel van die beslissing.

Bescherming van klantgegevens

Zowel CodeRabbit als onze modelproviders trainen AI-modellen niet op de propriëtaire code van CodeRabbit-klanten of persoonlijke informatie die is verzameld tijdens private code reviews.

OpenAI en Anthropic hebben verschillende bewaartermijnen voor gegevens:

• OpenAI: GPT-6 Astra ondersteunt zero data retention (ZDR) voor in aanmerking komende API-klanten.
• Anthropic: Fable vereist standaard een bewaartermijn van 30 dagen voor veiligheidsmonitoring, maar in aanmerking komende klanten kunnen nu Fable 5 en 5.1 gebruiken met ZDR, terwijl Enterprise Frontier Safeguards (EFS) wordt geïntroduceerd. Voor producten die andere bedrijven bedienen, vereist deze optie afspraken met Anthropic. EFS is ontworpen om bewaarde activiteitsgegevens in door de klant beheerde infrastructuur te houden.

Elk model dat we gebruiken voor klantreviews moet voldoen aan onze vereisten voor gegevensbescherming.