È ora delle stringhe di connessione llm://

Semplifica la configurazione di modelli e provider con gli URL llm://

Aggiornamento: questo articolo ha portato a un Internet-Draft per lo schema URI llm:// e al relativo pacchetto npm llm-strings. L’implementazione è disponibile anche su GitHub.

Ricordate i bei vecchi tempi in cui collegarsi a un database significava destreggiarsi tra un assortimento eterogeneo di variabili d’ambiente?

Era una torre di configurazione delicata. DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME… oppure aspettate, era DB_USERNAME? È DB_PASS o DB_PWD? Questa volta servono i prefissi PG_*? E dove diavolo si imposta il timeout?

Una fragile casa di carte, pronta a far crollare la build di produzione perché avevate dimenticato di scrivere HOST in maiuscolo.

Poi a qualcuno venne la brillante idea di usare semplicemente un URL¹:

postgres://user:pass@host:5432/dbname

Un’unica stringa. Tutto quello che serve. Analizzabile universalmente. Portabile. Oso dirlo… elegante?

Perché allora trattiamo gli LLM come se fossimo nel 1999?

L’esplosione delle variabili d’ambiente

In questo momento il mio file .env sembra un cimitero di chiavi API abbandonate. OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY. E non fatemi nemmeno iniziare con Azure: servono un endpoint, un nome di deployment, una versione API e una chiave solo per dire «ciao».

Non è solo brutto; è attrito. Ogni volta che voglio cambiare modello o provare un nuovo provider, devo riscrivere il codice di inizializzazione, andare a caccia nella documentazione dei nomi specifici dei parametri e aggiungere altre tre righe alla configurazione dell’ambiente.

E se semplicemente… rubassimo prendessimo in prestito l’idea degli URL per i database?

Introduciamo le stringhe di connessione per gli LLM

Immaginate di configurare l’intera interfaccia del modello con una sola riga:

llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

Anatomia di una stringa di connessione per LLM

Lo schema è llm://. L’host è l’URL di base dell’API del provider. Il percorso è il nome del modello. I parametri di query gestiscono tutte le opzioni di runtime che di solito ingombrano il codice.

Serve l’autenticazione? Ottimo, aggiungila.

Proprio come con postgres://, possiamo incorporare direttamente l’autenticazione:

llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

Nota: sì, inserire le credenziali negli URL può rappresentare un rischio per la sicurezza se li incolli nei log pubblici. Ma i moderni servizi di logging sono piuttosto bravi a ripulire questi pattern e, onestamente, tratti davvero meglio il tuo file .env? Verifica, sanifica e usa con cautela.

Resilienza? Perché diavolo no.

Molte librerie per database supportano il failover round-robin specificando più host. Perché i nostri agenti AI non dovrebbero avere la stessa affidabilità?

llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

Quella s in llms:// non è un refuso. È il plurale. Se primary.gpt si blocca, il client ritenta automaticamente con backup.gpt. Senza bisogno di complesse logiche di routing.

Una stringa con tutto: dalla tua autenticazione al tuo endpoint, fino ai tuoi iperparametri.

Formati alternativi

Non sono sposato con llm://. Lo schema specifico conta meno dello standard in sé.

Posso immaginare un mondo in cui usiamo schemi specifici per provider per essere più concisi, mantenendo però la struttura standard:

ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

A prescindere dalla sintassi esatta, i vantaggi fondamentali sono innegabili:

1. Portabilità: copia e incolla l’intera configurazione da uno script locale a un worker cloud.
2. Adatto alla CLI: passa un singolo argomento ai tuoi script. my-agent --model "llm://..." è meglio di my-agent --model gpt-4 --temp 0.7 --key $KEY --host ....
3. Indipendenza dal linguaggio: ogni linguaggio di programmazione ha un parser URL robusto. Validazione, parsing e sanificazione sono inclusi.

Il mondo dei database ci ha messo decenni per capirlo.
La buona notizia è che, con i tempi dell’AI, è successo solo circa mezzo vibe-anno fa.

Il verdetto

Non ci serve un altro complesso standard di configurazione né un nuovo file manifest basato su YAML. Dobbiamo solo usare lo strumento che funziona per il resto di Internet da trent’anni.

Smettiamola di reinventare la ruota e iniziamo a trattare le nostre connessioni LLM con lo stesso rispetto che riserviamo ai database. Il tuo file .env — e la tua sanità mentale — ti ringrazieranno.