Det usynlige arbeidet: Hva som endrer seg når du optimaliserer for lange økter
Det usynlige arbeidet
Hva som endrer seg når du optimaliserer for lange økter
De fleste forbedringene i kodeagenter er synlige. En ny kommando, et nytt tema, en ny utvidelse. Du skriver noe, noe skjer, du ser det.
Endringene i Elyra v0.6.0 er av et annet slag. De handler om hva som skjer inne i agenten i løpet av en to-timers økt — hvordan den husker, hvor mye den koster, og om den velger riktig modell for hver runde. Du kommer ikke til å legge merke til disse endringene direkte. Du kommer til å legge merke til at øktene flyter bedre, koster mindre, og mister mindre kontekst underveis. Men du kommer ikke til å se hvorfor.
Her er hva som er endret, og hvorfor det betyr noe.
Komprimering pleide å glemme det viktige
Når en økt blir lang, komprimerer Elyra samtalen — den oppsummerer gamle meldinger for å frigjøre kontekstplass. Sammendraget erstatter den rå historikken, slik at agenten har rom til å fortsette å jobbe uten å smelle inn i grensen på kontekstvinduet.
Problemet var hva sammendraget bevarte. Det gamle formatet hadde seks seksjoner: Mål, Begrensninger, Fremdrift, Viktige beslutninger, Neste steg, og Kritisk kontekst. Funksjonelt, men det manglet ting som teller i reelt utviklingsarbeid.
Det hadde ingen dedikert plass for arkitekturbeslutninger. Hvis du og agenten ble enige om å bruke repository-mønsteret for databasetilgang, levde den beslutningen som en one-liner under "Viktige beslutninger" — hvis oppsummereren i det hele tatt fanget den opp. To komprimeringer senere kunne den være borte. Agenten begynte å foreslå inline-spørringer fordi den ikke lenger visste at du hadde valgt et mønster.
Det sporet ikke feilhistorikk. Hvis du brukte tjue minutter på å feilsøke en race condition i en kø-worker, ble løsningen — hva som feilet, hva stack tracen sa, hva som var fiksen — komprimert til "Fikset bug i kø-worker" under Fremdrift. Hvis en lignende feil dukket opp senere i økten, hadde agenten ingen hukommelse om hva den allerede hadde prøvd.
Det nye formatet legger til to seksjoner:
Arkitektur og mønstre bevarer strukturelle beslutninger eksplisitt. "Bruker repository-mønster for DB-tilgang." "Delt opp i service- og controller-lag." "Hendelser sendes via Laravels event-system, ikke direkte kall." Disse overlever komprimering fordi oppsummeringsprompten spør spesifikt etter dem.
Feilhistorikk bevarer hva som gikk galt og hvordan det ble løst. Filstier, linjenumre, selve feilmeldingen, løsningen. Hvis agenten fikset en null pointer exception i UserService.php på linje 47 ved å legge til en null-sjekk, blir det bevart med nok detalj til å kjenne igjen samme mønster hvis det dukker opp igjen.
Reglene for oppsummering ble også mer eksplisitte. I stedet for "hold det kortfattet," sier prompten nå: bevar nøyaktige filstier, funksjonsnavn, klassenavn, variabelnavn, feilmeldinger og stack traces ordrett. Inkluder spesifikke linjenumre der det refereres. Noter hvilke filer som ble opprettet, endret eller slettet.
På serialiseringssiden ble verktøyresultater tidligere kuttet til 2000 tegn før de ble sendt til oppsummereren. Det er trangt. En PHP stack trace alene kan være 1500 tegn. En filediff med kontekst overstiger lett 2000. Grensen er nå 4000 tegn, som betyr at oppsummereren ser mer av selve feilutdataen og filinnholdet når den bestemmer hva som skal bevares.
En dato kostet deg penger hver dag
Denne er nesten pinlig enkel.
Systemprompten — den lange tekstblokken som forteller agenten hvem den er, hvilke verktøy den har, hvilke ferdigheter den kjenner, hvordan prosjektkonteksten ser ut — sluttet med:
Current date: 2026-05-16
Hver dag ved midnatt endret den datoen seg. Og når datoen endret seg, ble hele systemprompt-cachen invalidert.
Anthropic og OpenAI cacher systemprompts slik at gjentatte kall med samme prompt ikke må reprosessere alle de tokenene. En cache hit er omtrent 10× billigere enn en cache miss. Men fordi datoen var bakt inn i systemprompten, var det første kallet etter midnatt alltid en cache miss — for hele prompten, ikke bare datoen.
For en typisk systemprompt på 3000 tokens betyr det 3000 tokens reprosessert til full inputpris i stedet for cache-pris. Multipliser med hver økt som spenner over midnatt, eller starter på en ny dag.
Fiksen: flytt datoen ut av systemprompten og injiser den som en del av første samtalemelding i stedet. Systemprompten er nå stabil på tvers av dager. Datoen når fortsatt agenten (den ligger i konteksten sammen med pinnede filer), men den invaliderer ikke prompt-cachen lenger.
Dette er den typen optimalisering du aldri ser, men alltid kjenner på fakturaen.
Den smarte ruteren pleide å tvile på seg selv
Elyras smarte ruter velger mellom billige modeller (for enkle oppgaver som å lese filer) og dyre modeller (for komplekse oppgaver som refaktorering på tvers av flere filer). Ideen er fornuftig: ikke betal Opus-priser for en grep.
Men klassifikatoren hadde problemer.
Den kjente åtte nøkkelord. Hvis meldingen din inneholdt refactor, debug, eller architect, eskalerte den til den dyre modellen. Hvis den ikke inneholdt ett av de åtte ordene, holdt den seg billig — selv om du skrev "undersøk hvorfor betalingssystemet stille slipper transaksjoner under samtidig last." Det er åpenbart en kompleks oppgave, men ingen av de magiske ordene dukket opp.
Nøkkelordlisten er nå 35 termer. Den dekker:
Ytelsesarbeid — optimize, memory leak, race condition
Feilsøking — investigate, diagnose, troubleshoot, root cause
Arkitektur — design pattern, dependency injection, decouple
Omfangsindikatorer — implement from scratch, build a system
Det er fortsatt nøkkelordmatching — ikke semantisk analyse — men dekningen er dramatisk bedre.
Viktigere: ruteren hadde ingen hukommelse. Hver runde ble klassifisert uavhengig. En kompleks refaktorering i flere steg kunne se slik ut:
powerful — bruker beskriver refaktoreringen
powerful — agenten planlegger
powerful — agenten redigerer filer
fast — agenten leser en fil for å sjekke resultatet
powerful — agenten fortsetter å redigere
Det fallet til fast midt i var feil. Agenten var midt i en oppgave, og gjorde bare et verifiseringssteg uten skriving. Men fordi klassifikatoren bare så på den aktuelle runden, så den "read-only-verktøy + kort melding" og nedgraderte.
Ruteren har nå hysterese. Hvis forrige runde ble klassifisert som powerful, faller ikke neste runde direkte til fast — den demper til balanced i stedet. Dette forhindrer oscilleringen uten å bli klebrig: hvis oppgaven faktisk blir enkel (et nytt urelatert spørsmål), legger den seg tilbake til fast etter én balanced-runde.
Nedgraderingen for read-only ble også smartere. Den utløses nå bare i korte samtaler (under 10 meldinger). I en lang økt er en read-only-runde nesten helt sikkert et mellomsteg i en større oppgave, ikke et frittstående enkelt spørsmål. Ruteren respekterer den konteksten nå.
Og store verktøyutdata (over 5000 tegn) eskalerer nå til powerful. En enkelt filskriving som skriver om en hel modul er komplekst arbeid, selv om brukerens melding var kort. Ruteren fanger det signalet nå.
Hvorfor dette betyr mer enn nye funksjoner
Nye kommandoer og utvidelser er spennende. De utvider hva Elyra kan gjøre. Men optimaliseringene i v0.6.0 forbedrer det Elyra allerede gjør — kjerneløkken med å forstå kontekst, holde kostnadene nede, og velge riktig verktøy for jobben.
En økt som mister arkitektonisk kontekst etter komprimering produserer dårligere kode i den andre timen enn i den første. En cache miss på systemprompten hver morgen koster reelle penger på tvers av tusenvis av økter. En smart ruter som oscillerer kaster bort tokens på modellbytter og retries.
Dette er ikke ting du feilsøker. Det er ting du merker — som en vag følelse av at "agenten virker som den glemmer ting," eller "dette koster mer enn det burde." Fiksene er usynlige. Men forbedringen hoper seg opp på tvers av hver økt, hver dag, hver bruker.
Og det, stille og rolig, er jobben.
