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

[neavo]

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?