Lead: Hvad er nyt nu
OpenAI lancerer GPT-6.1 Sol, en opgradering af GPT-6 Sol, og positionerer den som en mellemklassemodel med ambitioner tæt på Astra i kodning, computerbrug og professionelt arbejde. Hovedpåstanden er klar: nær-Astra-ydeevne til cirka en femtedel af prisen. Sol er live i OpenAI API som gpt-6.1-sol og tilgængelig i ChatGPT Work og Codex. Alle tal i denne artikel stammer fra OpenAIs eget lanceringsoverblik, gengivet af MarkTechPost, og benchmarks er vendor-rapporterede.
Priser per million tokens: Sol koster 2 dollar for input, 10 dollar for output og 0,10 dollar for cached input. Til sammenligning står Astra til 10, 50 og 1 dollar, mens Luna ligger på 0,10, 0,50 og 0,01 dollar. OpenAI angiver samtidig, at cached læsninger på Sol nu takseres til 5 procent af den almindelige inputrate, ned fra 10 procent på GPT-6 Sol. Det påvirker direkte totalomkostningen i agent-arkitekturer.
Hvad OpenAI siger: pris, tilgængelighed og API-detaljer
Sol kører i API’et som gpt-6.1-sol og kan bruges i ChatGPT Work og Codex. Ifølge modelens specifikationsside er prisen per million tokens: input 2 dollar, output 10 dollar og cached input 0,10 dollar. For Astra hedder det 10/50/1 dollar, og for Luna 0,10/0,50/0,01 dollar. OpenAI fremhæver, at cached reads på Sol nu prissættes til 5 procent af den ordinære inputrate; tidligere var det 10 procent på GPT-6 Sol.
API-specifikationerne: 1.050.000 tokens i kontekstvindue og 128.000 tokens som maks. output. Tekst og billede ind; tekst ud. Tool-calling via Responses API, mens Chat Completions virker uden værktøjer. reasoning.effort accepterer low, medium (default), high, xhigh og max; none og minimal findes ikke. Kendskabsgrænsen er 30. april 2026. Fine-tuning er ikke understøttet.
Driftsrelaterede takster og tilstande: Prompts over 272.000 tokens koster 2x på input og cache samt 1,5x på output for hele forespørgslen. Batch og Flex er angivet 50 procent billigere. Fast mode koster 2x, men er ikke tilgængelig ved EU data residency. US og EU data residency er understøttet. OpenAI varsler også en “GPT-6.1 Sol Ultrafast” i Codex med op til 8x hurtigere tokenhastighed end standard.
Benchmarks: hvad OpenAI rapporterer
OpenAI præsenterer en række evalueringsresultater, som er vendor-rapporterede. Ifølge OpenAI bygger sammenligninger mod konkurrenter på offentligt tilgængelige rapporter.
Kodning: På DeepSWE v1.1 oplyser OpenAI, at GPT-6.1 Sol matcher Astra, omtrent til en femtedel af omkostningen. Sol skulle samtidig overgå GPT-6 Sols bedste score med 6,4 procentpoint ved lavere reasoning effort.
Professionelt arbejde: OpenAIs tal viser, at Sol slår Claude Opus 5.5 (med fallbacks) på GDP.pdf til under halv pris per opgave. På AutomationBench 1.0.6 noteres en margin på 2,2 point over Opus 5.5 ved medium effort, til cirka en tredjedel af omkostningen.
Computerbrug: På OSWorld 2.0 (offline) ligger Sol, ifølge OpenAI, 7 point over GPT-6 Sol ved maks. effort og inden for 2,1 point af Astra – til omkring en syvendedel af pris per opgave.
Videnskab: På Terminal-Bench Science 0.1 mere end fordobler Sol GPT-6 Sols score ved maks. effort. Den gennemsnitlige pris per opgave opgives som 5,47 dollar for Sol mod 23,21 for Opus 5.5 og 23,80 for Astra. Astra topper fortsat benchmarken med 68,1 procent og anbefales til de sværeste forskningsopgaver. Alle tal er fra OpenAIs lanceringsoverblik.
Faktualitet og fejlmarginer
OpenAI angiver en reduktion i faktuelle fejl ved lav effort: andelen af svar med en faktuel fejl falder i deres egne evals fra 11,4 til 7,7 procent, cirka 32 procent reduktion. Reelt værdifuldt, hvis man vil køre lave effort-indstillinger for at spare tid og penge – men kræver validering i egne domæner, dokumentlængder og længere flows.
For god ordens skyld: Samtlige benchmarktal er OpenAIs egne, gengivet via MarkTechPost. OpenAI oplyser, at konkurrenttallene stammer fra offentligt materiale. Uden fulde prompt-sæt, seed-kontrol og omkostningsregler kan tallene ikke efterprøves én til én.
Hvorfor tallene kræver forsigtighed
Små ændringer i prompting, værktøjsvalg og timeouts kan flytte benchmarks markant. Fallback-strategier og retrypolitikker påvirker både score og pris per opgave. Derudover er det uklart, hvilke versioner og indstillinger af Astra og Opus 5.5 der er brugt, og hvordan “faldbacks” er implementeret. Uden standardiserede opsætninger risikerer man æbler mod pærer.
Cost-per-task er også uafklaret: Tæller man kun tokenpriser, eller også lageromkostninger for cache, eksterne værktøjskald, kø-tider og fejlhåndtering? En for snæver beregning undervurderer totalomkostningen – især i agentiske flows med mange skridt. Én flot graf er ikke et deploy-grundlag.
Teknisk konsekvens: caching, agenter og tokenøkonomi
At cached læsninger nu koster 5 procent af inputraten på Sol giver en konkret besparelse, når den samme systemprompt, tool-schema og session-historik genbruges. “Kolde” prompt-dele fylder ofte tusindvis af tokens. Når de takseres til 0,10 dollar per million (mod 2 dollar uncached), flytter det omkostningen for hvert skridt i kæden.
Det kalder på konkrete valg: Korte, stramme systemprompts er stadig bedst, men incitamentet til hård slankning er mindre, hvis cache-raten holder. Hav en plan for cache-invalidisering, så man ikke betaler for forældede værktøjsskemaer. Overvej også, hvor kontekst skal bo: ofte giver det mening at lægge statiske fakta i lokale embeddings og kun lade det dynamiske følge med i prompten. Balancen bliver latency, pris og vedligehold.
Multiplikatorerne ved meget store prompts er kritiske: Over 272.000 tokens fordobles input- og cache-prisen og output stiger 1,5x på hele forespørgslen. Den første overskridelse kan blive dyr, hvis den går ubemærket hen. Et soft-limit og en guard i pipeline kan spare penge; “chunk og stream” slår “monolit og håb”.
Drift og implementering: hvad teams skal teste i PoC’er
Før bred udrulning: genskab egne workloads og mål cost-per-task på tværs af effort-niveauer. Medtag retries, timeouts og tool-kald – ellers er tallene pyntede. Test med og uden caching for at se den faktiske effekt i jeres prompts; små variationer i historiklængde kan vælte økonomien.
Mål hallucinationsfrekvens og faktuelle fejl ved low, medium og max effort i jeres domæner. Det er fint, at lav effort forbedres i OpenAIs evals – men hvor ligger jeres knækpunkt? Test data residency og fast mode: Fast er 2x dyrere og virker ikke med EU-residency. Batch og Flex loves 50 procent billigere – undersøg konsekvensen for latency og throughput på travle dage.
Prøv RAG-arbejdsgange med store dokumenter og kontekstvinduer tæt på millionen. Mål relevans, svarstabilitet og sikkerhedseffekter. Store vinduer hjælper ikke, hvis promptstyringen skrider, eller man mister overblik over, hvad der faktisk blev sendt ind.
Trade-offs: pris vs. rå ydeevne vs. forskning
Det oplagte valg findes ikke. Astra er dyrere, men topper fortsat science-benchmarks og anbefales af OpenAI til de hårdeste forskningsopgaver. Sol sigter på hverdagsproduktion, agentisk kodning og computerbrug, hvor pris per opgave er afgørende. Bygger man brede interne assistenter eller automatiserede eftersyn i kodebaser, kan Sol være et fornuftigt kompromis.
Luna frister med ultralav pris, men der er et ydelsesgab i de rapporterede tal. Til simple triager og grove filtreringer kan den stadig være fin. Kræver opgaverne længere handlingstrin, værktøjsbrug eller robusthed i dokumenttunge flows, er Sol sandsynligvis det økonomiske sweet spot. Omvendt vil nogle organisationer vælge Astra for at minimere fejl i kritiske afgørelser – det koster, men nedbrud koster mere.
Sikkerhed, governance og dataprivatliv
Et kontekstvindue på over en million tokens øger ikke kun mulighederne; det øger også risikoen. Mere tekst ind betyder større eksponering for fortrolige oplysninger, fejlplacerede adgange og utilsigtet dataaflejring i logs. Sørg for adgangskontrol, maskering og data retention-politikker, før de store dokumentindsprøjtninger går i drift.
EU- og US-data residency er understøttet, men fast mode virker ikke med EU-residency. Det påvirker latency og prisstrategi i europæiske miljøer, hvor compliance-krav er stramme. Manglende fine-tuning flytter personalisering over i retrieval, værktøjer og promptdesign. Det gør governance enklere nogle steder, sværere andre.
Hvad journalister og tekniske læsere bør kræve af leverandører
For at benchmarks kan bruges til indkøb, bør leverandører dokumentere opsætningen i detaljer: prompts, versioner, effort-niveauer, værktøjer, retries og tidtagning. Uden det famler man. Del også cost-modellen, inklusive eventuelle lagerpriser for cache og eksterne kald. En enkelt “score” uden kontekst er sjældent beslutningsdygtig.
Replikerbarhed er afgørende. Adgang til eval-scripts eller en sandkasse med faste datasæt og referencesvar ville løfte kvaliteten af diskussionen. Det er ikke kun akademisk pænhed – teams kommer hurtigere til en realistisk baseline.
Konklusion og næste skridt
Hvis prissætningen holder i praksis, flytter GPT-6.1 Sol økonomien for agentiske løsninger og dokumenttunge arbejdsgange. Cached læsninger til 5 procent af inputraten og et kontekstvindue på en million tokens gør længere kæder billigere at køre. Men vendor-rapporterede benchmarks skal valideres, før arkitekturen lægges om.
Næste skridt er praktiske: planlæg små PoC’er, mål totalomkostningen inklusive fejl og retries, test effort-niveauer, og sæt grænser for lange prompts for at undgå multiplikatorfaldgruber. Dokumentér dataflows, især ved store dokumentindlæsninger. Forskellen bliver tydelig, når man måler den.
