OpenClaw model-provider changes from May to July 2026: what each route required

Published July 21, 2026, OpenClawBlog Team

An OpenClaw model can appear in a picker and still fail when the request starts. The missing piece may be a provider plugin, the wrong authentication method, an exact model identifier, a compatible runtime, or a catalog that has not been refreshed.

Scope. This article counts a change when a release record altered a provider, model catalog, authentication path, runtime, endpoint contract, or fallback behavior. It does not attempt to list every provider bug fix. No live OpenClaw installation was run for this article; the checks below are proposed operator checks.

The pattern in one table

May: authentication and provider behavior separated

The first useful May signal came from the pre-release v2026.5.12-beta.1 record, published May 12. openclaw models auth login --provider openai was changed to start the ChatGPT/Codex account login by default, while --method api-key remained the explicit OpenAI API-key path. The same record normalized retired Gemini 3 Pro Preview identifiers to google/gemini-3.1-pro-preview.

That was a change in meaning, not just a new command. A ChatGPT or Codex login and an OpenAI API key were separate account routes. A successful login therefore did not prove that every OpenAI model or runtime was available to that account.

The stable v2026.5.18 rollup, published May 18, grouped xAI OAuth, Anthropic and Claude CLI routing, OpenRouter and OpenAI-compatible reasoning replay, Gemini thought signatures, and fixes for Ollama, Qwen, Together, Xiaomi, Copilot, and local providers. By v2026.5.28, the provider surface also included Claude Opus 4.8, NVIDIA featured catalogs, MiniMax music streaming, voice model catalogs, and GitHub Copilot agent-runtime support.

May also tightened the route around those features. The release record says provider credentials from workspace dotenv files were ignored, non-canonical api_key profiles were rewritten, provider requests received bounds, and GitHub Copilot and Tokenjuice became official install-on-demand plugins. The practical requirement was to know where the credential lived, which package owned the runtime, and whether the chosen model was in the provider's current catalog.

June: the package became part of the provider contract

On June 3, the pre-release v2026.6.2-beta.1 record replaced dangerous-code scanner enforcement with an operator install policy for skills and plugins. The current skills configuration reference describes that policy as a host-side decision made after source staging and before an install or update. It can return allow, warn, or block; an enabled policy with no valid trusted command fails closed.

This mattered to model providers because a provider could now arrive as an external package, source checkout, archive, or marketplace entry. The requirement was no longer only an API key. The operator also had to trust the package source, allow the Gateway to load it, and decide how warnings were acknowledged. The beta label matters: this was evidence of a changing boundary, not a promise that every installation had the same stable behavior.

The v2026.6.9 release, published June 21, made external provider packages first-class npm releases. It also listed external plugin loading at Gateway startup, StepFun through npm and ClawHub, Codex Hosted Search, and better Gemini CLI OAuth behavior behind proxies. External-provider onboarding was expected to keep its current choices and package metadata.

The June 30 v2026.6.11 release dealt with the less visible consequences. Provider-qualified model IDs began honoring configured runtime policies and CLI aliases. Local-provider errors could use a configured fallback, Codex subscription limits could advance to configured fallback models, and oversized provider catalogs were rejected before uncontrolled buffering. A first-run external provider could also open its credential prompt instead of leaving OpenAI selected.

July: a model name carried more provider context

The stable v2026.7.1 release, published July 13, expanded support across GPT-5.6 and Codex routes, Tencent Hunyuan Hy3, Meta Model API and Muse Spark 1.1, Claude models, Ollama, ClawRouter, LongCat, and other provider paths. The detailed July release notes make the requirements concrete.

GPT-5.6 needed preview access for eligible organizations. Hy3 had a setup path through TokenHub or TokenPlan. Meta Model API used a provider credential such as MODEL_API_KEY. Claude Sonnet 5 depended on the supported Anthropic, Claude CLI, Vertex, Bedrock, or Bedrock Mantle route. ClawRouter exposed only the models granted to its managed key. These are different contracts, even when the user experience presents them all as model choices.

July also documented openclaw plugins init scaffolding for model-provider plugins, including authentication, model setup, tests, packaging, validation, and ClawHub publishing structure. That does not make a generated plugin trustworthy or compatible by itself. It gives an author a supported shape to complete and an operator a more visible package boundary to inspect.

What an operator had to prepare

1. Identify the whole route. Record the provider ID, model ID, endpoint, runtime, account or profile, and any provider-specific context or reasoning limits. A bare model label is not enough.
2. Install the owner. The current official-provider reference says official plugins publish their own catalog rows. The normal path is to enable the plugin, set authentication, and choose a model. Custom or proxy routes instead use models.providers with explicit model metadata, as described in the custom-provider reference.
3. Set the default intentionally. The provider quick rules say that adding or reauthenticating a provider preserves an existing primary model unless --set-default is used. Use openclaw models set when the default should change.
4. Separate inventory from readiness. The Models CLI reference says models set requires an installed provider plugin or a configured provider. A known provider with an uncatalogued model can still be saved with a warning. Listing a model is not a successful model call.
5. Design the failure path. OpenClaw's failover documentation describes auth-profile rotation first and model fallback second. Explicit user session selections remain strict. A fallback therefore needs an intentional configuration and a test that cannot repeat an external side effect.

Proposed checks, not test results:

openclaw plugins list
openclaw models status --json
openclaw models list --provider <provider> --refresh
openclaw models status --probe --probe-provider <provider>

A probe makes live provider requests and needs exclusive ownership of the selected state directory. Stop the Gateway first when the installed version requires it. Keep credentials out of the command history and record only the provider, model, result, and timestamp.

Failure paths and limits

A valid credential can still produce an unavailable route when its provider plugin is missing or its runtime failed to start. A catalog can show a model that the account cannot use. A custom base URL can also remove implicit catalog rows, requiring explicit model entries. An API key does not prove that a native CLI login exists, and adding a fallback does not make an explicit session selection flexible.

The beta records should remain marked as beta in an upgrade note. The release pages document intended behavior; they do not prove performance, account-wide availability, provider pricing, or compatibility with every channel and operating system. No comparative benchmark or live-provider adoption result is claimed here.

Bottom line

May widened provider access and separated authentication choices. June made provider packaging, install policy, catalog loading, and fallback behavior visible parts of the route. July added more models, but also more provider-specific prerequisites. The safe reading is simple: choose the provider contract first, then choose the model inside it.

Sources

Release dates below are historical dates shown on the release pages. Documentation pages without a listed publication date are current references checked on September 13, 2026; they explain configuration semantics without backdating later documentation changes.

• OpenClaw v2026.5.12-beta.1 release, May 12, 2026.
• OpenClaw v2026.5.18 release, May 18, 2026.
• OpenClaw v2026.5.28 release, May 30, 2026.
• OpenClaw v2026.6.2-beta.1 release, June 3, 2026.
• Skills configuration and operator install policy.
• OpenClaw v2026.6.9 release, June 21, 2026.
• OpenClaw v2026.6.11 release, June 30, 2026.
• OpenClaw v2026.7.1 release, July 13, 2026.
• Detailed v2026.7.1 release notes.
• Model-provider quick rules.
• Official provider plugins.
• Custom providers and local runtimes.
• Models CLI.
• Model failover.