Bug: CLI silently falls back to Claude Opus and ignores default_provider in config.toml

[ppravdin]

Bug Description

When launching jcode, it ignores default_provider = "openrouter" and default_model configured in ~/.jcode/config.toml.
Instead, because --provider defaults to auto, it automatically discovers Claude credentials on the system and boots directly into claude-opus-5.

Steps to Reproduce

1. Configure ~/.jcode/config.toml with:

[provider]
default_provider = "openrouter"
default_model = "inclusionai/ling-3.0-flash-vl:free"

2. Ensure Claude credentials exist on the system (e.g. Claude Code OAuth/session).
3. Run jcode.

Expected Behavior

J-Code should respect default_provider from ~/.jcode/config.toml and start with the configured provider and model (in this case OpenRouter).

Actual Behavior

J-Code ignores config.toml, activates claude with claude-opus-5, sends heavy init payloads (MCP schemas, memory indexing) on cold start, and burns unexpected credits on expensive proprietary models without user consent or explicit selection.

[dajiaohuang]

Current master appears to apply provider.default_provider before auto-detection: provider/startup.rs selects the configured provider when it is configured, then applies default_model; otherwise it logs that the preference is unavailable and falls back. Could you share the exact config path, jcode version/commit, CLI or environment overrides, and --trace startup lines from a failing run? That will distinguish a stale binary/config parse from a precedence bug before changing routing.

[ppravdin]

To clarify the exact behavior: it does not fall back to Claude OAuth or an Anthropic subscription.

It uses my active OpenRouter API key and routes requests to Claude Opus via OpenRouter, burning paid OpenRouter credits on Opus instead of respecting the free model (:free) explicitly specified in config.toml.

Environment & Details

• Version: jcode v0.84.0 (57d587899) on Linux x86_64
• Config file: ~/.jcode/config.toml
• Provider configured: openrouter with an active OPENROUTER_API_KEY
• Configured default model: inclusionai/ling-3.0-flash-vl:free

Configuration used

[provider]
default_provider = "openrouter"
default_model = "inclusionai/ling-3.0-flash-vl:free"

[providers.openrouter]
type = "openai-compatible"
base_url = "https://openrouter.ai/api/v1"
env_file = "openrouter.env"
api_key_env = "OPENROUTER_API_KEY"
default_model = "inclusionai/ling-3.0-flash-vl:free"

What actually happens

1. When launching jcode, it connects to OpenRouter using the configured API key.
2. However, it overrides or ignores default_model = "inclusionai/ling-3.0-flash-vl:free".
3. Instead, it routes to Claude Opus via OpenRouter.
4. On cold start, it immediately sends heavy initialization payloads (MCP schemas, system context, indexing) to Opus via OpenRouter, consuming paid balance unexpectedly.

Expected Behavior

default_model specified under [provider] and [providers.openrouter] must strictly dictate the model sent to OpenRouter. It should never substitute Opus when the user has explicitly selected a free or specific model.

[dajiaohuang]

Thanks for the version and config details. The current master startup path applies [provider].default_provider before auto-detection and then binds [provider].default_model; to distinguish a regression in v0.84.0 from a stale daemon/config parse, could you paste the --trace startup lines around provider selection from the failing binary (redacting paths and keys)?

[ppravdin]

Here are the exact startup log lines around provider and model selection from jcode v0.84.0 (57d587899) on Linux x86_64 with ~/.jcode/config.toml:

[INFO] jcode starting
[INFO] Context limit cache: openrouter:inclusionai/ling-3.0-flash-vl:free = 262k
[AUTH] AUTH event=runtime_activation_clear_initial_provider provider=runtime selection=auto
[AUTH] AUTH event=auth_status_check_fast provider=all jcode=not_configured claude=not_configured openai=not_configured openrouter=not_configured azure=not_configured azure_api_auth=false azure_entra=false bedrock=not_configured copilot=not_configured antigravity=not_configured gemini=not_configured cursor=not_configured google=not_configured
[WARN] Found existing Claude credentials from Claude Code at ~/.claude/.credentials.json but jcode will not read them without confirmation.
[WARN] Found existing OpenRouter credentials from OpenCode auth.json at ~/.local/share/opencode/auth.json but jcode will not read them without confirmation.
[INFO] [TIMING] auto_provider_bootstrap: detect=5ms, external_import=false, supplemental=6ms, final_has_any=false
[INFO] No credentials configured; booting deferred-auth MultiProvider for in-TUI onboarding login
[WARN] Preferred provider 'openrouter' is not configured, using auto-detected default
[WARN] Failed to apply default_model 'inclusionai/ling-3.0-flash-vl:free' from config: OPENROUTER_API_KEY not found in environment
[INFO] Provider Anthropic missing at use site; reconciling auth from disk
[AUTH] AUTH event=auth_changed_received provider=multi-provider
[AUTH] AUTH event=auth_status_cache_invalidated provider=all
...
[INFO] begin telemetry session provider=Claude model=claude-opus-5 resumed=false parent=false
[INFO] ENV_SNAPSHOT {"captured_at":"...","provider":"Claude","model":"claude-opus-5","jcode_version":"v0.84.0 (57d587899)","os":"linux","arch":"x86_64"}
...
[INFO] Provider OpenRouter missing at use site; reconciling auth from disk
[ERROR] Failed to restore session model 'claude-opus-5' via 'openrouter:claude-opus-5': OPENROUTER_API_KEY not found in environment or ~/.config/jcode/openrouter.env (retried after reloading auth from disk)

Analysis from the trace:

1. Config parsing vs env resolution: In config.toml, env_file = "openrouter.env" was configured, but during the initial provider selection phase startup.rs / auto_provider_bootstrap checked OPENROUTER_API_KEY before sourcing env_file (or looked in ~/.config/jcode/openrouter.env instead of ~/.jcode/openrouter.env).
2. Fallback routing: Because OPENROUTER_API_KEY was deemed missing at that early check, it triggered:
   [WARN] Preferred provider 'openrouter' is not configured, using auto-detected default
[WARN] Failed to apply default_model 'inclusionai/ling-3.0-flash-vl:free' from config: OPENROUTER_API_KEY not found in environment
3. Opus selection: Once the fallback kicked in, instead of staying on the requested model or failing safely, it defaulted the active session model to claude-opus-5. Later when OpenRouter credentials were recovered/reconciled, it attempted routing claude-opus-5 through openrouter:claude-opus-5.

[dajiaohuang]

The trace confirms the fallback is credential availability, not an explicit Claude selection: startup could not find OPENROUTER_API_KEY before applying the configured provider/model, then correctly entered deferred auth and restored the session as Opus. One remaining detail determines whether this is a path regression or an env-file timing bug: where exactly is openrouter.env on the failing host—~/.jcode/openrouter.env or ~/.config/jcode/openrouter.env—and does jcode config report the same app-config directory? The current loader reads the platform app-config directory; once that location is confirmed I can target a regression without guessing at credential precedence.

[ppravdin]

On this host:

1. openrouter.env location:

   • It is located at ~/.jcode/openrouter.env (/home/p/.jcode/openrouter.env).
   • ~/.config/jcode/openrouter.env does not exist (only minor telemetry/hotkey files are in ~/.config/jcode/).

2. Config file location:

   • The config file is read from ~/.jcode/config.toml (as seen in the log: Failed to parse config file /home/p/.jcode/config.toml).
   • Note that jcode config is not a valid subcommand in v0.84.0 (error: unrecognized subcommand 'config').

3. Log discrepancy on env path:
   Notice this error from the log when it attempts to reload/restore:
   OPENROUTER_API_KEY not found in environment or /home/p/.config/jcode/openrouter.env
   So while config.toml is loaded from ~/.jcode/config.toml, the relative env_file = "openrouter.env" path resolution appears to look in ~/.config/jcode/openrouter.env (platform XDG app config dir) instead of the active config directory ~/.jcode/ where both config.toml and openrouter.env reside.

[1jehuang]

Thanks, the confirmed credential-file location explains the lookup failure: relative credential files currently use the platform config directory, separately from ~/.jcode/config.toml. Source review also confirms that unavailable configured defaults can fall back to another selection. Because this affects routing and potential charges, I am escalating the startup/auth behavior rather than changing credential precedence in an automatic patch. Recommendation: preserve the requested route through deferred authentication, or stop before sending when an explicit default cannot be honored. The supplied trace does not itself establish a billed request. Please share the complete redacted TOML parse error too, since a parse failure is distinct from a missing key. Never include credentials.

---

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

[ppravdin]

Here is the exact redacted TOML parse error from the log when config.toml failed to load:

[ERROR] Failed to parse config file: Failed to parse config file ~/.jcode/config.toml: TOML parse error at line 12, column 8
   |
12 | type = "openrouter"
   |        ^^^^^^^^^^^^
unknown variant `openrouter`, expected one of `open-ai-compatible`, `openai-compatible`, `openai_compatible`, `anthropic-compatible`, `anthropic_compatible`, `open-router`

Context around how this interacted with the startup flow:

1. When type = "openrouter" was parsed, the parser failed with the unknown variant error shown above.
2. Because the config file failed to parse, the configured provider table and env_file directives were not applied, leading to Login skipped. Run jcode login when you're ready to authenticate.
3. After correcting the type to openai-compatible, the config parsed, but the credential file lookup failed due to the relative path issue (~/.config/jcode/openrouter.env vs ~/.jcode/openrouter.env).
4. In deferred/unauthenticated state, the session then fell back to Opus instead of halting or honoring the configured free model default.

Appreciate you escalating the startup/auth fallback behavior — stopping execution with an explicit error when a configured default cannot be honored will prevent unexpected routing/charges in these edge cases.

[dajiaohuang]

Thanks for the redacted trace. It distinguishes three stages: the unsupported openrouter value rejects the whole TOML file, so its env_file setting is never applied; after the type is corrected, the relative env-file path still resolves under the XDG config directory rather than ~/.jcode; then deferred startup selects Opus instead of stopping when the explicit default cannot be honored. That confirms the parse failure is separate from the credential-path and fallback behavior. The startup/fail-closed choice remains with maintainers; please keep credentials out of the thread.