L’ANALISI
LiteLLM 1.103.5 corregge le tool call perse nel bridge Responses
Analisi pratica di LiteLLM 1.103.5: tool call nel bridge Responses, choices[0], indici multipli, compatibilità client, limiti del backport e checklist di aggiornamento.
In breve: LiteLLM 1.103.5 evita che un agente ignori una chiamata a strumento quando una risposta della Responses API contiene più messaggi prima della function call. Il bridge ora restituisce un solo `choices[0]` con testo e tool call insieme e assegna indici 0, 1 e successivi alle chiamate multiple. È una patch operativa per chi usa endpoint Chat Completions davanti a provider instradati sulla Responses API.
Il difetto corretto nella linea stabile
Dalla versione 1.97.0 una risposta bridged con più elementi poteva diventare più scelte separate. La prima conteneva testo e `finish_reason: stop`, mentre la tool call finiva in una scelta successiva. Molti framework agentici leggono soltanto `choices[0]` e quindi proseguivano senza eseguire lo strumento.
Come cambia la forma della risposta
La patch unisce i messaggi testuali, conserva reasoning e annotazioni, sposta correttamente gli offset delle citazioni e inserisce le tool call nella stessa scelta con `finish_reason: tool_calls`. Il percorso streaming era già concentrato sull’indice zero e non è il centro della regressione.
Più strumenti senza collisione di indice
Nel secondo difetto due chiamate nello stesso turno potevano ricevere entrambe `tool_calls[].index: 0`. Un client che usa l’indice come chiave poteva sovrapporre risultati o argomenti. La conversione ora mantiene l’indice ricevuto, producendo 0, 1 e così via come il formato Chat Completions nativo.
Chi è direttamente interessato
Il rischio riguarda proxy LiteLLM che espongono `/v1/chat/completions` ma inoltrano la richiesta a un endpoint `/responses`, in particolare con modelli che emettono messaggi intermedi seguiti da una o più function call. I client che analizzano tutte le scelte possono aver mascherato il primo difetto, ma restano esposti alla collisione degli indici.
Compatibilità e possibile cambiamento osservabile
Dopo l’upgrade i chiamanti che si aspettavano più scelte dal bridge ne ricevono una sola ricomposta. Questo comportamento è più vicino alle aspettative dei framework agentici comuni, ma va verificato se codice interno leggeva esplicitamente `choices[1]`, separava commentary e risposta finale o applicava logiche proprie alle citazioni.
Cosa prova e cosa non prova il rilascio
I pull request includono casi riproducibili e test sul proxy per forme con messaggi multipli, reasoning e due tool call. Il backport riporta centinaia di test unitari superati, ma dichiara anche l’assenza, in quel momento, di una prova live finale sulla linea stabile con un deployment reale. Non è quindi una garanzia automatica per ogni provider e harness.
Condizioni e limitazioni
La correzione riguarda il bridge non-streaming e soprattutto i client che leggono solo `choices[0]` o associano i risultati tramite l’indice della tool call. Il pull request di backport dichiara test unitari completati, ma segnala che la prova live contro un proxy stabile e un deployment reale non era ancora stata eseguita; prima dell’upgrade servono quindi test di compatibilità sul proprio harness.
Checklist pratica
- Registrare la versione LiteLLM attuale e verificare se il traffico Chat Completions viene convertito verso la Responses API.
- Riprodurre un turno non-streaming con due messaggi intermedi e una tool call, controllando che tutto arrivi in `choices[0]`.
- Provare due tool call nello stesso turno e verificare indici distinti 0 e 1, ID e argomenti completi.
- Confrontare lo stesso scenario in streaming per escludere differenze nel parser del client.
- Controllare codice che leggeva `choices[1]` o dipendeva da più scelte generate dal bridge.
- Aggiornare prima in staging, conservare payload e log sanitizzati e predisporre il rollback alla versione precedente.
- Eseguire almeno un test con il provider e il framework agentico realmente usati in produzione.