GPT-6 Astra API: Modell-ID:t, slutpunkten och vad en uppgift med lång horisont faktiskt kostar

The short version: GPT-6 Astra is callable today at https://api.openai.com/v1 under a single model id, gpt-6-astra, at $10.00 per million input tokens, $1.00 cached input and $50.00 output — the figures Ope​nAI's own pricing page carried on September 16, 2026. The model itself is from September 3, 2026, thirteen days before this page was written, so nothing here is launch coverage and nothing here is framed as an announcement. This is the reference page for the developer question that comes after availability: what string to pass, which endpoint takes it, what the 1,050,000-token window really buys, what the account has to look like first, and what one genuine long-horizon agent run costs on a rate card that quietly reprices itself above 272,000 input tokens. GPT-5.6 Sol appears throughout only as the price baseline it is sold above, never as the subject.

Anledningen till att en tretton dagar gammal modell förtjänar en sida den här veckan är att vägarna in till den förändrades efter lanseringen, och API-vägen är nu den vanliga. När Ope​nAI släppte Astra den 3 september beskrev man det som en utrullning snarare än en tillgänglighet; den 8 september uppgav man att modellen var fullt utrullad till Plus-, Pro-, Business- och Enterprise-användare i Co​dex och ChatGPT Work, och i veckan den 14 september listade AWS den på Bedrock och Microsoft Foundry tillhandahöll den som allmänt tillgänglig. För den som anropar API:et spelar den ordningen mindre roll än det låter — slutpunkten har varit live och dokumenterad hela tiden — men det innebär att inköpsfrågorna kring den nu har svar som de inte hade på lanseringsdagen. Allt nedan lästes från Ope​nAI:s egen modelldokumentation, prissida och sida för datakontroller den 16 september 2026, och allt som kommer från någon annanstans anger det i meningen som innehåller det.

Modell-id:t, och snapshot-frågan besvarad ärligt

Strängen som ska skickas är gpt-6-astra — gemener, med bindestreck, inget leverantörsprefix. Det är det enda ID som Ope​nAI dokumenterar för den här modellen.

Om du letar efter en daterad ögonblicksbild att låsa fast, finns det ingen att hitta, och vi kommer inte att hitta på ett trovärdigt suffix. OpenAI:s modellsida för GPT-6 Astra listar exakt en post under Ögonblicksbilder, och det är den rena gpt-6-astra. Det finns ingen daterad form av typen -2026-09-03 och inget -latest-alias på leverantörens sida. Vi såg ett föränderligt alias av formen ~openai/gpt-astra-latest i en routerlista under vår undersökning; det är en gateway-konstruktion byggd ovanpå leverantörs-id:t, inte något som OpenAI publicerar, och det bör inte läggas in i din konfiguration som om det vore det.

Den praktiska konsekvensen är liten men värd att nämna. Du kan hämta modellobjektet för att bekräfta vad du kommunicerar med:

curl https://api.openai.com/v1/models/gpt-6-astra -H "Authorization: Bearer $OPENAI_API_KEY"

Lås det bara id:t i ett konfigvärde i stället för att skriva in det på ett dussin anropsplatser. Om Ope​nAI senare lägger till daterade snapshots blir det bara id:t ett rörligt mål och ditt låsta värde börjar ändras under fötterna på dig – en plats att redigera är skillnaden mellan en tvåminutersändring och en eftermiddag av grepande.

Slutpunkten: bas-URL, kompatibilitet och en begäran som körs

The base URL is https://api.openai.com/v1. Per Ope​nAI's model documentation, GPT-6 Astra is supported on Responses (/v1/responses), Chat Completions (/v1/chat/completions) and Batch (/v1/batch). It is explicitly not supported on Realtime, Assistants, Fine-tuning, Embeddings, image generation and editing, video, audio, moderation, or the legacy Completions endpoint — and those absences matter as much as the presence list, because a team that planned around the Assistants API or a fine-tuned variant has to replan rather than rewrite.

Om kompatibilitet: detta är OpenAI:s eget förstaparts-API, vilket är det wire-format som alla OpenAI-kompatibla SDK:er och klienter skrevs mot. Allt som talar det formatet kan kommunicera med gpt-6-astra utan en shim – du ändrar modellsträngen och, om du migrerar från en äldre OpenAI-modell, parameternamnen nedan. Nytt arbete bör använda Responses API: det är ytan där OpenAI dokumenterar den här modellens resonemangskontroll, det är där de inbyggda verktygen finns, och Chat Completions-stödet för de nyaste modellerna har historiskt varit det mindre djupgående av de två.

Ett minimalt streaminganrop, med reasoning effort inställt:

curl https://api.openai.com/v1/responses \

-H "Authorization: Bearer $OPENAI_API_KEY" \

-H "Content-Type: application/json" \

-d '{"model": "gpt-6-astra", "input": "Lista de filer du skulle ändra för att flytta den här tjänsten bort från det äldre autentiserings-API:et.", "reasoning": {"effort": "high"}, "max_output_tokens": 16000, "stream": true}'

Och samma sak i Python, vilket är där de flesta läsare faktiskt kommer att hålla till:

from openai import OpenAI

client = OpenAI()

stream = client.responses.create(model="gpt-6-astra", input="Lista de filer du skulle ändra för att flytta den här tjänsten från det äldre auth-API:et.", reasoning={"effort": "high"}, max_output_tokens=16000, stream=True)

för händelse i ström:

if event.type == "response.output_text.delta": print(event.delta, end="")

Tre saker i den begäran är specifika för den här modellen snarare än kopierade från en generisk snabbstart.

• Resonemangsansträngning är ett kostnadsreglage, inte bara ett kvalitetsreglage. Ope​nAI:s modellsida listar de värden som stöds som low, medium, high, xhigh och max. Lägg märke till var den listan börjar: det finns inget none eller minimal för GPT-6 Astra, så golvet har höjts. Resonemangstokens faktureras som utdatatokens till $50.00 per miljon, vilket innebär att ändra ansträngningen från high till max är ett beslut med ett pris kopplat till sig, inte en gratis kvalitetsuppgradering.

• Streaming stöds, och det är det ärliga sättet att köra långa turer. En enda begäran till den här modellen kan generera upp till 128 000 utdatatokens. Att vänta på att det ska landa i en enda svarskropp, utan insyn i om det gör framsteg, är så man till slut gissar sig fram när det gäller timeouts.

• Prompt-cachning är explicit här. Responses API dokumenterar en prompt_cache_breakpoint på text-, bild- och filinnehåll, med läget explicit, som markerar "det exakta slutet på ett återanvändbart promptprefix" och ärver sin TTL från begärans prompt_cache_options.ttl. På en modell där priset för cachad indata är en tiondel av priset för icke-cachad indata är placeringen av den gränsen den mest avgörande raden i din begäran.

Vad ett tokenfönster på 1 050 000 tokens faktiskt innebär

De dokumenterade siffrorna är ett kontextfönster på 1 050 000 token, en maximal indata på 922 000 token, en maximal utdata på 128 000 token och en kunskapsgräns den 30 april 2026.

Börja med aritmetiken som folk missar: 922 000 plus 128 000 är lika med 1 050 000. Fönstret delas mellan det du skickar och det modellen kan returnera, och utdatataket reserveras ur det. Du kan inte skicka 1 050 000 tokens som indata; det praktiska taket för en enskild begäran är 922 000, och mindre än så om du vill ha utrymme för ett riktigt svar.

Vad får man för en miljon tokens i de enheter du faktiskt arbetar i? Omvandlingar från token till text är ungefärliga, och dessa är våra snarare än OpenAI:s, men de ligger i rätt storleksordning: vid ungefär fyra tecken per token är 1 050 000 tokens i storleksordningen 750 000 ord, eller något i stil med hundra tusen rader kod. Det är ett medelstort repositorium, i sin helhet, med plats kvar för verktygsutdata som en agent genererar medan den arbetar. Långhorisontfallet som modellen säljs in för är precis detta: en agent som läste en fil för en timme sedan och fortfarande kan se vad den sade, i stället för en som har komprimerat morgonen till ett sammanfattande stycke.

Sedan delen som hör hemma på en kostnadssida snarare än en specifikationssida. Ope​nAI:s modelldokumentation anger att prompter med fler än 272 000 indatatokens prissätts till 2x indata- och cachepriser samt 1,5x utdata för hela förfrågan. Prissidan har det som en andra rad: lång kontext på GPT-6 Astra är $20.00 indata, $2.00 cachad indata och $75.00 utdata. Så de övre tre fjärdedelarna av det fönstret är ett prisband, inte bara utrymme. En körning vars transkript ligger över 272 000 tokens betalar dubbelt för varje indatatoken — inklusive de cachade — för hela förfrågan, och det är den enskilt största svängningen i den här modellens ekonomi. Det gås igenom i sin helhet nedan.

Ytterligare en mekanism som är värd att känna till, eftersom det är leverantörens eget erkännande att ett fönster inte är hela svaret. För Co​dex beskriver Ope​nAI en experimentell kontextmetod som levereras med Astra, där anteckningar består över kontextfönster i stället för upprepad komprimering till en enda sammanfattning, medan tidigare fönster förblir sökbara så att krav och testresultat från tidigare meddelanden och verktygsutdata fortsätter att gå att hitta. Ope​nAI kallar det experimentellt, säger att det är aktiverat i Co​dex config.toml och säger att det kommer att bli standard för Astra. Om du bygger motsvarigheten själv på API:et är det formen att kopiera: beständiga anteckningar plus hämtbar historik, i stället för en enda heroisk prompt.

Och gränsen för själva siffran: ett stort fönster är en kapacitet, inte en garanti för uppmärksamhet över hela fönstret. De leverantörsrapporterade siffrorna för lång horisont är en bättre vägledning för beteendet än tokenantalet – Ope​nAI rapporterar OSWorld 2.0 till 72,6 % vid ungefär 40 minuter per uppgift, och Terminal-Bench 4.0 till 57,9 % mot 37,3 % för GPT-5.6 Sol. Det är Ope​nAI:s egna siffror, inte reproducerade av oss, och den oberoende bilden är nära men inte identisk: Artificial Analysis uppmätte Astra till 59,1 % på Terminal-Bench v4.0 mot 52,0 % för Claude Fable 5.1 och 39,9 % för GPT-5.6 Sol. Båda är överens om att gapet för lång horisont jämfört med den tidigare generationen är verkligt; ingen av dem är en ersättning för att köra din egen uppgift.

Indatamodaliteter, och filfrågan lämnad ärligt öppen

OpenAI:s modellsida listar indatamodaliteter för text och bild, med textutdata. Inget ljud, ingen video, ingen bildgenerering för den här modellen.

Bildindata läggs in som en innehållsdel i ett användarmeddelande. Deltypen är input_image, och bilden tillhandahålls antingen som en fullt kvalificerad URL eller en base64-data-URL på image_url, eller som ett file_id från Files API. Det finns en valfri detail av auto, low, high eller original, med standardvärdet auto. Formen är:

{"model": "gpt-6-astra", "input": [{"role": "user", "content": [{"type": "input_text", "text": "vad ändrades i den här skärmbilden?"}, {"type": "input_image", "image_url": "data:image/png;base64,...", "detail": "high"}]}]}

OpenAIs vision-dokumentation anger att PNG, JPEG, WEBP och icke-animerad GIF accepteras, upp till 512 MB total nyttolast per begäran och upp till 1 500 bilder per begäran, där bilder över 30 000 patchar avvisas i stället för att skalas ned. Det är plattformens allmänna visionsgränser snarare än Astra-specifika, och bilder faktureras som tokens precis som alla andra indata.

Nu kommer frågan som läsare faktiskt kommer med, och det ärliga svaret. Kan du skicka filer eller PDF:er? Vi kunde inte bekräfta dokumentinmatning för den här modellen i Ope​nAI:s dokumentation, och vi tänker inte antyda att det fungerar. Responses API definierar visserligen en innehållsdel av typen input_file, så själva infrastrukturen finns i API:et generellt; men Ope​nAI:s sida för GPT-6 Astra listar text och bild som sina indatamodaliteter och listar inte file, och vi hittade inget uttalande från Ope​nAI som dokumenterar PDF-inmatning för denna endpoint. En router-listning för samma modell visar visserligen file tillsammans med text och bild – betrakta det som router-rapporterat, vilket är vad en router registrerar om en route snarare än vad leverantören garanterar. Om dokumentinläsning är avgörande för din arbetsbelastning bör du testa det mot den verkliga endpointen innan du bygger på det, och ha en OCR-till-text-fallback redo. Det är skillnaden mellan en eftermiddag av testning och en omskrivning.

Hela prislinjen, och en långsiktig körning prissatt

Alla siffror i det här avsnittet hämtades från Ope​nAI:s egen prissida den 16 september 2026, och alla avser per miljon tokens på nivån Standard om inte raden anger något annat.

• Kort kontext, upp till 272K indata — $10.00 indata, $1.00 cachad indata, $12.50 cacheskrivning, $50.00 utdata.

• Lång kontext, över 272K indata — $20.00 indata, $2.00 cachad indata, $25.00 cacheskrivning, $75.00 utdata, tillämpas på hela begäran.

• Batch och Flex — hälften av Standard: 5,00 $ / 0,50 $ / 6,25 $ / 25,00 $ kort kontext, 10,00 $ / 1,00 $ / 12,50 $ / 37,50 $ lång kontext.

• Snabbläge – dubbelt mot Standard: 20,00 $ / 2,00 $ / 25,00 $ / 100,00 $ för kort kontext, 40,00 $ / 4,00 $ / 50,00 $ / 150,00 $ för lång kontext. OpenAI noterar att snabbläget inte är tillgängligt för GPT-6 Astra med EU-datalagring.

• Datahemvist — slutpunkter som använder den har ett påslag på 10 % för modeller som släpps den 5 mars 2026 eller senare. GPT-6 Astra kvalificerar sig, så en distribution med datahemvist ligger 10 % över alla siffror ovan.

Raden att ta till sig är priset för cachad indata. 1,00 $ mot 10,00 $ är 90 % rabatt på den del av prompten som du skickar igen – och i en agentarbetsbelastning är det nästan hela prompten. Cacheskrivningar debiteras med 12,50 $, eller 1,25 gånger priset för icke-cachad indata, så brytpunkten är enkel: 100 000 tokens som skickas utan cache två gånger kostar 2,00 $, medan det kostar 1,35 $ att skriva det prefixet en gång och läsa tillbaka det en gång. Cachning lönar sig från och med den andra återanvändningen, och en agent som arbetar med samma transkript i hundra turer återanvänder det hundra gånger.

Vilket för oss till den aritmetik som faktiskt avgör om den här modellen är överkomlig, för priset i rubriken är inte siffran som hamnar på fakturan. Här är en modellerad körning – vår egen, byggd på OpenAIs publicerade priser, inte en uppmätt faktura – för den typ av uppgift som modellen säljs för: en autonom kodagent som arbetar med en migrering i reposkala under några timmar, 120 modellanrop, en arbetsutskrift som i genomsnitt ligger på omkring 500 000 indatatoken per anrop i takt med att den byggs upp, 80 % av dessa indata serveras från cache, och 400 000 utdatatoken under hela körningen, inklusive resonemang.

Till Standardpriser för kort kontext:

• Ocachad indata — 12M tokens × 10,00 $ = 120,00 $

• Cachad indata — 48M tokens × $1,00 = $48,00

• Utdata — 0,4 mn tokens × $50,00 = $20,00

• Totalt ≈ $188.00 för körningen

Samma körning i långkontextbandet, vilket är vad en transkription som ligger över 272 000 tokens per anrop faktiskt får:

• Ej cachad indata — 12M tokens × $20,00 = $240,00

• Cachad indata — 48M tokens × $2.00 = $96.00

• Utdata — 0,4M tokens × 75,00 $ = 30,00 $

• Totalt ≈ $366.00 för körningen

Två slutsatser följer av det, och ingen av dem framgår av den angivna taxan. För det första, var din transkription ligger är lika viktigt som vilken modell du väljer — samma uppgift blir ungefär dubbelt så dyr beroende på om den passerar 272K-tröskeln, vilket gör kontextdisciplin (att hämta rätt 100K i stället för att bära med sig 600K) till en teknik för kostnadskontroll för den här modellen, inte bara en prestandaåtgärd. För det andra, cachning är värd mer än vad rabatten antyder: utan några cacheträffar alls bär det första scenariot $600.00 i indata i stället för $168.00, och körningen kostar omkring $620 i stället för $188. Aktivera cachning innan du höjer resonemangsinsatsen.

För baslinjen uppgår samma tokenblandning på GPT-5.6 Sol, enligt de priser som Ope​nAI:s prissida visade den 16 september – 4,00 USD för indata, 0,40 USD för cachad indata, 20,00 USD för utdata vid kort kontext – till ungefär 75,20 USD, och vid Sols långa kontextrad (8,00 / 0,80 / 30,00 USD) ungefär 146,40 USD. Det gör den här körningen cirka 2,5x i båda intervallen. Två förbehåll för den multipeln, eftersom den redan har skapat förvirring på andra håll: Sols siffra är ett kampanjpris – Ope​nAI säger att kampanjen finns tillgänglig åtminstone till och med den 21 november 2026 – medan Astras är listpris, så multipeln mäter dagens två prislistor snarare än ett stabilt faktum om modellerna, och den minskar om kampanjen upphör. Och den äldre "2,5x" som cirkulerar för Astra beräknas ibland mot Sols listpris före kampanjen på 5,00/30,00 USD, vilket ger 2x på indata och ungefär 1,67x på utdata. Ange vilken Sol-taxa du menar, annars är siffran värdelös.

En rad till: Batch-nivån halverar allt detta, vilket gör att den första körningen landar på ungefär $94. Huruvida du kan använda den beror på nästa avsnitt.

Zero Data Retention, och rabatten som diskvalificerar sig själv

OpenAI uppger att Zero Data Retention är tillgängligt för berättigade API-kunder på API-slutpunkter som stöds, med förbehåll för godkännande – och båda halvorna av den meningen gör verklig skillnad. Det är inte en självbetjäningsväxel: behörighet förutsätter förhandsgodkännande från OpenAI och att ytterligare krav accepteras, och du startar det genom att prata med säljavdelningen. När det har godkänts konfigureras det på organisations- eller projektnivå under Inställningar → Organisation → Datakontroller, på fliken Datalagring, där ett projekt kan ärva organisationens standard, ställa in ZDR uttryckligen, välja Modified Abuse Monitoring eller inaktivera båda.

Vad det förändrar i praktiken: ZDR utesluter kundinnehåll från loggar för missbruksövervakning, vilket ersätter standardlagringen på upp till 30 dagar, och store-parametern på /v1/responses och /v1/chat/completions behandlas som false även om en begäran försöker sätta den till true.

Detaljen som spelar störst roll på en sida om kostnad: /v1/batches finns inte med på listan över ZDR-berättigade slutpunkter. OpenAIs sida för datakontroller listar den som inte berättigad, med applikationstillstånd som bevaras tills det raderas. Så på GPT-6 Astra är Batch-nivåns 50 % rabatt och Zero Data Retention ömsesidigt uteslutande — en compliance-bunden arbetsbelastning som behöver ZDR bör budgetera för Standard-priset, inte batch-priset, och siffran $94 ovan är inte tillgänglig för den.

Tre ytterligare förbehåll, uttalade rakt ut eftersom en sida som överdriver ZDR är sämre än en som utelämnar det. ZDR är inte absolut: under "Eyes Off" förbehåller sig Ope​nAI rätten att göra modeller icke kvalificerade för ZDR för specifika kunder, med skriftlig förvarning, och under "Safety Retention" kan innehåll bevaras och granskas av människor där klassificerare flaggar för allvarlig risk. Bild- och filinmatningar som flaggas för potentiell CSAM bevaras för manuell granskning även under ZDR. Och ZDR stannar vid Ope​nAIs gräns — om din agent anropar en fjärransluten MCP-server eller en annan leverantörs API, styrs den trafiken av den partens bevarandepolicy, inte denna. Separat: data residency är en annan kontroll än ZDR, kräver sitt eget godkännande och ett Modified Retention-tillägg utanför USA, och medför den 10-procentiga höjning som nämnts ovan. Om du förlitar dig på cachelagring under ZDR, läs Ope​nAIs data-controls-sida för vad cachelagring bevarar; vi kommer inte att trycka en bevarandesiffra för det som vi inte själva kunde läsa där.

Hastighetsbegränsningar enligt dokumentationen, och den som biter först

OpenAI:s modellsida publicerar dessa gränser per nivå för GPT-6 Astra — förfrågningar och tokens per minut, därefter batchkögränsen:

• Tier 1 — 500 RPM, 500 000 TPM, batchkö 1 500 000

• Nivå 2 — 5 000 RPM, 1 000 000 TPM, batchkö 3 000 000

• Nivå 3 — 5 000 RPM, 2 000 000 TPM, batchkö 100 000 000

• Nivå 4 — 10 000 RPM, 4 000 000 TPM, batchkö 200 000 000

• Nivå 5 — 15 000 RPM, 40 000 000 TPM, batchkö 15 000 000 000

Två gränser som vi kommer att kalla för inte dokumenterade snarare än att fylla i: det finns ingen publicerad gräns för gratisnivån, eftersom GPT-6 Astra inte finns på gratisnivån alls; och vi hittade inget publicerat tak över nivå 5 och ingen separat gränstabell för Fast-läget. Om en leverantör inte har publicerat en gräns, behandla frånvaron som olöst — anta inte att den är obegränsad.

Siffran som först biter på en agent-arbetsbelastning är Tier 1:s 500 000 TPM. Ett enda anrop till den här modellen kan bära en transkription på 500 000 token, vilket innebär att en enda förfrågan kan förbruka en hel minuts tokenbudget på instegsnivån. Ett kontextfönster på en miljon token är inte till mycket nytta för en agent som ockuperar samma transkription i 120 turer om nivån inte kan trycka igenom tokens. Dimensionera nivån efter tokenvolymen från exemplet ovan, inte efter antalet förfrågningar – och notera att avancemang mellan nivåer beror på utgifter och kontohistorik, så det är värt att etablera före en deadline snarare än under en.

Azure och AWS Bedrock, en rad vardera

• Microsoft Azure — GPT-6 Astra går att driftsätta i Microsoft Foundry under samma id, gpt-6-astra, med Foundry-täckning som daterar den allmänna tillgängligheten till början av september 2026 och rapporterar driftsättningar i Global Standard och US Data Zone, ingen EU Data Zone vid lanseringen, och priser i nivå med eller nära Ope​nAI:s listpriser med en rad för lång kontext. Det läser vi ur Foundry-täckningen snarare än Microsofts egen katalogsida, som vi inte kunde nå i dag — verifiera den aktuella driftsättningslistan, regionuppsättningen och priset i Microsofts egen dokumentation innan du planerar en driftsättning på den.

• AWS Bedrock — listad som openai.gpt-6-astra, tillgänglig via Bedrock-API:er som stöds och bekräftad i AWS:s veckosammanfattning daterad 15 september 2026, med Bedrocks egen styrningsperimeter (VPC-slutpunktsisolering, KMS-kryptering, Guardrails) och AWS:s uttalande att inferensdata inte används för modellträning. Rapporterad inferens inom region och geografisk cross-region-inferens på Bedrock debiteras 10 % över baspriserna; den siffran är en andrahandsuppgift enligt vår tolkning, så kontrollera AWS:s egen prissättningssida.

Ingen av vägarna ändrar modellen. Båda ändrar upphandlingen, vilket för en företagsläsare är hela poängen: en Foundry- eller Bedrock-driftsättning kan rymmas inom ett befintligt molnåtagande, ärva dess IAM, loggning och nätverksgräns och hamna på en faktura som finansavdelningen redan har godkänt – ofta skillnaden mellan en pilot och något som faktiskt levereras. Avvägningen är att du tar molnets modelllivscykel och molnets pris, och båda molnen rapporteras ligga på eller över OpenAI:s prislista snarare än under den.

Var en router passar in, inklusive de delar som talar emot den

GPT-6 Astra finns i OrcaRouter-katalogen som openai/gpt-6-astra, och OrcaRouter för vidare leverantörens listpris med 0 % påslag — leverantörens pris är vårt pris, och en prisförändring från leverantören slår igenom på din faktura samma dag i stället för vid förnyelsen. För en modell till detta pris är det inte ett påstående om avrundningsfel: beräkningen ovan är samma beräkning som du skulle betala direkt.

Det ärliga argumentet för routing här är inte priset, det är reversibiliteten. Astra är ungefär 2,5 gånger så dyrt som modellen under det, och dess kostnad hänger på en tröskel som din arkitektur styr, så de flesta team vill prova det på en del av den verkliga trafiken innan de satsar på en produktionsväg. Med en enda nyckel kan du placera det bakom samma endpoint som modellerna du redan kör, skicka en del av trafiken till det och automatiskt växla över till något billigare när det inte tjänar in mellanskillnaden – en konfigurationsändring snarare än en migrering, med ett enda API som täcker över 200 modeller, ett routing-DSL som komponerar flera modeller till ett enda anrop och modellfusion när du vill att en panel ska svara tillsammans.

De delar som talar emot det, sagt rakt på sak. En router är ytterligare ett hopp i begärandevägen och ytterligare en part i dataflödet – och i den här modellen är det inte hypotetiskt, eftersom ZDR godkänns per organisation hos OpenAI och en routad begäran inte automatiskt omfattas av ditt ZDR-godkännande. Om du skickar reglerade data, bekräfta rutens datavillkor innan du skickar dem, och var beredd att ringa leverantören direkt för den arbetsbelastningen. Routning lägger också till en komponent som kan fallera eller öka latensen, och det gör det så enkelt att byta modeller att det är möjligt att ändra vad som svarar dina användare utan att granska det. Inget av det uppväger test- och återställbarhetsargumentet för de flesta team; allt är värt att känna till innan du bestämmer att routern är gratis. Vi ställer routningsplattformarna mot varandra i en separat artikel i stället för att upprepa jämförelsen här.

Tre frågor som inte är svar i en enda sats

Kan jag finjustera GPT-6 Astra, eller använda det med Assistants API? Nej, inte i något av fallen, och detta är en designgräns snarare än en konfiguration som du har missat. Ope​nAIs modellsida listar Chat Completions, Responses och Batch som de slutpunkter som stöds och listar uttryckligen Fine-tuning och Assistants som icke stödda, och det finns ingen rad för GPT-6 Astra i Ope​nAIs pristabell för finjustering. Om din arkitektur är beroende av en finjusterad flaggskeppsmodell måste Astra i stället styras via promptar, vilket flyttar kostnaden från träning till indatatokens – och med $10,00 per miljon för en stor systemprompt är det en verklig budgetpost snarare än en fotnot.

Kommer modellen att vägra säkerhetsarbete som jag är auktoriserad att utföra? Ibland, ja, och det är värt att veta innan du bygger. GPT-6 Astra är den första Ope​nAI-modellen som når tröskeln för kritisk cybersäkerhetskapacitet enligt företagets Preparedness Framework, och i sitt levererade skick vägrar den avancerade cyberuppgifter som att skriva proof-of-concept-exploater. Ope​nAI säger att man planerar att bredda åtkomsten med mindre restriktiva skyddsåtgärder genom sitt Daybreak-program. För en försvarare visar detta sig som en vägran som inte är en hastighetsbegränsning och inte en bugg — budgetera för den i din felhantering i stället för att göra återförsök mot den.

Behöver jag ett särskilt godkännande för att anropa den här modellen? Inte för standardändpunkten – det finns ingen väntelista och inget godkännandesteg för att anropa gpt-6-astra, bara ett konto med fakturering. Det du däremot kan behöva godkännande för är allt runtomkring: Zero Data Retention, som är ansökningsstyrt; datahemvist utanför USA, vilket kräver ett eget tilläggsavtal; och en nivåhöjning, om du tänker skicka tokenvolymer i agent-skala genom ett Tier 1-konto. Modellen är den enkla delen av anskaffningen.

Vad man bör hålla koll på – och vem som bör agera nu

Om du bygger på den här modellen finns det fyra saker värda att bevaka, och alla ligger på leverantörssidan och är tidsatta. Om OpenAI publicerar en daterad snapshot för gpt-6-astra – vilket skulle göra det nakna id:t till ett rörligt mål och göra pinning meningsfullt. Om tröskeln på 272 000 tokens flyttas, eftersom den där enda raden är värd mer för din faktura än något benchmark på sidan. Om priserna för Bedrock och Foundry närmar sig OpenAIs lista eller ligger kvar över den, eftersom det avgör inköpsvägen lika mycket som modellen gör. Och om Daybreak-programmet ändrar vad slutpunkten kommer att vägra, vilket för säkerhetsteam är skillnaden mellan ett användbart verktyg och en demo.

När det gäller vem som bör agera är uppdelningen tydlig. Om du redan betalar för GPT-5.6 Sol till kampanjpriser för långsiktigt agentarbete är 2,5x verkligt och frågan är snäv: överträffar andelen slutförda uppgifter i din egen arbetsbelastning prisskillnaden? Kör den på en del av verklig trafik och ta reda på det – det genomräknade exemplet ovan visar vad delen kostar innan du börjar. Om ditt arbete är kortkontextchatt eller klassificering i hög volym är detta inte din modell; omprissättningen för lång kontext och utpriset på 50,00 USD gör det till ett dyrt sätt att göra något som GPT-5.6 Luna gör för en bråkdel av priset. Och om du är ett storföretag med ett regelefterlevnadskrav bör du inleda ZDR-diskussionen först, eftersom den styr Batch-rabatten, residency-tillägget och ditt val av väg – och inget av det är ett beslut du kan fatta den dag du behöver det.