Slik holder du token-forbruket nede

Med bruksbasert fakturering betaler du per token. Lange sesjoner med mye frem og tilbake koster mer. Den gode nyheten: du kan få kortere, mer presise svar uten å miste kvalitet.

En 2026-studie fant at modeller ble mer treffsikre når de ble tvunget til å svare kort. Kortere svar kan derfor koste mindre og gi bedre resultat.

Det viktigste først: bruk nav-pilot CLI

nav-pilot er kommandolinjeverktøyet som holder Copilot-oppsettet ditt oppdatert og starter Copilot med riktig konfigurasjon. Den enkleste måten å starte en AI-sesjon:

nav-pilot --sync    # synkroniserer, deretter starter Copilot med @nav-pilot

Eventuelt steg for steg:

nav-pilot install nav-pilot        # installer Nav-agentpakka
nav-pilot sync                     # sjekk for oppdateringer
nav-pilot                          # interaktiv meny — install, sync, eller start Copilot

Når du starter Copilot via nav-pilot, får du automatisk:

• Konklusjonen først, ikke forklaringen
• Kode direkte uten lang innledning
• «Si 'forklar' for detaljer» når begrunnelse hoppes over
• Spørsmål bare når svaret faktisk endrer implementeringen
• Nav-konvensjoner (Aksel, Nais, auth) uten at du trenger å be om det

I VS Code Chat kan du skrive @nav-pilot for å få det samme.

Vil du ha enda kortere svar? Bruk terse-mode

Skills er tilleggskunnskap nav-pilot kan bruke. Du aktiverer dem ved å skrive navnet i meldingen, enten med $-prefiks ($terse-mode) eller uten (bruk terse-mode). $ er vår visuelle konvensjon, ikke påkrevd syntax. Les mer om skills i VS Code-dokumentasjonen.

Skriv terse-mode for å skru på ekstra kompakt stil. Tre nivåer:

Slik bruker du det:

terse-mode                ← slår på normal-nivå
terse-mode ultra          ← for raske iterasjoner
Stopp terse               ← tilbake til vanlig stil

Stilen vedvarer hele sesjonen. Ved sikkerhetsvarsler eller destruktive handlinger bytter den automatisk tilbake til full prosa, så du mister aldri viktig informasjon.

Fem vaner som kutter kostnader

1. Vær presis i spørsmålet

Den dyreste token-sløsingen er misforståelser. Fem runder med «mente du A eller B?» koster mer enn ett godt spørsmål.

Dyrt (vagt → mange oppfølgingsspørsmål):

«Lag en tjeneste for søknader»

Billig (presist → agenten kan starte med én gang):

«Lag et Ktor REST-endepunkt som tar imot dagpengesøknader over Kafka fra dp-soknad. Kotlin, Nais, Postgres.»

Jo mer kontekst du gir i første melding, jo færre runder bruker du.

2. For store oppgaver: la intervjuet gjøre jobben

For små oppgaver gjør nav-pilot jobben direkte, uten spørsmål. For medium/store oppgaver går den gjennom en kort intervjufase der den sjekker blindsoner som personvern, auth og avhengigheter.

Hvis du vil ha et enda grundigere intervju, be om det med nav-deep-interview. Den kjører en strukturert gjennomgang med impactanalyse.

Fem minutter med avklaring slår en bortkastet sesjon.

3. Hold sesjoner fokuserte

Copilot bruker prompt caching, så kontekst fra tidligere i sesjonen koster opptil 90 % mindre enn ny kontekst. Det betyr at du ikke trenger å starte ny sesjon bare for å spare penger. Men en fokusert sesjon gir bedre svar fordi modellen slipper å filtrere bort irrelevant historikk.

• Én oppgave per sesjon gir mer presise svar
• Unngå «kan du også...» som tar sesjonen i helt ny retning
• Lang, ufokusert historikk forvirrer modellen, i tillegg til å koste

4. La nav-pilot finne verktøyene

Du trenger ikke huske alle skills. Nav-pilot bruker riktig kunnskap basert på konteksten:

• Skriver du Kotlin eller TypeScript? → Sikkerhetsregler (OWASP) er allerede aktive
• Jobber du med Nais-manifest? → Nais-kunnskap aktiveres
• Trenger du auth? → TokenX/Azure AD-kunnskap brukes

Du kan be om en spesifikk skill med navn (f.eks. bruk terse-mode), men for de fleste oppgaver klarer nav-pilot seg selv.

5. Hjelp agenten med å lese mindre

I terminalen er den største token-lekkasjen ofte verktøyoutput som testlogger, stacktraces og store diffs. Noen vaner som hjelper:

• La agenten lese filer selv i stedet for å lime inn hele filer
• Ved testfeil: gi den relevante feilmeldingen, ikke hele build-loggen
• Be agenten kjøre målrettede tester (./gradlew test --tests *MinTest) før full pipeline
• Pek på branch eller fil for diff i stedet for å lime inn manuelt

Gode første meldinger

Eksempler som gir presise svar uten mange oppfølgingsrunder:

Legg til et nytt REST-endepunkt /vedtak/{id} i Ktor-appen.
Valider tilgang med TokenX. Hent vedtak fra Postgres via kotliquery.
Les eksisterende endepunkter i src/main/kotlin/routes/ for stil.

Finn ut hvorfor /soknader-siden i Next.js-appen re-rendrer mye.
Sjekk komponenten i src/app/soknader/page.tsx. Foreslå minimal fix.

Podden dp-soknad krasjer i dev med OOMKilled. Se på .nais/dev.yaml
og foreslå justeringer. Ikke endre prod-konfig.

Migrer denne Java-klassen til idiomatic Kotlin. Behold samme
offentlige API. Bruk sealed class for feilhåndtering.

Oppsummert

Under panseret

Resten er for deg som vedlikeholder instruksjoner, bygger MCP-servere, eller vil forstå hvorfor tipsene over fungerer.

Hvorfor kortere kontekst gir bedre svar

Hver gang du sender en melding, pakker Copilot med alt: systemprompt, instruksjonsfiler, åpne filer, verktøydefinisjoner og hele samtalehistorikken. En flerstegssesjon i Copilot CLI kan bruke over 1 million input-tokens. Vantage sin analyse viser at kostnader varierer opptil 30x mellom kjøringer på samme oppgave.

De to største besparelsene:

1. Kortere sesjoner (færre runder = mindre historikk å sende)
2. Mindre instruksjonslast (smalere applyTo-mønstre = færre filer i konteksten)

Hva vi gjorde i dette repoet

Vi hadde en OWASP-sikkerhetsinstruks på 21 KB som ble lastet ved hver eneste Go- og Kotlin-redigering, også når oppgaven ikke handlet om sikkerhet. Vi flyttet innholdet til en on-demand skill og beholdt bare en kort stub (1 KB) med de mest kritiske reglene.

Tommelfingerregel: Hvis en instruks bare er relevant for 10 % av oppgavene, hører den hjemme i en skill, ikke i en alltid-aktiv fil.

Instruksjonsarkitektur

Det viktigste feltet i en Copilot-instruksjon er applyTo-globen:

• applyTo: "**" → lastes alltid (bruk sparsomt)
• applyTo: "**/*.go" → lastes bare for Go-filer
• applyTo: "**/db/migration/**/*.sql" → lastes bare ved databasemigrering

Andre tips for vedlikeholdere:

• Komprimer innhold. Instruksjoner leses av modellen, ikke mennesker
• Hold filer stabile, fordi prompt caching fungerer best når innholdet sjelden endres
• Bruk konkrete dropp-lister («dropp artikler og høflighetsfraser») fremfor vagt «vær kort»

RTK komprimerer terminaloutput

Oppdatert 2026-08-24: Denne seksjonen påsto opprinnelig at «RTK rapporterer 60–90 % reduksjon på verktøydata». Det tallet er verktøyets egen selvrapportering, og ingen kontrollert måling bekrefter det. Vi har rettet avsnittet, og nav-pilot anbefaler ikke lenger RTK aktivt.

RTK er en CLI-proxy som filtrerer og komprimerer kommando-output (testresultater, diff, kubectl) før den når kontekstvinduet.

brew install rtk
rtk init -g --copilot

Hva vi vet om effekten: RTK har en innebygd teller (rtk gain) som viser hvor mye verktøyet mener det har spart. Den tellingen er ikke det samme som lavere regning:

• Den regner hele den rå kommando-outputen som «spart», selv om agenten uansett kutter store verktøyresultater.
• Den priser fjernede tokens til full input-pris, selv om det meste av sesjonsinput er cachede gjenlesninger til rundt en tidel av prisen.
• Bare en del av verktøyresultatene går gjennom hooken i det hele tatt. Innebygde lese- og søkeverktøy går utenom.

Den eneste store offentlige kontrollerte studien, JetBrains, 425 kjøringer over 86 oppgaver med forhåndsregistrerte endepunkter, fant ingen besparelse: 7,6 % høyere kostnad per oppgave ved lavt resonneringsnivå (p = 0,004) og ingen målbar forskjell ved høyt nivå (+0,1 %, p = 0,99), uten kvalitetsforskjell.

Merk omfanget: studien målte RTK i Claude Code, og hook-dekningen over er et arkitekturtrekk ved den agenten. Tilsvarende kontrollert måling finnes ikke for Copilot CLI eller OpenCode, så der er effekten ikke målt. Andre har rapportert liknende for andre komprimerende verktøy: 0,6 % av en faktisk regning på 755 dollar, og en prompt-komprimerende proxy som kuttet tokens 39 % men brøt prompt-cachen 123 ganger og dermed flyttet millioner av tokens til full pris.

Grunnen er strukturell: output-tokens utgjør en liten andel av totalen i en agent-sesjon, og cache-treffraten er høy. Da er det lite å hente på å komprimere tekst.

Praktisk konklusjon: RTK gjør terminaloutput lettere å lese, og det kan være verdt noe i seg selv. Men ikke regn med lavere regning, og ikke bruk verktøyets eget sparetall som bevis. Mål heller fakturert kostnad per fullført oppgave. Grepene som faktisk har dokumentert effekt, er modellvalg, resonneringsnivå, å holde prompt-cachen intakt og å gjøre mindre arbeid.

Merk: RTK prosesserer terminaloutput lokalt. Sjekk at verktøyet er godkjent for ditt team før du bruker det med output som kan inneholde sensitive data.

TOON og dynamiske verktøysett

To teknikker for deg som bygger MCP-servere:

• TOON koder strukturert data med 30–60 % færre tokens. Relevant når serveren returnerer store JSON-objekter.
• Dynamiske verktøysett betyr at du ikke laster alle verktøyskjemaer på forhånd. Bruk et søk → beskriv → utfør-mønster. Speakeasy rapporterer 100x reduksjon med denne tilnærmingen.

Videre lesing

• GitHub: Improving Token Efficiency in Agentic Workflows
• arXiv: Brief is better? finner at korte svar kan gi bedre nøyaktighet
• Matt Pocock: skills med grill-mønster og andre agent-skills
• Vantage: Hidden Cost Driver in Agentic Coding med kostnadsanalyse av agentiske arbeidsflyter