[Bug]: Custom (BYOK) model does not appear in the model picker

[chengbot-ai]

Qoderian version

1.0.7

qodercli version

1.1.50

Obsidian and operating system

Obsidian 1.13.7, macOS (Darwin 25.6.0, arm64)

Reproduction steps

1. Configure a custom (BYOK) provider in ~/.qoder/settings.json — a providers entry with type: "openai-compatible", protocol: "anthropic", pointing at a self-hosted Anthropic-compatible endpoint, single model deepseek-flash.
2. Verify the CLI can use it: qodercli -m "<provider_id>/<model>" returns a normal response, and qodercli's own /model picker does offer the custom model.
3. In Obsidian, enable Qoderian, open a chat and open the model picker.

Expected behavior

The custom provider model should appear in Qoderian's model picker (as it does in the CLI) so it can be selected for chats in the vault.

Actual behavior

The picker lists only built-in Qoder models. The custom (BYOK) model never appears and cannot be selected, even though the same ~/.qoder/settings.json and the same CLI installation work outside Obsidian.

Redacted logs or screenshots

Lead from the plugin's bundled SDK transport layer (main.js, v1.0.7):

listByokProviders() and validateByokModel() are declared, but one transport implementation answers with this.unsupported("listByokProviders") / this.unsupported("validateByokModel"). That same no-op group also covers getAvailableModels, setModel, supportedCommands, cancelAsyncMessage, stopTask, backgroundTasks, setPermissionMode, setProxy, generateSessionTitle, addDirectories, applyFlagSettings.

If Qoderian runs on that transport, BYOK provider listing is unavailable, which would explain why custom models never reach the picker.

Not an account/entitlement gate. qodercli logs show the SDK channel reports BYOK as allowed:

[custom-providers] Runtime access checked { source: 'sdk', allowed: true }
[custom-providers] SDK status access updated { allowed: true, allow_byok: 2 }

Note for verification. The custom model additionally needs an explicit fixed thinking budget in settings.json, otherwise the CLI's own requests are rejected with HTTP 400 by the Anthropic-compatible endpoint (reasoning.enabled=true requires an explicit fixed budget for this model):

"model": {
  "preferences": {
    "<provider_id>/<model>": {
      "reasoning": {
        "effort": "max",
        "thinking": { "type": "enabled", "budgetTokens": 8192 }
      }
    }
  }
}

That is a separate CLI-side issue, but worth knowing when verifying a fix here.