Summary

OpenClaw image tool reports Unknown model for a custom LiteLLM-backed image-capable model configured via agents.defaults.imageModel, even though:

• the model is present in models.providers
• the model is declared with input: ["text", "image"]
• direct multimodal requests to the LiteLLM endpoint succeed
• agents.defaults.imageModel.primary/fallbacks resolves to that model

This appears to be a runtime registry / models.json generation issue, not a provider connectivity issue.

Environment

• OpenClaw installed via npm/homebrew path on macOS
• Runtime observed in local install under /opt/homebrew/lib/node_modules/openclaw/dist
• Channel/agent binding: Feishu group bound to agent gpt-5-4
• Custom provider: litellm
• Model: azure-gpt-5-mini
• Provider API style: openai-completions

Relevant config

Provider config includes an image-capable LiteLLM model:

models: {
  providers: {
    litellm: {
      baseUrl: 'http://localhost:4000',
      apiKey: '***',
      api: 'openai-completions',
      models: [
        {
          id: 'azure-gpt-5-mini',
          name: 'Azure GPT-5 Mini',
          api: 'openai-completions',
          reasoning: false,
          input: ['text', 'image'],
          contextWindow: 200000,
          maxTokens: 8192
        }
      ]
    }
  }
}

And image model routing is explicitly configured:

agents: {
  defaults: {
    imageModel: {
      primary: 'minimax-portal/MiniMax-VL-01',
      fallbacks: ['litellm/azure-gpt-5-mini']
    }
  }
}

(Using primary: 'litellm/azure-gpt-5-mini' directly also failed earlier in the same way.)

Direct provider verification

The LiteLLM backend itself is healthy.

Direct call to the LiteLLM endpoint with multimodal chat/completions succeeds for azure-gpt-5-mini.

So this is not a case where the upstream model lacks image support or the provider is unreachable.

Reproduction

1. Configure a custom provider under models.providers.litellm
2. Add a model with:
   • id: 'azure-gpt-5-mini'
   • api: 'openai-completions'
   • input: ['text', 'image']
3. Set agents.defaults.imageModel.primary or fallbacks to litellm/azure-gpt-5-mini
4. Restart OpenClaw
5. Run the image tool against a local image file

Actual result

The image tool fails with:

Unknown model: litellm/azure-gpt-5-mini

With primary/fallback setup, the full error looked like:

All image models failed (2):
minimax-portal/MiniMax-VL-01: Unknown model: minimax-portal/MiniMax-VL-01 |
litellm/azure-gpt-5-mini: Unknown model: litellm/azure-gpt-5-mini

Expected result

If a model is present in models.providers, declared with input: ['text', 'image'], and referenced by agents.defaults.imageModel, the image tool should treat it as a valid candidate and attempt execution.

What was already verified

• agents.defaults.imageModel is being read by the image tool candidate selection path
• the current agent has a valid agentDir
• agent-local models.json exists under paths like:
  • ~/.openclaw/agents/gpt-5-4/agent/models.json
• manually editing that file was not enough, because the image path appears to call ensureOpenClawModelsJson(...) before lookup

Strong suspicion / likely root cause

Looking at the installed runtime code:

• createImageTool(...) -> runImagePrompt(...) calls:
  • ensureOpenClawModelsJson(effectiveCfg, params.agentDir)
  • then discoverAuthStorage(params.agentDir)
  • then discoverModels(authStorage, params.agentDir)
• describeImageWithModel(...) similarly calls ensureOpenClawModelsJson(params.cfg, params.agentDir) before registry lookup

So the failure seems to happen in the generated runtime registry / models.json path, not in the config parsing path.

There is also a suspicious fallback resolver path in the installed runtime that appears to normalize resolved models with:

input: ["text"]

instead of preserving configured model input capabilities.

If that path is involved in models.json generation or runtime normalization, it could explain why a configured ['text', 'image'] model later becomes unknown or is not considered image-capable in the registry.

Ask

Could you check whether:

1. custom provider models referenced via agents.defaults.imageModel are always written into runtime models.json
2. input capabilities from configured custom provider models are preserved during runtime normalization
3. the image tool's runtime registry path supports custom LiteLLM-backed openai-completions models with input: ['text', 'image']

Happy to test a fix or patch if needed.