Fra brugerinput til AI-svar — hvad sker der i hvert trin, hvad koster det i tokens, og hvornår er ét agent nok?
Udforsk systemet ↓Et token er den mindste enhed af tekst en AI-model arbejder med — ikke et tegn, ikke et ord, men noget midt imellem. Tokens er AI-modellers valuta: alt du sender ind og alt du får tilbage tælles i tokens, og de fleste AI-tjenester begrænser og prisfastsætter præcis på det grundlag.
Prøv det selv — skriv tekst og se token-estimatet i realtid:
Dit token-budget dækker hele samtalen — ikke bare ét svar. En lang session med 100 svar bruger langt mere end 100 korte isolerede spørgsmål, fordi historikken gensendes som input ved hvert trin.
Når du sender en besked til en AI-agent, er der mindst 6 trin — og tokens akkumuleres i hvert af dem. Klik hvert trin for at se, hvad der sker og hvad det koster:
Alt starter her: din besked og eventuelle vedhæftede filer. Dette er den mindste del af input-tokens — typisk 10–200 tokens for et normalt spørgsmål.
Men din besked er kun toppen af isbjerget. Den pakkes ind i langt mere inden den sendes til modellen.
Din besked udgør kun ~4% af input ved sessionsstart.
Før din besked sendes, pakkes det ind: systemprompten (adfærdsregler, din CLAUDE.md, memory), hele samtalehistorikken, og tool-definitioner. Dette er typisk den største del af input-tokens.
I Claude Code kan systemprompten alene udgøre hundredevis af tokens — og historikken vokser for hvert svar i sessionen.
Historikken er oftest den dyreste post — og den vokser ved hvert svar.
Al kontekst sendes til modellen på én gang. Claude læser det hele — fra første token til sidst — ved hvert kald. Det er derfor lange samtaler er dyre: du betaler at "genindlæse" al historik for hvert nyt svar.
Modellen genererer ét token ad gangen i output. Jo mere den skriver, jo dyrere — output-tokens koster typisk 3–5× mere end input-tokens.
En agent kan kalde "tools" — læse filer, køre tests, søge på nettet. Hvert tool-kald er en ekstra round-trip: AI'en genererer et kald (output), tool'et kører, resultatet tilføjes som nyt input, og AI'en fortsætter.
Tool-kald akkumulerer hurtigt. I Habit Tracker-testen lavede standard-agenten 50 tool-kald; The Council lavede 105.
Council brugte 2× tool-kald — men hvert kald var en specialist-review.
Modellen genererer sit svar. Det er output-tokens — den dyreste kategori. Her gør token-optimering den største forskel.
Fra testen med identisk opgave (BST i Python + quiz): standard genererede ~1.073 tokens pr. run. v1 optimering: ~357 tokens. En reduktion på 67% i output alene — samme korrekthed, langt kortere svar.
Samme funktionalitet — dramatisk forskel i output-pris.
Claude understøtter prompt caching — gentagen kontekst (system-prompt, lange dokumenter) gemmes og genbruges til en brøkdel af prisen.
I standard-agent Habit Tracker-sessionen over 169 turns akkumuleredes 10M+ cache-read tokens. Cache-creation er lidt dyrere end normal input, men cache-read er 10× billigere.
Testet med identisk opgave i 5 gentagelser per tilstand: Binary Search Tree i Python + 5-spørgsmåls multiple choice quiz. Tre tilstande, reelle målinger:
Vælg en tilstand og se hvad der faktisk ændres — både i tall og i kodeoutput:
Avg: ~1.073 · Spread: ±38 tok (~8%) · Meget konsistent
Fulde docstrings · beskrivende navne · __main__ blok · quiz med forklarende feedback
Avg: ~357 · Spread: ±38 tok (~26%) · Mere variabel
Forkortede navne · ingen docstrings · ingen __main__ · kun verdikt i quiz (ingen forklaring)
Avg: ~712 · Spread: ±35 tok (~5%) · Mest konsistent af alle
Fulde navne · én-linje docstrings · __main__ bevaret · quiz med én-sætnings forklaring
Output-token reduktionen fra 67% (v1) svarer kun til ~49% reduktion i det samlede token-forbrug — fordi input-tokens er de samme i alle tilstande. v1 giver ~1.9× flere interaktioner per plan-periode; v2 giver ~1.3×. Koden er identisk korrekt i alle tre tilstande.
En enkelt agent er en generalist — den ved lidt om alt. The Council er et multi-agent system med 6 specialister der hver ejer et snævert domæne, og en Builder-agent der orchestrerer builds i 4 strukturerede faser. Klik en specialist for at se, hvad de fangede i Habit Tracker-buildet:
Fund 1: completedToday manglede i HabitResponse DTO. Frontend ville behøve et separat netværkskald per habit blot for at vise completion-tilstand.
Fund 2: DashboardStatsResponse manglede weeklyData-felt til kalender-widget — ingen datakilde uden det.
Fund 1 (Phase 1): Ownership-tjek skal håndhæves på hvert eneste endpoint. Hvert habit-mutation og toggle skal verificere ejerskab på service-laget — ikke blot de åbenlyse endpoints.
MediumFund 2 (Phase 4): JWT secret havde hardkodet fallback i kildekoden. Fix: kast IllegalStateException ved opstart hvis JWT_SECRET env var mangler eller er under 32 tegn.
Fund 1: List<String> i join-tabel til ugedage = unødvendige rækker og joins. Fix: bitmask-integer med AttributeConverter<Set<DayOfWeek>, Integer> — én kolonne, O(1) reads.
Fund 2: Manglende index på habits(user_id) ville give full table scan på hvert habit-list-kald.
Fund (Phase 4): DashboardService.getStats() kaldte findAllDatesByHabitId() inde i en loop — et N+1 query-problem på service-laget.
Fix: Ét samlet query returnerer Map<UUID, List<LocalDate>> — streaks beregnes i memory fra dette map.
Verificerede: Korrekt 7-lags package-struktur: entity → dao → service → controller → dto → config → util.
Verificerede: @Data bruges ikke på entities — det forårsager StackOverflowError i Hibernate 6 pga. hashCode() på lazy collections.
Definerede design-system upfront: Mørkt tema (#0f0f13 bg, #6366f1 accent), ProgressRing-komponent, ugentlig kalender-grid, streak-tæller, slide-in drawer til habit-oprettelse.
Specificerede: Optimistisk UI på completion-toggle — lokal tilstand flipper øjeblikkeligt, API-kald sker i baggrunden.
Standard-agenten leverede 46 filer på 8 minutter — men 2 af dem kompilerede ikke. Debug-sessionen kostede ~31k ekstra output-tokens. Når debug inkluderes, konvergerer standard-agentens samlede pris (~105k) med The Council's (~119k). Hastighedsfordelen falder fra 4× til under 2× — og Council leverede kode der kompilerede første gang.
Valget afhænger af, hvad du bygger og hvad der er vigtigst. Her er beslutningsrammen baseret på de reelle testresultater:
| Scenarie | Anbefalet | Begrundelse |
|---|---|---|
| Første build af nyt system | The Council | Fanger design-fejl før de eksisterer i kode. Spec hardening. |
| Ny feature på hærdet spec | Standard Agent | Spec er testet. Hurtigst og billigst på velkendt terræn. |
| Output skal læses af andre | Standard / v2 | Læsbart kode og forklarende feedback er kritisk. |
| Du kender basen, quick review | v1 Optimeret | 67% færre output-tokens. Du har konteksten i forvejen. |
| Plan-limit nærmer sig slutning | v2 Optimeret | 34% reduktion uden at ofre kode-kvalitet eller quiz-forklaring. |
| Kritisk produktionskode | The Council | Audit trail + specialistreview > enhver token-besparelse. |
Den hurtigste måde at bruge Council på er ikke til hvert build — det er til det første build af et nyt system. Lad Council hærde spec'en og fange design-fejl. Brug derefter den hærdede spec med standard-agenter på alle features efter det. Du får Councils korrekthed på arkitekturen og standard-agentens hastighed på eksekvering.