OpenAI Responses API og fristen for at migrere ældre assistants

Hvorfor det her blev en reel arbejdsopgave

Mange interne AI-værktøjer begyndte i det små. Nogen havde brug for hurtigere svar på spørgsmål om retningslinjer, opsummeringer af tickets, dokumentsøgning eller rutinemæssige udkast, og der blev bygget en assistant med udgangspunkt i OpenAI's ældre mønstre. Det var fornuftigt på det tidspunkt. Nu ser situationen anderledes ud. OpenAI's FAQ om Assistants henviser nu først udviklere til Responses API, værktøjer hostet af OpenAI, Agents SDK og tracing og oplyser, at forbedringerne fra Assistants-betaen er videreført i Responses. Migreringsvejledningen er mere direkte: Responses er den fremtidige retning for udvikling af agents på OpenAI. For en virksomhed ændrer det perspektivet. Det, der tidligere kunne betragtes som en afgrænset funktion, er nu en legacy-integration med en planlagt udfasning, som der skal tages højde for.

Datoerne gør det tydeligere. Ifølge FAQ'en lancerede OpenAI byggeklodserne til sin Agents-platform den 11. marts 2025 og beskrev en planlagt udfasning af Assistants i første halvår af 2026, når der var opnået feature parity. Den aktuelle migreringsvejledning oplyser, at Assistants API pr. 26. august 2025 er deprecated med udfasningsdato den 26. august 2026. Den præcise deadline er vigtig, men retningen er det større spørgsmål. Nye funktioner, den aktuelle vejledning og priserne er alle centreret omkring Responses. Når platformen bevæger sig så entydigt, er det ikke længere et neutralt vedligeholdelsesvalg at blive på det gamle mønster.

Hvorfor det er mere end at omdøbe et endpoint

Det handler ikke blot om at skifte fra ét endpoint til et andet. OpenAI præsenterer Responses som en samlet grænseflade til agentbaserede applikationer med indbyggede værktøjer som web search, file search, computer use, code interpreter og remote MCP servers. Den er udviklet til multi-turn-interaktioner, hvor teams kan sende tidligere responses videre, bevare state med store: true eller genbruge krypterede reasoning items i stateless workflows. Migreringsvejledningen ændrer også datamodellen. Responses bruger Items i stedet for den ældre, beskedcentrerede struktur, og tool calls og tool outputs bliver separate enheder, der forbindes via call_id. Multi-turn-kæder kan videreføres med previous_response_id.

OpenAI bemærker, at der nu findes Assistant-lignende og Thread-lignende objekter i Responses. Det gør overgangen lettere, men fjerner ikke migreringsarbejdet. Teams skal stadig mappe assistants, threads, runs, prompts, tool wrappers og retry-logik til response- og item-modellen. De fleste interne hjælpere ophober også en række uudtalte antagelser med tiden: hvor samtalens state befinder sig, hvor længe jobs må køre, hvordan retrieval tilknyttes, og hvad systemet skal gøre, når et tool call mislykkes. Det er som regel disse antagelser, der gør, at en »simpel migrering« ikke længere er simpel.

Hvor ældre interne assistants typisk bryder sammen

State og jobhåndtering er som regel det første brudpunkt. Ældre assistant-løsninger var ofte stærkt afhængige af persistente threads og runs, så applikationskoden kunne holdes enkel. Responses gør dette valg eksplicit. Du kan gemme state på tværs af interaktioner, deaktivere lagring med store: false eller understøtte workflows i stil med Zero Data Retention ved hjælp af krypterede reasoning items, som dekrypteres i hukommelsen og derefter slettes. OpenAI har også tilføjet background mode. I funktionsopdateringen til Responses oplyser OpenAI, at reasoning models kan bruge flere minutter på komplekse problemer, og at background mode er udviklet til at håndtere disse opgaver asynkront og mere pålideligt. Hvis en intern assistant udfører research, analyse eller flertrinsoperationer, er migreringen det tidspunkt, hvor teamet skal beslutte, hvad der fortsat hører hjemme i en synkron request, og hvad der skal behandles som et administreret baggrundsjob.

Retrieval er det næste prespunkt. FAQ'en om Assistants beskriver faste standardindstillinger for file search: chunks på 800 tokens, et overlap på 400 tokens, text-embedding-3-large med 256 dimensioner og op til 20 chunks tilføjet til context. Den angiver også faste begrænsninger: ét vector store pr. assistant, ét vector store pr. thread, ingen kontrol over indstillingerne for chunking eller embedding, ingen billedfortolkning i dokumenter og ingen struktureret retrieval i CSV eller JSONL. Den nyere annoncering af Responses tilføjer opdateringer til file search, som understøtter søgning på tværs af flere vector stores og attributfiltrering med arrays. Det er en reel driftsmæssig forskel. Den påvirker, hvordan en virksomhed opdeler sin viden, anvender tilladelser og kontrollerer, at assistenten fortsat finder den rigtige dokumentation, når løsningen får produktionstrafik og faktiske brugere.

Tooling er det tredje område, hvor ældre implementeringer ofte bliver sårbare. Opdateringen til Responses tilføjer understøttelse af remote MCP servers, som OpenAI beskriver som en måde at forbinde modeller med værktøjer hostet på en hvilken som helst MCP server med blot nogle få linjer kode. Det udvider mulighederne for en intern assistant, men ændrer også samtalen om governance. Når platformen tilskynder til bredere orkestrering af værktøjer i en enkelt request, bliver det sværere at forsvare løse kontroller med, hvilke værktøjer der er tilgængelige, hvordan de godkendes, og hvordan brugen af dem overvåges.

Hvorfor det også er et budget- og governanceprojekt

Prismodellen gør det klart, at det ikke kun er en udvikleropgave. OpenAI's prisside angiver web search til $10 pr. 1.000 calls og oplyser, at tokens fra søgeindhold er gratis. Samme side udspecificerer også priser for containere og omtaler en ændring den 31. marts 2026 til prissætning pr. session på 20 minutter. FAQ'en om Assistants angiver Code Interpreter til $0.03 pr. session og lagring til file search til $0.10 pr. GB pr. dag. Den nyere funktionsopdatering til Responses angiver Code Interpreter til $0.03 pr. container, file search til $0.10 pr. GB vector storage pr. dag plus $2.50 pr. 1.000 tool calls samt ingen yderligere omkostninger til remote MCP-værktøjet ud over output tokens fra API'et. Intet af dette er uoverskueligt, men det betyder, at migreringen skal behandles som en opgave inden for LLM-drift og budgettering – ikke blot som en omskrivning af kode.

Det praktiske budgetspørgsmål er ligetil: Hvilke workflows må kalde betalingsværktøjer, hvor ofte, med hvilke lofter, og hvor er forbruget synligt? OpenAI's prisside henviser også til månedsbudgetter, tærskler for e-mailnotifikationer, registrering af forbrug og faktureringsbegrænsninger på projektniveau. Disse kontroller skal med i projektets scope. En hjælper, der ser billig ud under udviklingen, kan blive svær at redegøre for i produktion, når model-tokens, retrieval storage, fakturering af tool calls og langvarig eksekvering blandes sammen uden et tydeligt ejerskab.

Governance kræver samme disciplin. FAQ'en om Assistants oplyser, at data og filer, som sendes til API'et, ikke bruges til at træne OpenAI's modeller, men også at data uploadet til Assistants API gemmes på ubestemt tid, indtil de slettes manuelt. Responses introducerer mere eksplicitte valg om state og tilføjer reasoning summaries uden ekstra omkostninger, som OpenAI fremhæver som nyttige til debugging og audit. Det har betydning for et forretningssystem. Hvis assistenten behandler retningslinjer, kontrakter, kundeoplysninger eller driftsdokumenter, bør migreringen omfatte regler for opbevaring, procedurer for sletning og design af observability sideløbende med test af feature parity.

Hvad et godt migreringsprojekt faktisk omfatter

En fornuftig migrering til Responses omfatter typisk fem arbejdsspor:

Gennemgå den nuværende assistant-opsætning, herunder assistants, threads, filer, prompts, tool definitions, langvarige jobs og kendte fejlscenarier.
Map legacy-begreber til Responses, især gemt state, Items, tool calls, retrieval flows og eventuel brug af previous_response_id eller background execution.
Refaktorér driftskontrollerne: logging, omkostningslofter, overvågning af forbrug, regler for opbevaring og workflows til sletning.
Test retrieval og værktøjernes adfærd igen, især hvor dokumenttilladelser, kvaliteten af file search eller langvarige analyser påvirker brugernes tillid.
Gennemfør overgangen kontrolleret ved at sammenligne outputs, validere omkostninger og først fjerne skrøbelige antagelser, når den nye løsning har vist sig stabil.

Det er her, Gregs service er relevant. Han kan gennemgå en eksisterende assistant, mappe threads, filer og værktøjer til Responses, refaktorere jobhåndtering og retrieval, tilføje kontroller for omkostninger og logging samt teste overgangen, så funktionen også holder efter prototypestadiet. Værdien er ikke »prompt-magi«. Den ligger i disciplineret migreringsarbejde, mere gennemskuelig drift og færre dyre overraskelser efter lanceringen.

Den strategiske pointe er enkel. OpenAI's FAQ, migreringsvejledning, udrulning af funktioner og priser peger alle i samme retning: Det er i Responses, de nye agentfunktioner lander. Hvis en virksomhed stadig er afhængig af et ældre mønster for interne assistants, bevarer den ikke stabiliteten ved at gøre ingenting. Det øger risikoen for, at workflows, omkostninger og governance ikke længere følger platformens udvikling. Derfor gør dette skifte ældre interne assistants til et betalt migreringsprojekt.

Har du brug for hjælp til denne type opgave?

Planlæg din Responses-migrering – kontakt Greg.

Kilder

Sidst ændret

2026-08-27