OpenAI Agents API flytter Codex-harnessen bak ett API-kall

OpenAI Agents API gir deg infrastrukturen bak Codex gjennom ett API-kall, uten at du må bygge og vedlikeholde hele agentløkken selv. Du velger modell, verktøy og arbeidsmiljø. OpenAI tar seg av sesjoner, kontekst, koordinering og gjenoppretting når en jobb varer lenge.

Det er en ganske stor sak hvis du bygger AI-agenter for egne prosjekter eller en liten bedrift. Forskjellen mellom en chatbot som svarer én gang og en agent som faktisk arbeider i flere timer, ligger sjelden bare i modellen. Noen må holde orden på filer, verktøy, kontekst, feil, deloppgaver og fortsettelsen etter at noe stopper.

OpenAI gjorde dette laget til et produkt i går. Agents API ble lansert i public beta 10. september 2026 og er tilgjengelig for alle utviklere. Min dom er nøkternt positiv: Dette kan fjerne mye kjedelig infrastrukturarbeid. Men et godt harness er ikke tryllestøv, og det gjør ikke modellen mer pålitelig enn den faktisk er.

Hva er OpenAI Agents API?

OpenAI Agents API er en driftet tjeneste for langvarige AI-agenter. Den bruker samme åpne harness som ligger bak Codex, mens OpenAI driver selve agentløkken. I den offisielle dokumentasjonen er tjenesten delt i fire hovedbegreper: agent, environment, session samt events og items.

Agenten er oppskriften: modell, instruksjoner, verktøy og eventuelle MCP-servere. Environment er stedet der arbeidet skjer, for eksempel en sandkasse med filer og kommandolinje. Session er den varige agentinstansen, mens events og items beskriver det du sender inn og det agenten produserer underveis.

En vanlig sesjon har fire trinn. Du oppretter sesjonen, gir agenten en oppgave, følger arbeidet gjennom streaming eller webhooks og fortsetter eller styrer den ved behov. Det høres enkelt ut fordi mye av kompleksiteten er flyttet bak API-et. Det er nettopp poenget.

OpenAI hadde allerede Responses API for modellkall med verktøy og Agents SDK for agentlogikk i egen applikasjon. Agents API går et hakk lenger: OpenAI kjører og vedlikeholder harnessen som styrer arbeidet. Du kjøper ikke bare tilgang til en modell. Du får et driftslag rundt modellen.

Hva tar OpenAI over for utvikleren?

OpenAI tar over fem tunge oppgaver i agentdriften: varige sesjoner, kontekstkomprimering, gjenoppretting, effektiv verktøylasting og koordinering av subagenter. Agenten kan dermed fortsette på tvers av flere kontekstvinduer uten at du må skrive din egen logikk for å oppsummere hele historikken hver gang grensen nærmer seg.

Tool search laster inn relevante verktøydefinisjoner først når agenten trenger dem. Det kan redusere tokenbruk og bevare modellens cache, særlig når en agent har tilgang til mange funksjoner eller MCP-servere. Programmatic tool calling lar agenten kjøre verktøy parallelt, kjede operasjoner og filtrere resultatene i kode før det viktigste sendes tilbake til modellkonteksten.

Subagenter er også bygget inn. OpenAIs lanseringseksempel setter grensen til tre samtidige subagenter for å undersøke deployment, feil og avhengigheter hver for seg. Hver subagent beholder sin egen kontekst, mens hovedagenten fordeler oppgaver og samler resultatene. Det sparer deg for å bygge kø, tilstand og sammenslåing fra bunnen av.

Dette er arbeidet som ofte blir usynlig i en demo. Et enkelt modellkall kan se imponerende ut, men produksjon krever at agenten tåler en lang oppgave, et midlertidig avbrudd og et verktøy som svarer med altfor mye data. OpenAI har pakket erfaringene fra Codex og ChatGPT for Work inn i én tjeneste. For et lite utviklerteam kan det være langt mer verdifullt enn enda en modell med et glanset resultatdiagram.

Hvor kjører agenten og filene dine?

Du kan velge mellom tre hovedtyper arbeidsmiljø: OpenAI-hostet sandkasse, egen infrastruktur eller en integrert sandkassepartner. Agenten kan også kjøre uten sandkasse når oppgaven ikke krever filer eller kodekjøring. Valget avgjør hvor data, hemmeligheter, pakker og faktisk datakraft befinner seg.

Den enkleste veien er OpenAIs egen sandkasse. Den bruker infrastrukturen bak Codex og ChatGPT, og kan settes opp med filer, pakker, skills og plugins. OpenAI oppretter miljøet, lar agenten kjøre kommandoer og lagre artefakter, og rydder opp etter livssyklusen du har valgt.

Vil du beholde arbeidsmiljøet selv, kan du kjøre codex exec-server i egen infrastruktur. Den registreres med en begrenset nøkkel og kobler seg utgående til tjenesten over WebSocket. Det er et viktig skille: OpenAI driver fremdeles harnessen og sesjonen, mens kommandoene og filarbeidet kan foregå hos deg.

Lanseringen har dessuten førstegangsintegrasjoner med ni partnere: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop og Vercel. De tilbyr ulike kombinasjoner av VPC-oppsett, lagring, CPU, GPU, minne, oppstartstid og pris. Fleksibiliteten er bra, men den betyr også at du må vite hva oppgaven trenger. «Sandbox» er ikke en universell innstilling som automatisk løser sikkerhet, kostnad og personvern.

Hva koster OpenAI Agents API?

Det finnes ingen egen avgift for Agents API i public beta. OpenAI oppgir at du betaler ordinære API-priser for modellen, verktøyene agenten bruker og eventuell containertid i en OpenAI-hostet sandkasse. Den endelige kostnaden styres derfor av modellvalg, oppgavens lengde og hvor mye kode, søk og parallelt arbeid agenten utfører.

Det er bedre enn en ny fast plattformavgift, men ikke det samme som gratis. En agent som arbeider i flere timer, bruker flere subagenter og stadig fyller konteksten på nytt, kan bli dyr selv om inngangsbilletten er null. Tool search, programmatisk filtrering og automatisk komprimering er derfor kostnadsfunksjoner, ikke bare tekniske pyntelister.

OpenAI viser til tidlige kundetall, men de bør leses som leverandørens egne kundehistorier. Ciridae oppgir at en evalueringsscore gikk fra 0,71 til 0,85 og at subagentflyter fikk fire ganger lavere forsinkelse. SafetyKit oppgir 60 prosent lavere kostnad per sak, mens Hypha sier antallet mislykkede agentsvar falt med 86 prosent etter at harness og sandkasse ble skilt. Lovende? Absolutt. Uavhengig dokumentasjon? Nei.

Hvordan skiller API-et seg fra Agents SDK og Responses API?

Agents API passer når du vil at OpenAI skal drive en varig Codex-lignende agent for deg. Agents SDK passer når agentløkken skal kjøre inne i din egen applikasjon. Responses API gir mest direkte kontroll, men lar deg også håndtere mer av historikken, orkestreringen og arbeidsflyten selv.

Med Agents SDK eier du runtime, deployment og vanligvis større deler av tilstanden. Det krever mer arbeid, men gir også mer kontroll. OpenAI utvidet SDK-et i april 2026 med et modelltilpasset harness, sandkassestøtte og en portabel Manifest-abstraksjon. SDK-et støtter både egne sandkasser og flere eksterne leverandører, men agenten kjører fremdeles som en del av løsningen din.

Responses API er den lavere byggeklossen for modellresponser og verktøykall. Den er riktig når du trenger et bestemt, kontrollert steg eller allerede har infrastrukturen for tilstand, køer og feilhåndtering. Agents API er et høyere abstraksjonsnivå for oppgaver som varer over tid og kan kreve nye runder, styring og recovery.

Det finnes ingen vinner for alle prosjekter. Et avgrenset kundesøk kan være et Responses-kall. En agent som jobber inne i en eksisterende backend kan passe bedre i SDK-et. En agent som skal undersøke en hendelse i to timer, delegere tre spor og levere filer til slutt, er nettopp jobben Agents API er laget for.

Hva er begrensningene i public beta?

Den viktigste begrensningen er datahåndtering. Agents API støtter foreløpig bare datalagring i USA og støtter ikke Zero Data Retention. OpenAI presiserer at selv en selvhostet sandkasse ikke gjør tjenesten ZDR-kompatibel, fordi sesjonstilstanden fremdeles ligger i Agents API.

Det gjør tjenesten uaktuell for enkelte regulerte eller særlig følsomme arbeidsløp fra dag én. Ikke la deg lure av at kommandoene kjører i ditt eget miljø. Kontroll over sandkassen og kontroll over all agentdata er to forskjellige ting. Sjekk hvilke instrukser, hendelser, verktøyresultater og artefakter som faktisk går gjennom tjenesten før du kobler den til produksjonsdata.

Den andre begrensningen er selve beta-stempelet. OpenAI sier at tjenesten skal endres raskt frem mot generell tilgjengelighet. API-kontrakter, støttede funksjoner og driftsmønstre kan dermed flytte på seg. Bygg en tynn integrasjon rundt tjenesten, logg egne resultater og unngå å gjøre hele produktet avhengig av en detalj som bare finnes i beta.

Og så er det elefanten i serverrommet: Harnessen kan håndtere kontekst, verktøy og gjenoppretting, men modellen må fremdeles ta gode beslutninger. Jeg har tidligere vært tydelig på at Codex må vurderes ut fra faktisk agentarbeid, ikke navnet på leverandøren. Et API kan redusere driftsfeil. Det kan ikke garantere at agenten forstår oppgaven eller lar være å gjøre noe dumt.

Hvem bør teste Agents API nå?

Utviklere og små team med en avgrenset, etterprøvbar arbeidsflyt bør teste Agents API nå. Gode kandidater er feilanalyse, dokumentgjennomgang, research, kodearbeid og interne oppgaver der resultatet kan kontrolleres før noen handler på det. Start med arbeid som tåler at agenten tar feil.

Velg én konkret jobb, lag et lite evalueringssett og mål tre ting: kvalitet, feilrate og total kostnad. Kjør samme oppgave flere ganger. Se hva som skjer når et verktøy feiler, når konteksten blir lang og når agenten må fortsette etter et avbrudd. Det er der forskjellen mellom en demo og et arbeidsverktøy viser seg.

Gi agenten minst mulig tilgang. Legg skriveoperasjoner bak godkjenning, bruk egne nøkler med begrensede rettigheter og hold produksjonssystemer utenfor den første testen. Dersom du trenger europeisk datalagring eller ZDR, er svaret foreløpig enkelt: Vent eller velg en annen arkitektur.

Jeg liker retningen. OpenAI selger nå noe utviklere faktisk trenger: ikke bare en modell, men den seige infrastrukturen som holder en agent i arbeid. Test den gjerne. Bare ikke forveksle «produksjonsklar infrastruktur» med «en agent jeg kan stole blindt på». Det skillet kan spare deg for både penger og en ganske lang natt.

Ofte stilte spørsmål