OpenClaw Stops Making Model Launches Wait for a Release as Main Teaches Wedged Gateways to Restart Themselves
OpenClaw published the engineering story behind a quieter change: new models now reach OpenClaw from a hosted catalog, your provider account and your installed Codex, so a model launch no longer waits for an OpenClaw release. A second official post walked through how releases ship across dev, beta and stable. Overnight, main taught supervised Gateways to restart themselves when their main thread wedges and to record crashes after automatic restarts. There is no new tag: npm latest is still 2026.11.1.
Model Launches No Longer Wait for an OpenClaw Release
Today's lead is an engineering explainer, not a tag. The OpenClaw engineering blog post "Use new models in OpenClaw without an update" by Ayaan Zaidi, dated November 6, 2026, says OpenClaw now learns about new models from three places: a hosted catalog, the operator's own provider account, and an installed Codex binary. The motivating bug is blunt. When OpenAI shipped GPT-6.1 Sol, people using OpenClaw with a ChatGPT sign-in could not select it, because OpenClaw bundled Codex 0.158.0 and ChatGPT only offers Sol to Codex 0.159.2 and newer. "Launch day is when people most want to try a model, and we were the reason they had to wait," the post says. The fix took about five weeks and roughly 80 pull requests. The official @openclaw post introducing the model-catalog engineering write-up went out at 10:08 AM Pacific on November 6 and credits @obviyus.
The first source is a catalog at catalog.openclaw.ai that a job rebuilds every four hours from models.dev data, OpenClaw's own manifests and prices; the post puts it at about 1,000 models. A running Gateway now adopts a newer catalog live, and a turn already in progress finishes on the catalog it started with so its model list and prices match. The Models CLI concept page on docs.openclaw.ai adds the operator boundaries: the Gateway makes one background request at startup and checks at most every six hours, the request "sends no prompts, credentials, model usage, or configuration payload," remote data can only update models for providers declared by installed plugin manifests, and it "cannot supply API base URLs or request headers." The blog is also candid about an outage: on September 21 a split kimi-for-coding entry on models.dev made every publisher run fail, so GPT-6 Sol and Luna did not reach existing installs until a missing provider was downgraded to a warning.
The second source is account discovery. When you sign in to a provider, OpenClaw asks it for your model list and shows every chat model on it. The post lists before-and-after cases for OpenAI and Anthropic API keys, Claude Code, GitHub Copilot, Grok subscriptions, Ollama and OpenCode Go, and says capabilities such as thinking levels and request format are now read from provider listings rather than guessed from model names. The third source is Codex. A first attempt reported the newest Codex version from npm while turns still ran on the bundled binary, which moved failures from the picker to an HTTP 400 on the first message, so it was reverted. What ships now looks for a stable Codex on your PATH that is newer than the bundled one on the same major version, performs a real handshake, and uses that same binary for both the model list and the turns; it "never installs anything for you." The post also reports a default-model change dropping from 68 to 142 seconds to 0.6 to 1.4 seconds, and an OpenRouter timeout no longer collapsing 466 models to 3.
This changes how teams should read model-launch days. The question is no longer "when does OpenClaw ship support" but "does our account list it, and which Codex binary is on the Gateway host's PATH." Before the next big launch, run openclaw models list --refresh on a staging Gateway and record what appears. If you rely on ChatGPT sign-in, decide deliberately whether a newer global Codex belongs on production hosts, because updating it now changes which models those hosts can run.
How OpenClaw Ships: Channels, a Weekly Beta Train and an Agent Shepherd
The second official item explains release mechanics. The official @openclaw release-process video post with @dallinfinite, published at 12:33 PM Pacific on November 6, describes how OpenClaw ships as "dev, beta and stable channels, a weekly beta train, and one agent session shepherding every release." The written companion is the Release channels guide on docs.openclaw.ai, which actually lists four channels: stable on npm latest, extended-stable for a trailing supported month, beta as the newest of the beta and latest dist-tags, and dev as the moving head of main, which the guide warns not to run on production gateways. Stable builds usually ship to beta first and are then promoted to latest without a version bump.
The OpenClaw release policy reference on docs.openclaw.ai fills in the guardrails. Versions use year.month.patch, where the patch is a release number within the month rather than a day; regular releases stay below patch 33 and extended-stable starts at 33. Release tags are annotated and signed, and the shared publication workflow refuses lightweight, unsigned or unverified tags. Published npm versions and tags are never replaced: a fix gets a new version. Every failed release test needs an explicit release-lead decision, blocker or flake, and a flake may be rerun on the same release SHA at most twice.
Release status as of this morning, checked directly: the openclaw/openclaw releases page on GitHub still shows v2026.11.1 as the newest full release and v2026.11.5-beta.1 as the newest prerelease, and there is no 2026.11.5-beta.2 tag. The npm registry metadata for the openclaw package lists latest at 2026.11.1, beta at 2026.11.5-beta.1 and extended-stable at 2026.9.36. The "agent session" idea is visible in the merge log too. Pull request #194537, which adds Parallel Decisions natively and through OpenRouter, was opened by the project's roboclaw-bot account and says it was requested by Vincent Koc through an X request; it merged at 1:56 AM Pacific today and adds decision-only models such as parallel/decisions-fast that stay out of conversational model selection.
Map your fleet to these channels on purpose. Production Gateways belong on stable or extended-stable, a single canary belongs on beta so the weekly train reaches you before it reaches everyone, and nobody's customer-facing Gateway should track dev. Because published versions are never replaced, pin by exact version in your change records, and treat the signed-tag rule as a reason to reject any "patched" build that did not come through the official channels.
Main Overnight: A Wedged Gateway Now Restarts Itself, and Says So
None of the following is in a package yet. On main, pull request #194481, which lets a supervised Gateway recover when its main thread wedges, merged at 9:57 PM Pacific on November 6 from Peter Steinberger's account. Until now a Gateway with a permanently blocked main thread stayed alive but unresponsive until an operator killed it. With the change, a supervised Gateway records main-thread stall recovery: and kills itself after five continuous minutes without a heartbeat, so its existing supervisor restarts it and crash recovery can resume eligible runs. Debugger pauses are exempt, laptop sleep resets the window, and there is no new configuration. Foreground processes still need an external supervisor to respawn.
The follow-up, pull request #194492, which makes Gateway crashes visible after automatic restarts, merged at 2:10 AM Pacific. It targets "silent Gateway crashes": after an automatic restart, operators saw a healthy fresh process with no record of the unexpected exit. The next startup now records and warns about the previous unexpected exit, and the last ten crashes appear in Gateway status, Doctor findings, the health RPC and authorized readiness details. Clean shutdowns and planned restarts do not create crash records.
Two more merges matter for upgrade paths. Pull request #194599, which parks the Gateway service when an agent database needs offline migration, merged at 5:37 AM Pacific; instead of restarting repeatedly, including after a direct global npm replacement, the maintenance handler exits 78 with stop, openclaw doctor --fix, start guidance, and systemd and Windows supervisors treat that exit as terminal. And pull request #194558, which repairs the extended-stable upgrade from 2026.9.36, merged at 1:02 AM Pacific; it fixes the published 2026.9.36 updater failing after it activates the 2026.9.37 candidate. That candidate is not on npm yet.
Self-restart only helps if something is supervising. Check now that every production Gateway runs under launchd, systemd or the Windows task supervisor rather than a terminal session or a tmux pane. When these changes ship, add the crash list from Gateway status to your morning health check, and teach your alerting that exit 78 means "run Doctor offline," not "restart harder." Extended-stable users should wait for the 2026.9.37 release notes before upgrading.
Security Tip: Know Which Credential Pays for a Tool Call
Pull request #194583, which exposes x_search to Grok OAuth users on non-xAI models, merged at 2:34 AM Pacific and is a useful lesson in credential scoping. An earlier change hid xAI's billed server tools from non-xAI models unless explicitly enabled, so an xAI API key would not start incurring $5 per 1,000 calls just because it existed. That gate could not tell a paid API key from a Grok OAuth subscription. Plugin auth callbacks can now ask for a specific credential type, and the xAI plugin requests OAuth only: searches "use only the OAuth credential and never fall back to an xAI API key," and a failed OAuth refresh returns an error instead of silently using a paid key.
- Inventory which provider keys sit in Gateway environment variables versus stored auth profiles; an unused key in the environment is still a billing path.
- API-key-only users keep the old behavior: a non-xAI model still needs
plugins.entries.xai.config.xSearch.enabled: true, andenabled: falsehides the tool everywhere. - When this ships, test an expired OAuth session on staging and confirm the tool errors rather than switching credentials.
- Apply the same rule to your own plugins: when a fallback would change who pays, fail closed.
Skill Card: openai-whisper-api, After a Night of curl Fixes
The bundled openai-whisper-api SKILL.md on OpenClaw main transcribes audio through OpenAI's /v1/audio/transcriptions endpoint with curl. It defaults to gpt-4o-transcribe and writes <input>.txt, supports gpt-4o-mini-transcribe, gpt-4o-transcribe-diarize with --json for speaker labels, and whisper-1, and honors OPENAI_BASE_URL for compatible proxies. It needs curl, node and OPENAI_API_KEY; the hosted API has a 25 MB upload limit. Four merges by contributor zhangguiping-xydt hardened its helper script overnight:
- Errors are errors. Pull request #194478 fails transcription when the API returns an HTTP error; before, 401, 429 or 500 JSON bodies could be saved as transcripts with exit 0.
- Prompts arrive intact. Pull request #194579 preserves literal transcription prompts; a semicolon used to truncate the hint, and a leading
@or<was read as curl file syntax. - Old transcripts survive. Pull request #194588 preserves transcripts when downloads fail, writing output only after curl succeeds.
- Odd filenames work. Pull request #194593 uploads audio paths containing form delimiters such as commas and semicolons.
If an agent already turns voice notes or meeting audio into text with this skill, audit last month's transcripts for files that are really JSON error bodies; the old helper could save those with a success exit. Until a release carries these fixes, avoid commas and semicolons in audio paths and keep speaker-name prompts free of semicolons. Then rerun one known recording after upgrading and compare the output byte for byte.
What to Watch Next
First, whether a 2026.11.5-beta.2 or the next stable picks up the overnight Gateway self-recovery, crash history and maintenance-parking changes, so operators on npm get them without tracking main. Second, whether extended-stable 2026.9.37 publishes with the repaired upgrade path from 2026.9.36. Third, how the hosted catalog behaves on the next major model launch, now that account discovery and installed Codex selection are the documented route. We are not treating third-party harness leaderboards or ClawHub promotions as OpenClaw releases. We will recheck tags, npm dist-tags and the catalog docs on the next run.
Getting your Gateways ready for the next model launch?
SEN-X helps teams map Gateways to the right release channels, verify model discovery and Codex selection on staging, and wire crash history and supervisor checks into daily operations.
Contact SEN-X →