OpenAI har gjort GPT‑5.6‑familien generelt tilgængelig efter en begrænset preview. Ikke bare én model, men tre: Sol som flagskib, Terra som mellemvare og Luna som volumeklasse. Samtidig lander to ændringer i Responses API, der rækker ind i drift: Programmatic Tool Calling og en multi‑agent beta. Det flytter beslutninger fra laboratoriet over i økonomistyring, sikkerhed og arkitektur.
Det korte af det lange: prisen per million tokens sænker tærsklen for højvolumenbrug, cache‑reglerne flytter omkostninger mellem input og gentagelser, og værktøjskald i et isoleret JavaScript‑miljø gør agent‑flows lettere at bygge — men sætter infosec på arbejde. Spørgsmålene følger med nytten.
Tre modeller, tre budgetter
Sol, Terra og Luna er officielt prislagt per 1M tokens med differentierede input og output‑takster. Ifølge den sammenstillede tabel gengivet i MarkTechPosts gennemgang: Sol koster 5 dollar for input og 30 dollar for output, Terra 2,50 for input og 15 for output, og Luna 1 for input og 6 for output. Alle tre er tilgængelige i API’en, mens adgangen i Chat\/ChatGPT varierer efter brugerplan, hvor Sol tilbydes til Plus\/Pro\/Business\/Enterprise på de højere “effort”‑indstillinger, og Terra er tilgængelig for Free\/Go i Chat.
Denne forskudte tilgængelighed er ikke kosmetik. Den afgør, hvem der faktisk kan teste og rulle ud uden kontraktændringer. IT‑drift må derfor koordinere, hvem der ser hvad, hvornår, for at undgå datasplid mellem sandkasser og produktion.
Faktaboks med nøgletal
– Modelnavne: GPT‑5.6 Sol (flagship), Terra (balanceret), Luna (omkostningseffektiv)
– Pris per 1M tokens: Sol $5 input \/ $30 output; Terra $2,50 \/ $15; Luna $1 \/ $6
– Tilgængelighed: Alle tre i API; i Chat varierer adgangen pr. brugerplan, Sol for Plus\/Pro\/Business\/Enterprise ved middel\/høj effort, Terra for Free\/Go; “max”‑indstilling beskrives som tilgængelig for brugere med GPT‑5.6‑adgang (jf. den gengivne oversigt)
– Nye API‑funktioner: Programmatic Tool Calling og multi‑agent beta i Responses API
Hvad er Programmatic Tool Calling i praksis
OpenAI beskriver Programmatic Tool Calling således: Modellen skriver JavaScript, som eksekveres i en isoleret V8‑runtime uden netværksadgang. Ingen HTTP. Ingen DNS. Ingen intern trafik. Pointen er, at modellen kan lave små beregninger, parsing og kontrol‑logik lokalt i en sandbox, så applikationen ikke skal hoppe ud i en separat funktion for hvert trin.
Sikkerhedsantagelsen hviler på isolation. Et V8‑miljø uden net forhindrer data i at vandre ud, men efterlader klassiske gråzoner: filsystemadgang, ressourcelofter, persistens på tværs af kald og eventuelle sidekanaler (tid, CPU‑profil). Dokumentationen, som gengivet, siger “ingen netværk”. Den siger ikke alt om syscalls og timeouts. Det bør afklares i en sikkerhedsgodkendelse før produktion.
Multi‑agent beta og ‘ultra’
Den nye multi‑agent beta giver mulighed for at køre flere agenter i parallel. En ‘ultra’‑konfiguration beskrives med fire samtidige agenter. På Terminal‑Bench 2.1 hævdes en stigning fra 88,8 til 91,9 procent. Det lyder småt — og er det måske også i en ren benchmark.
I drift kan fire agenter betyde fordoblet eller firedoblet tokenforbrug, afhængigt af orkestrering og delte kontekster. Spørgsmålet er derfor ikke kun “bedre score?”, men “bedre pr. krone?”. Dokumentationen, som refereret, uddyber ikke ressourceprofil pr. agent eller priseksempel for en ‘ultra’‑session. Det er et af de steder, hvor indkøb og arkitektur bør kræve regneeksempler.
Cache‑regler der flytter regnestykket
OpenAI ændrer prompt caching med tre vigtige parametre: eksplicitte “breakpoints” i prompts, minimum 30 minutters cache‑levetid, og at cache‑skrivninger faktureres til 1,25 gange modellens normale inputpris. Cache‑læsninger beholder 90 procents rabat på input. Det lyder teknisk. Det er ren økonomi.
Konsekvensen: Flows med mange gentagne system‑prompter eller lange instruktioner bliver markant billigere ved cache‑læsninger. Men hvis man ofte ændrer små detaljer, der bryder cachen, betaler man dyrere writes igen og igen. 30 minutters minimumslevetid gør sporadiske kald mindre fordelagtige, fordi man ikke altid når at få læserabatten. Planlæg derfor: hvor ofte fornyes prompts, hvilke dele kan stabiliseres, og hvem ejer cache‑politikken i CI\/CD?
Hvad siger evals — og hvad siger de ikke
På Artificial Analysis Coding Agent Index v1.1 rapporterer OpenAI, at Sol rammer 80 ved “max reasoning”, 2,8 point over Claude Fable 5 — ifølge de gengivne tal med mindre end halvt så mange output‑tokens og tid. Samtidig nævnes et nyt tal for Agents’ Last Exam: 53,6 for Sol. OpenAIs egen evaltabel, som gengives, fører dog Sol med 52,7 procent, mens Fable 5 står på 40,5. Forskellen på 13,1 point er den samme — kun Sol‑tallet afviger. Hvilken “reasoning”‑indstilling gav 53,6? Ikke oplyst.
På SWE‑Bench Pro står Sol på 64,6 procent i samme oversigt, mens Claude Mythos 5 er omkring 80,3. Et hul på cirka 15 point på en bredt fulgt kode‑eval. På andre benchmarks (Terminal‑Bench 2.1, DeepSWE, BrowseComp, OSWorld 2.0) ser Sol stærk ud, men mønsteret er ikke entydigt: Toolathlon viser eksempelvis Sol under Fable 5. Konklusionen er den jordnære: mål mod egne eval‑sæt, ikke kun scoreboardet.
Modelvalg i praksis
Ud fra pris og profiler tegner der sig et mønster: Sol til komplekse beslutninger, planlægning og generativ kode, hvor én fejl koster dyrt. Terra som “default” til generelt vidensarbejde og interne assistenter. Luna til store volumener af samtaler, hurtige svar og enkle beslutningstræer, hvor overvågning og fallback kan fange fejl.
Undtagelser findes. Hvis værktøjsbrug dominerer, kan Luna\/Terra levere fint, fordi eksterne værktøjer bærer præcisionen, mens modellen orkestrerer. Omvendt: Hvis man udnytter multi‑agent eller lange kontekster, bliver Sols øvre kapacitet og bedre agent‑scores mere relevant — selv når prisen gør ondt i output.
Sikkerhed og governance først
Programmatic Tool Calling lover isolation i V8 og ingen netadgang. Godt. Men enterprise‑teams bør have klare svar på: er filsystem helt frakoblet? Hvilke syscalls er whitelistet\/blokeret? Hvad er CPU\/wall‑time‑grænser, og hvordan håndhæves de? Logges og revideres alt JS‑indhold og output deterministisk for audits? Og hvor sker isolationen i en multi‑tenant cloud?
Spørgsmålet om dataudslip flytter også. Ingen netværk fra sandbox er betryggende, men værktøjs‑API’er uden for sandboxen kan stadig kaldes programmatisk via “tools”. Her kræver compliance end‑to‑end‑tracing: hvilken agent udløste hvilket værktøj, med hvilke parametre, og hvor endte data? Uden det opstår blinde vinkler i DPA og revisionsspor.
Implementering og drift
At gå fra POC til produktion kræver tydelige API‑kontrakter. Responses API ændrer orkestreringen: Beslut, hvornår model‑skrevet JS må køre, hvordan fejl håndteres (timeout, exceptions, delvise writes), og hvilke sikkerhedskontroller der placeres før\/efter sandboxen. Teststrategien må udvides med scenarier for cache‑breakpoints og multi‑agent konkurrence.
Driftsmæssigt bliver monitorering af tokenforbrug finere: adskil input, output, cache‑writes og cache‑reads. Ellers skjuler 90 procents rabatten sving i forbruget, og regningen rammer uventet — især hvis variationer i prompt‑versionering bryder cachen oftere end planlagt.
Regneeksempler der gør ondt og godt
Antagelser (for overslag, ikke fakturakopier): 1.000 sessioner á 2.000 input‑tokens og 1.000 output‑tokens. 70 procent genbruger en identisk systemprompt på 1.500 tokens inden for 30 minutter. Cache‑write pr. ny systemprompt = 1,25× input.
– Sol: Uden cache cirka $5×2.000\/1M + $30×1.000\/1M = ~$0,04 pr. session. Med cache: første session skriver 1.500 tokens til 1,25× ($5×1.500\/1M×1,25 ≈ $0,0094), efterfølgende 70 procent læser med 90 procent rabat (≈ $0,0005 per læsning). Den samlede besparelse ender typisk i størrelsesordenen 10–25 procent afhængigt af andelen af cache‑reads og outputlængde.
– Terra og Luna: Samme logik, men den lavere inputpris flytter balancen. Fordi cache‑write er dyrere end uncached input (1,25×), kan write‑tunge workloads (mange unikke prompts) blive mindre fordelagtige relativt. Læsetunge, stabile flows vinder mest — især i Luna, hvor input er $1\/M, så 90 procents rabat på læsninger er næsten “gratis”.
Hvornår giver ‘ultra’ mening
Hvis opgaven kan paralleliseres naturligt — fx søge\/planlægnings‑tråde eller uafhængige hypoteser — kan fire agenter løfte både latency og kvalitet. Men prisen følger med, og uden hårde stop for tokens pr. agent samt en fornuftig aggregator æder regningen gevinsten. Benchmarks viser forbedringer på Terminal‑Bench; rigtige workloads bør måle latency p95\/p99 og omkostning pr. løst opgave, ikke kun procentpoint.
Her mangler stadig svar: Hvordan aggregeres output? Stemmer agenterne, eller vinder “først færdig”? Og prissættes koordinationen som særskilte tokens? Dokumentation for priseksempler på ‘ultra’ efterlyses af gode grunde.
Usikkerheder der bør afklares
- Agents’ Last Exam: Hvilken reasoning‑konfiguration gav 53,6 for Sol, når evaltabellen viser 52,7? Hvad er mest repræsentativt for enterprise‑workloads?
- Prompt caching: Hvordan håndhæves 30‑minutters levetid teknisk (server‑tid vs. klient‑ticket), og er cachen isoleret pr. organisation i multi‑tenant miljøer? Sletning\/retention ift. GDPR?
- Sandbox‑sikkerhed: Hvilke syscalls er blokeret, tids\/CPU‑grænser, eventuel I\/O‑adgang og auditerbarhed af JS‑kørsler? Fuldstændigt offline — også for interne netværk?
- Multi‑agent pris: Hvad koster en typisk 30‑sekunders ‘ultra’‑session (tokens pr. agent, koordination)? Og hvordan ser output‑aggregeringen ud i API‑kontrakten?
- Adgangsregler: Er model‑tilgængelighed i Chat bundet til bruger eller organisation, og hvordan sikres konsistens mellem Chat og API i enterprise‑konti?
- Benchmark‑metodologi: Datasæt, prompts, temperatur, max reasoning, tokenforbrug og scripts til reproduktion — nødvendig for troværdige sammenligninger med Anthropic og Google.
Hvad betyder det de næste seks måneder
Kortsigtet tvinger GPT‑5.6 til to hurtige beslutninger: vælg en default‑model (ofte Terra) og sæt en cache‑politik i jeres pipeline. Langsigtet bør governance‑rammen udvides til værktøjssandboxing, audit‑logning og multi‑agent kontrol. Økonomisk giver de nye takster et incitament til at stabilisere prompts, forkorte output og måle på opgave‑niveau — ikke kun per token.
Benchmark‑lederskab på enkelte tests er fint, men ændrer ikke det grundlæggende: modeller skal vælges efter opgaven. Især når SWE‑Bench Pro viser et markant hul til Claude Mythos 5. Det er ikke en deal‑breaker, men en påmindelse om, at robusthed og fit‑for‑purpose slår flotte tal på en slide.
Kilder og metode
De centrale fakta i artiklen — tre‑tiers lancering, priser, Programmatic Tool Calling i isoleret V8 uden netværk, multi‑agent beta og cache‑reglerne (breakpoints, 30 minutter, 1,25× write, 90 procent read‑rabat) — er samlet fra MarkTechPosts gennemgang af OpenAIs offentliggjorte materialer. Evals og benchmark‑tal (AA Coding Agent Index v1.1, Agents’ Last Exam, Terminal‑Bench 2.1, SWE‑Bench Pro m.fl.) refererer til de tabeller, MarkTechPost gengiver fra OpenAI. For en bredere debat om modelkapabilitet kontra abstrakt problemløsning kan læsere orientere sig i uafhængige analyser som The Algorithmic Bridge.
Det er redaktionelt relevant, at en del nøglepunkter bør verificeres direkte i OpenAIs officielle blog, prisside og Responses API‑dokumentation, herunder nøjagtige adgangsregler pr. produktflade, cache‑håndhævelse og sandbox‑garantier. Uden dem risikerer implementeringer at blive styret af antagelser i stedet for kontrakter.
