Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Control UI thinking dropdown label ignores agents.defaults.thinkingDefault and per-model params.thinking [3 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#72407•Fetched 2026-04-27 05:30:25
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
NotecAGNotecAG
Participants
NotecAGNotecAGsteipetesteipete
Timeline (top)
cross-referenced ×3closed ×1commented ×1labeled ×1

Control UI thinking dropdown shows "Default (off)" even when both agents.defaults.thinkingDefault: "adaptive" and per-model agents.defaults.models[<key>].params.thinking: "adaptive" are configured for non-Claude-4.6 models — backend resolution is correct, only the UI label is wrong.

Root Cause

## Root cause analysis (minified bundle)

Fix Action

Workaround

Setting reasoning: true on the model entry in models.providers.<p>.models[] changes the dropdown label to Default (low) — still incorrect (the actual config is adaptive) but less misleading than off. No backend side effect because the per-model params.thinking already overrides the catalog heuristic.

PR fix notes

PR #72460: fix(gateway): align UI thinking default with runtime resolver

Description (problem / solution / changelog)

Fixes #72407

Problem

The Control UI thinking-level dropdown shows Default (off) for non-reasoning models (e.g. Ollama Gemma) even when openclaw.json sets agents.defaults.thinkingDefault: "adaptive" and per-model params.thinking: "adaptive". The runtime applies adaptive correctly (verified by ~60% thinking-token usage), but the label disagrees, which sends users on long debugging chases over a working config.

Root cause

The bug is server-side, not in the minified UI pa(). Both the gateway-emitted session-defaults payload and per-row session payload were calling the catalog-only heuristic resolveThinkingDefaultForModel({ provider, model }) from auto-reply/thinking.ts, which never consults the user config:

  • src/gateway/session-utils.ts:1057 (getSessionDefaults)
  • src/gateway/session-utils.ts:1432 (per-session row)

Meanwhile, the runtime resolver resolveThinkingDefault({ cfg, ... }) in src/agents/model-thinking-default.ts correctly walks per-model → global → Claude-4.6 heuristic → catalog fallback. The UI faithfully renders whatever label arrives — it inherits the wrong source value.

Fix

Switch both call sites to resolveThinkingDefault({ cfg, provider, model }). cfg is already in scope at both sites (getSessionDefaults takes it directly; the row formatter has it through formatSession). The catalog fallback path inside resolveThinkingDefault calls the same helper the gateway used to call directly, so the no-config behavior is preserved.

Tests

New file src/gateway/session-utils.thinking-default.test.ts covers:

  • global thinkingDefault: "adaptive" for a non-reasoning model — UI gets adaptive
  • per-model params.thinking set with no global — UI gets adaptive
  • per-model overrides global — UI gets the per-model value
  • no thinking config at all — UI label matches resolveThinkingDefault's fallback (regression guard against UI/runtime drift)

Test plan

  • pnpm exec vitest run src/gateway/session-utils.thinking-default.test.ts — 12/12 (4 cases × 3 shards)
  • pnpm tsgo:core:test — clean
  • pnpm lint — clean
  • Manual: reproduce with the issue's openclaw.json, restart gateway, confirm dropdown reads Default (adaptive)

Changed files

  • src/gateway/session-utils.thinking-default.test.ts (added, +112/-0)
  • src/gateway/session-utils.ts (modified, +6/-6)

PR #63418: fix(control-ui): show effective thinking default in session settings

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem: the Control UI thinking dropdown labeled the default option from a frontend model heuristic instead of the session's effective configured default.
  • Why it matters: sessions could show Default (low) or Default (off) even when runtime resolution was using a configured global or per-agent default such as high.
  • What changed: the gateway now includes effectiveThinkingDefault on each session row, sessions.list passes the gateway model catalog through when deriving that field, and session-row resolution now preserves per-agent thinkingDefault precedence before falling back to model/global defaults.
  • What did NOT change (scope boundary): this does not change actual thinking behavior, session override persistence, or model-default resolution logic outside the displayed Control UI label and session metadata payload.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes # N/A
  • Related # N/A
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: the Control UI derived Default (...) from a frontend model heuristic instead of consuming the active session's effective configured default from backend session/config state.
  • Missing detection / guardrail: there was no focused coverage for catalog-dependent reasoning defaults or for non-default agents with their own thinkingDefault.
  • Contributing context (if known): the session row originally carried only the explicit override (thinkingLevel), not the separately resolved effective default.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/gateway/session-utils.test.ts, src/gateway/server.sessions.gateway-server-sessions-a.test.ts, ui/src/ui/views/chat.test.ts
  • Scenario the test should lock in: configured global defaults, catalog-backed reasoning defaults, and per-agent thinkingDefault overrides should all produce the same Default (...) label the runtime uses for the active session.
  • Why this is the smallest reliable guardrail: the bug crosses the gateway session payload seam, model-catalog resolution, per-agent config precedence, and the Control UI render path.
  • Existing test that already covers this (if any): None before this PR.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

The Control UI thinking dropdown now shows the actual effective default for the active session, including global configured defaults, catalog-backed reasoning defaults, and per-agent thinkingDefault overrides, instead of stale heuristic values such as low or off.

Diagram (if applicable)

Before:
[open session settings] -> [session row has only thinkingLevel override]
-> [UI recomputes default from heuristic] -> [Default (low/off)]

After:
[open session settings] -> [session row includes effectiveThinkingDefault]
-> [gateway resolves catalog + config precedence] -> [Default (high/minimal/etc.)]

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: local dev branch build via pnpm build and pnpm openclaw gateway run --bind loopback --port 18789 --force
  • Model/provider: live local Control UI session on openai-codex/gpt-5.4
  • Integration/channel (if any): Control UI session settings
  • Relevant config (redacted): agents.defaults.thinkingDefault: high

Steps

  1. Configure agents.defaults.thinkingDefault or an agent-specific agents.list[].thinkingDefault.
  2. Open the Control UI for the active session and inspect the thinking dropdown label.
  3. Compare the label against the runtime chat.history / session payload from the running gateway.

Expected

  • The dropdown shows the same effective default that runtime session resolution uses.

Actual

  • Before this change, the dropdown could show heuristic values like Default (low) or Default (off) even while runtime resolution used a configured higher default.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: ran pnpm test src/gateway/session-utils.test.ts src/gateway/server.sessions.gateway-server-sessions-a.test.ts ui/src/ui/views/chat.test.ts; rebuilt with pnpm build; restarted the local branch-run gateway; verified via direct RPC that sessions.list returned effectiveThinkingDefault: "high" and chat.history returned thinkingLevel: "high"; manually verified the Control UI rendered Default (high) after refresh.
  • Edge cases checked: confirmed catalog-backed reasoning defaults are used when available; confirmed effectiveThinkingDefault stays unset when the backend cannot resolve it safely; confirmed per-agent thinkingDefault takes precedence in session-row defaults.
  • What you did not verify: full pnpm test, non-Control-UI surfaces, or provider-specific behavior beyond the reproduced live local session.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk: older gateways that do not return effectiveThinkingDefault would otherwise lose the label.
    • Mitigation: the Control UI keeps the existing model-heuristic fallback when the new field is absent.
  • Risk: session-list metadata could drift from runtime thinking precedence again if config/catalog resolution changes in only one path.
    • Mitigation: the PR adds focused gateway helper, handler, and UI coverage for catalog-backed and per-agent default cases.

Changed files

  • src/gateway/server-methods/chat.ts (modified, +14/-4)
  • src/gateway/server-methods/sessions.ts (modified, +3/-1)
  • src/gateway/server.chat.gateway-server-chat.test.ts (modified, +39/-0)
  • src/gateway/server.sessions.gateway-server-sessions-a.test.ts (modified, +55/-0)
  • src/gateway/session-utils.test.ts (modified, +127/-0)
  • src/gateway/session-utils.ts (modified, +51/-5)
  • src/plugins/jiti-loader-cache.test.ts (modified, +1/-5)
  • ui/src/ui/views/chat.test.ts (modified, +106/-27)

PR #72593: fix: align thinking default label with config

Description (problem / solution / changelog)

Summary

Align the Control UI thinking default label with the same config-aware precedence the backend already uses.

Changes

  • switch gateway session/default thinking resolution from the model-only heuristic to resolveThinkingDefault(...)
  • keep session rows and defaults aligned with configured agents.defaults.thinkingDefault and per-model params.thinking
  • add regression coverage for both session defaults and session rows

Testing

  • pnpm vitest run src/gateway/session-utils.test.ts

Fixes openclaw/openclaw#72407

Changed files

  • src/gateway/session-utils.test.ts (modified, +47/-0)
  • src/gateway/session-utils.ts (modified, +6/-6)

Code Example

{
     "agents": {
       "defaults": {
         "thinkingDefault": "adaptive",
         "models": {
           "ollama/<any-non-claude-4.6-model>": {
             "params": { "thinking": "adaptive" }
           }
         }
       }
     }
   }

---

{
  "agents": {
    "defaults": {
      "thinkingDefault": "adaptive",
      "models": {
        "ollama/gemma4:hermes-e4b": { "params": { "thinking": "adaptive" } },
        "ollama/gemma4:26b":       { "params": { "thinking": "off" } }
      }
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "api": "ollama",
        "baseUrl": "http://<host>:11434",
        "models": [
          { "id": "gemma4:hermes-e4b", "contextWindow": 131072, "maxTokens": 8192 },
          { "id": "gemma4:26b",       "contextWindow": 131072, "maxTokens": 12288 }
        ]
      }
    }
  }
}

---

## Root cause analysis (minified bundle)

The label `Default (X)` displayed in the thinking dropdown is computed by a function (let's call it `pa()` in the minified code) located in `/app/dist/control-ui/assets/index-Dba6JFRP.js`:


function pa(e){
  let t=ca(e.provider), n=e.model.trim();
  return t===`anthropic`&&oa.test(n)||t===`amazon-bedrock`&&sa.test(n)
    ?`adaptive`
    :e.catalog?.find(t=>t.provider===e.provider&&t.id===e.model)?.reasoning
      ?`low`
      :`off`
}
// with regexes:
//   oa = /^claude-(?:opus|sonnet)-4(?:\.|-)6(?:$|[-.])/i
//   sa = /claude-(?:opus|sonnet)-4(?:\.|-)6(?:$|[-.])/i


`pa()` only consults three sources:
1. **Hardcoded heuristic**: provider == `anthropic` (or `amazon-bedrock`) AND model name matches the Claude 4.6 regex → returns `"adaptive"`.
2. **Catalog `reasoning` flag**: if the catalog entry for that model has `reasoning: true` → returns `"low"`.
3. **Otherwise** → returns `"off"`.

It **never reads** `agents.defaults.thinkingDefault`, `agents.defaults.models[<canonicalKey>].params.thinking`, or `agents.list[<id>].thinkingDefault` to determine the displayed default.

## Backend behavior (correct)

The backend `resolveThinkingDefault()` function in `model-selection-CTdyYoio.js` properly walks the precedence chain:
1. Per-model `agents.defaults.models[canonicalKey].params.thinking`
2. Global `agents.defaults.thinkingDefault`
3. `resolveThinkingDefaultForModel` heuristic fallback (Claude 4.6 + reasoning catalog flag)

So the actual `think:` value sent to Ollama is correct — only the dropdown label is wrong.

## Empirical evidence

A 58-scenario benchmark on `gemma4:hermes-e4b` configured with `params.thinking: "adaptive"` produced **60% thinking tokens** in output (averaged across all scenarios). With the same model configured `"off"`, the same benchmark produced **0% thinking tokens**. This proves the backend correctly transmits `think: true` to Ollama's native `/api/chat` even though the UI label keeps showing `Default (off)`.

## Workaround

Setting `reasoning: true` on the model entry in `models.providers.<p>.models[]` changes the dropdown label to `Default (low)` — still incorrect (the actual config is `adaptive`) but less misleading than `off`. No backend side effect because the per-model `params.thinking` already overrides the catalog heuristic.

---

function pa(e){
  // 1. Per-model configured thinking
  const configuredModels = e.cfg?.agents?.defaults?.models;
  const canonicalKey = `${e.provider}/${e.model}`;
  const perModel = configuredModels?.[canonicalKey]?.params?.thinking;
  if (perModel && ['off','minimal','low','medium','high','xhigh','adaptive'].includes(perModel)) {
    return perModel;
  }

  // 2. Global default
  const globalDefault = e.cfg?.agents?.defaults?.thinkingDefault;
  if (globalDefault) return globalDefault;

  // 3. Existing fallback (Claude 4.6 heuristic + catalog reasoning flag)
  const t = ca(e.provider), n = e.model.trim();
  return t===`anthropic`&&oa.test(n)||t===`amazon-bedrock`&&sa.test(n)
    ?`adaptive`
    : e.catalog?.find(t=>t.provider===e.provider&&t.id===e.model)?.reasoning
      ?`low`
      :`off`;
}
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Control UI thinking dropdown shows "Default (off)" even when both agents.defaults.thinkingDefault: "adaptive" and per-model agents.defaults.models[<key>].params.thinking: "adaptive" are configured for non-Claude-4.6 models — backend resolution is correct, only the UI label is wrong.

Steps to reproduce

  1. Configure openclaw.json with: 
    {
  "agents": {
    "defaults": {
      "thinkingDefault": "adaptive",
      "models": {
        "ollama/<any-non-claude-4.6-model>": {
          "params": { "thinking": "adaptive" }
        }
      }
    }
  }
}
  2. Restart the Gateway.
  3. Open the Control UI on a session using that model.
  4. Look at the thinking-level dropdown label.

Expected behavior

The dropdown label should display Default (adaptive) matching the configured per-model and global default. Per the documented precedence in /gateway/config-agents and the backend resolveThinkingDefault in model-selection-CTdyYoio.js, the per-model params.thinking should win, falling back to agents.defaults.thinkingDefault.

Actual behavior

The dropdown displays Default (off) instead. The backend resolveThinkingDefault correctly resolves to adaptive and Ollama receives think: true in the /api/chat payload (verified empirically — see logs section). Only the UI label in the dropdown is wrong, which is misleading when debugging or sharing setup.

OpenClaw version

2026.4.15

Operating system

Debian 12 (Docker container ghcr.io/openclaw/openclaw:latest, host Proxmox 8.4 LXC)

Install method

docker (ghcr.io/openclaw/openclaw:latest)

Model

ollama/gemma4:hermes-e4b (custom Modelfile from gemma4:e4b base)

Provider / routing chain

openclaw -> ollama (native /api/chat) -> remote Ollama instance on RTX 5070

Additional provider/model setup details

Two agents (hermes-fast / hermes-deep) sharing one Ollama provider with custom-tuned models. Per-model thinking config in openclaw.json:

{
  "agents": {
    "defaults": {
      "thinkingDefault": "adaptive",
      "models": {
        "ollama/gemma4:hermes-e4b": { "params": { "thinking": "adaptive" } },
        "ollama/gemma4:26b":       { "params": { "thinking": "off" } }
      }
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "api": "ollama",
        "baseUrl": "http://<host>:11434",
        "models": [
          { "id": "gemma4:hermes-e4b", "contextWindow": 131072, "maxTokens": 8192 },
          { "id": "gemma4:26b",       "contextWindow": 131072, "maxTokens": 12288 }
        ]
      }
    }
  }
}

No systemPromptOverride. Backend resolveThinkingDefault correctly returns adaptive for the e4b agent and off for the 26b agent.

Logs, screenshots, and evidence

## Root cause analysis (minified bundle)

The label `Default (X)` displayed in the thinking dropdown is computed by a function (let's call it `pa()` in the minified code) located in `/app/dist/control-ui/assets/index-Dba6JFRP.js`:


function pa(e){
  let t=ca(e.provider), n=e.model.trim();
  return t===`anthropic`&&oa.test(n)||t===`amazon-bedrock`&&sa.test(n)
    ?`adaptive`
    :e.catalog?.find(t=>t.provider===e.provider&&t.id===e.model)?.reasoning
      ?`low`
      :`off`
}
// with regexes:
//   oa = /^claude-(?:opus|sonnet)-4(?:\.|-)6(?:$|[-.])/i
//   sa = /claude-(?:opus|sonnet)-4(?:\.|-)6(?:$|[-.])/i


`pa()` only consults three sources:
1. **Hardcoded heuristic**: provider == `anthropic` (or `amazon-bedrock`) AND model name matches the Claude 4.6 regex → returns `"adaptive"`.
2. **Catalog `reasoning` flag**: if the catalog entry for that model has `reasoning: true` → returns `"low"`.
3. **Otherwise** → returns `"off"`.

It **never reads** `agents.defaults.thinkingDefault`, `agents.defaults.models[<canonicalKey>].params.thinking`, or `agents.list[<id>].thinkingDefault` to determine the displayed default.

## Backend behavior (correct)

The backend `resolveThinkingDefault()` function in `model-selection-CTdyYoio.js` properly walks the precedence chain:
1. Per-model `agents.defaults.models[canonicalKey].params.thinking`
2. Global `agents.defaults.thinkingDefault`
3. `resolveThinkingDefaultForModel` heuristic fallback (Claude 4.6 + reasoning catalog flag)

So the actual `think:` value sent to Ollama is correct — only the dropdown label is wrong.

## Empirical evidence

A 58-scenario benchmark on `gemma4:hermes-e4b` configured with `params.thinking: "adaptive"` produced **60% thinking tokens** in output (averaged across all scenarios). With the same model configured `"off"`, the same benchmark produced **0% thinking tokens**. This proves the backend correctly transmits `think: true` to Ollama's native `/api/chat` even though the UI label keeps showing `Default (off)`.

## Workaround

Setting `reasoning: true` on the model entry in `models.providers.<p>.models[]` changes the dropdown label to `Default (low)` — still incorrect (the actual config is `adaptive`) but less misleading than `off`. No backend side effect because the per-model `params.thinking` already overrides the catalog heuristic.

Impact and severity

Affected: any user configuring thinking via openclaw.json on non-Claude-4.6 models (Ollama local/cloud, custom OpenAI-compat providers, vLLM behind openai-completions, etc.)

Severity: Medium — cosmetic only (backend behavior is correct), but causes significant debugging confusion. In our case, several hours were spent assuming the configured thinking: "adaptive" was not being applied because the dropdown showed Default (off). We added per-agent thinkingDefault overrides, dropdown manual selections, and various other workarounds before identifying that the label itself was the lie.

Frequency: Always (deterministic, every session UI render) for any model not matching the Claude 4.6 hardcoded regex.

Consequence: Users add manual dropdown overrides to "fix" what looks like a config that is not being applied. Those manual selections then override the per-message resolution and create cascading confusion about which value is actually in effect. The documentation in /gateway/config-agents describes agents.defaults.thinkingDefault and agents.list[].thinkingDefault as effective — but at least the UI label doesn't reflect this.

Additional information

Suggested fix

Align the UI's pa() with the backend's resolveThinkingDefault precedence:

function pa(e){
  // 1. Per-model configured thinking
  const configuredModels = e.cfg?.agents?.defaults?.models;
  const canonicalKey = `${e.provider}/${e.model}`;
  const perModel = configuredModels?.[canonicalKey]?.params?.thinking;
  if (perModel && ['off','minimal','low','medium','high','xhigh','adaptive'].includes(perModel)) {
    return perModel;
  }

  // 2. Global default
  const globalDefault = e.cfg?.agents?.defaults?.thinkingDefault;
  if (globalDefault) return globalDefault;

  // 3. Existing fallback (Claude 4.6 heuristic + catalog reasoning flag)
  const t = ca(e.provider), n = e.model.trim();
  return t===`anthropic`&&oa.test(n)||t===`amazon-bedrock`&&sa.test(n)
    ?`adaptive`
    : e.catalog?.find(t=>t.provider===e.provider&&t.id===e.model)?.reasoning
      ?`low`
      :`off`;
}

This requires the UI to receive the relevant subset of agents.defaults.* config (likely already accessible via existing config.get or session metadata payload).

Related observation

This is potentially part of a broader UI/backend divergence pattern around resolved configuration values. Worth auditing other dropdowns (model selector, verbose, elevated, reasoning) for similar issues where the displayed label uses a different resolution logic than the backend.

Setup context

NotecNetwork homelab, custom Hermes AI agent stack (2 agents Fast/Deep on shared Ollama backend), running OpenClaw 2026.4.15 in Docker on Proxmox LXC, RTX 5070 12GB GPU. Configuration is in version control and reproducible.

extent analysis

TL;DR

The UI label for the thinking dropdown can be corrected by updating the pa() function to align with the backend's resolveThinkingDefault precedence.

Guidance

  • Review the pa() function in /app/dist/control-ui/assets/index-Dba6JFRP.js to understand the current logic for determining the thinking dropdown label.
  • Update the pa() function to include the per-model configured thinking and global default thinking values, as suggested in the issue.
  • Verify that the updated pa() function correctly reflects the configured thinking values for non-Claude-4.6 models.
  • Consider auditing other dropdowns for similar issues where the displayed label may not match the backend resolution logic.

Example

The suggested fix provides an updated pa() function that aligns with the backend's resolveThinkingDefault precedence:

function pa(e){
  // 1. Per-model configured thinking
  const configuredModels = e.cfg?.agents?.defaults?.models;
  const canonicalKey = `${e.provider}/${e.model}`;
  const perModel = configuredModels?.[canonicalKey]?.params?.thinking;
  if (perModel && ['off','minimal','low','medium','high','xhigh','adaptive'].includes(perModel)) {
    return perModel;
  }

  // 2. Global default
  const globalDefault = e.cfg?.agents?.defaults?.thinkingDefault;
  if (globalDefault) return globalDefault;

  // 3. Existing fallback (Claude 4.6 heuristic + catalog reasoning flag)
  const t = ca(e.provider), n = e.model.trim();
  return t===`anthropic`&&oa.test(n)||t===`amazon-bedrock`&&sa.test(n)
    ?`adaptive`
    : e.catalog?.find(t=>t.provider===e.provider&&t.id===e.model)?.reasoning
      ?`low`
      :`off`;
}

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The dropdown label should display Default (adaptive) matching the configured per-model and global default. Per the documented precedence in /gateway/config-agents and the backend resolveThinkingDefault in model-selection-CTdyYoio.js, the per-model params.thinking should win, falling back to agents.defaults.thinkingDefault.

#api#memory management#API rate limit#retriever error#indexing error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING