[Bug] Qoder provider cannot discover or use Sonus (`smodel`) and Cantus (`cmodel`)

Summary

The Qoder provider in 9router cannot discover or use the newly available Sonus and Cantus models.

The same Qoder account can see and select both models in the official Qoder CLI, but 9router's Qoder model-list resolver returns only 16 models and omits them.

The internal Qoder model IDs appear to be:

• Sonus: smodel
• Cantus: cmodel

Adding sonus, qoder/sonus, or qoder/smodel manually does not work because 9router cannot obtain the corresponding model_config.

Environment

• 9router: 0.5.75
• Qoder CLI: 1.1.54
• Node.js: 24.15.0
• OS: Linux x64
• Qoder authentication: Device OAuth
• Tested on: September 17, 2026

Steps to reproduce

1. Connect a Qoder account to 9router using Device OAuth.

2. Verify that the official Qoder CLI lists Sonus and Cantus:

   bash复制

   qodercli --list-models

The relevant output includes:

 Sonus
 Cantus

1. Refresh the model list for the same Qoder connection in 9router.

2. Observe that 9router returns only 16 models and does not include Sonus or Cantus.

3. Manually add or send a request using one of the following model names:

   sonus qoder/sonus qoder/smodel

4. The request fails because the model configuration is unavailable.

Expected behavior

9router should discover the models exposed to the authenticated Qoder account and return entries similar to:

[ { "id": "qoder/smodel", "name": "Sonus" }, { "id": "qoder/cmodel", "name": "Cantus" } ]

Requests using qoder/smodel and qoder/cmodel should use their corresponding upstream Qoder model configurations.

Optionally, the display-name aliases sonus and cantus could resolve to these internal IDs.

Actual behavior

The Qoder model resolver returns 16 models, but smodel and cmodel are absent.

A request for Sonus fails with:

qoder: model_config for "sonus" not yet known (run a model list fetch or check upstream connectivity)

Using the correct internal ID, smodel, does not solve the issue because the current Qoder model-list response used by 9router does not contain its raw model configuration.

Additional investigation

The official Qoder CLI resolves the display name Sonus to the internal model key:

smodel

Similarly, Qoder's model metadata maps:

Sonus -> smodel Cantus -> cmodel

The current 9router Qoder integration appears to use the legacy Qoder model-list flow and expects a response containing a chat model array.

That response currently contains models such as:

auto ultimate performance efficient lite qmodel_38max qfmodel qmodel_latest qmodel kmodel_latest kmodel gmodel gfmodel dmodel dfmodel mmodel

However, it does not contain:

smodel cmodel

This suggests that the current Qoder CLI and 9router are using different model-catalog protocols or catalog versions.

Suggested fix

1. Update the Qoder provider to use the current Qoder model-catalog protocol.

2. Preserve the complete raw model_config for every enabled model.

3. Map Qoder display names to their internal model IDs:

   • Sonus → smodel
   • Cantus → cmodel

4. Allow requests using:

   • qoder/smodel
   • qoder/cmodel

5. Add a clearer error when a manually configured model is not present in the upstream catalog.

6. Add integration tests covering models that are available in the current Qoder CLI but absent from the legacy model-list response.

Workaround

No reliable workaround is currently available.

Adding a custom model or alias such as:

sonus -> qoder/smodel

is insufficient because the adapter still requires the upstream raw model_config.