fix(thinking): keep client thinking config for uncatalogued models

[warelik]

Summary

A model declared in config but missing from the bundled internal/registry/models/models.json silently loses reasoning: the client's generationConfig.thinkingConfig is stripped before dispatch, so includeThoughts never reaches the upstream. The provider still runs and bills the reasoning pass, it just returns no thought parts.

This affects every model newer than the embedded catalog — which is the normal case for a freshly released Gemini model added through gemini-api-key.models[].

Root cause

internal/modelconfig/model_info.go built the capability snapshot for a configured model and unconditionally cleared the user-defined marker:

info := registry.LookupStaticModelInfo(baseName)  // nil for an uncatalogued model
if info == nil {
    info = &registry.ModelInfo{}                  // Thinking == nil
}
...
info.UserDefined = false

So an uncatalogued model resolves to Thinking == nil and UserDefined == false. internal/thinking/apply.go reads exactly that pair as an authoritative "this model cannot reason":

if modelInfo.Thinking == nil {
    config := extractThinkingConfig(body, providerFormat)
    if hasThinkingConfig(config) || summaryConfig.Mode != SummaryUnspecified {
        return StripThinkingConfig(body, providerFormat), nil
    }

The two states are not the same: an absent catalog entry means the capability is unknown, not proven absent. Only the second justifies stripping. This also contradicts the documented contract on IsUserDefinedModel, which states that models configured via *-api-key.models[] should have their thinking configuration applied directly and validated by the upstream.

Live evidence

Same prompt, same key, same model (gemini-3.7-flash behind a configured alias), before the fix:

	parts	thought part	thoughtsTokenCount
Direct to generativelanguage.googleapis.com	2	present, 1192 chars	302
Through the proxy	1	missing	188

The upstream request log confirms the cause — the whole block was removed:

Body: {"contents": [...], "generationConfig": {},"safetySettings":[...]}

Non-zero thoughtsTokenCount alongside a missing thought part is the signature of the bug: Gemini only emits thought parts when includeThoughts is set, but it reasons (and bills) regardless.

Change

ResolveModelInfo now distinguishes unknown capability from proven-absent capability:

info.UserDefined = !catalogKnown && support == nil

• Uncatalogued model, no explicit thinking: block → unknown capability → snapshot is user-defined → the caller's configuration is forwarded and the upstream validates it.
• Catalog-known model whose entry records no thinking support → absence is authoritative → still stripped, unchanged.
• Explicit thinking: block in config → still wins, unchanged.

After the fix (same live setup)

gemini-native  parts=2, part[0] thought=true (1029 chars), thoughtsTokenCount=157
OpenAI path    reasoning_content len=1171, reasoning_tokens=780
upstream body  "generationConfig": {"thinkingConfig": {"thinkingBudget": 2048, "includeThoughts": true}}

Test plan

• New internal/modelconfig/model_info_unknown_thinking_test.go covers both directions: an uncatalogued model must retain includeThoughts and thinkingBudget through ApplyThinkingWithModelInfoAndSummary, and a catalog model documented without reasoning must keep its authoritative absence.
• Two existing tests asserted the previous contract (TestResolveModelInfoUnknownModelKeepsMissingCapability, TestAttachResolvedAPIKeyModelInfoBindsUnknownConfiguredCapability) and are updated with the rationale inline.
• go build ./... — clean
• go test ./... -count=1 — 0 failures
• gofmt -l — clean
• Live verification against Google Gemini on both the Gemini-native and OpenAI-compatible paths, as quoted above.

Mirror

CPA: router-for-me/CLIProxyAPI#4991 (identical changes)