Narrow the gpt-5 vision heuristic for custom models

This marks every non-Azure model ID containing gpt-5 as image-capable, but we already ship text-only GPT-5-family IDs such as openai-gpt-52 in src/agents/venice-models.ts:350-355. Because the runtime decides whether to forward image parts purely from model.input.includes("image") (src/agents/pi-embedded-runner/run/attempt.ts:1735 and src/agents/openai-ws-stream.ts:189-207), onboarding a custom proxy that serves one of those text-only IDs will now advertise image support and send input_image payloads that the upstream model cannot handle.

Useful? React with 👍 / 👎.

Broad claude catch-all may over-match text-only models

id.includes("claude") matches every Claude variant, including known text-only deployments like claude-instant-1 and claude-2.0. Those models will now receive input: ["text", "image"] as the default even though they don't support images.

For a heuristic this is probably fine (better to default to vision-capable than to silently disable it for modern claude-3+ models), but it's worth noting. If you want tighter matching you could scope it to claude-3 and above:

id.includes("claude-3") ||
id.includes("claude-sonnet") ||
id.includes("claude-haiku") ||
id.includes("claude-opus") ||

Also note that llava, pixtral, phi-3-vision, and minicpm-v style models won't match the current heuristic — but that's probably acceptable given those are less common custom-provider deployments.

This is a comment left during a code review.
Path: src/commands/onboard-custom.ts
Line: 56-68

Comment:
**Broad `claude` catch-all may over-match text-only models**

`id.includes("claude")` matches every Claude variant, including known text-only deployments like `claude-instant-1` and `claude-2.0`. Those models will now receive `input: ["text", "image"]` as the default even though they don't support images.

For a heuristic this is probably fine (better to default to vision-capable than to silently disable it for modern claude-3+ models), but it's worth noting. If you want tighter matching you could scope it to `claude-3` and above:

```ts
id.includes("claude-3") ||
id.includes("claude-sonnet") ||
id.includes("claude-haiku") ||
id.includes("claude-opus") ||
```

Also note that `llava`, `pixtral`, `phi-3-vision`, and `minicpm-v` style models won't match the current heuristic — but that's probably acceptable given those are less common custom-provider deployments.

How can I resolve this? If you propose a fix, please make it concise.

Re-onboard silently overwrites deliberate text-only config

shouldUpgradeNonAzureVisionInput only checks whether model.input is currently ["text"], but this is indistinguishable from a user who intentionally restricted a vision-capable model ID to text-only (e.g., because their custom deployment endpoint doesn't actually expose vision, or they want cost controls). Re-running onboard --custom will silently change their config with no opt-out.

A concrete failure path: user deploys claude-sonnet-4-6 behind a text-only proxy and explicitly sets input: ["text"]. After re-onboard, input becomes ["text", "image"], and any image attachment will now be forwarded to a deployment that rejects it at runtime.

Consider adding a user-settable sentinel — for example only upgrade configs that still carry the generated name: "${modelId} (Custom Provider)" pattern (strongly suggesting they were never hand-edited), or introduce an explicit inferredInput: true flag set at generation time that the upgrade path uses as the gate:

// only auto-upgrade if the input was inferred by onboard, not user-set
return model.input.length === 1 && model.input[0] === "text" && model._inferredInput === true;

Without such a guard the upgrade is a one-way destructive migration for users with intentionally restricted configs.

This is a comment left during a code review.
Path: src/commands/onboard-custom.ts
Line: 693-700

Comment:
**Re-onboard silently overwrites deliberate text-only config**

`shouldUpgradeNonAzureVisionInput` only checks whether `model.input` is currently `["text"]`, but this is indistinguishable from a user who *intentionally* restricted a vision-capable model ID to text-only (e.g., because their custom deployment endpoint doesn't actually expose vision, or they want cost controls). Re-running `onboard --custom` will silently change their config with no opt-out.

A concrete failure path: user deploys `claude-sonnet-4-6` behind a text-only proxy and explicitly sets `input: ["text"]`. After re-onboard, `input` becomes `["text", "image"]`, and any image attachment will now be forwarded to a deployment that rejects it at runtime.

Consider adding a user-settable sentinel — for example only upgrade configs that still carry the generated `name: "${modelId} (Custom Provider)"` pattern (strongly suggesting they were never hand-edited), or introduce an explicit `inferredInput: true` flag set at generation time that the upgrade path uses as the gate:

```ts
// only auto-upgrade if the input was inferred by onboard, not user-set
return model.input.length === 1 && model.input[0] === "text" && model._inferredInput === true;
```

Without such a guard the upgrade is a one-way destructive migration for users with intentionally restricted configs.

How can I resolve this? If you propose a fix, please make it concise.

Preserve explicit text-only custom input on re-onboard

When a user has intentionally kept a non-Azure custom model text-only (for example because their proxy only accepts text for a Claude/Gemini-style ID), re-running openclaw onboard --custom now overwrites that choice to [text, image]. That regresses the existing “preserve user-customized fields” behavior covered in src/commands/onboard-custom.test.ts, and it has a real runtime effect because both src/agents/pi-embedded-runner/run/attempt.ts and src/agents/openai-ws-stream.ts decide whether to forward image parts from model.input. So a harmless API-key refresh can turn a working text-only custom provider into one that starts sending unsupported image payloads.

Useful? React with 👍 / 👎.

Extend the vision heuristic to GPT-4.1 and o-series

This matcher still leaves several mainstream OpenAI vision models text-only. buildCopilotModelDefinition() marks gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, o1, o1-mini, and o3-mini as input: ["text", "image"] in src/providers/github-copilot-models.ts, and src/media-understanding/runner.vision-skip.test.ts treats gpt-4.1 as a native vision model. If a user onboards a custom OpenAI-compatible proxy serving one of those IDs, applyCustomApiConfig() still writes input: ["text"] because the heuristic only matches gpt-4o/gpt-5, so image attachments remain disabled for a common class of custom models this change is meant to fix.

Useful? React with 👍 / 👎.

Redundant model.id !== modelId guard

shouldUpgradeNonAzureVisionInput is only ever called inside the model.id === modelId ? ... branch (line 706), so the model.id !== modelId clause will never be true. The guard is dead code and could mislead a future reader into thinking this function might be invoked in a broader context.

This is a comment left during a code review.
Path: src/commands/onboard-custom.ts
Line: 693

Comment:
**Redundant `model.id !== modelId` guard**

`shouldUpgradeNonAzureVisionInput` is only ever called inside the `model.id === modelId ? ...` branch (line 706), so the `model.id !== modelId` clause will never be true. The guard is dead code and could mislead a future reader into thinking this function might be invoked in a broader context.

```suggestion
    if (isAzure || !isLikelyVisionCapableModel) {
```

How can I resolve this? If you propose a fix, please make it concise.

Include o4 models in the non-Azure vision matcher

This widens the OpenAI heuristic to o1/o3, but o4 is still excluded. The repo already treats o4-mini as image-capable in the Azure path (src/commands/onboard-custom.test.ts:472-490 expects input: ["text", "image"]), so a non-Azure OpenAI-compatible endpoint serving the same model will still be onboarded as text-only here. Because downstream image forwarding is gated on model.input.includes("image"), attachments stay disabled for that model family.

Useful? React with 👍 / 👎.

Cover multimodal families we already ship in the catalog

The new heuristic still misses several image-capable IDs that are already first-class in our own catalogs. For example, moonshotai/Kimi-K2.5 and both meta-llama/Llama-4-* models are input: ["text", "image"] in src/agents/together-models.ts:21-33 and src/agents/together-models.ts:49-75, and unsloth/gemma-3-27b-it is marked the same in src/agents/chutes-models.ts:111-117. If a user onboards an OpenAI-compatible proxy exposing any of those IDs, this code still writes input: ["text"], so image attachments remain unavailable even though the upstream model supports vision.

Useful? React with 👍 / 👎.