Enrich discovered models with model info

[xz-dev]

Summary

Fixes #2.

• Query a LiteLLM-style model info endpoint by default, while gracefully continuing when unavailable.
• Filter non-chat models by default when model_info.mode is present.
• Skip embedding models detected from model ids so OpenCode never receives unsupported embedding modalities.
• Populate OpenCode context limits from max_input_tokens, max_output_tokens, and max_tokens.
• Populate reasoning and reasoning-effort variants from LiteLLM capability metadata.
• Preserve provider model id casing while using case-insensitive metadata lookup fallback.
• Document provider overrides for custom model info endpoints and disabling non-chat filtering.

Testing

• npm run typecheck
• npm test -- --run
• /bin/opencode debug config --print-logs --log-level ERROR
• /bin/opencode models litellm --print-logs --log-level ERROR
• /bin/opencode run "Reply with OK only." --model litellm/deepseek-v3.2 --print-logs --log-level ERROR

Notes

npm run lint currently fails before linting because this repo uses ESLint 9 but only has .eslintrc.json, so ESLint cannot find eslint.config.js.

[yuhp]

Thanks for the implementation. I pushed a follow-up commit to keep the LiteLLM metadata enrichment while making the integration more provider-specific and extensible.

What Changed

• Model info enrichment is now opt-in instead of querying /v1/model/info for every OpenAI-compatible provider by default.
• Providers can enable it with both modelsDiscovery.modelInfoEndpoint and modelsDiscovery.modelInfoFormat:

{
  "modelsDiscovery": {
    "modelInfoEndpoint": "/v1/model/info",
    "modelInfoFormat": "litellm"
  }
}

• The LiteLLM-specific parsing and enrichment logic was moved into src/utils/model-info/litellm.ts.
• The main config enhancement flow now goes through a small model-info registry keyed by modelInfoFormat, so future formats can be added without growing provider-specific logic in enhance-config.ts.
• The generic model info fetcher now returns raw data, and each format-specific enricher owns its response parsing.
• Existing LiteLLM enrichment behavior is preserved for:
  • context/input/output limits
  • reasoning support
  • reasoning-effort variants
  • non-chat filtering
  • embedding model skipping

Why

/v1/model/info is a LiteLLM-specific extension rather than part of the generic OpenAI-compatible API contract. Querying it globally would add an extra request and send a non-standard endpoint hit to providers that are unlikely to support it.

Question

Could you check whether this still covers your LiteLLM usage?

In particular, is explicitly setting both of these acceptable for your setup?

{
  "modelInfoEndpoint": "/v1/model/info",
  "modelInfoFormat": "litellm"
}

[yuhp]

I’m going to proceed with merging this since the follow-up commit keeps the LiteLLM enrichment behavior while making it opt-in and provider-specific.
The final behavior will be:

• /v1/models remains the default discovery path for OpenAI-compatible providers.
• LiteLLM model metadata enrichment is available when explicitly configured with:

  {
    "modelsDiscovery": {
      "modelInfoEndpoint": "/v1/model/info",
      "modelInfoFormat": "litellm"
    }
  }

• Non-chat filtering, context limits, reasoning support, and reasoning-effort variants are preserved for LiteLLM metadata.
• The model info enrichment path is now extensible through the modelInfoFormat registry, so we can add more provider-specific metadata formats later without changing the main discovery flow.
  If this does not cover your LiteLLM setup, we can adjust in a follow-up PR.