Feature Request: Persist discovered models to disk and allow default parameter injection

[beingshafin]

1. Persist discovered models to disk

Currently, discovered models appear to be available only in memory.

Would it be possible to add an option to write the discovered models to a file on disk (for example, a generated JSON file)? This would allow other tool such as the OpenCode GUI desktop app to read and display the discovered models as well, instead of only the CLI/runtime having access to them.

Something like:

• Discover models
• Save the discovered model list to a configurable file
• Keep it updated whenever discovery runs

---

2. Default parameter/template injection for discovered models

It would also be very useful if users could define a default configuration that is automatically merged into every discovered model.

For example:

{
  "attachment": true,
  "reasoning": true,
  "tool_call": true,
  "temperature": true,
  "modalities": {
    "input": ["text", "image", "pdf"],
    "output": ["text"]
  },
  "variants": {
    "max": {
      "thinking": {
        "type": "enabled",
        "budgetTokens": 100000
      }
    }
  }
}

This would let users configure capabilities for all discovered models in one place instead of manually editing every model after discovery.

Possible use cases include:

• Marking all discovered models as supporting image inputs.
• Adding a default "thinking" variant.
• Enabling reasoning/tool calling flags.
• Defining common modalities.
• Setting other default metadata.

Ideally this could be configured through a single template or merge configuration that is applied automatically to every discovered model.

[yuhp]

Thanks for the feature request. I think persisted discovery is a good direction, with one important distinction: this should live outside project-level configuration.

The plugin could persist discovery results per provider_id under its XDG Base Directory data location. Each provider would have its own stored model configuration and refresh/expiry metadata, including a TTL, so the result can be reused by other local consumers without requiring every project to duplicate the discovered model list.

This also suggests a safer alternative to automatic default-template injection. Rather than applying capability overrides blindly at discovery time, the plugin could provide an explicit configuration command that updates the persisted configuration for a selected provider. Users could then review and customize the generated model definitions, including capabilities, modalities, limits, or variants, in a persistent provider-specific location.

This avoids globally advertising unsupported capabilities at runtime while still making bulk customization practical.

I suggest treating the first implementation as:

• provider-specific persisted discovery under the XDG data directory
• TTL-based refresh behavior
• an explicit command to inspect or update the persisted provider configuration

Automatic template injection during discovery can remain a separate discussion after the persistence format and command workflow are established.