I think is ok with me. Would rather not add more env things but maybe in this case and just for this provider. Must be some other way to do config which is relevant to the provider? (I think you can add a variable to the provider and let people set it there - may be better @rabi ?)

I think users would want these to be session specific, so prpbably won't make sense to have it in provider config. The same pattern of env vars are already there for others. CLAUDE_THINKING_ENABLED/CLAUDE_THINKING_BUDGET for Anthropic.

I think you can add a variable to the provider and let people set it there

@michaelneale Hey! Are you ok with the explanation or still want it in provider config? Even if we set in provider config, it can be overridden by env vars[1] and also it does not apply to all models (only gemini 3 models) for google provider.

Else, we can merge this to reduce the latency as we now default to 'low' thinking for our use-cases.

[1] https://github.com/block/goose/blob/main/crates/goose/src/config/base.rs#L637

thanks - is there some way to normalise this, this seems very very hard coded to gemini-3 for something they will probably change their mind over - can it be mapped from some normalised thing in the provider?

thanks - is there some way to normalise this, this seems very very hard coded to gemini-3 for something they will probably change their mind over - can it be mapped from some normalised thing in the provider?

It's a gemini-3 thing and we've these kind of checks elsewhere too. They may change things in the future but we can't predict what api changes they would make. That's the reason I had earlier proposed to just use an env var. There is no way we can give the option of thinking leval to the user before a model is selected during configuration.