Skip to content

fix(providers): gate thinking on model capability; add an installed-font picker - #162

Merged
Zongwei9888 merged 2 commits into
mainfrom
fix/thinking-requires-capable-model
Aug 6, 2026
Merged

fix(providers): gate thinking on model capability; add an installed-font picker#162
Zongwei9888 merged 2 commits into
mainfrom
fix/thinking-requires-capable-model

Conversation

@Zongwei9888

Copy link
Copy Markdown
Collaborator

Description

Two follow-ups to #161: one fixes a bug that PR widened, the other delivers the part of #155 it declined.

A thinking body reaching models that have no thinking mode

ProviderSpec.thinking_style describes the endpoint's dialect — how this API spells a thinking toggle. It says nothing about whether the model behind it has one, and the two were never intersected. Any model routed through a DeepSeek- or Zhipu-compatible endpoint received:

{"thinking": {"type": "enabled"}}

including gpt-4o and llama3. The empty reasoning_content echo rode along with it.

Pre-existing, but #161 widened it by giving Zhipu a style, so it is not waiting for a larger cleanup. Both halves of the answer now live in one place — the catalog knows whether the model thinks, the spec knows how the endpoint writes it — and the style applies only when both agree.

Deliberately not narrowed to a vendor. A capable model reached through an endpoint that speaks a given dialect should get that dialect: gpt-5.4 behind a DeepSeek-compatible gateway still gets the DeepSeek body, because that is the endpoint's contract, not a claim about who built the model.

The font picker #155 actually asked for

#161 shipped a free-text field and argued a fixed dropdown would be a hardcoded guess about the user's machine. The premise was right; the conclusion was not — the browser can be asked.

document.fonts.check() reports whether a family resolves locally, so the candidate list is filtered to what is installed and grouped Interface / Monospace / CJK. Selecting one appends to the field rather than replacing it, which keeps the mixed-script case from #155 working: list the CJK face next to the Latin one and both render through a single fallback chain.

Free text stays the source of truth, so families outside the candidate list remain reachable, and where the Font Loading API is absent the picker hides rather than offering settings that would do nothing.

Testing

  • Python: 1218 passed, 3 skipped
  • Desktop: 148 passed across 24 files; tsc --noEmit, eslint, npm run build clean
  • The thinking gate is verified in reverse — removing it fails 12 of the 28 new cases

Still open from the same investigation

  • AgentDefaults.context_window_tokens is dead config on the modern path. Nothing outside core/compat/ reads it; the runner takes its window from ExecutionProfile, which comes from the catalog. Setting it in deepcode_config.json has no effect today, which matters for the context-length half of [Feature Request]: Adjustable thinking strength & context length for DeepSeek and other reasoning models #153.
  • tests/application/test_automation_goal_runs.py::test_legacy_unreserved_turn_is_never_adopted_as_automation_initial_turn fails ~2/20 on clean main, unrelated to this work.

Zongwei9888 and others added 2 commits August 6, 2026 22:43
`ProviderSpec.thinking_style` describes the endpoint's dialect — how this API
spells a thinking toggle. It says nothing about whether the model behind it
has one, and the two were never intersected, so any model routed through a
DeepSeek- or Zhipu-compatible endpoint received:

    thinking: {"type": "enabled"}

including gpt-4o and llama3, which have no thinking mode at all. The empty
`reasoning_content` echo rode along with it.

Pre-existing, but #161 widened it by giving Zhipu a style, which is why this
is not waiting for a larger cleanup. Both halves of the answer now live in one
place: the catalog knows whether the model thinks, the spec knows how the
endpoint writes it. `model_supports_thinking()` asks the first, and the style
only applies when both agree.

Deliberately not narrowed to a vendor. A capable model reached through an
endpoint that speaks a given dialect should get that dialect — gpt-5.4 behind
a DeepSeek-compatible gateway still gets the DeepSeek body, because that is
the endpoint's contract, not a claim about who made the model.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
#155 asked for a font dropdown. #161 shipped free text instead, on the
grounds that a fixed menu is a hardcoded guess about the user's machine. The
premise was right and the conclusion was not: the browser can be asked.

`document.fonts.check()` answers whether a family resolves here, so the
candidate list is filtered to what is actually installed and grouped by
Interface / Monospace / CJK. Picking one appends it to the field rather than
replacing it, which keeps the CJK case #155 raises working — put the CJK face
alongside the Latin one and mixed text renders through a single fallback
chain.

The list stays advisory. Free text remains the source of truth, so a family
outside the candidates is still reachable, and the candidates themselves cost
nothing when absent because they are filtered out. Where the Font Loading API
is missing the picker hides rather than claiming every family exists.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Zongwei9888
Zongwei9888 merged commit 4e32a98 into main Aug 6, 2026
14 checks passed
@Zongwei9888
Zongwei9888 deleted the fix/thinking-requires-capable-model branch August 6, 2026 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant