OpenClaw’s Default-Model Doctor PR Is the Gemini Migration Story in Miniature
The ugliest AI-tooling failure is not “the model is unavailable.” It is “the tool says this dead model is your default, then tells you the model does not exist, then fails your agent run anyway.” That is not an error message. That is a trust withdrawal.
OpenClaw PR #92292 addresses a sharp version of that failure in the wake of OpenClaw 2026.6.5. A configured default model of google/gemini-3.1-pro-preview could still resolve as the default while no longer being inspectable or executable. The linked bug report shows the contradiction clearly: openclaw infer model auth status reported the dead Gemini model as the resolved default, while inspect returned “Model not found” and run returned “Unknown model.”
The PR is modest in size — 111 additions, one deletion, four changed files — but it sits inside a much larger developer-tools migration story. It adds a new doctor health check, core/doctor/default-model, following the existing core/doctor/hooks-model pattern. It also improves openclaw infer model inspect so that a missing model lists available models from the same provider instead of only telling the operator that the configured one is gone.
Model names are now operational dependencies
Issue #92009, which this PR fixes, is a useful artifact because it captures how confusing model catalog drift feels from the operator’s side. The configured default pointed at google/gemini-3.1-pro-preview. The Google provider catalog available through openclaw infer model list showed only google/gemini-2.5-pro in the native catalog. The observed workaround was to manually change the default model to google/gemini-2.5-pro. Until then, Gemini-backed agents could stop responding.
That is the important category shift: model IDs are no longer casual strings in a config file. They are operational dependencies. A coding agent’s ability to respond may depend on a provider catalog, regional availability, auth state, modality support, context-window metadata, and runtime routing logic all agreeing on what a model name means. When any one of those layers changes, the failure should surface before the first real task, not halfway through an agent turn.
This matters especially during migration windows. The research brief ties this PR to high-intent searches around Gemini Code Assist and Gemini CLI alternatives, with developers looking at replacement paths around Google’s June 18 cutoff for some usage tiers. Whether that exact migration affects a given team or not, the pattern is familiar: a provider changes product packaging, a model disappears or is renamed, and tools built around yesterday’s catalog start returning contradictory answers.
OpenClaw’s improvement is not that it magically migrates every stale default. It does not. The useful move is turning a broken default from a mystery into a health check. A doctor command that understands “your configured default is not in the live catalog; here are same-provider alternatives” is qualitatively better than discovering the problem when a delegated coding task never starts.
The doctor check belongs at the config/catalog boundary
The strongest design principle in this PR is boundary validation. A default model is where static configuration meets mutable provider reality. That boundary should be checked explicitly. Auth checks alone are not enough. A valid API key for Google does not prove that google/gemini-3.1-pro-preview exists, supports the requested route, or remains exposed by the provider plugin. Conversely, a missing model is not the same thing as missing auth. Conflating those errors wastes operator time.
For practitioners, this should become part of the agent-platform checklist. When a provider removes or renames a model, what happens? Does the platform fail at startup, during a doctor run, on the first request, or after a background task has already been scheduled? Does it suggest same-provider alternatives? Does it preserve a fallback chain? Can it distinguish catalog failure from auth failure, transport failure, quota failure, and unsupported modality?
Those questions are not theoretical. Coding agents run longer, touch more state, and often execute across asynchronous surfaces: Slack messages, cron jobs, background subagents, pull-request reviewers, inbox triage, and local shell workflows. A stale default model in a normal chatbot is annoying. A stale default model in an agent orchestration layer can strand tasks across multiple entry points, each one producing a different symptom.
The original issue’s contradiction — resolved default here, unknown model there — is also a UX smell. Operators should never have to reconcile two official answers from the same CLI. If the model is not executable, the “resolved default” output should say so or link directly to the diagnostic path that does. A platform that can route across many providers has to make model resolution explainable, not merely configurable.
There is a fair criticism here: agent platforms should already validate defaults against live catalogs. The less charitable reading of PR #92292 is that this class of failure arrived late. But the direction is correct, and in fast-moving model ecosystems, the platforms that win will be the ones that make catalog churn survivable. Doctors, preflight checks, fallback explanations, and replacement suggestions are not polish. They are runtime reliability features.
The Gemini migration story should not be framed only as “which coding tool should I use next?” The better question is operational: how does the tool behave when the ground under a provider moves? Model catalogs change. Defaults rot. Agent platforms need doctor checks that catch breakage before your workflow does.
Sources: OpenClaw PR #92292, OpenClaw issue #92009