Q1 — opt-in vs always-on default?

[weselben]

Question

Should the response-path think-block translation be:

• (a) opt-in, default off (env-gated, e.g. GOMODEL_TRANSLATE_THINK_BLOCKS=false default)
• (b) always-on, with no opt-out
• (c) opt-in per surface (chat vs responses vs messages individually)

Look at precedent PR ENTERPILOT#508 (Kimi Code provider) and the compression /
guardrails opt-in pattern in this repo, plus maintainer preferences on
silent behaviour changes vs explicit config. The translation is
lossless-by-construction (the text content stays in the message, just
moves to a structured field), but it can change wire-shape behaviour
clients depend on, so the safer default is probably opt-in. Decide.

[weselben]

opt out per surface per env key (as overwrite) or per webui individually from another

[weselben]

Resolution

Default on, per-surface opt-out:

• env keys per surface: THINK_EXTRACT_CHAT_ENABLED, THINK_EXTRACT_RESPONSES_ENABLED, THINK_EXTRACT_MESSAGES_ENABLED (each defaulting to the global THINK_EXTRACT_ENABLED).
• WebUI per-surface override: follow-up task; dashboard runtime-settings pattern (pro.compression.level) is the precedent.

Implementation ticket: T8.