openclaw - 💡(How to fix) Fix [Feature]: Expose per-model availability (the `available` flag) to plugins and RPC clients

Summary

The authoritative per-model availability signal (the available flag shown by openclaw models list --all) is computed only inside the CLI and is not reachable by third-party plugins or gateway RPC clients. Please expose it so credential-aware model pickers can mirror OpenClaw's own "usable models" set instead of re-deriving a divergent heuristic.

Problem to solve

A third-party channel plugin that renders a "choose your default model" UI needs the same set of models OpenClaw itself considers usable under the current credentials. Today that set is only obtainable through the CLI:

• openclaw models list --all --json returns entries { key, name, input, contextWindow, local, available, tags, missing }. The available: boolean is the authoritative flag, computed in toModelRow (src/commands/models/list.model-row.ts:49-56) from ModelRegistry.getAvailable() plus the provider-level fallback createModelListAuthIndex().hasProviderAuth (src/commands/models/list.auth-index.ts).

Neither path is reachable from outside the CLI:

• The gateway RPC models.list (src/gateway/server-methods/models.ts) returns the bare manifest catalog under view:"all" (:70-72) — entries are { id, name, provider, contextWindow, reasoning, input }, with no available field. models.authStatus only reports provider-level health for explicitly-configured auth profiles (too narrow — it omits api-key and synthetic-auth providers).
• The plugin SDK does not export ModelRegistry.getAvailable() nor createModelListAuthIndex / hasProviderAuth. Only lower-level building blocks are exported (isProviderApiKeyConfigured, resolveEnvApiKey, listUsableProviderAuthProfileIds, hasUsableCustomProviderApiKey, hasSyntheticLocalProviderAuthConfig).

A plugin therefore has to hand-roll an availability heuristic from those building blocks, which only reproduces a coarser provider-level approximation and diverges from the CLI's true model-level result. Concrete divergences we hit:

• Provider-level "is this provider authed" over-lists models: with a ChatGPT OAuth profile, all of openai/* (40+ models) look authed via the codex-runtime routing, while getAvailable() correctly surfaces only openai/gpt-5.5 plus openai-codex/*.
• Synthetic-auth providers (e.g. claude-cli/*, the codex app-server provider) are easy to miss without re-implementing the marker logic.

Proposed solution

Either of the following fully solves it (we'd prefer Option 1 — it needs no algorithm duplication downstream):

Option 1 — Add availability to the models.list RPC. Include available (and ideally missing / local) on each entry, e.g. behind a new view:"available" or an includeAvailability: true param (or unconditionally under view:"all"). The server method would wire the same ModelRegistry.getAvailable() + auth-index path the CLI already uses in toModelRow. RPC clients — and plugins that proxy through the gateway — could then read the authoritative flag directly.

Option 2 — Export the availability computation through the plugin SDK. Expose ModelRegistry.getAvailable() (or a small listAvailableModels(config) helper) and/or createModelListAuthIndex + hasProviderAuth via an openclaw/plugin-sdk/* subpath, so in-process plugins can reproduce the exact CLI result instead of re-deriving it.

Impact

• Lets third-party UIs present a model picker that exactly matches openclaw models list — no "selectable but not runnable" entries from a divergent local heuristic, and no missed synthetic-auth providers.
• Keeps availability logic single-sourced in OpenClaw; downstream consumers stop drifting as the auth model evolves.
• Low blast radius: Option 1 is additive to an existing RPC; Option 2 is an additive SDK export.

Additional information

• OpenClaw version: 2026.5.26
• Discovered while building a credential-aware "default model" picker: with a ChatGPT (openai-codex) OAuth login, the picker could not surface the usable GPT-5.x models because our local heuristic — reading only persisted models.json providers — diverged from getAvailable().

Reported by the CoClaw team. This issue was discovered while developing @coclaw/openclaw-coclaw, a CoClaw channel plugin for OpenClaw.