Salta ai contenuti

Gestisci i costi

Questa guida mostra come capire quanto costano le esecuzioni degli agenti e come imporre un limite a un’esecuzione autonoma.

Ogni esecuzione di un agente scrive un registro delle esecuzioni che riporta i suoi token di input, i token di output, i token di ragionamento, i token letti dalla cache e scritti nella cache, un costo stimato in centesimi e il costo degli eventuali subagenti che ha generato.

I prezzi provengono dal catalogo models.dev, che serve solo ad arricchire l’elenco dei modelli con prezzo e finestra di contesto — mai come fonte di id dei modelli. Un modello che il catalogo non riesce a prezzare registra $0 e le esecuzioni a costo zero sono escluse dal riepilogo Utilizzo e costo. Un modello Ollama locale non mostra quindi alcuna spesa, anche se i suoi conteggi di token vengono comunque registrati. Un piano a tariffa fissa (kimi-code, un abbonamento Claude) si comporta allo stesso modo solo quando il catalogo non ha un prezzo per il modello servito; se ce l’ha, l’esecuzione viene comunque stimata a quelle tariffe. Nell’ambito di una catena di fallback l’esecuzione viene prezzata sul modello che l’ha effettivamente servita, non su quello richiesto.

Ci si arriva dal piè di pagina della barra laterale → Osservabilità. Si apre per prima la scheda Utilizzo (totali dei token dall’inizio); passa a Panoramica — la seconda scheda — per la superficie principale dei costi:

  • Un selettore dell’intervallo di tempo: ultime 24 ore, ultimi 7 giorni, ultimi 30 giorni o tutto
  • Filtri a faccette su agente, modello, stato e ruolo, sotto forma di chip rimovibili
  • Una striscia di KPI: esecuzioni totali, costo totale, tasso di errore, tasso di cache, token al secondo, latenza media e tempo al primo token, ciascuno con una variazione rispetto al periodo precedente (nascosta su «Tutto»)
  • Grafici di attività e costi, più una ripartizione del costo per ruolo che distribuisce la spesa tra l’agente principale, i suoi subagenti e il suo consulente
  • Una tabella per agente ordinata per costo, i primi dieci con un interruttore per mostrarli tutti. Toccando una riga si filtrano tutte le altre superfici su quell’agente
  • Il registro delle esecuzioni dettagliato, che aggancia un pannello della trascrizione per un’esecuzione selezionata

Il riquadro Utilizzo e costo di questa pagina mostra la spesa osservata negli ultimi sette giorni come un’unica cifra in dollari, con una ripartizione per fornitore e, quando un fornitore la pubblica, il tempo che manca all’azzeramento della prossima finestra di quota.

Impostazioni → Spazio di lavoro → Agenti → seleziona un agente → Log elenca le sue esecuzioni con stato, durata, orari di avvio e di completamento, PID e adapter. Questa scheda non mostra il costo — per quello usa la tabella per agente in Osservabilità → Panoramica.

Due comandi slash, digitati nel compositore di uno spazio, sono le uniche esecuzioni con un limite di spesa:

/goal ship the auth refactor --budget 20
/loop keep the flaky tests green
  • Ogni segmento di un’esecuzione /goal o /loop si ferma quando la sua spesa valorizzata raggiunge 500 centesimi ($5.00). All’80% di quella soglia il loop indirizza prima il modello a concludere e a lasciare un passaggio di consegne pulito, così non muore a metà attività.
  • Un intero obiettivo durevole è limitato a 5000 centesimi ($50.00) a meno che tu non passi --budget <dollars>. Il supervisore propaga il budget rimanente dell’obiettivo a ogni segmento, così un budget esplicito non viene mai superato di un segmento intero.
  • --days N aggiunge una scadenza a orologio e --max N un tetto al numero di esecuzioni. Entrambi sono facoltativi; senza di essi l’obiettivo è limitato solo dal costo.
  • Un obiettivo che tocca il suo muro si ferma in budgetExhausted e può essere ripreso solo aumentando il budget.

Poiché il limite si basa sul prezzo, un modello che il catalogo non riesce a prezzare non lo raggiunge mai. Un’esecuzione di questo tipo è limitata invece dalla protezione contro le ripetizioni in doom-loop, dalla resa del supervisore dopo tre errori consecutivi e da te.

Un messaggio in uno spazio, una menzione con @ o un passaggio di pipeline non hanno alcun limite di spesa. L’esecuzione termina quando il modello si ferma, quando la fermi tu o quando la protezione doom-loop la reindirizza.

Digita /compact nel compositore dello spazio. Il comando viene intercettato lato client e non arriva mai nella trascrizione; il server ripiega la cronologia più vecchia in un riepilogo ancorato e la conversazione prosegue sul contesto compattato.

La compattazione viene rifiutata mentre un agente è a metà turno e quando non c’è nulla di abbastanza vecchio da ripiegare. L’harness integrato compatta anche da solo man mano che la cronologia si avvicina alla finestra di contesto del modello.

Lo Sforzo di ragionamento di un agente (Impostazioni → Spazio di lavoro → Agenti) offre i livelli pubblicati dal modello selezionato. I livelli più alti consumano più token di ragionamento. Riserva i livelli massimi al lavoro che li richiede.

Il modello è un campo per agente, quindi un agente di formattazione o di triage può girare su un modello economico mentre un agente di architettura gira su uno costoso. Filtra per modello la tabella per agente in Osservabilità → Panoramica per vedere quale abbinamento ti sta davvero costando.

Cerca le esecuzioni con conteggi di token sproporzionati

Sezione intitolata “Cerca le esecuzioni con conteggi di token sproporzionati”

Apri il registro delle esecuzioni di Panoramica (le 50 esecuzioni filtrate più recenti) e il pannello della trascrizione su qualsiasi cosa insolita. Le cause comuni sono un prompt di sistema o una persona troppo lunghi, un contesto che avrebbe dovuto essere compattato e un’attività che avrebbe dovuto essere suddivisa in più attività più piccole.

Che cosa succede se un budget viene impostato dall’esterno

Sezione intitolata “Che cosa succede se un budget viene impostato dall’esterno”

Per completezza, se monthlyBudgetCents o una policy di budget viene scritto direttamente in una riga di un agente:

  • I budget vengono valutati dopo il completamento di un’esecuzione, non prima dell’invio. Un listener al completamento dell’esecuzione confronta la spesa dell’agente da inizio mese con il suo tetto.
  • Il superamento della soglia morbida (80% per impostazione predefinita) registra un incidente di avviso e genera un evento BudgetThresholdCrossed su cui puoi agganciare un trigger di pipeline.
  • L’esaurimento del budget registra un incidente bloccante, genera lo stesso evento e porta lo stato del ciclo di vita dell’agente su paused.
  • Il blocco pre-invio esiste, ma viene consultato solo dal reaper delle esecuzioni orfane e dal riconciliatore dei ticket in stallo quando pianificano il recupero — un invio normale non lo raggiunge mai e nulla nel percorso di invio controlla lo stato paused. L’unico segnale visibile è il badge del ciclo di vita nell’organigramma.