Token-vinduet der vokser i smug

Der er noget, der holder optrædende i produktionsmiljøer med AI-assistenter. Du beder værktøjet om en lille opgave, det leverer varen — og så tjekker du token-tælleren og tænker: "Vent, hvad?"

Lad mig give et eksempel. En udvikler instrumenterede en session, hvor en agent lukkede en GitHub-issue. Læste dokumentet, redigerede en fil, kørte tests, lavede en commit, åbnede en pull request. Pænt, færdigt, brugbart arbejde.

Output? Cirka 10.300 tokens med egentlig ræsonnement.

Den samlede kontekst? Omkring 1,55 millioner tokens.

Lad det bundfælde sig. Det er en arbejds-til-overhead-ratio på omkring 1:150. Agenten tænkte altså ikke med 1,5 millioner tokens. Den slæbte rundt på dem som møbler i en flyttebil, den ikke kunne pakke ud.

Hvis du kører coding agents i din arbejdsgang — uanset om det er startup-udvikling, DevOps-automatisering eller bare acceleration af kode-gennemgange — så æder denne ratio stille og roligt dit budget, puster din latency op, og øger risikoen for "context rot" (hvor modellen begynder at miste tråden, fordi samtalevinduet er for proppet til at parse rent).

Så lad os kigge på, hvor de tokens egentlig ender.

Hvad der fylder konteksten

Efter at have gennemgået data fra flere agent-sessioner, tegner der sig et klart billede. Hovedparten af token-forbruget kommer ikke fra selve ræsonnementet. Det kommer fra kontekstsammenhængen — den infrastruktur agenten har brug for bare for at fungere.

Værktøjskataloget, der vokser. Det er den store synder, og den sniger sig ind på dig. Jo flere MCP-servere (Model Context Protocol) du forbinder, jo flere værktøjsdefinitioner bliver pumpet ind i kontekstvinduet. I én session var ni MCP-servere forbundet med cirka 260 værktøjer. Da to af dem blev tilkoblet midt i sessionen, listede én server alene omkring 180 værktøjsnavne. Det sker kun én gang per forbindelse — men det forsvinder aldrig fra samtalehistorikken. Det bliver bare ved med at sidde der, samle sig, og lægge vægt på hver eneste efterfølgende udveksling.

Skills-kataloget som løbende udgift. I modsætning til værktøjs-dumps, som er en engangspris, er skills-kataloget en pris du betaler hver eneste gang. Snesevis af skills, hver med multi-sætningsbeskrivelser, der indlæses ved hver eneste interaktion. Det får ikke token-tælleren til at eksplodere — det hæver bare bundniveauet. Session efter session.

System-prompten og infrastruktur overhead. Før din agent overhovedet gør noget som helst, er du i mange opsætninger allerede forbi 100k tokens. System-prompten, sikkerhedspolitikker, værktøjsskemaer og formateringsinstruktioner — alt sammen loader ved hver omgang. De er nødvendige, men de er ikke arbejdet.

Den egentlige opgave. Her kommer det ubehagelige: issue-teksten, fil-redigeringerne, test-outputtet, commit-beskeden — alt sammen lagt sammen kan være ganske få tusind tokens. Opgaven er lille sammenlignet med værkstedet.

Hvorfor det betyder mere, end du tror

Du fristes måske til at trække på skuldrene. "Tokens er billige, ikke?"

De er billige — indtil du kører tyve agent-sessioner om dagen, hver opsvulmet af faktorer du ikke vidste, du kunne kontrollere. Regnestykket vokser hurtigt. Og det handler ikke kun om pris.

Høj kontekstvolumen betyder højere latency. Modellen skal processere mere ved hver omgang, hvilket sænker svartiderne præcis når du har brug for hastighed.

Mere kritisk: context rot bliver et reelt problem. Når din agents arbejdskontekst er pakket med værktøjsdefinitioner, skill-beskrivelser og samtalehistorik, den ikke har brug for til den umiddelbare opgave, begynder den at miste signal-støj-forholdet. Den kan glemme relevant kontekst fra tidligere i sessionen, misforstå hvad du beder om, eller træffe beslutninger baseret på forældet information begravet dybt i samtalevinduet.

For startups, der bevæger sig hurtigt, er det ikke en mindre gene — det er et pålidelighedsproblem.

Sådan måler du, hvad du egentlig bruger

Instinktet er at gætte. "Måske er denne session stor, fordi opgaven er kompleks." Som regel er den ikke. Som regel er det infrastruktureren.

Tre tilgange der faktisk virker:

1. Læs usage-blokken i din endelige API-respons. Hver respons fra din model indeholder usage-statistik: output tokens (hvad modellen genererede), input tokens (hvad du sendte), og cache_read_input_tokens (hvad der blev hentet fra samtalehistorikken). Den cache_read-tals er din smoking gun. Hvis den viser 1,5 millioner tokens, og din output var 10k, har du et klart billede af overhead-ratioen.

2. Tjek din session-kontekst midt i kørslen. De fleste moderne agent-frameworks har en kommando som /context, der viser præcis hvad der optager dit vindue lige nu, kategoriseret. Sådan fanger du de per-run omkostninger — skills-kataloget og skemaerne — som en final-turn usage-blok ikke kan adskille rent fra den egentlige opgave.

3. Audit dine værktøjsforbindelser, før du tilføjer flere. Før du forbinder endnu en MCP-server eller tilføjer endnu en kapabilitet til din agent, så spørg: hvad kommer det til at koste mig per omgang? Én værktøjsdefinition er måske fint. Hundrede værktøjsdefinitioner på tværs af snesevis af servere er en stille budget-drukningsmand.

Praktiske måder at krympe ratioen

Nu til den brugbare del. Hvis du har identificeret, at dine agent-sessioner er token-tunge, så er det her, du starter med at trimme.

Strømlin dine værktøjsforbindelser. Audit hver MCP-server og spørg, om den trækker sin vægt. Hvis en server eksponerer 50 værktøjer, og din agent brugte 3, så er der et mismatch. Overvej, om du har brug for alle de værktøjer forbundet hele tiden, eller om du kunne scope dem per opgavefase.

Brug fokuserede kontekster i stedet for globale. I stedet for at loade hele dit værktøjskatalog og skills-bibliotek ind i hver session, så overvej opgave-specifikke konfigurationer. En agent der hjælper med kode-review har ikke brug for samme kontekst som én der skriver infrastrukturkode.

Overvåg per session, ikke kun per måned. At tjekke aggregerede omkostninger skjuler udliggerne. Kig på individuelle session token-tællinger, og du begynder at se mønstre — hvilke opgaver boomer, hvilke forbindelser svulmer, hvilke skills der aldrig bruges men altid er loadet.

Overvej modeller og frameworks bygget til effektivitet. Nogle agent-frameworks er mere token-effektive end andre fra design-stadiet. Vibe Hosting's AI-assisterede udviklingsmiljø er bygget med dette i tankerne — giver dig kraften i agentiske arbejdsgange uden den skjulte overhead, der æder dine marginer.

Konklusionen

Næste gang du kører en coding agent og føler, at intelligence-til-cost ratioen er forkert, har du sandsynligvis ret. Tokensene ender ikke der, hvor du tror. Hovedparten af dem bærer værkstedet — værktøjerne, skills, skemaerne og samtale-stilladsen — ikke det egentlige arbejde.

Mål først. Usage-blokken og context-kommandoerne lyver ikke. Når du kan se, hvor tokensene ender, kan du træffe informerede beslutninger om, hvad du skal trimme. I de fleste tilfælde vil du finde betydelig plads til optimering uden at ofre kapabilitet.

Din agent behøver ikke at bære hele værkstedet. Den skal bare have de rigtige værktøjer til opgaven. Sørg for at give den præcis det.