[Question/Bug] Inconsistent JSON serialization for ThinkingConfig fields (snake_case vs camelCase)

## Description
We have observed a discrepancy between the field naming convention used by the Python SDK when serializing `ThinkingConfig` and the field names defined in the official REST API documentation.

## Observed Behavior
When sending requests, the Python SDK serializes the thinking configuration fields into the JSON request body using snake_case:
* `thinking_level`
* `thinking_budget`
* `include_thoughts`

## Expected Behavior
According to the REST API documentation (and the standard convention for this API), these fields are expected to be serialized as camelCase:
* `thinkingLevel`
* `thinkingBudget`
* `includeThoughts`

It appears that even when users attempt to configure these parameters, the SDK enforces snake_case serialization in the outgoing network request.

## Impact
While the upstream API endpoint might be permissive enough to accept snake_case, this inconsistency causes issues for strict schema parsers or middleware that rely on the documented REST API contract. It also creates ambiguity regarding the correct parameter naming convention for developers.

## Questions
1. Is the use of snake_case in the JSON payload intended behavior?
2. If so, does the API officially support both camelCase and snake_case formats, and can the documentation be updated to reflect this?
3. If not, is this a serialization bug within the SDK that should be fixed to match the camelCase standard?