Bug Report: Custom `openai-compatible` models incorrectly tagged with `copilot:` prefix in model picker

[rahulchirumamilla]

Bug Report: Custom openai-compatible models incorrectly tagged with copilot: prefix in model picker

Summary

When using custom openai-compatible providers (e.g., local MLX servers via the omlx profile), the /model picker incorrectly labels the models with PROVIDER = Copilot and constructs internal model IDs with the copilot: prefix (e.g., copilot:KAT-Coder-V2.5-Dev-OptiQ-4bit). This causes "model not found" errors when selecting the model.

Reproduction

1. Configure a custom provider in ~/.jcode/config.toml:

   [providers.omlx]
   type = "openai-compatible"
   base_url = "http://127.0.0.1:18000/v1"
   default_model = "KAT-Coder-V2.5-Dev-OptiQ-4bit"

2. Start jcode with the profile: jcode --provider-profile omlx
3. Press /model inside the TUI.
4. Observe that the model table shows Copilot in the PROVIDER column and the status bar shows Copilot:KAT Coder V2.5 Dev OptiQ 4bit.
5. Selecting the model results in: Error: Model copilot:KAT-Coder-V2.5-Dev-OptiQ-4bit not found.

Expected Behavior

Models from custom openai-compatible profiles should be tagged with their configured profile name (omlx) or the generic openai-compatible label in the picker, and the model ID should be passed cleanly to the runtime without the copilot: prefix.

Actual Behavior

The picker merges custom profile models into a catalog that incorrectly inherits the copilot provider label from ProviderChoice::Copilot.

Code Location

• src/cli/provider_init.rs: Defines ProviderChoice::Copilot => "copilot" and handles OpenaiCompatible registration via resolve_openai_compatible_profile.
• src/cli/provider_init.rs:1811: init_provider_and_registry likely performs the catalog merge.
• crates/jcode-tui/src/tui/info_widget_model.rs (or related TUI picker components): Renders the table with the incorrect PROVIDER column.

Environment

• jcode v0.64.2 (6c6fbba)
• macOS
• Custom openai-compatible profile pointing to local MLX server.

[1jehuang]

Thanks, the report pinned this down well. Root cause: route resolution for bare model ids only consulted the built-in openai-compatible profiles, never user-defined [providers.<name>] entries from config.toml. Your omlx model matched no known provider, so it fell through to the Copilot heuristic, which labelled it Copilot and built a copilot:<model> id nothing could resolve.

Fixed in #701: named config profiles are now consulted during route resolution, so the model shows PROVIDER = omlx with api_method openai-compatible:omlx. Tests added.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[1jehuang]

Update: the fix is merged to master (#701). Follow-up end-to-end tests are in #702. It will ship in the next release.

--- — Jcode agent (automated triage), on behalf of @1jehuang