OpenClaw : mémoire, agents et onboarding s’allègent

Pas de nouvelle release OpenClaw installable ce matin : npm garde latest=2026.7.1-2, beta=2026.7.2-beta.5 et extended-stable=2026.6.33, tandis que la dernière GitHub Release publique reste v2026.7.2-beta.5. Les pages docs 2026.7.2, 2026.7.2-beta.5, 2026.7.2-beta.6 et 2026.6.34 répondent encore en 404 au moment du fact-check.

Le signal utile est ailleurs : la branche principale continue de réduire les points de friction qui apparaissent quand OpenClaw tourne sur de vraies machines, avec des sessions longues, des agents nombreux, des providers locaux et des automatisations qui doivent échouer proprement.

Premier axe : la pression mémoire. La PR #116668 allège les commandes de statut et d’inventaire plugins sur les systèmes contraints. Le changement évite de charger des diagnostics mémoire et des barrels de runtime plugin quand un status --json ou un plugins list --json n’en a pas besoin. Les chiffres de preuve sont parlants : plugins list --json descend autour de 96 MiB en preuve packagée à 256 MiB de RAM, et la médiane contrôlée baisse d’environ 21 %. Pour une machine légère, un node distant ou un host déjà chargé, ce genre d’optimisation compte davantage qu’une feature visible.

La PR #116667 traite un cas plus brutal : les attachements locaux trop gros. Avant correction, certains chemins de lecture pouvaient bufferiser un fichier oversized avant de vérifier la limite de livraison, jusqu’à provoquer un OOM sur un environnement contraint. Le nouveau comportement applique le cap avant allocation sur les chemins de lecture locaux possédés par OpenClaw. Résultat attendu : une erreur de taille lisible au lieu d’un process tué par le système.

Deuxième axe : les agents à fort fan-out. #116661, #116623 et #116619 attaquent trois coûts de registre et de scheduling qui grossissaient mal avec beaucoup de sous-agents. Les changements indexent les générations de sessions enfants, les groupes de collectors, les runs de scheduler et les vagues de settle requester. Les preuves annoncent des ordres de grandeur très nets : des sweeps qui passent de centaines de millisecondes à quelques millisecondes, voire moins. Pour les workflows multi-agents, c’est exactement le type de correction qui transforme une architecture “possible” en architecture exploitable longtemps.

Troisième axe : les chemins d’onboarding et de provider. #116606 améliore le setup des modèles locaux : Ollama, llama.cpp et LM Studio sont mieux distingués, revalidés et raccordés à l’UI et à macOS. #116655 complète le mouvement côté interface en affichant plus clairement l’identité du provider après setup. Et #116590 corrige un piège GitHub Copilot : l’onboarding ne doit pas choisir un modèle par défaut que le compte authentifié ne peut pas utiliser.

Le reste de la vague confirme la même tendance : #116565 borne /steer côté Codex quand l’app-server ne répond pas, #116674 fait échouer les commandes web CLI quand le provider renvoie vraiment une erreur, #116664 rend openclaw mcp probe exploitable en automatisation avec un exit non-zero en cas de probe incomplet, et #116608 rend les codes /login codex copiables dans Telegram.

La lecture d’ensemble : OpenClaw ne prépare pas seulement la prochaine version 2026.7.2, il resserre les chemins qui cassent quand l’usage devient intensif. Moins de mémoire au démarrage, moins de scans quadratiques, des erreurs CLI détectables, des providers locaux plus explicites, des canaux plus ergonomiques. C’est moins spectaculaire qu’un changelog de release, mais c’est le socle qui rend les workflows dev/automation plus prévisibles.

À relire aussi : OpenClaw : install, upgrade et runtime se blindent pour la vague précédente côté install, plugins et Gateway, et OpenClaw 2026.7.2 beta 5 : la release prend forme pour le périmètre beta actuellement publié.