fix(model): apply thinkingBudget to OpenAI-compatible API request

[lizhihao688]

Summary

GenerateOptions.thinkingBudget was stored in the options object but never mapped to OpenAIRequest, causing the thinking_budget parameter to be silently dropped from all OpenAI-compatible API calls.

Root Cause

In OpenAIChatFormatter.applyOptions(), all other GenerateOptions fields were correctly mapped to OpenAIRequest setters — but thinkingBudget was missing. Additionally, OpenAIRequest had no thinking_budget field at all.

Field	Status (before fix)
temperature → request.setTemperature()	✅ handled
reasoningEffort → request.setReasoningEffort()	✅ handled
maxCompletionTokens → request.setMaxCompletionTokens()	✅ handled
thinkingBudget → NOT HANDLED — silently dropped	❌ missing

This breaks reasoning/thinking models (e.g. Qwen3, DeepSeek-R1): without the cap, the model exhausts all max_completion_tokens on reasoning_content and returns an empty content field.

Changes

• OpenAIRequest.java: Add @JsonProperty("thinking_budget") field with getter/setter and Builder method
• OpenAIChatFormatter.java: Map GenerateOptions.thinkingBudget in applyOptions()
• OpenAIChatFormatterTest.java: Add ThinkingBudgetTests with 4 unit tests covering: direct options, default fallback, override, and absent cases

Testing

All 948 existing unit tests pass. spotless:check passes.

Before / After

Before — thinkingBudget silently ignored:

GenerateOptions.builder()
    .maxCompletionTokens(8192)
    .thinkingBudget(4096) // silently dropped — not in HTTP request
    .build()
// HTTP body: {"max_completion_tokens": 8192}

After — thinking_budget correctly sent:

GenerateOptions.builder()
    .maxCompletionTokens(8192)
    .thinkingBudget(4096) // now included
    .build()
// HTTP body: {"max_completion_tokens": 8192, "thinking_budget": 4096}

Fixes #1697

[CLAassistant]

All committers have signed the CLA.

[AgentScopeJavaBot]

🤖 AI Review

This is a clean, well-scoped bug fix that correctly addresses the missing thinkingBudget → OpenAIRequest mapping in OpenAIChatFormatter.applyOptions(). The implementation follows the exact same pattern used by all other option fields (temperature, reasoningEffort, topP, etc.), ensuring consistency. The new thinking_budget JSON property on OpenAIRequest is properly guarded by the class-level @JsonInclude(NON_NULL), so it will not leak into requests for providers that don't support it. The four unit tests cover the essential cases (direct, default-fallback, override, absent) and mirror the test structure used for other options. The Javadoc on the new field is informative and cites a concrete provider example. No logic, concurrency, or serialization issues found.

[AgentScopeJavaBot]

[praise] Clean, minimal addition that follows the established apply-options pattern exactly. The null-guard and getOptionOrDefault usage are consistent with every other field in this method — easy to review and low risk.

[AgentScopeJavaBot]

[praise] Good Javadoc — citing a concrete provider (DashScope Qwen3) gives future maintainers the context they need to understand why this non-standard field exists on an OpenAI-compatible DTO.

[AgentScopeJavaBot]

[praise] Solid test coverage for a single-field addition. The four cases (direct set, default fallback, override, absent) mirror the pattern used by other option test groups and give confidence that getOptionOrDefault semantics are correct.

[AgentScopeJavaBot]

🤖 AI Review

This is a clean, well-scoped bug fix that correctly addresses the missing thinkingBudget → OpenAIRequest mapping in OpenAIChatFormatter.applyOptions(). The implementation follows the exact same pattern used by all other option fields (temperature, reasoningEffort, topP, etc.), ensuring consistency. The new thinking_budget JSON property on OpenAIRequest is properly guarded by the class-level @JsonInclude(NON_NULL), so it will not leak into requests for providers that don't support it. The four unit tests cover the essential cases (direct, default-fallback, override, absent) and mirror the test structure used for other options. The Javadoc on the new field is informative and cites a concrete provider example. No logic, concurrency, or serialization issues found.

[AgentScopeJavaBot]

[praise] Clean, minimal addition that follows the established apply-options pattern exactly. The null-guard and getOptionOrDefault usage are consistent with every other field in this method — easy to review and low risk.

[AgentScopeJavaBot]

[praise] Good Javadoc — citing a concrete provider (DashScope Qwen3) gives future maintainers the context they need to understand why this non-standard field exists on an OpenAI-compatible DTO.

[AgentScopeJavaBot]

[praise] Solid test coverage for a single-field addition. The four cases (direct set, default fallback, override, absent) mirror the pattern used by other option test groups and give confidence that getOptionOrDefault semantics are correct.