Hantera kostnader

Den här guiden visar hur du ser vad agentkörningar kostar och hur du sätter ett tak för en autonom körning.

Så registreras kostnader

Varje agentkörning skriver en körningslogg med sina indatatokens, utdatatokens, resonemangstokens, cachelästa och cacheskrivna tokens, en uppskattad kostnad i cent och kostnaden för eventuella subagenter som körningen startade.

Prissättningen kommer från katalogen models.dev, som bara används för att berika modellistan med pris och kontextfönster – aldrig som källa för modell-id:n. En modell som katalogen inte kan prissätta registreras som $0, och körningar utan kostnad utesluts från sammanställningen Användning och kostnad. En lokal Ollama-modell visar därför ingen utgift alls, även om dess tokenantal fortfarande registreras. Ett abonnemang med fast pris (kimi-code, en Claude-prenumeration) fungerar bara på samma sätt när katalogen saknar pris för den modell som betjänade körningen; om den har ett pris uppskattas körningen ändå efter de priserna. Under en reservkedja prissätts körningen efter den modell som faktiskt betjänade den, inte den som begärdes.

Se vad du gör av med

Observability → Insikter

Du når den via sidofältets sidfot → Observability. Fliken Användning öppnas först (totala tokens sedan start); växla till Insikter – den andra fliken – för den huvudsakliga kostnadsvyn:

En tidsväljare: senaste 24 timmarna, senaste 7 dagarna, senaste 30 dagarna eller all tid
Fasetterade filter över agent, modell, status och roll, som chips du kan ta bort
En KPI-rad: totalt antal körningar, total kostnad, felfrekvens, cachefrekvens, tokens per sekund, genomsnittlig latens och tid till första token, var och en med en förändring mot föregående period (dold vid ”All tid”)
Diagram för aktivitet och kostnad, plus en uppdelning av kostnad per roll som fördelar utgifterna mellan huvudagenten, dess subagenter och dess rådgivare
En tabell per agent sorterad efter kostnad, med de tio främsta och en växel för att visa alla. Om du trycker på en rad filtreras alla andra vyer till den agenten
Den detaljerade körningsloggen, som dockar en transkriptpanel för en vald körning

Inställningar → Server → Modellleverantörer

Kortet Användning och kostnad på den här sidan visar de senaste sju dagarnas observerade utgifter som en enda dollarsiffra, med en uppdelning per leverantör och, när en leverantör publicerar en sådan, hur lång tid det är kvar till nästa kvotfönster börjar om.

En enskild agents körningar

Inställningar → Arbetsyta → Agenter → välj en agent → Loggar listar dess körningar med status, varaktighet, start- och sluttider, PID och adapter. Den här fliken visar inte kostnad – använd tabellen per agent i Observability → Insikter för det.

Sätt ett kostnadstak för en autonom körning

Två slash-kommandon, som skrivs i en ytas meddelandefält, är de enda körningarna med ett kostnadstak:

/goal ship the auth refactor --budget 20
/loop keep the flaky tests green

Varje segment av en /goal- eller /loop-körning stoppar när dess prissatta utgift når 500 cent ($5.00). Vid 80 % av det styr loopen först modellen att varva ner och lämna en ren överlämning, så att den inte dör mitt i en uppgift.
Ett helt hållbart mål har ett tak på 5 000 cent ($50.00) om du inte anger --budget <dollars>. Målövervakaren trär in målens återstående budget i varje segment, så en uttrycklig budget överskrids aldrig med ett helt segment.
--days N lägger till en absolut tidsfrist och --max N ett tak för antalet körningar. Båda är valfria; utan dem begränsas målet bara av kostnaden.
Ett mål som når sin gräns stannar vid budgetExhausted och kan bara återupptas genom att höja budgeten.

Eftersom taket är prissatt når en modell som katalogen inte kan prissätta det aldrig. En sådan körning begränsas i stället av doom-loop-skyddet mot upprepningar, av att målövervakaren ger upp efter tre misslyckanden i följd – och av dig.

Ett meddelande i en yta, en @-nämning eller ett pipelinesteg har inget kostnadstak. Körningen tar slut när modellen stannar, när du stoppar den eller när doom-loop-skyddet styr om den.

Minska tokenanvändningen

Komprimera ett långt samtal

Skriv /compact i ytans meddelandefält. Kommandot fångas upp på klientsidan och hamnar aldrig i transkriptet; servern fogar samman äldre historik till en förankrad sammanfattning och samtalet fortsätter på den komprimerade kontexten.

Komprimering nekas medan en agent är mitt i en tur och när det inte finns något tillräckligt gammalt att foga samman. Den inbyggda harnessen komprimerar också på egen hand när historiken närmar sig modellens kontextfönster.

Välj resonemangsinsats medvetet

En agents Resonemangsinsats (Inställningar → Arbetsyta → Agenter) erbjuder de nivåer som den valda modellen publicerar. Högre nivåer gör av med fler resonemangstokens. Spara de högsta nivåerna till arbete som behöver dem.

Välj modell per agent

Modell är ett fält per agent, så en formaterings- eller triageagent kan köra på en billig modell medan en arkitekturagent kör på en dyr. Filtrera tabellen per agent i Observability → Insikter efter modell för att se vilken kombination som faktiskt kostar dig pengar.

Leta efter körningar med orimligt stora tokenantal

Öppna körningsloggen i Insikter (de 50 senaste filtrerade körningarna) och transkriptpanelen på allt ovanligt. De vanligaste orsakerna är en alltför lång systemprompt eller persona, kontext som borde ha komprimerats och en uppgift som borde ha varit flera mindre.

Vad som händer om en budget sätts utanför det vanliga flödet

För fullständighetens skull: om monthlyBudgetCents eller en budgetpolicy skrivs direkt till en agentrad:

Budgetar utvärderas efter att en körning har slutförts, inte före dispatch. En lyssnare på körningsslut jämför agentens utgifter sedan månadens början mot dess tak.
När den mjuka tröskeln passeras (80 % som standard) registreras en varningsincident och en BudgetThresholdCrossed-händelse utlöses, som du kan hänga en pipelinetrigger på.
När budgeten tar slut registreras en hård incident, samma händelse utlöses och agentens livscykelstatus flippar till paused.
Spärren före dispatch finns, men den används bara av städaren för föräldralösa körningar och avstämningen av strandsatta ärenden när återhämtning schemaläggs – en vanlig dispatch når den aldrig och inget i dispatchvägen kontrollerar den pausade statusen. Den enda synliga signalen är livscykelmärket i organisationsschemat.

Relaterade guider

Relaterade koncept

Livscykel för agentdispatch