OpenAI Decisions API gir svar du kan bruke direkte – 10 ganger raskere

Hvis en AI-agent bare skal velge riktig handling, trenger du ikke vente på et langt svar som koden må tolke etterpå. OpenAI Decisions API returnerer sannsynligheter, valg og poeng i et fast format som programmet kan bruke direkte. OpenAI oppgir at dette skjer omtrent 10 ganger raskere enn med GPT-6 Luna gjennom Responses API.

Det høres kanskje ut som en liten spesialfunksjon. I praksis treffer den en svært vanlig flaskehals: En modell blir bedt om å klassifisere en henvendelse, prioritere en oppgave eller velge et verktøy, men svarer først med tekst som må parses, kontrolleres og oversettes til en faktisk handling.

Decisions API skjærer bort mye av dette mellomarbeidet. Det er offentlig beta, bare GPT-6 Luna støttes foreløpig, og nøyaktigheten må fortsatt bevises i din egen bruk. Men selve retningen er glimrende: Bruk en rask beslutningsmotor til små, avgrensede valg, og spar de tyngre modellkallene til oppgaver som faktisk krever forklaring og resonnering.

Hva er OpenAI Decisions API?

OpenAI Decisions API er et eget endepunkt som vurderer tekst, bilder eller begge deler og returnerer ett av tre maskinlesbare svar: en sannsynlighet, et valg eller en poengsum. Ifølge OpenAIs dokumentasjon bruker du POST /v1/decisions, og GPT-6 Luna er den eneste tilgjengelige modellen i betaperioden.

En forespørsel består av tre hoveddeler. model angir modellen, input inneholder materialet som skal vurderes, og questions beskriver avgjørelsene du vil ha. Svaret kommer i en answers-liste, der hvert svar kobles til spørsmålets unike navn.

Det viktige er at API-et ikke prøver å skrive en hyggelig forklaring rundt resultatet. Hvis du spør hvilken avdeling som skal håndtere en kundehenvendelse, får du et valg og tilhørende sannsynligheter. Koden slipper å lete etter ordet «fakturering» i et lite essay om kundeservice. Det er faktisk en ganske befriende tanke.

Tre svartyper dekker de vanligste avgjørelsene

API-et har tre spørsmålstyper: predicate, choice og score. De er laget for ulike beslutninger, og skillet er viktig. OpenAIs API-referanse beskriver både feltene i forespørselen og de typede svarobjektene som kan returneres.

predicate brukes til et ja-eller-nei-spørsmål, men returnerer ikke bare ja eller nei. Du får en sannsynlighet fra 0 til 1. Det kan være sannsynligheten for at en pakke er skadet på et bilde, at et tekstavsnitt er relevant, eller at en henvendelse inneholder en bestemt type problem.

choice velger mellom alternativer du har definert på forhånd. Det passer for ruting til avdeling, valg av verktøy eller kategorisering av innhold. Svaret inneholder det valgte alternativet, en confidence-verdi og sannsynligheten for hvert alternativ. Verdiene kan være tekst eller boolske verdier, og typene bevares i svaret.

score brukes når nivåene har en rekkefølge, for eksempel lav, middels og høy alvorlighetsgrad. API-et returnerer en sannsynlighetsvektet poengsum som kan ligge mellom nivåene. I OpenAIs eksempel gir sannsynlighetene 0,1, 0,7 og 0,2 for tre nivåer en samlet poengsum på 1,1. Du får dermed mer informasjon enn bare en hard merkelapp.

Hvorfor er dette nyttig for AI-agenter?

En agent tar mange små avgjørelser før den gjør noe synlig: Hvilket verktøy passer? Må saken sendes til et menneske? Er resultatet godt nok til å fortsette? Skal neste steg være søk, kode eller et vanlig modellsvar? Slike valg trenger ofte ikke en hel tekstgenerering. De trenger et raskt og forutsigbart svar.

Det er her Decisions API kan bli viktigere enn navnet først antyder. Når svaret allerede har riktig type, kan applikasjonen forgrene arbeidsflyten uten en egen runde med teksttolking. Du kan for eksempel sende en fakturahenvendelse til økonomi, legge en usikker skadeanalyse i manuell kontroll eller velge en dyrere modell bare når poengsummen passerer en bestemt terskel.

Dette passer også godt sammen med OpenAIs øvrige agentplattform. Jeg skrev nylig om hvordan OpenAI Agents API flytter mer av agentkjøringen bak ett API-kall. Decisions API løser en smalere oppgave: selve valget mellom kjente alternativer. En agent trenger begge deler, men det er sjelden smart å bruke den tyngste delen av systemet på hvert eneste veikryss.

Flere uavhengige spørsmål kan dessuten sendes i samme questions-liste når de vurderer samme input. Ett produktbilde kan for eksempel sjekkes for skade og kategoriseres i samme forespørsel. Hvis spørsmål nummer to avhenger av svar nummer én, sier dokumentasjonen at du skal sende separate forespørsler. Det skillet gjør flyten lettere å forstå og teste.

Decisions erstatter ikke Responses API

Decisions API er riktig når du vil ha en sannsynlighet, velge mellom faste alternativer eller beregne en poengsum mot definerte nivåer. Det er ikke et billig snarspor til alle typer AI-svar. Skal modellen skrive en forklaring, hente ut mange felt i ditt eget JSON-skjema eller føre en samtale, er Responses API fortsatt riktig verktøy.

OpenAI trekker en tydelig grense i dokumentasjonen. Structured Outputs brukes når du trenger et objekt som følger ditt eget JSON-skjema. Function calling brukes når modellen skal be om at et verktøy kjøres med bestemte argumenter. Decisions brukes når applikasjonen allerede kjenner beslutningsrommet og trenger et raskt, målbart svar innenfor det.

Det betyr også at gode spørsmål blir viktigere enn lange prompts. Kriteriene bør være observerbare, alternativene må ha tydelig forskjellig betydning, og nabonivåene i en poengskala må kunne skilles fra hverandre. Hvis to kategorier betyr nesten det samme, har ikke et pent JSON-svar løst problemet. Da har du bare fått uklarheten tilbake i et ryddigere format.

Hvor raskt er det egentlig?

OpenAI hevder at Decisions API svarer omtrent 10 ganger raskere enn GPT-6 Luna gjennom Responses API. MarkTechPost oppgir et eksempel på rundt 150 millisekunder, mot cirka 1,6 sekunder for et vanlig Luna-kall. Det er leverandøroppgitte tall, ikke en uavhengig test.

Forskjellen kan likevel ha stor praktisk betydning. En forsinkelse på litt over ett sekund er til å leve med i en samtale, men blir fort seig når samme arbeidsflyt skal ta fem eller ti beslutninger etter hverandre. Rundt 150 millisekunder åpner for ruting og prioritering som oppleves nær sanntid.

Fart alene er selvsagt ikke nok. OpenAI har foreløpig ikke publisert tall for nøyaktighet eller kalibrering, og det finnes heller ingen uavhengige evalueringer. Et svar på 0,8 er bare nyttig hvis omtrent åtte av ti tilsvarende vurderinger faktisk er riktige over tid. Det må testes, ikke antas.

Prisen er nesten komisk lav

GPT-6 Luna koster 0,10 dollar per million input-tokens i Decisions API, uten betaling for output, cache-lesing eller cache-skriving. Med valutakursen i begynnelsen av oktober tilsvarer det omtrent 1 krone per million input-tokens. OpenAI opplyser samtidig at tillegg for regional behandling og multiplikator for lang kontekst fortsatt gjelder.

Setter vi det i et mer håndgripelig perspektiv, koster 10 000 input-tokens omtrent ett øre før eventuelle tillegg. En million korte avgjørelser på 100 tokens hver vil bruke 100 millioner input-tokens og koste rundt 10 dollar, altså cirka 96 kroner. Den virkelige regningen vil avhenge av hvor mye kontekst du sender med hver vurdering.

Det er lett å stirre seg blind på den lave tokenprisen. Den største besparelsen kan ligge et annet sted: færre trege genereringskall, mindre kode for å reparere halvveis gyldig output og færre unødvendige turer innom en dyrere modell. Men beta betyr beta. Ikke bygg hele driften rundt en pris eller kontrakt som kan endres uten å ha en plan B.

Slik bør du vurdere API-et før produksjon

Begynn med en smal avgjørelse der du allerede har fasitdata. Det kan være 500 tidligere kundehenvendelser med riktig avdeling, eller et sett bilder som mennesker har merket som skadet eller uskadd. Kjør materialet gjennom API-et, sammenlign svarene med fasiten og mål både falske positive og falske negative.

Deretter setter du terskelen etter konsekvensen av feil. En usikker sortering av en intern e-post tåler kanskje automatikk ved 0,7. En avgjørelse som stanser en betaling eller avviser en kunde bør kreve langt høyere sikkerhet og ofte manuell kontroll. OpenAI anbefaler selv å bruke merkede eksempler fra egen applikasjon når tersklene fastsettes.

Koden må også håndtere at svaret kan være refusal, ikke bare predicate, choice eller score. Logg modellversjon, input, spørsmål, svar og det endelige utfallet så lenge personvern og avtaler tillater det. Uten den historikken vet du ikke om systemet fortsatt treffer når brukeradferd og datagrunnlag endrer seg.

Til slutt bør du teste hele kjeden, ikke bare ett isolert API-kall. Ti ganger raskere modellrespons hjelper lite hvis databasen, køen eller neste verktøy bruker to sekunder. Mål faktisk ende-til-ende-tid, kostnad per fullført oppgave og hvor ofte et menneske må rydde opp.

Dette er den riktige typen spesialisering

AI-bransjen har brukt mye tid på stadig større modeller som kan gjøre stadig mer. Decisions API går motsatt vei: én avgrenset jobb, tre tydelige svartyper og et endepunkt som er laget for å passe inn i vanlig programlogikk. Jeg liker den retningen. Ikke alt trenger å være en samtale, og ikke alle valg trenger et resonnement på størrelse med et leserinnlegg.

Den største begrensningen er at vi foreløpig må stole på OpenAIs egne fartstall, samtidig som bare GPT-6 Luna støttes. Offentlig beta er et godt tidspunkt for testing, ikke for blind tillit. Bruk egne eksempler, mål kalibreringen og behold menneskelig kontroll der feil koster mye.

Hvis resultatene holder, kan dette bli en svært nyttig byggekloss for agenter, kundeservice, dokumentflyt og interne automatiseringer. Kombinasjonen av rundt en tidel av ventetiden, faste svartyper og omtrent 1 krone per million input-tokens er vanskelig å overse. Nå må OpenAI bevise at svarene ikke bare kommer fort, men også er stabile nok til å styre virkelige arbeidsflyter.

Ofte stilte spørsmål