Correction du délai d'attente OpenClaw LLM pour le chargement de modèle à froid

Problème : Délais d'attente des modèles froids à 60 secondes
Les utilisateurs ont signalé que les modèles locaux chargés à froid dans OpenClaw échouaient systématiquement après environ 60 secondes, malgré un délai d'attente général de l'agent défini bien plus élevé. Ce problème survenait également avec les modèles cloud via Ollama et parfois avec OpenAI Codex.
Le schéma d'échec typique :
- Les modèles fonctionnent s'ils sont déjà chauds
- Les modèles froids échouent vers ~60 secondes
- Les journaux mentionnent timeout / basculement intégré / statut : 408
- Le modèle de secours prend le relais
Configurations trompeuses
La source avertit que plusieurs options de configuration évidentes ne sont PAS la véritable solution et peuvent orienter les développeurs sur la mauvaise voie :
agents.defaults.timeoutSeconds- Exports
.zshrc LLM_REQUEST_TIMEOUT- Accuser immédiatement LM Studio / Ollama
Cause racine
Le problème provient du fait qu'OpenClaw possède un délai d'attente d'inactivité du LLM de l'embedded-runner distinct pour la période précédant l'émission du premier token en flux continu par le modèle.
Trace source trouvée dans :
src/agents/pi-embedded-runner/run/llm-idle-timeout.ts
Valeur par défaut :
DEFAULT_LLM_IDLE_TIMEOUT_MS = 60_000
Le chemin de configuration résout à partir de :
cfg?.agents?.defaults?.llm?.idleTimeoutSeconds
Donc le paramètre de configuration réel est :
agents.defaults.llm.idleTimeoutSeconds
La correction
Après tests, la configuration fonctionnelle est :
{
"agents": {
"defaults": {
"llm": {
"idleTimeoutSeconds": 180
}
}
}
}
Les tests ont montré qu'un appel froid à Gemma qui échouait auparavant vers 60 secondes a survécu au-delà de ce seuil et a finalement répondu avec succès sans basculement immédiat.
Configuration permanente recommandée
{
"agents": {
"defaults": {
"timeoutSeconds": 300,
"llm": {
"idleTimeoutSeconds": 300
}
}
}
}
La recommandation de 300 secondes tient compte du caractère imprévisible des modèles locaux, où les faux basculements sont plus problématiques qu'une attente plus longue pour des modèles véritablement froids.
📖 Lire la source complète : r/openclaw
👀 See Also

Construire avec Codex, exécuter avec OpenClaw : une séparation pratique qui fonctionne
Un développeur raconte comment il a surmonté sa frustration avec OpenClaw en construisant la logique d'automatisation avec Codex et en utilisant OpenClaw uniquement comme couche d'exécution — et comment Apple Messages via CarPlay a rendu l'expérience plus proche d'un assistant à la Jarvis.

Wtf.md et le rêve : deux concepts de workflow Claude qui méritent d'être explorés
Un développeur partage deux concepts pour Claude : Wtf.md pour stocker les erreurs de Claude, et Dreaming, l'idée de Karpathy pour la consolidation nocturne des sessions.

Comment réduire de 80 % les coûts de l'agent OpenClaw grâce au changement de modèle
Un utilisateur a suivi l'utilisation des tokens pendant 14 jours et a constaté que 67% des dépenses concernaient des tâches où les modèles Flash bon marché égalent la qualité d'Opus. Passer à Flash par défaut et utiliser /model en cours de session a réduit les coûts d'environ 170 $ à environ 35 $ par mois.

L'utilisation de l'IA pour générer des tickets de projet avant le codage réduit la dérive des objectifs.
Un développeur a constaté que demander à l'IA de générer des tickets de projet détaillés avec tâches, sous-tâches, périmètre et critères d'acceptation avant d'écrire du code réduisait significativement les dérives de périmètre et les différences importantes. Chaque agent IA ne reçoit que sa sous-tâche spécifique, pas le plan entier.