Innhold Vis
Codex kvalitetsfall er ikke bare følelsen av at en AI-agent ga meg et dårlig svar. I mine lokale logger ser jeg et gjentakende mønster: ferske økter bryter enkle kontrakter, rettelser svinger til motsatt ytterpunkt, og reparasjonen blir starten på neste feil.
Jeg har begynt å kalle denne oppførselen «narkoman». Det er min metafor for en agent som virker desorientert og inkonsekvent – ikke en medisinsk eller teknisk diagnose. Den kan være glimrende i ett øyeblikk, og i det neste gjøre det motsatte av en beskjed den nettopp har gjengitt helt korrekt.
Fra 4. til 17. juli 2026 registrerte 41 lokale sesjonsfiler omtrent 1,152 milliarder behandlede konteksttokens, 10 288 verktøykall, 43 automatiske komprimeringer og 26 avbrudd. Det store tallet trenger en viktig presisering: Rundt 1,102 milliarder var mellomlagret input (cached input). Dette er ikke 1,152 milliarder nye tokens, og det er heller ikke en faktura. Det er et mål på hvor mye kontekst som gikk gjennom agentarbeidet mens jeg forsøkte å få faktiske leveranser i mål.
Codex kvalitetsfall: Hva viser loggene?
Det dokumenterte funnet er ustabilitet i den samlede agenttjenesten, ikke en bevist nedgradering av én grunnmodell. Alle de ti aktive produksjonsdagene som ble kontrollert, hadde minst ett konkret avvik, et nytt forsøk, en uteblitt sluttstatus eller en feil kvalitetsport. Enkelte leveranser kom ut etter automatisk retry eller manuell redning, men ingen av dagene var en ren ende-til-ende-kjøring.
Det er et viktig skille. En artikkel som til slutt blir levert etter timer med diagnose, kodeendringer og ny kjøring, er ikke bevis på en fungerende autopilot. Poenget med en agent er jo nettopp at jeg ikke skal sitte som manuell driftsvakt og oppdage hver eneste feil selv.
Enkelte dager har jeg brukt opptil omtrent ti timer på diagnose, kontroll og reparasjon; rundt 100 dollar er et grovt anslag for hele Codex-perioden, ikke en revidert faktura for én video.
Feilene lå heller ikke i ett enkelt ledd. De dukket opp i scoring, argumenttransport, metadata, lenkekontroll, planlegging, kjøremiljø og varige kodeendringer. På én dag stoppet en stor forespørsel med Argument list too long, før kjeden presenterte den tekniske feilen som om ingen saker hadde høy nok score. En annen dag ble en gyldig artikkel holdt igjen av et feil krav om flere interne lenker. Dagen etter krasjet batchen etter at et WordPress-utkast allerede var opprettet, fordi en tidsvariabel ikke var ført gjennom funksjonskontrakten.
Hvorfor kan ikke context rot forklare alt?
OpenAI beskriver selv context pollution og context rot i Codex-manualen: Nyttig informasjon kan drukne i logger, mellomresultater og andre detaljer etter hvert som en hovedtråd vokser. Det er en reell risiko, og den forklarer sannsynligvis noen feil sent i lange sessioner. Men den forklarer ikke feil som kommer før økten har rukket å bli lang.
Jeg fant fire ferske økter fra 14. til 17. juli som kjørte den samme etablerte medieflyten med samme synlige modellfamilie og innsatsnivå. I alle fire kom den første alvorlige innsigelsen blant de tre første brukerhandlingene og før automatisk komprimering. Resultatet drev mellom manglende detaljer, feil innramming, unaturlig bevegelse og til slutt en figur som sluttet å snakke og gjorde noe helt annet.
Her må jeg samtidig være ryddig: Bilde- og videogeneratorer er stokastiske. Ikke hvert dårlig bilde eller videoklipp kan legges på Codex. Men Codex styrte instruksjonene, promptene, filendringene og valget av hva som skulle kjøres. Serien dokumenterer derfor ustabilitet i den samlede agentkjeden, ikke at språkmodellen alene skapte hver visuelle feil.
Det tydeligste øyeblikket kom da en rettelse gikk fra kaotisk bevegelse til helt stillestående kamera, livløs figur og mekaniske kroppsbevegelser. Codex beskrev selv at den hadde overkorrigert fra kaos til livløs mekanikk. I samme svar brøt den en enkel navneinstruks som lå tydelig i den ferske økten. Navnefeilen er målbar, men den er ikke hovedsaken. Det interessante er at agenten kunne forstå den komplekse overkorrigeringen og samtidig miste en enkel, eksplisitt regel.
Når reparasjonen blir neste dags regresjon
Den mest kostbare feilklassen er ikke et dårlig formulert svar. Det er når agenten lagrer en reparasjon i det varige systemet, erklærer jobben ferdig og lar neste ordinære produksjonskjøring bli den egentlige testen. Da flytter feilen seg fra samtalen og inn i arbeidsflyten.
Fra 15. til 17. juli fulgte jeg en slik kjede. Først ble en transportfeil tolket som et gyldig tomt resultat. Reparasjonen endret flere kontrakter. Neste dag avviste en feil kvalitetsport innhold som faktisk var gyldig, samtidig som metadata og lenkesøk krevde nye runder. På den tredje dagen krasjet en tidsendring batchen, og første reparasjon avdekket enda en variabelfeil.
Dette er mer enn vanlig språkvariasjon. Det er Codex-genererte endringer som blir stående og påvirker neste kjøring. Observasjonen er solid: Reparasjonsrunddansen skjedde. Hypotesen om hvorfor agenten ikke oppdaget sideeffektene før den sa seg ferdig, er fortsatt åpen.
Den samme proporsjonsfeilen kan ramme innhold. I en annen test var hovedfunnet en lokal 27B-modell på rundt 7,2 GB som kjørte omtrent 83-85 token i sekundet og fortsatt kunne gjøre praktisk arbeid. En liten installasjonsavstikker fikk likevel kapre artikkelvinkelen, sosiale medier og bildemotivet. Da jeg korrigerte kursen, svingte agenten først til et nytt forenklet ytterpunkt. Den fant den mest dramatiske detaljen, ikke tyngdepunktet i hele researchen.
Når retrieval finner svaret uten å få kontroll
Grok 4.5-caset viser en annen feilklasse. Den autoritative sakspakken 17. juli inneholdt en intern lenke til min publiserte artikkel fra 9. juli, «Grok 4.5 er ute – pris, API og OpenRouter-tilgang». Writermodellen brukte lenken i utkastet, men skrev likevel lanseringssaken på nytt. Retrieval fant altså riktig informasjon, uten at treffet fikk bindende virkning på beslutningen om å stoppe.
Redaktøren stoppet saken før publisering, men først etter full tekst, tre nye bilder og et WordPress-utkast. Det siste sikkerhetsnettet virket, bare altfor sent. Forskjellen er viktig: Et system kan være flinkt til å hente relevant informasjon og fortsatt være dårlig til å la informasjonen styre hva agenten faktisk får lov til å gjøre.
Dette må skilles fra en avgrenset Grok 4.5-erfaring i et annet prosjekt. Der brukte jeg modellen via OpenRouter i ett kall til én del av en medieflyt, og resultatet var dårligere enn GPT-5.6 Terra til akkurat den oppgaven. Det var ikke en bred Grok-test eller en samlet dom over modellen. Her var problemet manglende minnefangst; i lanseringssaken var kunnskapen hentet fram, men uten kontrollvirkning.
Hva forteller 1,152 milliarder tokens egentlig?
De 1,152 milliardene er behandlet modellkontekst i lokale logger, ikke 1,152 milliarder unike eller likt fakturerte tokens. Omtrent 1,149 milliarder var input, og rundt 1,102 milliarder av disse var mellomlagret. Ikke-cached input var omtrent 47,3 millioner, mens output var omtrent 3,08 millioner og registrert reasoning-output rundt 798 000.
Mellomlagret input kan ha en annen pris og kvotevekting enn ny input. Derfor ville det vært misvisende å gjøre totalen om til en dramatisk API-regning. Tallet er likevel relevant fordi cache ikke gjør behandlet kontekst usynlig. Det viser skalaen på agentarbeidet som gikk gjennom systemet.
Det mest interessante er utviklingen mellom periodene. Fra 4. til 10. juli ble omtrent 362,6 millioner tokens behandlet, med fem avbrudd. Fra 11. til 17. juli steg dette til omtrent 789,5 millioner tokens og 21 avbrudd. Avbruddsraten gikk fra omtrent 0,85 til 2,53 per 100 brukermeldinger. Den tyngste observerte dagen, 15. juli, stod for omtrent 219 millioner behandlede tokens.
Dette beviser ikke at høy tokenbruk forårsaket kvalitetsfallet. Årsaksretningen kan også gå motsatt vei: Flere feil gir flere korreksjoner, omstarter, filgjennomganger og nye kjøringer. Høy bruk er både en mulig belastningsfaktor og et resultat av at agenten ikke kommer i mål. Det er nettopp derfor tokens per ferdig leveranse er mer interessant enn totalen alene.
Hvorfor minner dette om Claude?
Det ubehagelige er at mønsteret er kjent. Claude ga meg omtrent ett år med nyttig agentarbeid før jeg begynte å se den samme synlige oppførselen: Instrukser mistet kraft, rettelser holdt ikke, fungerende arbeid ble endret, og agenten svingte mellom ytterpunkter. Jeg har tidligere skrevet om Claude, tokenproblemer og kvalitetsfall hos Anthropic.
Med Codex kom enkelte symptomer første dag, mens den brede kvalitetsveggen ble tydelig etter få dager med intensiv bruk. Det gjør ikke Codex og Claude teknisk like. Lik synlig oppførsel på tvers av to leverandører beviser verken samme backend, samme komprimering eller samme kontohåndtering.
Parallellen er likevel for sterk til å avfeie. En åpen Anthropic-rapport analyserer 6 852 Claude Code-økter, mens en åpen Codex-rapport analyserer 2 702 brukerprompter og 56 717 verktøykall. Begge beskriver økende behov for korreksjon, flere omstarter og tap av autonomi. Dette er brukeranalyser, ikke offisielle årsaksbekreftelser, men de peker mot et større spørsmål: Har dagens agenttjenester en stabilitetsgrense som brukeren ikke får se?
Jeg har også tidligere vurdert hva Codex CLI faktisk tilfører. Denne analysen endrer ikke at Codex kan være svært god. Den endrer hvor mye ansvar jeg mener verktøyet bør få uten kontroll.
Hva kan være den tekniske forklaringen?
Den ærlige konklusjonen er at jeg ikke vet. Backend- eller kjøremiljøvariasjon bak samme synlige modellnavn er den mest interessante hypotesen, fordi to økter kan få ulik oppgaveevne selv med samme synlige innstillinger. Det er en plausibel forklaring, men fortsatt bare en hypotese.
Runtime-variasjon er faktisk dokumentert lokalt. To nesten samtidige, skrivebeskyttede tester brukte samme prosjekt, modell, innsatsnivå og nesten identisk prompt. Den første ble blokkert av en sandbox-/nettverksfeil og kunne ikke lese filene. Den andre fikk tilgang og leverte korrekt. Den første modellen gjorde det riktige ved å ikke dikte, men fra brukerens side så øktene dramatisk forskjellige ut.
Kontekstforurensning og automatisk komprimering er også reelle mekanismer, særlig i lange tråder. Selvforsterkende instruksjonsforurensning er en annen plausibel forsterker: Hvis agenten først bryter en regel og deretter skriver feilformen inn i en varig prosjektfil, kan neste session arve en konflikt agenten selv har skapt.
En kontoavhengig begrensning er teknisk mulig, men det lokale belegget er svakt. Den synlige ukeskvoten var 29 prosent brukt, ingen rate limit var logget, og øktene viste fortsatt valgt modell. OpenAI har riktignok bekreftet at enkelte kontoer feilaktig ble ratebegrenset av systemene for misbruks- og svindelforebygging i juni. Selskapet skrev samtidig at det ikke hadde observert en bredere kvalitetsforverring i Codex.
Jeg kan altså ikke hevde at OpenAI straffer storbrukere, ruter meg til en skjult minimodell eller senker kvaliteten når kvoten brukes. Oppgaveblanding, vanskelige mediemodeller og min egen frustrasjon er også feilkilder. De må tas på alvor. Men de forklarer ikke bort det samlede mønsteret i ferske økter, produksjonslogger og varige regresjoner.
Hva trenger en pålitelig AI-agent?
Codex kan levere svært godt i en styrt økt. I gode økter følger den instrukser, graderer påstander og holder fast i hovedfunnet i stedet for å jage den mest dramatiske avstikkeren. Problemet er at jeg ikke på forhånd kan vite når den kvaliteten er der.
Som selvstendig styringslag for lange produksjonsoppgaver har Codex derfor vært for ustabilt i denne perioden. Det betyr ikke at GPT bare duger til chat. Det betyr at agenten foreløpig trenger tettere tilsyn, mindre risikable ansvarsområder og tydelige kvalitetsporter før den får endre varige systemer eller bestille eksternt arbeid.
Et agentprodukt bør også ha en synlig stoppmekanisme. Hvis kapasitet, kontekst, konto eller runtime gjør normal kvalitet usikker, vil jeg heller få en tydelig advarsel enn et uendret modellnavn og en agent som fortsetter å bruke tid, kvote og penger. OpenAIs egne statussider påpeker at samlet tilgjengelighet kan skjule forskjeller mellom abonnementer, modeller og funksjoner. Da trenger brukeren mer telemetri, ikke mindre.
Det er litt som en bil med et fantastisk ratt ni av ti turer. Det hjelper ikke hvis du på den tiende turen ikke vet om problemet sitter i rattet, bremsene eller motoren – og dashbordet fortsatt sier at alt er normalt. En agent som kan endre kode, opprette utkast og bestille betalte jobber trenger varsellamper og en sikker stopp.
Jeg sitter derfor ikke igjen med bevis for én skjult teknisk forklaring. Jeg sitter igjen med noe mer praktisk: 41 sesjonsfiler, ti produksjonsdager med avvik, 1,152 milliarder behandlede konteksttokens og et mønster der reparasjonen altfor ofte blir neste problem. Tallene lyver i hvert fall ikke. Det åpne spørsmålet er hvilket lag som gjør det.
Ofte stilte spørsmål
Betyr dette at Codex alltid gir dårlige svar?
Nei. Codex kan levere svært godt i en styrt økt. Analysen gjelder stabiliteten i lange agentoppgaver med mange trinn der verktøyet endrer filer, bruker verktøy og må bevare kontrakter over tid. Problemet er variasjonen og mangelen på tydelige varsler når kvaliteten svikter.
Er 1,152 milliarder tokens det samme som fakturerte tokens?
Nei. Tallet er behandlet kontekst fra lokale logger. Omtrent 1,102 milliarder var mellomlagret input, mens rundt 47,3 millioner var ikke-mellomlagret input. De kan prises og kvoteres forskjellig, så totalen skal ikke leses som en API-faktura.
Kan full kontekst være årsaken til Codex-problemene?
Full eller støyende kontekst kan forklare enkelte sene feil, og OpenAI dokumenterer risikoen som context pollution og context rot. Den forklarer ikke alene de utvalgte feilene som oppstod blant de første brukerhandlingene i helt ferske økter før automatisk komprimering.
Har OpenAI nedgradert modellen for storbrukere?
Det finnes ikke bevis for det her. Synlig ukeskvote var 29 prosent brukt, ingen rate limit var logget, og øktene viste valgt modell. Backend- eller kontoavhengig variasjon er en hypotese som OpenAI bør undersøke, ikke en teknisk konklusjon fra de lokale loggene.
