L’ANALISI
LLM 0.37: il blocco dei tool passa anche da reply
LLM 0.37 inoltra i callback di controllo in Response.reply(): il test offline confronta 0.36 e 0.37, senza chiamate a modelli remoti.
In breve: LLM 0.37 corregge un difetto nel percorso Response.reply(): i controlli before_call e after_call vengono passati all’esecuzione automatica dei tool e conservati per i turni successivi. Il cambiamento riguarda la libreria Python e la sua CLI, non un nuovo modello AI. Per chi usa questo metodo con tool locali, la verifica utile è osservare le azioni eseguite, non soltanto il testo prodotto dal modello. Note ufficiali di LLM 0.37.
Verifica del 3 novembre 2026: release, issue e patch ufficiali rilette, più riuso della prova eseguita dall’assistente nello stesso mattino in due ambienti isolati. Sono stati controllati gli hash di script e risultati. Francesco non ha eseguito né filmato questo test; non sono state chiamate API di modelli remoti.
Che cosa non veniva bloccato prima della correzione?
L’issue descrive una Response ottenuta da conversation.prompt() con i callback della conversazione già associati. Proseguendo con response.reply(), l’esecuzione automatica dei tool pendenti non riceveva quei controlli. Un callback before_call configurato per rifiutare un tool tramite CancelToolCall non veniva quindi invocato in quel percorso. Anche la risposta restituita perdeva i callback, rendendo rilevante il controllo dei turni successivi. Il rapporto distingue questo comportamento da Conversation.chain(), che applicava i callback: non consente di estendere il difetto a qualunque agente, framework o modalità di esecuzione. Issue 1835: riproduzione del difetto e percorso interessato.
Come cambia Response.reply() nella versione 0.37?
La PR 1836 inoltra before_call e after_call a execute_tool_calls e li assegna alla risposta successiva. La modifica copre sia la versione sincrona sia quella asincrona. I test aggiunti nel repository includono un tool rifiutato, un tool consentito e un secondo turno di reply. Il merge è del 2 novembre alle 23:07 UTC; la release stabile 0.37 segue alle 23:49:30 UTC, già 3 novembre in Italia. L’issue era aperta dal 29 ottobre: il fatto nuovo è la disponibilità della correzione nella release, non la scoperta di una nuova vulnerabilità oggi. PR 1836: callback nei reply sincroni e asincroni.
Che cosa ha verificato il confronto tra 0.36 e 0.37?
L’assistente ha eseguito la stessa fixture con Python 3.13.15 e dipendenze uguali salvo LLM. Per ogni versione ci sono tre ripetizioni sincrone e tre asincrone. Con 0.36 il tool rifiutato compare tra le azioni in tutti e sei i casi; con 0.37 in nessuno. In entrambe le versioni le due chiamate al tool consentito mantengono i risultati attesi. La versione corretta registra i callback e mantiene il controllo nei due follow-up osservati. Il modello è simulato e deterministico: serve a produrre tool call ripetibili mentre viene esercitato il codice reale della libreria. Le sole azioni modificano liste in memoria. PR 1836: callback nei reply sincroni e asincroni.
Come verificare il proprio percorso senza azioni rischiose?
Prima di aggiornare un’applicazione, identificare il metodo che esegue davvero i tool: chain, reply o un ciclo scritto dall’applicazione non sono intercambiabili. In un ambiente separato si può ripetere un caso minimo con due funzioni innocue, una consentita e una rifiutata dal callback, registrando le chiamate effettive. Dopo il primo reply occorre continuare almeno un altro turno e controllare che il rifiuto resti applicato e il tool consentito funzioni. Per l’aggiornamento si può fissare llm==0.37 nell’ambiente di test e controllare la versione installata; il passaggio in produzione richiede le regressioni della propria applicazione. Non è necessario provare con invii, cancellazioni o credenziali reali. LLM 0.37: note ufficiali della release.
Condizioni e limitazioni
Prova offline con modello simulato, codice reale della libreria e marcatori innocui in memoria. I dodici casi sono ripetizioni della stessa fixture, non un benchmark di modelli, una stima statistica di affidabilità o una certificazione di sicurezza. Nessun invio, cancellazione, dato personale o aggiornamento produttivo è stato usato nel test.
Checklist pratica
- Individua dove l’applicazione usa Response.reply() ed esegue automaticamente i tool.
- Fissa la versione della libreria in un ambiente isolato e annota le dipendenze.
- Usa solo due tool innocui in memoria, uno consentito e uno rifiutato da before_call.
- Registra sia i callback sia le funzioni davvero eseguite, non soltanto la risposta testuale.
- Prosegui con un secondo turno e controlla che i callback restino applicati.
- Conferma che i tool consentiti funzionino ancora prima di valutare l’aggiornamento produttivo.