---
title: "GPT-5.6 Sol, Terra en Luna testen: zo kies je op taak"
date: 2026-07-09
author: "Sam"
featured_image: "https://promptcoaching.nl/wp-content/uploads/2026/07/promptcoaching-nl-model-hero.png"
categories:
  - name: "AI en strategie"
    url: "/category/ai-en-strategie.md"
---

# GPT-5.6 Sol, Terra en Luna testen: zo kies je op taak

Prompttest · 9 juli 2026

Begin niet met Sol omdat de naam het sterkst klinkt. Maak Terra met medium effort je baseline, test Luna op dezelfde voorbeelden en schakel alleen op naar Sol wanneer de opdracht meer planning, autonomie of foutcontrole vraagt.

**1. Baseline**Draai dezelfde taak met Terra en leg vooraf vast wat een goed antwoord moet bevatten.

**2. Afschalen**Test Luna zonder de prompt te versoepelen. Controleer vooral randgevallen en verplichte velden.

**3. Opschalen**Test Sol als Terra faalt op samenhang, lange opvolging, code of toolgebruik.

## De modelkeuze die het Codex-team zelf gebruikt

Een vaste favoriet bestaat volgens Codex-productmanager Kath Koverec niet. Zij kiest op taakomvang, foutkosten en wachttijd. Haar praktische indeling uit de Reddit-AMA:

TaakKeuzeExtra instructieKleine lokale wijziging, documentatie of verkenningLichter model, low reasoningVraag om één afgebakende wijziging.Kleine bug met een duidelijke reproductieSol, medium reasoningGeef de reproductiestappen en de test die moet slagen.Onduidelijke bug, onbekende repo of brede refactorSol, hogere reasoningLaat Codex eerst oorzaken onderzoeken.Migratie, productie-incident of securitywijzigingSol, high reasoning; Ultra alleen bij echte parallelle werkstromenVraag om een plan, tests en verificatiebewijs.OpenAI beschrijft Terra als de goedkopere dagelijkse optie en Luna als de snelste, voordeligste tier. Het team wees in de AMA ook op Luna voor afgebakend verkenningswerk dat een sterkere hoofdagent aan een subagent delegeert. Dat is een gebruiksadvies, geen garantie dat dezelfde routering voor jouw repo de beste uitkomst geeft.

## Geef `/goal` een begrensde opdracht

Codex-onderzoeker Allan Zhou gebruikt `/goal` wanneer een agent langer moet volhouden. Koverec gaf daarbij een nuttiger patroon dan “blijf proberen”: beperk de bestanden, bescherm de publieke API, geef een hypotheselimiet en leg vast wanneer de agent stopt.

```
/goal Onderzoek waarom deze flaky test faalt en probeer hem te repareren.

Scope:
- wijzig alleen packages/auth en de bijbehorende tests;
- verander de publieke API niet;
- test maximaal drie plausibele oorzaken;
- draai na iedere poging de relevante tests.

Stop als geen van de drie oorzaken klopt. Meld dan wat je hebt geleerd en welk experiment daarna het meeste informatie oplevert.
```

Deze grens voorkomt twee bekende problemen: een agent die door de hele repo dwaalt en een grote patch die lastig te beoordelen is.

## Houd zware MCP-context bij de taak die haar nodig heeft

Een AMA-deelnemer meldde dat zijn Unreal Engine-MCP al veel gebruik kostte voordat het werk begon. Developer Experience-lead Dominik Kundel stelde twee routes voor: laat Codex de MCP via een CLI en skill ontsluiten, of hang de MCP alleen aan een gespecialiseerde subagent. Zo hoeft je hoofdagent de volledige toolbeschrijving niet bij iedere taak mee te dragen.

Voor kenniswerk geldt een ander patroon. Codex-onderzoeker Janvi Kalra noemt connectors voor Slack, GitHub en Notion een grote stap vooruit, omdat de agent dan bronnen kan lezen en resultaten kan terugschrijven. Geef zo’n agent nog steeds een bronnenlijst, schrijfgrenzen en een expliciete goedkeuringsstap.

**Werkregel:** kies eerst de kleinste model- en toolconfiguratie die je acceptatiecriteria haalt. Schaal pas op als de foutanalyse laat zien wat de lichtere route mist.

## Gebruik één eerlijke taakset

Een losse indrukwekkende output zegt weinig. Kies vijf tot twintig voorbeelden uit het echte werk: normale gevallen, lastige uitzonderingen en invoer die vaak fouten veroorzaakt. Gebruik dezelfde context, tools en uitvoervereisten bij ieder model.

## Schrijf het resultaat, niet de modelnaam

Een goede testprompt noemt doel, bronnen, grenzen, stopregels en gewenste uitvoer. Vraag niet “gebruik Sol en denk extra hard”. De modelkeuze en reasoning-instelling horen in de API-configuratie; de prompt beschrijft wat goed werk is.

### Taaksucces

Is het gevraagde eindresultaat compleet en bruikbaar?



### Bewijs

Zijn bronnen, aannames en onzekerheden zichtbaar waar dat nodig is?



### Herstelwerk

Hoeveel menselijke correcties of extra rondes zijn nodig?



### Efficiëntie

Wat zijn latency, tokens en kosten per geslaagde taak?





## Pas effort pas daarna aan

OpenAI noemt medium een gebalanceerd startpunt. Low past bij latencygevoelig werk; high, xhigh en max horen alleen bij taken waar je evaluatie een echte kwaliteitswinst laat zien. Test bij een migratie ook één effortniveau lager: GPT-5.6 kan dezelfde kwaliteit soms met minder tokens halen.

## Let op met “wees kort”

De GPT-5.6-gids waarschuwt dat algemene instructies als “wees beknopt” de taakprioriteit kunnen veranderen. Schrijf liever: leid met de conclusie, behoud alle vereiste feiten en schrap herhaling en optionele achtergrond eerst.

## Gebruik een stopregel in iedere test

Laat het model expliciet melden wanneer een bron ontbreekt, een claim niet controleerbaar is of de uitvoer buiten het gevraagde schema valt. Tel zo’n nette stop niet automatisch als mislukking: bij risicovol werk kan weigeren beter zijn dan een overtuigende gok. Vergelijk vervolgens hoe vaak iedere tier terecht stopt, onnodig stopt of toch ongefundeerd doorgaat. Dat maakt de keuze veel betrouwbaarder dan alleen een stijlscoresheet.

Keuzeregel: houd de goedkoopste configuratie die de volledige scorekaart consequent haalt. Niet de goedkoopste losse API-call.

 ## Mijn veilige standaard voor Codex: eerst begrenzen, daarna pas opschalen

Begin een normale codingtaak met Sol op medium of high. Zet Fast, max of Ultra pas aan als je kunt aanwijzen welk probleem de standaardinstelling niet oplost. Dat scheelt meer dan blind een lichter model kiezen, omdat een sterke agent met een te brede opdracht alsnog uren context, tools en herstelrondes kan verbruiken.

WerkPraktische startWanneer opschalen?Kleine fix, documentatie, afgebakende reviewSol mediumPas als de eerste poging een concreet randgeval mist.Onduidelijke bug, grotere refactor, onbekende repoSol highMax alleen wanneer extra onderzoek aantoonbaar betere oorzaken of tests oplevert.Vier onafhankelijke onderzoekslijnenUltra kan passenAlleen als de taak echt in parallelle delen uiteenvalt en je de extra tokeninzet accepteert.Ultra is geen reasoningniveau. OpenAI beschrijft het als een aparte modus die standaard vier agents parallel inzet en bewust meer tokens ruilt voor een kortere doorlooptijd en soms een sterker resultaat. Eén kleine bug vier keer laten onderzoeken is dus geen gratis kwaliteitsknop.

## Fast is een snelheidskeuze, geen intelligentiekeuze

Fast laat een ondersteund model sneller antwoorden tegen een hoger credittarief. De officiële Codex-documentatie noemt op 12 juli 2026 GPT-5.5 en GPT-5.4 als ondersteunde modellen: respectievelijk 2,5 en 2 keer het standaardtarief. GPT-5.6 staat daar nog niet bij. Controleer daarom met `/fast status` wat jouw client werkelijk gebruikt in plaats van een multiplier uit een social post over te nemen.

## Zet de subagentrem in je globale AGENTS.md

Sol kan lang zelfstandig doorwerken. Dat is prettig bij een duidelijke taak en duur bij een vage. Als je niet wilt dat iedere brede opdracht automatisch vertakt, leg die keuze één keer globaal vast:

```
Start alleen subagents als ik daar expliciet om vraag.
Gebruik dan het kleinste aantal dat de gevraagde parallelle taken afdekt.
```

De regel verbiedt parallel werk niet. Hij zorgt dat jij de kostenbeslissing neemt. Vraag bijvoorbeeld om twee subagents voor twee onafhankelijke libraries, maar niet om “een team” voor een wijziging die één gedeelde functie raakt.

## Schrijf het stopmoment alsof het een acceptatiecriterium is

Een goede prompt zegt niet alleen wat Codex moet bereiken, maar ook waar deze beurt eindigt. Dat voorkomt dat planning ongemerkt overgaat in bouwen, deployen en nog een reviewronde.

```
Onderzoek de bug en schrijf een plan met maximaal drie plausibele oorzaken.
Stop na het plan en wacht op feedback. Wijzig nog geen bestanden.
```

Voor een uitvoerende opdracht mag de grens verder liggen:

```
Implementeer de afgesproken fix en draai de relevante tests.
Maak geen PR en deploy niets. Stop zodra de tests groen zijn of nadat
twee verschillende reparatiepogingen dezelfde blocker geven.
```

“Blijf doorgaan tot alles werkt” is soms precies goed. Schrijf er dan bij welke tests tellen, welke bestanden buiten scope liggen en welke externe actie toestemming vereist.

## De zuinigste Codex-taak is meestal de best afgebakende taak

Modelkeuze telt, maar contextdiscipline telt iedere beurt opnieuw. Geef alleen relevante bestanden, knip logs terug tot de eerste fout en zet beslissingen in een issue of kort projectbestand. Start een nieuwe taak wanneer onderzoek, implementatie en productiecontrole verschillende bronnen nodig hebben. Combineer dit bij lange sessies met de 240K-compactiebuffer verderop op deze pagina.

**Broncontrole 12 juli 2026:** [OpenAI over GPT-5.6 en Ultra](https://openai.com/index/gpt-5-6/), de [officiële Codex Speed-documentatie](https://learn.chatgpt.com/docs/agent-configuration/speed) en de [Codex rate card](https://help.openai.com/en/articles/20001106-codex-rate-card). Medium/high als praktische standaard en de subagentrem zijn operatoradviezen, geen universele OpenAI-regel.

## Bronnen en claimgrenzen

Deze pagina is gecontroleerd aan de hand van de [officiële OpenAI-modelgids voor GPT-5.6](https://developers.openai.com/api/docs/guides/latest-model) en de [aankondiging van OpenAI Developers van 9 juli 2026](https://x.com/openaidevs/status/2075286157186003348). OpenAI positioneert Sol, Terra en Luna voor verschillende taakvormen. Prestaties, latency en kosten blijven workload-afhankelijk; test daarom met eigen representatieve taken. De modelnamen gaan over de API en zeggen niet automatisch welke modellen in ieder ChatGPT-abonnement zichtbaar zijn.

Toegevoegd op 11 juli 2026: adviezen uit de [Reddit-AMA met het OpenAI Codex-team](https://www.reddit.com/r/codex/comments/1us9ty9/ama_with_openais_codex_team/). Uitspraken over persoonlijke modelkeuze en toekomstige verbeteringen zijn teamadviezen of voornemens, geen productgaranties.

 **Lees verder**  
 [Schrijf een werkopdracht in plaats van een losse prompt](https://promptcoaching.nl/chatgpt-work-goede-opdracht-geven/)  
 [Zes checkpoints voor AI-coding](https://promptcoaching.nl/ai-coding-workflow-checkpoints/)  


## Voorkom dat een lange Codex-taak onnodig in het duurdere contexttarief valt

GPT-5.6 Sol heeft ruimte voor 1,05 miljoen tokens, maar meer context is niet gratis. OpenAI rekent bij meer dan 272.000 inputtokens twee keer het inputtarief en anderhalf keer het outputtarief voor het volledige verzoek.

Laat Codex daarom bij lange codingtaken eerder compacten. Voeg dit toe aan `~/.codex/config.toml`:

```
model_context_window = 272000
model_auto_compact_token_limit = 240000
```

De 240K-grens geeft ruimte voor toolresultaten, systeemprompts en de compactiesamenvatting. OpenAI schrijft deze waarde niet voor en de uiteindelijke requestgrootte kan afwijken. Bewaar acceptatiecriteria en belangrijke foutmeldingen in bestanden of een issue, want compactie kan details samenvatten.

### Wat kost GPT-5.6 Sol via de API?

NormaalBoven 272K inputInput per 1M$5$10Cached input$0,50$1Output per 1M$30$45Korte taken worden hiermee niet goedkoper. Gebruik voor een nieuwe werkfase liever een nieuwe taak dan maanden aan irrelevante geschiedenis mee te dragen.

**Broncontrole 12 juli 2026:** [OpenAI GPT-5.6 Sol](https://developers.openai.com/api/docs/models/gpt-5.6-sol) en de [Codex-configuratiereferentie](https://learn.chatgpt.com/docs/config-file/config-reference#configtoml). De dollarbedragen zijn API-prijzen; Codex-abonnementen kunnen met credits of gebruikslimieten werken.