OpenAI har lagt till en ny API-yta för applikationer som behöver snabba, strukturerade bedömningar snarare än generering med öppen gräns. Företagets API ändringslogg listar en version 6 oktober för v1/decisions, en offentlig betaslutpunkt som för närvarande körs på GPT-6 Luna.
Den praktiska skillnaden är viktig. OpenAI beskriver besluten API som ett sätt att förvandla text och bilder till maskinskrivna svar och säger att det kan vara upp till 10 gånger snabbare än att använda svar API för samma typ av klassificeringsstil. Vercel lade till stöd för den nya slutpunkten till sin AI Gateway nästa dag, med hjälp av modellidentifieraren openai/gpt-6-luna-decisions.
Det gör lanseringen till mer än en modellkataloguppdatering. Den introducerar ett förfrågnings- och svarsmönster som sitter vid sidan av chatt, generering, inbäddningar och verktygskörning. För team som använder en multi-model API gateway för team är frågan inte längre bara vilken modell som ska anropas. Det är också vilken API form som bäst passar uppgiften.
Vad förändrades
Besluten API är inriktade på arbetsbelastningar där applikationen behöver ett begränsat resultat: en etikett, kategori, routingbeslut, policyresultat eller annat maskinskrivet svar. Istället för att be en modell för generella ändamål att producera prosa och sedan analysera resultatet, kan utvecklare använda en slutpunkt som är utformad kring strukturerad beslutsutdata.
OpenAI säger GPT-6 Luna är för närvarande den enda tillgängliga modellen för betaversionen. Den begränsningen är viktig eftersom det betyder att utvecklare inte väljer bland en bred familj av beslutsmodeller ännu. De testar en ny OpenAI slutpunkt och en specifik modellbindning samtidigt.
Timingen visar också hur snabbt gateway-leverantörer förväntas absorbera nya API ytor. Vercels support den 7 oktober innebär att utvecklare som använder dess gateway kan anropa besluten API utan att integrera direkt mot OpenAIs slutpunkt. Andra OpenAI-kompatibla plattformar kommer att ställas inför samma produktfråga: om kompatibilitet innebär att endast använda bekanta API:er i chattstil, eller även exponera specialiserade ytor som beslut, agenter, sökningar och verktygskörning.
Varför det är viktigt för gateways
De flesta AI-gateway-arkitekturer började med ett relativt enkelt antagande: normalisera leverantörsskillnader så att utvecklare kan byta modell efter en API. Besluten API driver mot detta antagande. Det är inte bara en annan modell bakom samma chattförfrågan. Det är en specialiserad slutpunkt med ett annat löfte: utdata med låg latens.
Det påverkar routing, observerbarhet och fakturering. Ett klassificeringsanrop som returnerar ett litet skrivet objekt ska inte nödvändigtvis analyseras bredvid en genereringsförfrågan i långa format, även om båda använder en GPT-6-family-modell. Latensmål, framgångskriterier och kostnadstillskrivning kan alla vara olika. Ett beslut om bedrägerikontroll, en etikett för bildmoderering och ett resultat för routing av säljleads kan ha mer gemensamt med varandra än med en samtalsassistent.
För ett AI API kontrollplan för utvecklarteam betyder det att katalogen behöver en tydligare åtskillnad mellan modellidentitet och slutpunktskapacitet. En rad som säger "GPT-6 Luna" räcker inte om en version exponeras genom ett allmänt svarsflöde och en annan genom en maskinskriven slutpunkt för beslut. Åtkomstkontroller kan också behöva vara slutpunktsmedvetna, eftersom ett team kanske vill tillåta lågriskklassificeringsarbetsbelastningar samtidigt som de begränsar användningen av en bredare generation.
Model Gate och liknande OpenAI-kompatibla gateways har en direkt produktimplikation här: kompatibilitet måste nu täcka arbetsflödessemantik, inte bara begära autentisering och modellnamn. Om kunder förväntar sig en API-nyckel, en användningsreskontra och en uppsättning teampolicyer måste beslutsanrop vara synliga som deras egen arbetsbelastningsklass snarare än dolda i allmän GPT-användning.
Fakturering och analys blir mer detaljerad
Lanseringen lägger också press på faktureringssystem som redan kämpar för att göra olika AI-arbetsbelastningar jämförbara. Tokenanvändning är fortfarande viktig, men en beslutsslutpunkt köps ofta för genomströmning, latens och tillförlitlighet. Om slutpunkten marknadsförs som mycket snabbare än svar API för samma uppgiftsklass, kommer kunder att vilja ha analyser som visar om de faktiskt får den operativa fördelen.
Det skapar ett behov av separata rapporteringsdimensioner: slutpunkt, beslutsschema, modell, latens, felfrekvens och kostnad. I en plattform byggd kring unified AI API billing hjälper dessa fält att förklara varför två anrop till samma underliggande modellfamilj kan visas under olika produktkategorier eller prisklasser.
Återförsäljare och partnerplattformar står inför ett relaterat problem. Om de exponerar besluten API för sina egna kunder kan de behöva separat dokumentation, marginalregler och användningsexporter för beslutsarbetsbelastningar. Att behandla varje Luna-samtal som vanlig textgenerering kan sudda ut marginalerna och göra kundfakturor svårare att försvara.
Vad är fortfarande osäkert
Betaetiketten lämnar flera öppna frågor. OpenAI har ännu inte förvandlat besluten API till en bred yta för flera modeller, och GPT-6 Luna är den enda modellen som listas för närvarande. Det är också oklart hur snabbt SDK:er, OpenAI-kompatibla gateways och observerbarhetsverktyg kommer att konvergera till vanliga namn- och spårningskonventioner för beslutsanrop.
Det finns också en produktdesignfråga för utvecklare. Vissa applikationer kommer att dra nytta av en dedikerad typad slutpunkt omedelbart, särskilt när snabb analys har varit spröd eller långsam. Andra kanske föredrar att behålla klassificeringen i ett bredare Responses-arbetsflöde om de är beroende av flerstegsresonemang, verktygsanrop eller delat sammanhang.
Den säkraste läsningen är att OpenAI skär ut en annan specialiserad API-kategori. Den bredare gateway-marknaden har rört sig i samma riktning: sökning, agenter, värdverktyg, ljud och nu maskinskrivna beslut blir separat mätta ytor. För utvecklare kan det innebära bättre passform och lägre latens. För plattformsteam betyder det att gatewaylagret har mer att förstå än en basadress och en modellsträng.