Det kom bag på dem. Budgettet så pænt ud på whiteboardet: model X, kontekst Y, cirka så mange forespørgsler per dag. Alligevel landede den første faktura 2,5 gange over. Vi har set det før hos en dansk fintechkunde i et POC‑forløb, og Zenefa Rahamans analyse i Towards AI rammer årsagen. Tokenlinjen stjæler opmærksomheden. Men i agent‑systemer er den sjældent det, der vælter læsset. Det er alt det omkring.
Jeg ærgrede mig også første gang vi selv fik sådan en regning. Vi fandt 12 procent i prompt‑trim og lidt kontekstslankning. Fint. Hullet var der stadig. Det lugter mere af serverrum end af poesi: drift koster, især når agenter går i dybden.
Hvorfor regningen overrasker
Rahaman beskriver det klart: tokenomkostning er synlig i regnearket, men sjældent dominerende i produktion. Teams undervurderer andenordenseffekter som retries, tool‑fan‑out, fallback og observability. Når prototypen bliver til et produktionsflow, begynder de poster at leve deres eget liv. Artiklen nævner, at første faktura ofte er flere gange over estimatet, og at klassiske prompt‑tweaks typisk kun flytter 10–15 procent. Det billede genkender vi.
Ingeniørerne kigger efter overflødige tokens eller for store kontekstvinduer. Man finder lidt. Men regningen ligger i adfærden under modstand: når et værktøj kalder et andet, eller når systemet prøver igen efter en valideringsfejl. Driftens pris, ikke bare modelkaldet.
Hvordan agenter bryder traditionelle omkostningsmodeller
Klassiske ML‑budgetter bygger på lav dybde og lineær pris. Én forespørgsel, ét kald. Agenter er anderledes: depth‑variable workflows, hvor en forespørgsel kan blive til ti reasoning‑trin, fem tool‑kald, to forsøg på struktureret output og en fallback til en anden model. Ikke altid. Men ofte nok til at halen styrer gennemsnittet.
Det giver en omkostningsfordeling med lang hale. Medianen ser pæn ud, gennemsnittet trækkes op af de hårde sager. Rahamans anbefaling er klar: mål cost‑per‑resolved‑task i stedet for cost‑per‑call. Ellers skruer I på de forkerte håndtag.
De konkrete skjulte linjeposter
Her gør det ondt, men også gavn. Vi ser de samme poster igen og igen, som sjældent står i prototypens regneark. Nedenfor er korte beskrivelser med simple regneeksempler eller erfaringsspænd. Tallene er pejlemærker fra kilden og vores cases, ikke universalregler.
- Retries og reasoning‑loops: Når struktureret output fejler, eller en validering siger prøv igen, kommer der 1–3 ekstra modelkald. Hvis 20 procent af sagerne i snit får 2 ekstra kald, er det cirka 40 procent oven på tokenbudgettet for de berørte sager.
- Tool‑fan‑out: Agenten spørger flere værktøjer i parallel. Søgning, vektor‑slag, interne API’er. Hver gren koster. Ser vi tre værktøjsopslag per sag i snit, med 10 procent der ryger til 10 opslag under tvivl, kan det lægge 15–30 procent til end‑to‑end prisen. Parallelitet og timeouts dæmper, men fjerner ikke regningen.
- Fallback‑arkitektur: Billig model som standard, dyr som redningskrans. Hvis 15 procent af sagerne eskalerer til en model der koster 5x, kan den effektive gennemsnitspris stige 30–40 procent, afhængigt af fordelingen.
- Observability og logging: Tracing pr. opgave, hændelseslogning, retention til revision. Cloud‑logning og tracing kan i praksis lægge 5–15 procent til driften, mere hvis fuld kontekst gemmes for compliance.
- Latency‑mitigering: Prefetching, cache‑varmning, redundante kald for at undgå hale‑latens. Det forbedrer oplevelsen, men koster. Vi har set 8–12 procent højere cloudregning for at holde P95‑latens nede i travle perioder.
- Orkestrationsinfrastruktur: Køer, idempotensnøgler, state‑stores, scheduler. Ikke dyrt per kald, men konstant. Typisk 5–10 procent af totalen i mindre miljøer, lavere i stor skala.
- Løbende labeling og modelopdatering: Fejlsager skal mærkes, policies justeres, små finetunes rulles ud. Mennesketimen kan spise 10–20 procent af månedens AI‑budget, hvis man ikke prioriterer. Vi har set 1–2 FTE på tværs af produkt og data for at holde kvaliteten stabil i POC til tidlig drift.
- Compliance og sikkerhed: PII‑maskering, auditlogik, DPA’er, nøglestyring. Omkostningen er både licenser og ingeniørtimer. Læg et realistisk fast lag og et variabelt lag pr. sag, hvis I kører dyb logging.
Summen? Hvis tokenlinjen føles som 100, så ender totalen nemt på 170–250, afhængigt af haleopførsel. Det ligger i tråd med Rahamans pointe om 2–3x på første faktura. Vores anonymiserede fintechcase, en etableret aktør i Danmark i et afgrænset POC‑miljø, ramte 2,5x drevet af tool‑fan‑out og retries.
Hvor meget kan optimering hjælpe
Vi kan godt lide en skarp prompt og en mindre kontekst. Rahaman vurderer, at de tiltag typisk flytter regningen 10–15 procent. Det matcher vores erfaring. I et support‑agentprojekt halverede vi latensen ved at skære overflødige kontekstkæder væk og indføre kort‑cache på ofte stillede spørgsmål. Fakturaen faldt 12 procent, fordi halen stadig udløste fallback og tool‑kaskader.
Moralen: optimer for hele opgaven. Et hurtigt men uroligt flow er stadig dyrt. Et lidt langsommere, stabilt flow kan være billigere, hvis halen tæmmes.
Bedre diagnostic: cost‑per‑resolved‑task
Mål end‑to‑end. Prisen for en afsluttet opgave, ikke prisen på ét API‑kald. Vi bruger selv en ramme: cost‑per‑resolved‑task. Den inkluderer tokens, værktøjer, retries, fallback, logning og den del af infrastrukturen, der skalerer med mængden. Faste omkostninger holdes for sig.
Et kort regneeksempel fra et dansk POC, anonymiseret: cost‑per‑call på den primære model lå på 0,9 øre. Men pr. løst sag inkl. fan‑out og 12 procent fallback var snittet 6,2 øre. Efter et sprint med cache på top 50 intents, hårdere timeout ved P95 over 3 sekunder og trimmet tool‑parallelisering faldt tallet til 4,9 øre. 21 procent ned. Tokens var under halvdelen af totalen før og efter.
Gør målingen brugbar fra dag 1. Log få, skarpe felter og byg alarmer på dem. For eksempel:
- Events: task_start, step_start, tool_call, tool_error, retry, fallback_escalation, task_end
- Metrics: retries_count, tool_calls_count, p95_latency_ms, cost_per_task, fallback_rate, cache_hit_rate
- Tracing‑felter: task_id, user_id_hash, model_name, prompt_tokens, completion_tokens, tool_names, error_code
Tørt? Ja. Effektivt.
Praktisk playbook: hvad vi anbefaler
Ingen trylleri. Bare disciplin og tidlige valg, der betaler sig.
- AI‑økonomi‑audit i 2–3 uger: Kortlæg flows og lav en første cost‑per‑resolved‑task model. Bryd ned i tokens, tools, retries, fallback, logning, infrastruktur. Ansvar: produkt + data + platform. Output: baseline, risikohypoteser, budget‑guardrails.
- Proof‑of‑value med omkostningsmål i 4–6 uger: Definér succes som “løst sag til under X kr., P95”. Kør A\/B på cache og fallback‑strategier. Ansvar: det team, der også skal drive drift.
- Hybrid inferens og caching fra dag 1: Billig model som standard, selektiv eskalering til dyr. Kort‑ og mellemlang cache for hyppige forespørgsler og tool‑resultater. Økonomiske guards: max‑retries, circuit‑breakers, fan‑out‑lofter per sag.
- MLOps\/observability fra dag 1: Tracing af hele agentkæden. Kostbrud pr. sag. Alarmer på hale‑latens og afvigelser i cost‑per‑resolved‑task. Budget‑alerts og daglige dashboards. Brug det i uge 1, ikke efter go‑live.
- SLA, timeouts og fallback‑design: Beslut hvor meget I vil betale for at redde en sag. Transparente fejl frem for uendelig ventetid. Hellere en pæn undskyldning end et dyrt loop.
- Test for halen: Stress‑ og kaostest med fejl i tools, langsomme API’er og tomme caches. Mål omkostning på dårlige dage, ikke kun på gennemsnittet. Vi ser ofte, at en mindre del af trafikken i halen driver meget af regningen. En observation, ikke en lov.
Vores rytme har typisk været en 3‑ugers audit og et 6‑ugers sprint for at få hybrid‑cache, observability og guards på plads. Ikke glamourøst. Bare drift.
Tradeoffs og begrænsninger
Kompromiser er uundgåelige. Hybridarkitektur giver flere dele at holde styr på. Caching kan gøre svaret ældre end ideelt, og aggressiv fallback kan skære i kvalitet. I skal også forholde jer til jura: logning af indhold kan være persondata, og retention‑krav gør lagring dyrere.
Nogle omkostninger kan ikke trylles væk, hvis nøjagtighed er central. Har I regulatoriske krav med forklarbarhed eller dobbeltkald, stiger prisen. Enkelte vil indvende, at de kører simple workloads hvor tokenomkostning dominerer. Fair i lineære flows, batch‑opgaver eller embeddings‑jobs uden agentik. Så taler vi bare ikke om agent‑systemer i egentlig forstand.
Konkrete næste skridt for beslutningstagere
Står I før et agent‑projekt, så mål de rigtige steder. Tidligt. En kort tjekliste vi selv bruger:
- Definér mål i opgaveløsning: “Vi vil løse X procent af sagerne til under Y kr. pr. sag over 30 dage.”
- Etabler observability i POC: tracing, cost‑breakdown, hale‑alarmer. Ikke slides. Grafer.
- Beslut økonomiske guards: max retries, fan‑out‑loft, fallback‑kvote pr. bruger eller pr. team.
- Kør mindst ét A\/B‑eksperiment på cache og ét på fallback. Hellere to klare end ti utydelige.
- Sæt revisionsinterval: ugentligt i POC, månedligt i drift. Kig på halen: Hvorfor blev en andel af sagerne dyre i sidste uge?
- Udpeg ejerskab: produkt ejer cost‑per‑resolved‑task, platform ejer hale‑latens og drift, data ejer kvalitet og etiketter.
Små noter fra virkeligheden: En eftermiddag på kontoret på Frederiksberg målte vi et pludseligt hop i cost‑per‑resolved‑task. Årsagen var banal. Et eksternt API ændrede svarformatet en anelse, og vores validering tvang tre ekstra forsøg i halen. En ingeniør mumlede “vi betaler for tvivl her”. Guarden blev strammet, omkostningen faldt igen. Et agent‑system er et økosystem. Små bølger, store regninger.
Afslutning: Hvad vi har lært
Efter at have fulgt flere agent‑projekter fra whiteboard til drift, står én ting klart: Det, der ligner en modeludgift, er i praksis en driftsudgift. Den rigtige enhed er cost‑per‑resolved‑task, og de rigtige værktøjer er observability, økonomiske guards og ro i maven når halen driller. Rahamans analyse er skarp, og vores erfaringer peger samme vej.
Vi arbejder med AI‑økonomi‑audits, hybridarkitektur og MLOps fra dag 1, fordi det gør forskellen mellem demo og drift. Ingen glansbilleder. Man opdager først forskellen, når man sidder med det i hænderne.
