OpenAI lancerer GPT‑6 Sol og Luna
OpenAI introducerer to nye modeller i GPT‑6‑familien, Sol og Luna, ifølge materiale gengivet af MarkTechPost. De er tilgængelige i API’et som gpt-6-sol og gpt-6-luna og tilbydes som API‑only (ingen weights til selvhost). MarkTechPost angiver, at de placerer sig under GPT‑6 Astra i hierarkiet. AWS skriver samtidig: “GPT-6 Sol and GPT-6 Luna are now generally available on Amazon Bedrock, giving you more options to match intelligence and efficiency to each workload.” Kildeangivelserne er leverandørnære, så brug dem med omtanke.
Det er her, det rykker i praksis: lavere priser per token, bedre cache‑håndtering og rapporterede benchmarks, der peger på lavere omkostning per opgave. For teams med mange gentagne kald kan det være forskellen mellem pilot og produktion.
Nyheden kort
Sol og Luna udvider familien med to økonomimodeller. MarkTechPost skriver, at OpenAI har brugt metoder beslægtet med Astra for at bringe dens forbedringer ned i hurtigere og billigere varianter. Sol er målrettet komplekse kode‑ og professionelle opgaver til lavere pris. Luna er målrettet hurtige, gentagne opgaver i stor skala.
Alt kører via API. Det gør start let, men binder regioner, SLA og dataspor til OpenAI eller AWS. Nogle vil kalde det et fair bytte. Andre vil savne fuld kontrol.
Prisændringerne – tallene og regnestykket
MarkTechPost gengiver følgende per 1M tokens (OpenAI’s tal; verifikation anbefales):
- GPT‑6 Astra: input 10,00 USD, output 50,00 USD.
- GPT‑6 Sol: input 2,00 USD (før 4,00), output 10,00 USD (før 20,00).
- GPT‑6 Luna: input 0,10 USD (før 0,20), output 0,50 USD (før 1,20).
Sol er halveret på både input og output. Luna input er halveret. Luna output falder fra 1,20 til 0,50, hvilket svarer til ca. 58,3% – ikke 50%. Regn det selv efter før kontrakt, især ved høj volumen.
Regneeksempel 1 (Luna, lav indsats)
Antag 200 inputtokens og 400 outputtokens pr. kald, 100.000 kald pr. uge.
Før: input 0,20$/1M → 0,00004$/kald; output 1,20$/1M → 0,00048$/kald; i alt 0,00052$/kald.
Efter: input 0,10$/1M → 0,00002$/kald; output 0,50$/1M → 0,00020$/kald; i alt 0,00022$/kald.
Besparelse ~58%. Skaler til måned med 4 mio. kald: ca. 2.080$ før mod ca. 880$ efter, alt andet lige.
Regneeksempel 2 (Sol, højere indsats)
Antag 1.000 inputtokens og 1.500 outputtokens pr. kald, 50.000 kald pr. måned.
Før: 4,00$/1M og 20,00$/1M → ca. 0,004$ + 0,030$ = 0,034$/kald → 1.700$/måned.
Efter: 2,00$/1M og 10,00$/1M → ca. 0,002$ + 0,015$ = 0,017$/kald → 850$/måned.
Samme opgave, halvdelen af prisen.
Benchmarks og hvad de reelt viser
MarkTechPost gengiver OpenAI’s egne tabeltal (leverandørrapporteret; uafhængig replikation afventer). De korte nedslag:
- AutomationBench 1.0.6: Sol på xhigh effort scorer 33,2% til ca. 0,27$ pr. task. MarkTechPost anfører, at Claude Opus 5 ved max effort er 26,9% til 11,1× prisen.
- Agents’ Last Exam: Sol ved max effort står noteret med 56,4% og lavere cost per task end Opus 5’s bedste i tabellen.
- DeepSWE v1.1: Sol 68,8% (max) – ca. 1,1 point under Claude Fable 5 (xhigh) – til omkring 80% lavere cost per task. Luna 66,6% (max), sammenlignelig med Opus 5 og Fable 5 ved medium, til 93% og 96% lavere cost per task i de givne sammenligninger.
- FrontierCode 1.1 Main: Sol matcher Fable 5.1 ved xhigh i “klar til merge”‑vurdering, men billigere per task.
- OSWorld 2.0 offline: Sol 60,5% (xhigh) mod Opus 5 60,3% (medium) – angivet ca. 80% lavere cost per task for Sol. Luna ved max slår GPT‑5.6 Sol ved medium til omtrent en tiendedel af prisen.
Bemærk: “cost per task” afhænger af promptlængde, kontekst og effort‑valg. Brug tallene som pejlepunkt, ikke endelig sandhed, indtil tredjeparts‑tests foreligger.
Prompt caching og drift
MarkTechPost beskriver forbedret prompt‑caching i GPT‑6: højere standard‑hitrate, rabatter på cached inputlæsninger op til 90% og delte prefixer inden for 30 minutter. Nye værktøjer nævnes: Prompt Caching Dashboard, diagnostics med forklaringer på misses (fx “tools_changed”), eksplicitte breakpoints, ændring af reasoning‑effort midt i en samtale uden at bryde cache, allowed_tools og prewarming. Der refereres også til en GitHub‑observation om, at andelen af friskt behandlede prompttokens i Copilot blev skåret med over 50% ved lignende tiltag.
En konkret faldgrube: Et delt prefix der indeholder en kundemail, kan i værste fald dukke op i en anden brugers session, hvis cache‑scopet er sat for bredt. Sæt derfor tre faste værn: per‑bruger eller per‑team cache‑scope, automatisk maskering/redaktion af PII før caching, og auditlog på entitetsniveau for cache‑hits. Antag konservativ hitrate i budgetter, til beviserne siger andet.
Tilgængelighed og deployment på Amazon Bedrock
AWS skriver direkte, at Sol og Luna er “generally available” på Bedrock. Det betyder brug af AWS‑identitet, netværk, KMS‑nøgler og overvågning på modelkald. For mange gør det vejen fra POC til drift kortere, især hvor governance allerede lever i AWS.
En hurtig Bedrock‑tjekliste før go‑live: hvilke regioner har adgang, hvordan ser eventuelle Bedrock‑overheads/egress ud i totalprisen, og er der SLA‑forskelle i forhold til direkte API? Afklar på forhånd, ikke i efterfaktureringen.
Hvad det betyder i praksis for tekniske teams
Lavere tokenpriser frister til højere effort. Højere effort kan dog give højere latenstid og lavere throughput. Cachen trækker den anden vej. Mål på færdige resultater, ikke kun på kald.
Start disciplineret og målrettet:
- Byg en enkel cost‑model per flow: input/output‑tokens pr. kald, kald pr. uge, forventet retry‑rate, forventet cache‑hitrate (konservativt).
- Match model til trin: Sol til de svære hop, Luna til volumen. Opgrader kun, hvis kvaliteten kræver det.
- Gør prompts cache‑venlige: frys værktøjsdefinitioner og systeminstruktioner, brug breakpoints, dokumentér hvad der må genbruges, og overvåg hitrater.
- Mål kvalitet og stabilitet: faste eval‑sæt, regressionstests pr. release, og en metrik for cost per successful outcome.
- Hold øje med fire tal i piloten: tokens/kald, hitrate, P50/P95‑latenstid og cost per løst task.
Tradeoffs, begrænsninger og risici
Benchmark‑tabellerne stammer fra OpenAI’s materiale gengivet hos MarkTechPost. Indtil uafhængige tests er ude, er det indikationer. Planlæg egne A/B‑målinger, så beslutninger bygger på jeres data.
Cache‑styring er governance, ikke kun optimering. Rolle‑skift, værktøjsændringer og deling på tværs af teams kan skabe misses – eller utilsigtet kontekstdeling. Diagnostics hjælper, men politikker og auditspor skal være klare.
Billigere output kan også lokke til flere retries og længere samtaler. Sæt budgetlofter pr. flow. Følg cost per resultat, ikke kun per kald.
Hvor giver Sol og Luna mest mening nu
Scenarier med gentagne prompts og en fast systemkontekst: kodeassistenter i IDE’er, interne dokumentbots med standardiseret instruktionsblok, ETL‑sammenfatning og serviceflows med faste regler. Her kan Luna tage volumen, mens Sol løser de sværere delopgaver.
Organisationer med krav om fuld modelkontrol eller skarp datalokalisering bør vurdere afhængigheden af API‑drift og regionale udbud. Bedrock hjælper via AWS’ sikkerhedslag, men logning, retention og datapaths skal være afklaret skriftligt før produktion.
Metode og kilder
Oplysninger om lancering, API‑navne, priser, caching og benchmarks stammer fra MarkTechPost’s artikel, der gengiver OpenAI’s materiale. AWS bekræfter GA på Bedrock. Krydstjek prislinjer og benchmarkdefinitioner mod OpenAI/AWS, når primære dokumenter er tilgængelige.
Den lille, men vigtige detalje om Luna‑output (58% vs. 50%) er nævnt eksplicit hos MarkTechPost. Regn procentsatserne igennem i jeres budgetmodel før indkøb.
Næste skridt
Kør en 1‑uges A/B‑pilot på to udvalgte flows med budgetloft og faste eval‑sæt. Mål fire nøgletal: tokens/kald, cache‑hitrate, P95‑latenstid og cost per successful outcome. Publicér resultaterne internt og iterér. Det er der, forskellen kan mærkes.
