Named OpenAI-Compatible Profiles — context_window / reasoning_effort Routing

[wtry]

Bug Report: Named OpenAI-Compatible Profiles — context_window / reasoning_effort Routing
Environment
• jcode version: v0.24.2 (5914474) and also present on latest master
• OS: macOS aarch64 (also affects Linux)

Summary
When using a named OpenAI-compatible profile (e.g. opencode-go, custom profiles defined in
config.toml under [[providers..models]]), the context_window from the per-model config
is never read by the MultiProvider dispatch layer. Instead, all four query methods fall
through to the wrong (empty) provider slot and return incorrect fallback values. API
execution is unaffected (correct slot used), but context-limit-aware features are broken:
compaction budget, UI display, context-limit auto-recovery, etc.

Steps to Reproduce

1. Configure a named profile and model in ~/.jcode/config.toml:

┌─ toml
│ [provider]
│ default_provider = "opencode-go"
│ default_model = "deepseek-v4-flash"

│ [providers.opencode-go]
│ type = "openai-compatible"

│ [[providers.opencode-go.models]]
│ id = "deepseek-v4-flash"
│ context_window = 1048576
└─

2. Login to the profile (OPENCODE_GO_API_KEY env or jcode login --provider opencode-go)

3. Launch jcode

4. Check the context widget — it shows 200k instead of 1M

5. /effort max fails with “Reasoning effort is only supported for OpenRouter and DeepSeek”

Root Cause
In crates/jcode-base/src/provider/mod.rs, four provider trait methods dispatch to the wrong
OpenRouter-slot accessor:

Method │ Uses (wrong) │ Should Use
───────────────────────┼────────────────────────────┼────────────────────────────────────────
context_window() │ self.openrouter_provider() │ self.active_openrouter_execution_provid
│ │ er()
reasoning_effort() │ self.openrouter_provider() │ self.active_openrouter_execution_provid
│ │ er()
set_reasoning_effort() │ self.openrouter_provider() │ self.active_openrouter_execution_provid
│ │ er()
available_efforts() │ self.openrouter_provider() │ self.active_openrouter_execution_provid
│ │ er()

The openrouter_provider() accessor (defined in accessors.rs:60) only returns the generic
OpenRouter slot (registry.real_openrouter()), which is None when a named profile is active.
The correct accessor active_openrouter_execution_provider() (defined in accessors.rs:64)
uses registry.active_openrouter_execution() which first tries the active named compatible
profile, then falls back to generic OpenRouter.

Note that the API execution path in dispatch.rs:164 already uses the correct
self.active_openrouter_execution_provider() — so API requests work fine, but all
context_window/reasoning_effort queries do not.

Additional Bug: profile_supports_reasoning_effort too narrow
crates/jcode-base/src/provider/openrouter.rs:952-954:

┌─ rust
│ fn profile_supports_reasoning_effort(profile_id: Option<&str>) -> bool {
│ matches!(profile_id, Some(id) if id.eq_ignore_ascii_case("deepseek"))
│ }
└─

This only recognizes the "deepseek" profile ID, but many other profiles (e.g. opencode-go)
also serve DeepSeek V4 models that support reasoning_effort. The check should either be
broader (check model name pattern) or configurable.

Additional Bug: openai_reasoning_effort config not read for named profiles
crates/jcode-base/src/provider/openrouter.rs:1239 — new_named_openai_compatible() hardcodes
reasoning_effort: Arc::new(RwLock::new(None)). Unlike OpenAIProvider and AnthropicProvider
which read config.openai_reasoning_effort / config.anthropic_reasoning_effort during
construction, named profile providers never pick up the user’s effort preference from config.

Impact
• Users of opencode-go, custom named profiles, and any [[providers..models]] config
• context_window always falls through to DEFAULT_CONTEXT_LIMIT (200k), causing:
• Premature auto-compaction at 200k instead of model’s true limit (e.g. 1M for DeepSeek V4)
• Wrong context percentage in info widget
• Compaction prompt budget miscalculation
• reasoning_effort unavailable for named profiles using DeepSeek models
• openai_reasoning_effort config value silently ignored

Suggested Fix

1. Replace self.openrouter_provider() with self.active_openrouter_execution_provider() in
   the four affected methods in mod.rs
2. Broaden profile_supports_reasoning_effort to recognize additional profiles, or check
   model name patterns
3. Have new_named_openai_compatible() read config.openai_reasoning_effort for profile
   construction

[1jehuang]

Thanks for the detailed report. Triage status:

1. Primary bug (four dispatch methods using openrouter_provider() instead of active_openrouter_execution_provider()): already fixed on master by c8b5cbd (shipped in v0.25.0). context_window(), reasoning_effort(), set_reasoning_effort(), and available_efforts() all route through the active named compat profile now, so the 200k-instead-of-1M context widget and the /effort rejection should be resolved on >= v0.25.0. Could you update and confirm?

2. profile_supports_reasoning_effort only recognizing deepseek: still present on master (openrouter.rs). Agreed this should be broader or configurable, e.g. a per-profile supports_reasoning_effort config key or model-name matching.

3. openai_reasoning_effort config not read by new_named_openai_compatible(): still present, reasoning_effort is hardcoded to None at construction.

Keeping this open to track 2 and 3.

[1jehuang]

All three parts now fixed on master: (1) dispatch through wrong slot - c8b5cbd, shipped v0.25.0; (2) effort recognition - 54103f8 makes it instance-aware: explicit supports_reasoning_effort = true|false in [providers.<name>] wins, then the deepseek profile, then auto-detection from the active model family, so any compat profile serving deepseek-* models gets /effort (none|low|medium|high|max) automatically; (3) openai_reasoning_effort config is now read at named-profile construction. Regression tests cover all three. Ships in the next release.