Passa al contenuto principale

Budget e loop

Perché è il ledger, non un contatore in memoria, a decidere quando un flow deve fermarsi o chiedere a una persona.

Budget​

Ogni chiamata al modello e ogni tool call finiscono nel ledger del ticket: token, costo e tempo. Il budget si confronta con il ledger prima di ogni chiamata al modello, contando anche i token che la chiamata successiva aggiungerebbe. Quando un turno lancia più tool call, parte quella che supera una soglia. Le altre aspettano la risposta.

Il blocco <budget> è volatile: il motore lo accoda dopo la cronologia, come ultimo messaggio della chiamata, e non lo scrive mai nella cronologia salvata. Il system prompt, i tool e la cronologia prima di esso mantengono un prefisso identico byte-a-byte tra le chiamate di un turno. Il provider può mettere in cache quel prefisso, e il turno lungo costa meno.

Il ledger registra anche i token di prompt serviti dalla cache del provider (cached_tokens). I totali del ticket mostrano separati i token in cache e quelli freschi (tokens_in - cached_tokens). Il costo non si ricalcola: resta quello riportato dal provider, dove un hit di cache è già scontato.

I loop guard​

Un turno che chiama lo stesso tool con gli stessi argomenti ancora e ancora è un loop. Nessuna dimensione di budget lo ferma prima che la sua soglia sia superata, e un loop di tool call economiche può non superarne nessuna. Il motore conta invece le tool call identiche consecutive.

  • dalla terza chiamata, il risultato del tool porta una nota. Chiede al modello di cambiare strategia, o di consegnare il miglior risultato che ha e dire cosa resta aperto.
  • alla quarta chiamata, il turno si mette in pausa per una persona con le stesse scelte di un artefatto rifiutato. retry dà al modello un'altra possibilità e azzera il conteggio. take_over ferma il nodo per una persona. close chiude il nodo.

Il conteggio è per attivazione. Si azzera appena la chiamata cambia, o una persona risponde.

Vedi anche​