Gå til innholdet

Administrer kostnader

Denne veiledningen viser hvordan du ser hva agentkjøringer koster, og hvordan du setter et tak på en autonom kjøring.

Hver agentkjøring skriver en kjørelogg som inneholder inndatatokens, utdatatokens, resonneringstokens, bufferleste og bufferskrevne tokens, en estimert kostnad i cent og kostnaden for eventuelle underagenter den startet.

Prisene kommer fra katalogen til models.dev, som bare brukes til å berike modellisten med pris og kontekstvindu — aldri som kilde til modell-id-er. En modell katalogen ikke kan prise, registrerer $0, og kjøringer uten kostnad holdes utenfor Bruk og kostnad-sammendraget. En lokal Ollama-modell viser derfor ikke noe forbruk i det hele tatt, selv om tokentallene fortsatt registreres. En fastprisordning (kimi-code, et Claude-abonnement) er likestilt bare når katalogen ikke har en pris for modellen som betjente kjøringen; har den det, estimeres kjøringen likevel etter disse satsene. Under en reservekjede prises kjøringen etter modellen som faktisk betjente den, ikke den som ble forespurt.

Du kommer dit fra nederst i sidepanelet → Observabilitet. Fanen Bruk åpnes først (tokentotaler for hele levetiden); bytt til Innsikt — den andre fanen — for den viktigste kostnadsflaten:

  • En tidsvelger: siste 24 timer, siste 7 dager, siste 30 dager eller all tid
  • Fasetterte filtre på agent, modell, status og rolle, som brikker du kan lukke
  • En KPI-stripe: totale kjøringer, total kostnad, feilrate, cache-rate, tokens per sekund, gjennomsnittlig latenstid og tid til første token, hver med en endring mot forrige periode (skjult på «All tid»)
  • Diagrammer for aktivitet og kostnad, pluss en kostnad etter rolle-oversikt som deler forbruket mellom hovedagenten, underagentene og rådgiveren
  • En tabell per agent sortert etter kostnad, de ti øverste med en vis-alle-bryter. Å trykke på en rad filtrerer alle andre flater til den agenten
  • Den detaljerte kjøreloggen, som fester en transkriptskuff for en valgt kjøring

Kortet Bruk og kostnad på denne siden viser de siste sju dagene med observert forbruk som ett dollartall, med en oversikt per leverandør og, når en leverandør oppgir det, hvor lang tid det er til neste kvotevindu nullstilles.

Innstillinger → Arbeidsområde → Agenter → velg en agent → Logger viser kjøringene dens med status, varighet, start- og fullføringstider, PID og adapter. Denne fanen viser ikke kostnad — bruk tabellen per agent i Observabilitet → Innsikt til det.

To skråstrekkommandoer, skrevet i skrivefeltet til et område, er de eneste kjøringene med et kostnadstak:

/goal ship the auth refactor --budget 20
/loop keep the flaky tests green
  • Hvert segment av en /goal- eller /loop-kjøring stopper når det prisede forbruket når 500 cent ($5.00). Ved 80 % av dette styrer løkken først modellen til å runde av og legge igjen en ryddig overlevering, slik at den ikke dør midt i en oppgave.
  • Et helt varig mål er begrenset til 5000 cent ($50.00) med mindre du oppgir --budget <dollars>. Supervisoren trer målets gjenværende budsjett inn i hvert segment, slik at et eksplisitt budsjett aldri overskrides med et helt segment.
  • --days N legger til en frist i veggklokketid, og --max N et tak på antall kjøringer. Begge er valgfrie; uten dem er målet bare begrenset av kostnad.
  • Et mål som treffer veggen sin, stopper ved budgetExhausted og kan bare gjenopptas ved å heve budsjettet.

Siden taket er priset, når en modell katalogen ikke kan prise, aldri fram til det. En slik kjøring begrenses i stedet av vakten mot gjentakelsesløkker, av at supervisoren gir opp etter tre påfølgende feil, og av deg.

En melding i et område, en @-nevning eller et pipeline-steg har ikke noe kostnadstak. Kjøringen avsluttes når modellen stopper, når du stopper den, eller når vakten mot gjentakelsesløkker styrer den.

Skriv /compact i skrivefeltet til området. Kommandoen fanges opp på klientsiden og havner aldri i transkriptet; serveren folder eldre historikk inn i et forankret sammendrag, og samtalen fortsetter på den komprimerte konteksten.

Komprimering avvises mens en agent er midt i en tur, og når det ikke finnes noe gammelt nok å folde. Det innebygde harnesset komprimerer også av seg selv når historikken nærmer seg modellens kontekstvindu.

En agents Resonneringsinnsats (Innstillinger → Arbeidsområde → Agenter) tilbyr de nivåene den valgte modellen oppgir. Høyere nivåer bruker flere resonneringstokens. Spar de øverste nivåene til arbeid som trenger dem.

Modell er et felt per agent, så en formaterings- eller prioriteringsagent kan kjøre på en billig modell mens en arkitekturagent kjører på en dyr en. Filtrer tabellen per agent i Observabilitet → Innsikt på modell for å se hvilken kombinasjon som faktisk koster deg penger.

Se etter kjøringer med uforholdsmessig høye tokentall

Seksjon med tittelen «Se etter kjøringer med uforholdsmessig høye tokentall»

Åpne kjøreloggen i Innsikt (de 50 nyeste filtrerte kjøringene) og transkriptskuffen på alt uvanlig. De vanligste årsakene er en for lang systemprompt eller persona, kontekst som burde vært komprimert, og en oppgave som burde vært flere mindre.

Hva som skjer hvis et budsjett settes utenom normalen

Seksjon med tittelen «Hva som skjer hvis et budsjett settes utenom normalen»

For fullstendighetens skyld: hvis monthlyBudgetCents eller en budsjettpolicy skrives direkte til en agentrad:

  • Budsjetter vurderes etter at en kjøring er fullført, ikke før utsending. En lytter på kjøringsfullføring sammenligner agentens forbruk så langt i måneden mot taket.
  • Å krysse den myke terskelen (80 % som standard) registrerer en varselhendelse og utløser en BudgetThresholdCrossed-hendelse du kan henge en pipeline-utløser på.
  • Å bruke opp budsjettet registrerer en hard hendelse, utløser den samme hendelsen og vipper agentens livssyklusstatus til paused.
  • Blokkeringen før utsending finnes, men konsulteres bare av opprydderen for foreldreløse kjøringer og avstemmeren for strandede saker når de planlegger gjenoppretting — en vanlig utsending når den aldri, og ingenting i utsendingsbanen sjekker den pausede statusen. Det eneste synlige signalet er livssyklusmerket i organisasjonskartet.