OpenClaw dice che la richiesta all’LLM è andata in timeout

Una richiesta al modello andata in timeout è uno dei primi errori che si incontrano dopo aver passato OpenClaw a un modello locale, e le pagine di risoluzione dei problemi della documentazione le attribuiscono un breve elenco di cause. La maggior parte riguarda il backend locale: un grande modello che si carica a freddo, una finestra di contesto che l’hardware non regge, un host che risponde a curl ma non al Gateway. Due riguardano i provider ospitati: un rate limit travestito da 429 e un blocco a monte travestito da 403. Ecco ciascuna con la sua soluzione, nell’ordine in cui la documentazione suggerisce di provarle.

Le cause locali

• Un modello a freddo: i grandi modelli locali possono richiedere un primo caricamento lungo. Assegna al provider Ollama un timeout più lungo (l’esempio della documentazione è 300 secondi) e tieni il modello caricato tra un turno e l’altro con un parametro keep-alive nella voce del modello; la stessa impostazione allunga anche il timeout di connessione quando l’host è lento ad accettare connessioni.
• Una finestra di contesto troppo grande: molti modelli dichiarano contesti che l’hardware non riesce a gestire comodamente. Limita sia il budget di token di OpenClaw sia il contesto della richiesta nella voce del modello, per una latenza del primo token prevedibile.
• Un host che funziona con curl ma non con OpenClaw: verifica dalla macchina e dal runtime che eseguono il Gateway, perché un URL di base che dice localhost non punta da nessuna parte da dentro un container Docker, l’URL può contenere il suffisso compatibile con OpenAI che cambia il comportamento, l’host remoto può richiedere modifiche al firewall o al binding, e il modello può trovarsi sul daemon del portatile invece che su quello remoto.

I grandi modelli locali possono richiedere un primo caricamento lungo.

Il backend che supera i controlli e fallisce comunque

La pagina di risoluzione dei problemi dei provider ha un caso per un backend locale compatibile con OpenAI che risponde a piccole richieste dirette ma fallisce comunque le esecuzioni dell’agente: il trasporto probabilmente è corretto e il backend cede sulla forma più grande del prompt del runtime dell’agente, e l’esempio della documentazione è Gemma su alcune build di llama-server. Un messaggio di turno incompleto senza payload significa che il backend ha completato la richiesta ma non ha restituito testo visibile; OpenClaw riprova un turno del genere una volta. Se gli errori diminuiscono dopo aver disattivato gli strumenti ma non spariscono, gli schemi degli strumenti facevano parte del carico e il resto dipende dalla capacità del backend o da un bug.

Le cause lato provider

• Un 429 che dice che per il contesto lungo serve un utilizzo aggiuntivo: il modello Anthropic selezionato ha una finestra nativa da un milione di token, o una vecchia configurazione contiene ancora il flag legacy per il contesto lungo, e la credenziale non è idonea. Passa a una finestra standard, usa una credenziale idonea o una chiave API, e configura modelli di fallback così le esecuzioni continuano.
• Un 403 generico che dice che la richiesta è stata bloccata: non sempre è un problema di OpenClaw; può venire da una CDN, da un WAF, da una regola di gestione dei bot o da un reverse proxy davanti a un endpoint compatibile con OpenAI, quindi controlla lo stato generale, lo stato del Gateway e i log prima di cambiare la configurazione.
• L’URL sbagliato: il suffisso compatibile con OpenAI su un host Ollama rompe la chiamata agli strumenti e può far stampare a un modello il JSON degli strumenti come testo; la soluzione è l’URL nativo, senza il suffisso.

La guida a OpenClaw con Ollama è la pagina completa sui modelli locali, mentre, se il sintomo è il silenzio e non un timeout, la scala da seguire è la guida per quando OpenClaw non risponde.

Dove guardare

Per ognuna di queste cause si parte dagli stessi tre comandi che la documentazione ripete: seguire i log, controllare lo stato dei modelli e leggere la configurazione del modello. La guida ai log di OpenClaw spiega dove si trova il file e come seguirlo con tail.

Su Diali

Su Diali i modelli sono ospitati e i timeout li regoliamo noi, quindi la metà locale di questo elenco non si applica; la metà lato provider viene gestita dall’instradamento di fallback prima che una risposta vada persa. OpenClaw ospitato su Diali è l’assistente.

• Modello a freddo: un timeout del provider più lungo e un keep-alive.
• Troppo contesto: limita il budget e il contesto della richiesta.
• Un 429 o un 403 viene dal provider, non dal Gateway.