Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix(client): normalize and strip model names before request #2633

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hamzasheedi wants to merge 1 commit into openai:main
base: main
Choose a base branch
Loading
from hamzasheedi:patch-1

Conversation

Copy link

@hamzasheedi hamzasheedi commented Sep 14, 2025
edited
Loading

Summary

This change improves how model names are handled inside _base_client.py.

Previously, if a developer passed a model name with uppercase letters (e.g. "GPT-4O-MINI") or extra spaces (e.g. " gpt-4o-mini "), the client would send it directly to the API. Since the backend is strict and only accepts exact lowercase identifiers (like "gpt-4o-mini"), this would cause:

BadRequestError: unexpected model name format

Changes

  • Added a normalization step in BaseClient._build_request:
    • Automatically converts model names to lowercase.
    • Removes leading/trailing whitespace.

Why

This small improvement:

  • Prevents confusing 400 errors when users accidentally use uppercase or spacing.
  • Makes the SDK more developer-friendly and forgiving without altering API behavior.
  • Increases compatibility across both OpenAI and Gemini endpoints (since Gemini APIs accessed through the OpenAI Agent SDK also require strict lowercase model identifiers).
  • Keeps compatibility with existing OpenAI models — now "GPT-4", " gPt-4 ", and "gpt-4" all resolve correctly.

Examples

Before (OpenAI model)

client.chat.completions.create(model="GPT-4O-MINI", messages=[...])
# ❌ Error: unexpected model name format

After (OpenAI model)

client.chat.completions.create(model="GPT-4O-MINI", messages=[...])
# ✅ Works: normalized to "gpt-4o-mini"

Before (Gemini model used with OpenAIChatCompletionsModel)

client = AsyncOpenAI(
 api_key=API_KEY,
 base_url="https://generativelanguage.googleapis.com/v1beta/openai/"
)
model = OpenAIChatCompletionsModel(
 model=" GeMiNi-2.5-flAsH ", # note extra spaces / mixed casing
 openai_client=client,
)
# ❌ Error: unexpected model name format

After (Gemini model with fix applied)

model = OpenAIChatCompletionsModel(
 model=" GeMiNi-2.5-flAsH ", # note extra spaces / mixed casing
 openai_client=client,
)
# ✅ Works: normalized to "gemini-2.5-flash"

Impact

  • 🚫 No breaking changes.
  • ✅ Safer and more user-friendly client behavior.
  • ✅ Prevents tricky case/spacing bugs for both OpenAI and Gemini model IDs.
  • ✅ Helps beginners and production apps avoid unnecessary API errors.

🔑 Why This Matters

Whether using standard OpenAI models (gpt-4o, gpt-4o-mini, etc.) or integrating Google Gemini models via the OpenAI Agent SDK, developers will no longer run into frustrating case/format errors just because of casing or whitespace.

This makes the SDK robust, cross-compatible, and beginner-friendly.

  • I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested

Additional context & links

"I’m aware this repo is auto-generated. If this should instead be fixed in the generator or spec, I’m happy to move the patch there. Please advise."

## Summary
This change improves how model names are handled inside `_base_client.py`.
Previously, if a developer passed a model name with uppercase letters 
(e.g. `"GPT-4O-MINI"`) or extra spaces (e.g. `" gpt-4o-mini "`), 
the client would send it directly to the API. Since the backend is strict and only accepts exact lowercase identifiers (like `"gpt-4o-mini"`), this would cause:
```
BadRequestError: unexpected model name format
```
---
## Changes
- Added a normalization step in `BaseClient._build_request`:
 - Automatically converts model names to lowercase. 
 - Removes leading/trailing whitespace. 
---
## Why
This small improvement:
- Prevents confusing **400 errors** when users accidentally use uppercase or spacing. 
- Makes the SDK more developer-friendly and forgiving without altering API behavior. 
- Increases compatibility across both **OpenAI** and **Gemini** endpoints (since Gemini APIs accessed through the OpenAI Agent SDK also require strict lowercase model identifiers). 
- Keeps compatibility with existing OpenAI models — now `"GPT-4"`, `" gPt-4 "`, and `"gpt-4"` all resolve correctly. 
---
## Examples
### Before (OpenAI model)
```python
client.chat.completions.create(model="GPT-4O-MINI", messages=[...])
# ❌ Error: unexpected model name format
```
### After (OpenAI model)
```python
client.chat.completions.create(model="GPT-4O-MINI", messages=[...])
# ✅ Works: normalized to "gpt-4o-mini"
```
---
### Before (Gemini model used with `OpenAIChatCompletionsModel`)
```python
client = AsyncOpenAI(
 api_key=API_KEY,
 base_url="https://generativelanguage.googleapis.com/v1beta/openai/"
)
model = OpenAIChatCompletionsModel(
 model=" Gemini-2.5-flash ", # note extra spaces / mixed casing
 openai_client=client,
)
# ❌ Error: unexpected model name format
```
### After (Gemini model with fix applied)
```python
model = OpenAIChatCompletionsModel(
 model=" GeMiNi-2.5-flAsH ",
 openai_client=client,
)
# ✅ Works: normalized to "gemini-2.5-flash"
```
---
## Impact
- 🚫 No breaking changes. 
- ✅ Safer and more user-friendly client behavior. 
- ✅ Prevents tricky case/spacing bugs for both OpenAI and Gemini model IDs. 
- ✅ Helps beginners and production apps avoid unnecessary API errors. 
---
## 🔑 Why This Matters
Whether using standard **OpenAI models** (`gpt-4o`, `gpt-4o-mini`, etc.) or integrating **Google Gemini models** via the OpenAI Agent SDK, developers will no longer run into frustrating case/format errors just because of casing or whitespace.
This makes the SDK **robust, cross-compatible, and beginner-friendly**.
@hamzasheedi hamzasheedi requested a review from a team as a code owner September 14, 2025 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

1 participant

AltStyle によって変換されたページ (->オリジナル) /