Writer har offentliggjort forskning, der peger på, at virksomheder kan skære næsten 40 procent af deres tokenforbrug per opgave og i nogle workloads reducere cost-per-successful-task med op til 61 procent. Uden finjustering. Uden at udskifte foundation-modellen. VentureBeat dækker resultaterne og citerer Writers CTO Waseem AlShikh for en nøgtern pointe: regningen er tokens-per-task gange price-per-token. Mange følger kun med i det sidste tal.
Det opsigtsvækkende er, hvor meget der ligger i orkestrationen – ikke i modellen. Ifølge arXiv-papiret er det lag omkring modellen, harnesset, der i praksis sætter prisen på arbejdet. VentureBeat skriver med henvisning til studiet, at kvaliteten holdt sig stabil, hvilket gør fundene relevante for drift – ikke kun for besparelser på papiret.
Hvad er et AI-harness
Harnesset er det lag, der samler modellen til et fungerende system: prompt routing, formatering, caching af systemprompter, styring af tool-calls, retrieval frem for at fylde kontekstvinduet, samt fejl- og retry-logik, der stopper loops. Alt sammen i kode og under udviklernes kontrol. ArXiv-papiret beskriver det som laget, der i høj grad bestemmer opgavens pris.
Tænk på det som gearkassen. Motoren er stærk, men uden ordentlig gearing får du mest larm. VentureBeat gennemgår netop disse håndtag i harnesset – fra historikkomprimering til værktøjsstyring og retrieval-strategier. Det er dér, målerne flytter sig.
Tokenmaxxing forklaret
VentureBeat bruger ordet tokenmaxxing om et udbredt mønster: man øger kontekstvinduet og kører generate–retry i ring. Når noget fejler, sender man flere tokens og mere kontekst, og prøver igen. Det kan virke i øjeblikket – især i kodeopgaver – og glider derfor videre til andre flows.
Konsekvensen er, at tokens-per-task vokser som en snebold. Hver iteration gensender en større historik. Waseem AlShikh udtrykker det klart til VentureBeat: lavere pris per token dulmer smerten, men ineffektiviteten forsvinder ikke. Og når output-tokens hos flere udbydere koster mere end input, bliver tokenmaxxing en stille budgetdræber.
Hvad Writer faktisk optimerede
Studiet adresserer orkestrationslaget og evaluerer, hvordan konkrete greb påvirker forbrug og pris. VentureBeat fremhæver især: systemprompt-caching, komprimering af interaktionshistorik, strammere værktøjs- og fejlstyring samt retrieval-strategier, der erstatter kontekst-stuffing. ArXiv-papiret er den tekniske hovedkilde til eksperimentopstillingen; detaljer om præcise workloads må læses i fuldteksten.
Der findes mange kendte effektiviseringer, men pointen her er, at den målbare gevinst kommer af en samlet harness-ændring – ikke én magisk teknik isoleret. Besparelserne i studiet er forankret i orkestrationens helhedsgreb.
Tal, metrikker og hvad der er målt
To nøgletal går igen: cirka 40 procent færre tokens per opgave og op til 61 procent lavere cost-per-successful-task. VentureBeat gengiver tallene med henvisning til papiret. Tokens-per-task er summen af input- og output-tokens for at løse en opgave – inklusiv retrier og eventuelle agentkald. Cost-per-successful-task lægger prissætningen ovenpå og tæller kun de opgaver, der passerer en defineret kvalitetsgrænse.
Hvilke workloads er testet? Det er mindre klart i nyhedsdækningen. VentureBeat omtaler resultater på tværs af agentiske opgaver, men uden fuld liste. Det gør generaliserbarheden en smule usikker. Et rimeligt take-away: størst effekt dér, hvor der i forvejen er mange loops, lang historik og overdrevent store kontekstvinduer.
Hvorfor det virker uden modelændringer
Orkestration er gatekeeper for tokens. Mindre kontekst, færre unødvendige retrier og caching af stabile dele reducerer direkte tokens-per-task. Offloading af simple delopgaver til en mindre model eller via retrieval sænker både tokenmængde og regning. Alt sammen uden at røre modellen.
Det afgørende: harnesset er jeres kodebase og regler. Ingen nye weights, ingen leverandørskifte, ingen lange godkendelsesforløb for at komme i gang. Ændringer kan isoleres per flow og A\/B-testes på de samme metrikker som i studiet.
Praktiske beslutninger før skalering
Før et team skalerer, bør disse beslutninger være på plads:
- Gør tokens-per-task, retries-per-task og cost-per-successful-task til førsteborgere i jeres dashboards – ikke skjult telemetri.
- Implementer caching, hvor svar og systemprompter er stabile, og brug retrieval i stedet for kontekst-stuffing ved dokumenttunge opgaver.
- Indfør faste retry-politikker og breakers, så agentiske loops ikke løber løbsk.
- Model-tiering: send trivielle anmodninger til en mindre model og eskalér kun ved behov.
Tradeoffs findes: aggressiv caching kan forælde svar; retrieval kan øge latens; tiering øger driftskompleksitet. Sæt kvalitetsvagter tidligt, undgå overbudgettering af reasoning-trin uden klar routing, og mål alt, så diskussionen ikke ender i smag og behag.
Eksekveringsvej til en pilot
Start med at kortlægge nuværende tokenstrømme 1–2 uger. Etablér en baseline på tokens-per-task, success-rate, latens og cost-per-successful-task. Uden baseline gætter man.
Rul dernæst 2–3 målbare harness-ændringer ud: simpel systemprompt-cache, historikkomprimering og et retrieval-snit mod et ofte brugt dokumentdomæne. A\/B-test mod baseline. Lad eksperimenterne køre længe nok til at fange varians. Opsæt alarmer, når retries-per-task stiger, eller tokens-per-task overskrider budget.
Sikkerhed og compliance
Caching og retrieval kræver disciplin. Cachede svar og prompter skal krypteres i hvile og transit, have klare retention-regler og adgangskontrol. Retrieval, typisk via søgeindeks eller vektorstore, skal underlægges samme dataklassifikation som resten af systemet – ellers flyttes risikoen bare.
Hybrid on-prem\/cloud kan give mening, hvis følsomme data ikke må forlade en tenant. I den bredere kontekst peger en aktuel artikel om åbne vægtmodeller på, at nogle modeller er token-sultne i praksis og kan bære policy-risiko over tid, inklusiv potentielle ændringer i adgang via cloududbydere. Eksemplet nævner en model med 15 dollar per million output-tokens og højt sat reasoning som default – ikke nødvendigvis billigt i drift. Relevante overvejelser, hvis man planlægger tiering med sådanne modeller.
Økonomien og ROI-paradokset
Prototyper skjuler omkostninger: lille trafik, stor model, få loops. I produktion vokser loops, og tokens-per-task æder budgettet. VentureBeat beskriver det som en ROI-krise – rammende nok.
Harness-optimering ændrer regnestykket, fordi den rammer den faktor, der vokser hurtigst ved skalering. Et fald på 30–40 procent i tokens-per-task går direkte på OPEX – uden at låse jer til én model eller én leverandør.
Hvornår harness ikke rækker
Nogle gange skal modellen ændres. Mangler funktionalitet, eller fejler kvaliteten konsekvent på domænespecifik viden, er finjustering, adaptere eller distillation på sin plads. Harness opfinder ikke nye evner i modellen.
Visse arbejdsgange kræver deterministisk adfærd eller lange resonnementer, hvor budgetteret reasoning eller nye arkitekturer er nødvendige. Man starter med transmissionen – men der er et loft uden modelarbejde.
Konsekvenser for leverandørvalg
Kræv synlighed: finmasket telemetri for input- og output-tokens per kald, klare priser per token-type og hooks til observability. Uden det bliver cost-per-successful-task til blind flyvning – det skal stå i SLA’erne.
Arkitekturmæssigt gælder det samme: gode værktøjer til routing, batching og kontrollerede retrier. Hvis platformen ikke tilbyder det, ender arbejdet i applikationslaget – med mere kompleksitet til følge.
Citater og kilder
“Teams tokenmaxx because it’s the cheapest fix in the moment, and because it’s literally how most engineers work today,” siger Waseem AlShikh til VentureBeat. Det forklarer, hvorfor mønsteret spreder sig fra kodeopgaver til andre agentiske flows.
“Your invoice is tokens-per-task times price-per-token, and most teams only watch the second number,” fortsætter han. VentureBeat refererer samme sted til resultaterne: cirka 40 procent færre tokens per opgave og op til 61 procent lavere cost-per-successful-task med stabil kvalitet, med arXiv-papiret som teknisk reference for metode og målinger.
Hurtige prioriteringer
Kort liste, uden pynt: mål tokens-per-task; skær i historik og loops; brug retrieval før du udvider kontekstvinduet; og indfør tiering, når det giver mening. Det er ikke ny arkitektur – det er det stille arbejde, der skiller dyre eksperimenter fra sund produktion.
Hvorfor bliver det ikke gjort oftere? Faldende tokenpriser giver en falsk ro. Problemet forsvinder ikke. Forskellen mærkes først, når driften kører for alvor.
Bilag og teknisk note
Læs mere: VentureBeat-artiklen om Writer-fundene, arXiv-opslaget for den tekniske ramme, og policy-artiklen om åbne vægtmodeller og skjulte driftsomkostninger. For ingeniører: definer tokens-per-task, retries-per-task, success-rate, latency og cost-per-successful-task. Log per kald og per flow, og A\/B-test harness-ændringer, før de rulles bredt ud.
