TL;DR
AI-agenters tokenomkostninger vokser, når hvert trin gentagne gange behandler instruktioner, samtalehistorik, værktøjsresultater og mellemliggende tilstand.
Reducer tokenmængden med run-niveau budgetter, filtrering af værktøjsresultater, kontekstkomprimering, retry-grænser og kontrolleret ræsonnering. Brug prompt-caching til stabilt gentaget input, men optimer agentløkken, før du skifter til en billigere model.
Den mest nyttige produktionsmetrik er omkostning pr. vellykket opgave, målt på tværs af den komplette kørsel—ikke pris pr. anmodning eller kontekststørrelsen i det sidste kald.
Denne guide fokuserer specifikt på flertrins AI-agenter. Den forklarer, hvordan gentaget kontekst akkumuleres på tværs af en kørsel, hvordan man identificerer den største kilde til spild, og hvilke kontroller der skal implementeres først.
Introduction
En chatbot kan lave én modelanmodning pr. brugermeddelelse. En AI-agent kan foretage 10, 20 eller flere kald, før én opgave fuldføres.
Hvert trin kan gensende instruktioner, samtalehistorik, værktøjsresultater og mellemliggende tilstand. Genforsøg, ræsonnering og underagenter tilføjer mere forbrug, så et kort slutsvar kan stadig bruge et stort antal tokens.
Når brugen skalerer, bliver disse omkostninger sværere at forudsige og kan hurtigt reducere produktmargener. At sænke dem kræver optimering af hele agentløkken—ikke blot at skifte til en billigere model.
Denne artikel koncentrerer sig om agent-specifikke omkostninger. For en bredere guide, der dækker prompt-caching, præcis svarkaching, semantisk kaching, modelruting og generel API-omkostningsstyring, se Sådan reducerer du AI API-omkostninger.
Why Do AI Agent Token Costs Compound?
I en flertrins agent er omkostningen ved én opgave summen af hvert modelkald—ikke kun det endelige svar.
De primære kilder til agent-tokenforbrug er:
| Cost source | What causes it | First control to test |
|---|---|---|
| Repeated instructions | System prompts, tool schemas, policies, examples | Stabilize the reusable prefix |
| Growing history | Earlier turns are resent at each step | Compact or selectively retrieve state |
| Tool results | Search pages, files, logs, and database records | Filter before adding them to context |
| Intermediate output | Plans, status messages, and verbose tool decisions | Use compact structured outputs |
| Reasoning tokens | High reasoning effort on routine steps | Match effort to task complexity |
| Retries | Invalid output, timeouts, tool errors, and rate limits | Classify failures and cap retries |
| Subagents | Workers duplicate context, tools, and analysis | Send each worker a narrow context slice |
Der er to forskellige måder at reducere regningen:
- Processér færre tokens gennem filtrering, komprimering, outputbegrænsninger og løkkekontroller.
- Reducér den effektive pris for nødvendige tokens via prompt-caching eller modelvalg.
Vigtig sondring: Prompt-caching sænker prisen på gentaget input. Kontekstkomprimering reducerer selve det gentagne input.
How Can a 12-Step Agent Process 147,000 Tokens?
Overvej en hypotetisk supportagent med:
- Et stabilt præfiks på 4.000 tokens
- 1.500 nye tokens tilføjet efter hvert trin
- Den komplette akkumulerede historik gensendt i hver anmodning
- 12 samlede modelkald
Inputtet ved trin n er:
Input at step n = 4,000 + 1,500 × (n - 1)
Det kumulative input på tværs af 12 kald er:
Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens
Det sidste kald indeholder kun 20,500 inputtokens, men hele kørslen behandler 147,000 kumulative inputtokens.
Anvend nu to kontroller:
- Cach det stabile præfiks på 4.000 tokens efter det første kald.
- Komprimér historikken efter trin seks til en tilstandssummering på 2.500 tokens.
| Scenario | Uncached input | Cached input | Total processed input | Change |
|---|---|---|---|---|
| Full history on every step | 147,000 | 0 | 147,000 | Baseline |
| Stable prefix cached | 103,000 | 44,000 | 147,000 | Same volume, cheaper mix |
| Cache plus compaction | 64,000 | 44,000 | 108,000 | 26.5% fewer processed tokens |
Dette er en planlægningsberegning, ikke en udbyderbenchmark.
Den antager, at hver anmodning inkluderer den komplette akkumulerede historik. Agenter, der selektivt konstruerer tilstand, opsummerer gamle beskeder eller kun henter relevant information, kan følge en anden omkostningskurve.
Regel for omkostningsvækst: Mål kumulativt input på tværs af hele kørslen. Den endelige kontekststørrelse repræsenterer ikke det samlede antal behandlede tokens.
Which Metrics Reveal Agent Token Waste?
Begynd ikke med at skifte modeller. Identificér først hvor arbejdsgangen bruger tokens uden at forbedre resultatet.
Registrér disse felter for hvert agenttrin:
| Field | Why it matters |
|---|---|
run_id, step_id, parent_step_id | Genskaber agent- og underagenttræet |
| Rendered input tokens | Viser hvordan kontekst vokser mellem kald |
| Cached and uncached input | Adskiller genbrug fra ny kontekst |
| Output and reasoning tokens | Identificerer dyre genereringstrin |
| Tool result size and retained tokens | Viser hvor meget rå evidens går ind i senere prompts |
| Retry reason and attempt number | Identificerer gentagne fejl |
| Compaction tokens before and after | Måler faktisk kontekstreduktion |
| Worker ID and returned tokens | Afslører duplikeret underagentarbejde |
| Accepted, rejected, or escalated result | Knytter omkostning til opgavekvalitet |
Den primære metrik bør være:
cost per successful task
= total workflow cost
/ accepted tasks
En billigere kørsel er ikke en forbedring, når den forårsager flere mislykkede opgaver, gentagne værktøjer eller menneskelig korrektion.
Fire agent-specifikke metrikker hjælper med at lokalisere problemet.
Context Amplification
context amplification
= cumulative input tokens
/ final-step input tokens
En høj værdi indikerer, at tidligere kontekst er blevet behandlet gentagne gange.
Tool Retention Ratio
tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools
Et højt forhold kan indikere, at agenten bærer for meget rå evidens mellem trin.
Retry Tax
retry tax
= retry and repair cost
/ total workflow cost
Reasoning Share
reasoning share
= reasoning-token cost
/ total model cost
Mål hver arbejdsbelastning separat. Forsknings-, kode-, browser- og kundesupportagenter bør ikke dele én global baseline.
Six Ways to Reduce AI Agent Token Costs
1. Set a Budget for the Complete Run
En outputgrænse pr. anmodning kontrollerer ikke en flertrins agent.
Sæt run-niveau grænser for:
- Samlet antal modeltrin
- Kumulativt input og output
- Værktøjskald og størrelse på værktøjsresultater
- Genforsøg efter fejlkategori
- Underagenter
- Samlet forløbet tid eller estimeret omkostning
Det følgende udbyderneutrale Python-eksempel evaluerer kørslen før hvert modelkald:
from dataclasses import dataclass
from enum import Enum
class Action(str, Enum):
CONTINUE = "continue"
COMPACT = "compact"
STOP = "stop"
@dataclass(frozen=True)
class Budget:
max_steps: int = 12
max_input_tokens: int = 120_000
max_output_tokens: int = 18_000
compact_at: float = 0.80
@dataclass
class Usage:
steps: int = 0
input_tokens: int = 0
output_tokens: int = 0
def evaluate_budget(usage: Usage, budget: Budget) -> Action:
if (
usage.steps >= budget.max_steps
or usage.input_tokens >= budget.max_input_tokens
or usage.output_tokens >= budget.max_output_tokens
):
return Action.STOP
input_ratio = usage.input_tokens / budget.max_input_tokens
if input_ratio >= budget.compact_at:
return Action.COMPACT
return Action.CONTINUE
Kør checket før hver modelanmodning og opdatér Usage ud fra udbyderens rapporterede tokendata.
Ved 80% af inputbudgettet: komprimér tilstand eller indsnævr næste værktøjsforespørgsel. Ved 100%: stop med en struktureret årsag.
Almindelig fejl: At begrænse hvert svar, mens ubegrænsede trin, værktøjer og genforsøg tillades.
2. Filter Tool Results Before They Enter the Transcript
Returnér kun den evidens, der kræves til agentens næste beslutning.
Tilføj ikke hele:
- Webside
- Logfil
- Repositorietræ
- Databaserespons
- Terminalsessions
- API-payload
når næste trin kun har brug for få felter.
Et søgeværktøj kunne returnere:
{
"source_id": "search_17",
"title": "Relevant page title",
"url": "https://example.com/page",
"relevant_passage": "A short evidence block"
}
Gem det fulde artefakt uden for prompten og hent et smallere afsnit senere.
Regel for værktøjsfiltrering: Returnér felterne, der er nødvendige for den næste beslutning—ikke alle felter, der måske bliver nyttige senere.
Almindelig fejl: At trunkere de første 1.000 tegn af en JSON-payload. Det kan ødelægge strukturen eller fjerne de poster, agenten faktisk behøver.
Pars payloaden først, vælg felter strukturelt, begræns arrays og serialisér derefter gyldig JSON.
3. Compact Operational State, Not Just Conversation Text
Komprimering skal bevare den information, der er nødvendig for at fortsætte opgaven, samtidig med at historik, der ikke længere påvirker næste handling, fjernes.
En nyttig komprimeret tilstand indeholder:
- Brugerens mål og succeskriterier
- Beslutninger, der allerede er truffet
- Verificerede fakta og kilde-ID'er
- Filer eller poster der er ændret
- Mislykkede tilgange
- Åbne spørgsmål
- Den næste handling
- Sikkerheds- og outputbegrænsninger
Den skal ikke genfortælle hele samtalen.
OpenAI dokumenterer komprimering for langvarige interaktioner i Responses API. Anthropic tilbyder kontekststyringskontroller til at rydde eller opsummere ældre indhold. Disse implementeringer varierer, så verificér de aktuelle udbyderfelter før integration.
Regel for komprimering: Bevar beslutninger og uafsluttet arbejde. Fjern fortælling og evidens, der kan hentes igen.
Almindelig fejl: At droppe kilde-ID'er, ændrede filnavne, afviste tilgange eller uafklarede begrænsninger.
Efter at have tilføjet komprimering, mål om agenten gentager søgninger eller værktøjskald. En kortere prompt er ikke billigere, hvis agenten skal genopbygge tabt tilstand.
4. Keep the Reusable Prefix Stable
Agentprompter indeholder ofte store genbrugelige blokke:
- Systeminstruktioner
- Værktøjsskemaer
- Sikkerhedspolitikker
- Outputformater
- Delt referencemateriale
- Repositorie- eller produktinstruktioner
Placer disse stabile elementer før anmodningsspecifikke data:
1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data
Undgå at placere tidsstempler, anmodnings-ID'er, sessiondata eller ofte ændrede værdier tæt på begyndelsen.
Caching er mest nyttigt, når præfikset er langt, stabilt og genbrugt. Det sparer måske ikke penge for korte sessioner eller ofte ændrede prompter.
Almindelig fejl: At optimere for cache-hit-rate uden at måle omkostningen ved cache-skriv, -læs og -lagring.
For en bredere sammenligning af udbyderprompt-caching, præcis svarkaching og semantisk kaching, se Sådan reducerer du AI API-omkostninger.
5. Prevent Retries From Replaying the Same Context
Et genforsøg er endnu et agenttrin, ofte med den samme store prompt.
Gentag ikke en mislykket anmodning uden at ændre fejårsagen.
| Failure | Better response |
|---|---|
| Invalid structured output | Return the validation error and retry once |
| Tool timeout | Retry an idempotent operation once, then stop or use a fallback |
| Context overflow | Compact state or retrieve less evidence |
| Repeated tool call | Deduplicate using an operation hash |
| Rate limit | Back off or use a tested fallback route |
| Low-confidence result | Request missing information or escalate |
Brug idempotency-nøgler til operationer med bivirkninger som betalinger, e-mails, udrulninger og database-skriv.
Almindelig fejl: At retry'e en rate-limited model flere gange, mens hele agentkonteksten gensendes ved hvert forsøg.
Spor retry-omkostning efter fejrtype, så teamet kan fikse den største løkke først.
6. Limit Reasoning and Subagents to Steps That Need Them
Ikke hvert agenttrin kræver dyb ræsonnering.
Ekstraktion, formatering, klassifikation, validering og rutinemæssigt værktøjsvalg kan ofte bruge lavere ræsonneringsindsats og kompakt struktureret output.
Reserver højere ræsonneringsindsats til opgaver som:
- Kompleks planlægning
- Vanskelig kodning
- Multidokument-syntese
- Tvetydige beslutninger
- Genopretning efter fejlet eksekvering
Ræsonneringsregel: Brug den laveste ræsonneringsindsats, der bevarer andelen af accepterede opgaver.
Underagenter kræver også en klar grænse. Giv hver worker:
- En snæver opgave
- Et opgavespecifikt kontekstudsnit
- En værktøjs-allowlist
- Et tokenbudget
- Et kompakt outputskema
Root-agenten har typisk brug for fund, evidens-ID'er, sikkerhed (confidence) og uafklarede problemer—ikke workerens fulde transkript.
Underagent-regel: Parallelisér uafhængigt arbejde, ikke duplikeret kontekst.
Almindelig fejl: At sende hele root-agentens historik til hver worker, før en snæver opgave er tildelt.
Which Optimization Should You Apply First?
Brug agenttelemetri til at vælge den første intervention.
Tærsklerne nedenfor er undersøgelsestriggere, ikke universelle standarder.
| Observed signal | Start here |
|---|---|
| Context amplification is high | Compact history and selectively retrieve state |
| Tool output dominates the prompt | Filter fields and store full artifacts externally |
| Retry tax is high | Fix validation, timeouts, and repeated tool calls |
| Reasoning share is high | Lower effort on routine steps |
| Subagents repeat the same evidence | Narrow worker scopes and context slices |
| Cached input remains low | Stabilize the reusable prefix |
| Costs remain high after loop cleanup | Compare lower-cost model routes |
En sikker implementeringsrækkefølge er:
- Mål kumulativt input, værktøjsfastholdelse, genforsøg og ræsonnering.
- Tilføj hårde grænser for trin, værktøjer, genforsøg og samlede tokens.
- Filtrér store værktøjsresultater.
- Komprimér ældre tilstand ved en målt tærskel.
- Stabiliser det genbrugelige promptpræfiks.
- Sammenlign modelruter først efter, at agentløkken er ryddet op.
Ændr én stor variabel ad gangen og afspil det samme evalueringssæt.
Sammenlign:
- Andel accepterede opgaver
- Omkostning pr. vellykket opgave
- Kumulativt input
- Antal værktøjs-kald
- Retry-omkostning
- Ræsonneringsandel
- p50 og p95 latenstid
- Tid til menneskelig gennemgang
Rul ændringer tilbage, der sparer tokens ved at reducere opgavekvalitet eller fjerne nødvendig evidens.
Test Agent Workflows With CometAPI
Før du kører en multimodel-evaluering, brug CometAPIs prisside og vejledning i omkostningsestimering til at estimere input-, output-, cachet-token- og ræsonneringsomkostninger.
Brug derefter modelkataloget til at identificere egnede ruter og Quickstart til at konfigurere en OpenAI-kompatibel klient.
Til produktions-fallback, følg CometAPIs vejledning i modelfallback for at skifte ruter uden at gentage fuldførte værktøjsopkald eller kassere valideret tilstand.
Ensartet adgang forenkler modelsammenligning og fallback-integration. Tokenbudgetter, komprimering, validering, værktøjsfiltrering, retry-grænser og acceptkriterier hører stadig hjemme på applikationsniveau.
FAQ
Why do AI agents use more tokens than chatbots?
Agenter foretager flere modelkald og kan gensende tidligere beskeder, værktøjsresultater, instruktioner og mellemliggende tilstand ved hvert trin. Det får tidligere kontekst til at blive behandlet gentagne gange.
Does prompt caching reduce context-window usage?
Nej. Prompt-caching kan reducere den effektive pris eller latenstid for gentaget input, men cachede tokens udgør stadig en del af den behandlede kontekst. Brug komprimering, filtrering eller selektiv hentning for at reducere promptstørrelsen.
When should an AI agent compact its context?
Komprimér før kontekstvækst begynder at påvirke omkostning, latenstid eller tilgængelig outputplads. Verificér, at den komprimerede tilstand bevarer beslutninger, evidens-ID'er, ændrede filer, åbne spørgsmål og sikkerhedsbegrænsninger.
Do subagents reduce token costs?
Ikke automatisk. De kan reducere forløbet tid eller forbedre dækning for uafhængigt arbejde, men duplikeret kontekst og overlappende analyse øger ofte det samlede tokenforbrug.
What is the best metric for AI agent cost optimization?
Brug omkostning pr. vellykket opgave som primær metrik. Diagnostisér den med kumulativt input, kontekstforstærkning, værktøjsfastholdelse, retry-omkostning, ræsonneringsandel, latenstid og tid til menneskelig gennemgang.