What happened
OpenClaw’s November 6, 2026 engineering post describes a redesign completed over roughly five weeks and about 80 pull requests. Previously, each provider plugin carried a model list in a manifest bundled with OpenClaw. Because provider plugins were tied to releases, adding a model generally required a new OpenClaw release. The post uses GPT-6.1 Sol as an example: OpenClaw’s bundled Codex 0.158.0 could not see a model that ChatGPT offered only to Codex 0.159.2 and newer.
The new discovery path has three parts. First, OpenClaw hosts a model catalog at catalog.openclaw.ai. A job rebuilds it every four hours using data from models.dev, OpenClaw’s own manifests and pricing information; the post says it contains about 1,000 models. A running Gateway checks for updates in the background and adopts a completed catalog live. New turns use the new catalog, while a turn already in progress finishes with the catalog it began with, keeping its model list and prices consistent. Retired models are removed. If a refresh fails, the previous list remains available rather than being replaced by a partial one.
Second, a signed-in provider account can supply its own list of models. OpenClaw says this can expose models newer than the installed OpenClaw version or models available only to that account. Examples in the post include OpenAI API keys, Anthropic API keys, Claude Code, GitHub Copilot, Grok subscriptions, Ollama and OpenCode Go. It also says it now reads capabilities such as supported thinking levels and request endpoints from provider listings instead of inferring them from model names. The stated aim is to avoid hiding supported capabilities or sending a model a request format it does not accept.
Third, OpenClaw looks for a Codex executable on the user’s PATH. If it is a newer stable release than the bundled version and shares its major version, OpenClaw performs a handshake; on success, that same binary fetches the model list and runs turns. If the check fails, OpenClaw uses its bundled Codex. The post says OpenClaw does not install Codex for the user. In one example, a Gateway used installed Codex 0.162.1 instead of bundled 0.161.0.
The post also describes reliability and picker changes. OpenRouter discovery retries after a timeout, starting after 30 seconds and increasing intervals up to 30 minutes. Catalog switches keep the existing list until a replacement is complete. OpenClaw says changing the default model now takes 0.6–1.4 seconds, compared with 68–142 seconds previously, and pickers open immediately while remaining discovery continues in the background. Since a provider such as OpenRouter can list hundreds of models, the picker puts a manually curated recommended subset first while retaining search across the full list.
What the archive adds
New Runtime’s earlier coverage described OpenClaw v2026.10.1 moving installed-skill discovery into a permission-aware search-and-read path (October 12, 2026 note). This is a new engineering event, not a restatement: it applies a similar runtime-side discovery approach to models, but does not establish a broader product policy for skills or model access.
Trend signal
This supports harness architecture outlives model choice: OpenClaw is changing the surrounding runtime so model availability, capability metadata and execution-version compatibility are not fixed solely by the model bundled in a release. The example is specific to OpenClaw; it does not prove that this approach is becoming standard across agent systems.
Why now
The post ties the work to a concrete mismatch exposed by GPT-6.1 Sol: ChatGPT required a newer Codex client than the one bundled with OpenClaw, so users could not select the model until OpenClaw shipped an update. OpenClaw says the redesign took about five weeks and roughly 80 pull requests to address that release dependency and related discovery failures.
Why it matters
For teams operating an agent runtime, model discovery is not just a menu problem. The runtime has to know which models an account can use, what request formats and capabilities they support, and whether the client that lists a model is also the client that executes it. OpenClaw’s reverted first attempt is instructive: reporting a newer Codex version made a model appear, but turns still ran on the older bundled binary and could fail with HTTP 400. The final design requires the same tested binary to retrieve the list and run turns.
The operational details matter too. A failed refresh should not erase a usable catalog, and one renamed provider should not prevent every other provider from receiving fresh data. The examples of reduced model-switch latency and background picker loading point to another principle: discovery should not stall the user-facing workflow. Teams building similar systems can use these as concrete checks when separating model metadata from runtime execution, but the post does not establish that every provider exposes equally reliable account listings or capability data.
What happens next
- OpenClaw will continue expanding provider support and refining model discovery. (6 months, 70%). Watch for: a release or documentation update naming additional supported providers or discovery behavior.
Limits and uncertainty
These details are OpenClaw’s account of its own implementation; the reported timings and examples are not independently measured here. The post does not quantify how often account-provided model listings are complete or correct across providers, or how often the fallback to bundled Codex is triggered in production. A model newer than the catalog may have no price yet; OpenClaw says it displays the cost as unknown and uses cautious default limits until the catalog catches up. Users without a newer Codex installed remain constrained by the bundled version for ChatGPT model discovery.
Skill to build now
Test the boundary between discovery and execution in your own agent runtime. For one provider, compare the models and capabilities returned to an account with what the runtime displays, then send a real turn through the exact client binary that fetched the list. Include a negative test: make catalog refresh fail and verify that the last good list remains usable. This directly checks the failure modes OpenClaw says it addressed.
Reader takeaway
A model appearing in a picker is not enough. A reliable agent runtime must keep discovery current, preserve a usable last-known-good list, and make sure the client that advertises a model can also execute it. OpenClaw’s redesign makes those responsibilities explicit, while leaving account-list quality and broader provider behavior to be tested in practice.