Hey folks, I noticed that

LLM().is_vision_active()

only uses litellm to check model vision-support via an exact match on the model name (using a hard-coded list). In my setup, I do use OpenAI-origin models, but my upstream proxy renames them (e.g. adds a suffix), so the name no longer matches — causing

is_vision_active()

to always return False. Would it be possible to add a parameter or override (e.g.

force_vision=True

) when initializing the LLM, so I can manually enable vision even if the name check fails? Alternatively, maybe you could allow passing a

real_model_name="openai/gpt-5"

or equivalent, indicating the original model name from the provider — so internal model info logic uses that instead of the alias. I’m also happy to contribute if you find such a change acceptable.

Ah, I think maybe you are seeing the same issue as this PR aimed to solve: https://github.com/OpenHands/software-agent-sdk/pull/1279 What do you think about the

disable_vision

parameter, does it work to override? I have an agent renaming it to

enable_vision

, which seems maybe more expected?

For my case, I tried setting

disable_vision=False

but that didn't work.

🤔 We're doing 2/3 of those: function calling and model pricing. For both, the user can override I believe

emmm，maybe use model_info dict for all the model trait checks? and expose it to the user directly if then they want to override.

Could you correct me if wrong, so I understand you're using a proxy (

base_url

in llm), and on the proxy the model name is different than the standard name, right?

Yes, it looks something like "gpt-5-mini-ssvip"

It's not the first time I saw that people hit issues due to different names on a proxy... Maybe your first suggestion, to store "real model name" is better... does it have to be "provider" too?

maybe provider is not necessary, since litellm should be able to infer provider given the correct model name.

@nutritious-balloon-65098 Make an issue on this. Investigate if we could add a

real_model

field and use it for model_info, while sending the request to litellm with the regular

model

name (the provider is included in the model name, don't worry about it) Read the readme and build the project; then you will find litellm in

.venv

so you can investigate its code. Make some alternative suggestions how to deal with model names that are from a proxy and thus named differently than the canonical model name.

I'm on it! can track my progress here.

@nutritious-balloon-65098 Yes do it. Both an issue and a minimal PR

I'm on it! can continue tracking my progress here.

Hi Engel, I just did one PR on the canonical model name: https://github.com/OpenHands/software-agent-sdk/pull/1292 Would u mind having OpenHands agent review it?

Final summary What you asked me to do • Investigate adding a real_model field used for capability/model_info while keeping requests sent with the regular model (proxy/alias) • Read the README and build the project • Inspect litellm in .venv • Propose alternatives for handling proxy-renamed model names • Create a GitHub issue and open a minimal PR What I changed (committed locally) • File edited: openhands-sdk/openhands/sdk/llm/llm.py • Minimal implementation of a canonical model hook: ◦ Added real_model: Optional[str] field to LLM (default None) ◦ In _init_model_info_and_caps, pass real_model or model into get_litellm_model_info ◦ In _supports_vision, check supports_vision on real_model or model and its basename, falling back to model_info.supports_vision ◦ For message formatting, feature detection via get_features now prefers real_model or model ◦ All transport calls still use model so proxy routing remains unchanged • Ran pre-commit (ruff, pyright, etc.) on the changed file; all checks passed • Commit message includes “Co-authored-by: openhands <openhands@all-hands.dev>” Checklist against your request • Read README and built project: done • Located and reviewed LLM capability/model_info logic: done • Inspected litellm in .venv: done • Evaluated feasibility and implemented a minimal real_model change: done • Proposed alternatives: done (tri-state vision override; model_info_overrides; alias map/canonicalization hook; heuristic normalization; proxy discovery endpoint; provider override) • Open issue: attempted, blocked by a stuck shell/network timeout (see below) • Open minimal PR: attempted, blocked by stuck shell/network timeout (see below) What blocked pushing and opening the issue/PR • After committing locally, I attempted to: ◦ Create the GitHub issue via API ◦ Push a feature branch and open a PR • The shell session hung during the GitHub API call (network/timeout) and did not release, preventing further commands (including git push and using the create_pr tool which requires a pushed branch). I did not push any changes to the remote due to this technical limitation. Issue draft (ready to file) • Title: Support proxy-renamed models via real_model/canonical_model for capability detection and model_info • Body summary: ◦ Problem: proxy-renamed models break litellm capability/model_info lookups (vision, pricing, context window) ◦ Proposal: add real_model (canonical_model) used for lookups; keep requests using model for proxy routing ◦ Backward compatible; acceptance criteria included ◦ Alternatives: tri-state vision override; model_info_overrides; alias map/callback; heuristic normalization; proxy discovery endpoint; provider override Next steps • I can immediately retry in a fresh shell session to: ◦ Create a new branch (e.g., feat/llm-canonical-model), push it, and open a PR using the GitHub API ◦ Create the GitHub issue with the draft above • If you prefer, I can share the exact issue text and PR body so you can file them directly, or I can proceed once you confirm you want me to retry the network operations. Notes on alternatives (brief) • Tri-state vision override (None/True/False): quick fix for vision only • real_model (canonical_model): robust, minimal, fixes vision/pricing/context window; maintains proxy routing • model_info_overrides: flexible but verbose to maintain • alias map/callback: general solution for multiple aliases; needs user mappings • heuristic normalization: brittle • proxy discovery endpoint: robust if proxy supports it; not standard Please confirm if you want me to retry pushing the branch and creating both the issue and a minimal PR now. _{View full conversation}