Honor explicit 'disable' for reasoning effort

[rayss868]

Context

This PR addresses critical issues with the reasoning_effort implementation for the OpenAI Compatible provider. Previously, selecting the "disable" option in the UI did not actually prevent the provider from sending reasoning parameters (specifically binary thinking) to the API. Additionally, the UI state was prone to desynchronization because the settings wrapper was dropping non-reasoning fields.

Implementation

1. Backend Logic Fix: Updated BaseOpenAiCompatibleProvider to implement an isExplicitlyDisabled check. This check ensures that if the user selects "disable", both thinking: { type: "enabled" } and reasoning_effort parameters are omitted from the final API request.
2. UI State Synchronization: Refactored the ThinkingBudget component wrapper in OpenAICompatible.tsx to forward all configuration fields to the parent state handler. This prevents settings like thinkingBudget from being lost and ensures the UI correctly reflects the "disabled" state when selected.
3. Conflict Resolution: Manually resolved Git merge conflicts and fixed syntax errors that arose during the synchronization of these fixes across project directories.

Screenshots

before	after
Reasoning remained active even when "disable" was selected in the dropdown.	Selecting "disable" strictly omits all reasoning parameters from the API call.

How to Test

1. Open Kilo Code Settings.
2. Select OpenAI Compatible as the API provider.
3. Enable the Set Reasoning Level checkbox.
4. Select disable from the reasoning effort dropdown.
5. Verify Backend: Check the logs or network traffic to ensure neither thinking nor reasoning_effort is sent in the request body.
6. Verify UI: Ensure that selecting "disable" correctly updates the internal apiConfiguration without losing other related fields like thinkingBudget.

Get in Touch

If you have any questions about these changes, feel free to reach out!

[changeset-bot]

⚠️ No Changeset found

Latest commit: 922c72b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR