[FEATURE]: Add Omniroute provider with dynamic model discovery

[disonjer]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Add Omniroute as a built-in provider in OpenCode.

Omniroute is an OpenAI-compatible provider/gateway. It can expose user-defined/custom models, so a static bundled model list is not enough. Users currently need to configure Omniroute manually as a custom OpenAI-compatible provider and keep model definitions in sync themselves.

I found related issues about dynamic model discovery for generic OpenAI-compatible custom providers, but this request is specifically for first-class Omniroute support:

• Auto-discover models from OpenAI-compatible provider endpoints #6231
• [FEATURE]: Detect model(s) using the /v1/models route on custom provider #25624
• [Feature Request]: Allow dynamic model passthrough for custom OpenAI-compatible providers without explicit declaration #18219

Proposed behavior:

• Add a built-in omniroute provider.
• Implement it as an OpenAI-compatible provider, e.g. via @ai-sdk/openai-compatible.
• Support dynamic model discovery for Omniroute, so models added by the user in Omniroute become available in OpenCode without manually editing the OpenCode config.
• If possible, use Omniroute's OpenAI-compatible model listing endpoint, for example /v1/models, or a provider-specific discovery endpoint if Omniroute exposes one.

Why this helps:

• Omniroute users can add their own custom models and route them through one OpenAI-compatible endpoint.
• OpenCode would show the actual available Omniroute models instead of requiring users to duplicate model metadata in config.
• This makes Omniroute consistent with the provider UX for model gateways while preserving custom model support.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• Feature request titles must start with [FEATURE]: (e.g. [FEATURE]: Add Omniroute provider with dynamic model discovery)
• The feature request template requires checking the verification checkbox confirming the feature hasn't been suggested before

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Auto-discover models from OpenAI-compatible provider endpoints #6231: Auto-discover models from OpenAI-compatible provider endpoints (same core request: dynamic /v1/models discovery for OpenAI-compatible providers)
• [FEATURE]: Detect model(s) using the /v1/models route on custom provider #25624: [FEATURE]: Detect model(s) using the /v1/models route on custom provider (very similar: auto-detect models via /v1/models on custom providers)
• [Feature Request]: Allow dynamic model passthrough for custom OpenAI-compatible providers without explicit declaration #18219: [Feature Request]: Allow dynamic model passthrough for custom OpenAI-compatible providers without explicit declaration (closely related: dynamic model support for custom OpenAI-compatible providers)

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thank you for updating the issue! It now follows the contributing guidelines and looks good. We appreciate the clear description and the context you provided about Omniroute.

[XidaoApi]

Dynamic model discovery is the right approach for OpenAI-compatible gateways. Static model lists break the moment the gateway adds or removes models. Here's a pattern that works reliably across diverse backends:

1. Probe /v1/models with graceful fallback

async def discover_models(base_url: str, api_key: str, timeout: float = 5.0) -> list[str]:
    """Discover available models from an OpenAI-compatible endpoint."""
    try:
        async with httpx.AsyncClient(timeout=timeout) as client:
            resp = await client.get(
                f"{base_url.rstrip('/')}/v1/models",
                headers={"Authorization": f"Bearer {api_key}"}
            )
            if resp.status_code == 200:
                data = resp.json()
                return [m["id"] for m in data.get("data", [])]
    except (httpx.TimeoutException, httpx.ConnectError):
        pass
    return []  # Caller falls back to static list

2. Cache with TTL and background refresh

Model lists rarely change mid-session. Cache for 5-15 minutes with a background refresh:

class ModelCache:
    def __init__(self, ttl_seconds=300):
        self._cache: dict[str, tuple[float, list[str]]] = {}
        self._ttl = ttl_seconds

    async def get_models(self, base_url, api_key) -> list[str]:
        key = base_url.rstrip("/")
        now = time.time()
        if key in self._cache:
            ts, models = self._cache[key]
            if now - ts < self._ttl:
                return models
        models = await discover_models(base_url, api_key)
        if models:
            self._cache[key] = (now, models)
        return models

3. Capability inference from model IDs

When the /v1/models response doesn't include capability metadata, infer from naming patterns:

• *instruct* -> chat/completion
• *embed* -> embeddings only
• *vision* or *omni* -> multimodal
• *tts* / *whisper* -> audio

This won't be perfect but handles 90% of real-world model names.

4. Health check on startup

Run a lightweight /v1/models probe when the provider is first configured and surface errors immediately in the UI rather than waiting for the first chat request to fail.

This pattern is what many multi-provider tools use (including gateway services) — it eliminates the "model not found" class of errors that users hit when gateways update their model catalog.