feat(openai): add gpt-5.5 models - #2076
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdds two new model entries, Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/models/src/models/openai.ts (1)
1539-1655: Optional: consider placing the new entries near othergpt-5.xsiblings.
gpt-5.5/gpt-5.5-proare inserted betweengpt-5.4-nanoandgpt-5.2-codex, which further fragments the already-mixed ordering of thegpt-5.xfamily in this array. Grouping them aftergpt-5.4-nanoalongside the rest of the 5.x series (or consistently by release date) would make the file easier to scan. Purely cosmetic; no behavioral impact.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/models/src/models/openai.ts` around lines 1539 - 1655, The new model entries with id "gpt-5.5" and "gpt-5.5-pro" are placed between "gpt-5.4-nano" and "gpt-5.2-codex", breaking the logical grouping of the gpt-5.x family; relocate the entire objects for gpt-5.5 and gpt-5.5-pro so they appear adjacent to the other gpt-5.x siblings (for example, immediately after the "gpt-5.4-nano" entry) to keep the 5.x models grouped consistently in the array.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/models/src/models/openai.ts`:
- Around line 1539-1655: The new model entries with id "gpt-5.5" and
"gpt-5.5-pro" are placed between "gpt-5.4-nano" and "gpt-5.2-codex", breaking
the logical grouping of the gpt-5.x family; relocate the entire objects for
gpt-5.5 and gpt-5.5-pro so they appear adjacent to the other gpt-5.x siblings
(for example, immediately after the "gpt-5.4-nano" entry) to keep the 5.x models
grouped consistently in the array.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0fbd7db7-09df-468e-9e21-8e483b69f1b8
📒 Files selected for processing (1)
packages/models/src/models/openai.ts
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary OpenAI's API has no numeric reasoning-budget primitive — only `reasoning.effort` (none/minimal/low/medium/high/xhigh). The `reasoningMaxTokens: true` flag on `gpt-5.5` and `gpt-5.5-pro` (added in #2076) was unsupported upstream: a request with `reasoning.max_tokens: 1024` is rejected by OpenAI with `Unknown parameter: 'reasoning.max_tokens'`. The flag is dropped from those provider mappings; the gateway now correctly returns 400 instead of silently sending a budget that gets stripped or rejected. The earlier e2e `test.each(reasoningMaxTokensModels)` round-tripped a real completion against every capable model just to inspect the upstream request body — wasteful (real reasoning tokens are not free) and the response-shape assertions duplicated `basic reasoning`. Replaced with focused unit tests on `prepareRequestBody` covering each provider that maps the budget: - `anthropic` → `thinking.budget_tokens` - `aws-bedrock` → `additionalModelRequestFields.thinking.budget_tokens` - `google-ai-studio` → `generationConfig.thinkingConfig.thinkingBudget` - `google-vertex` → `generationConfig.thinkingConfig.thinkingBudget` The negative e2e in `api-individual.e2e.ts` (gateway returns 400 when `reasoning.max_tokens` is sent to a non-capable model) is kept — it short-circuits at validation, no provider call. ## Test plan - [x] `pnpm vitest run packages/actions/src/prepare-request-body.spec.ts` — 35/35 pass, including 4 new forwarding tests. - [x] `pnpm vitest run -c vitest/vitest.e2e.config.mts apps/gateway/src/api-individual.e2e.ts -t "reasoning.max_tokens error"` — gateway 400 path still verified. - [x] `pnpm format` clean; full build succeeds. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Corrected reasoning.max_tokens support status for gpt-5.5 and gpt-5.5-pro models on OpenAI and Azure. * Enhanced validation to reject reasoning.max_tokens requests on models that don't support this feature with appropriate error messaging. * **Tests** * Added end-to-end tests for reasoning.max_tokens handling and validation across providers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
…nco#2079) ## Summary OpenAI's API has no numeric reasoning-budget primitive — only `reasoning.effort` (none/minimal/low/medium/high/xhigh). The `reasoningMaxTokens: true` flag on `gpt-5.5` and `gpt-5.5-pro` (added in theopenco#2076) was unsupported upstream: a request with `reasoning.max_tokens: 1024` is rejected by OpenAI with `Unknown parameter: 'reasoning.max_tokens'`. The flag is dropped from those provider mappings; the gateway now correctly returns 400 instead of silently sending a budget that gets stripped or rejected. The earlier e2e `test.each(reasoningMaxTokensModels)` round-tripped a real completion against every capable model just to inspect the upstream request body — wasteful (real reasoning tokens are not free) and the response-shape assertions duplicated `basic reasoning`. Replaced with focused unit tests on `prepareRequestBody` covering each provider that maps the budget: - `anthropic` → `thinking.budget_tokens` - `aws-bedrock` → `additionalModelRequestFields.thinking.budget_tokens` - `google-ai-studio` → `generationConfig.thinkingConfig.thinkingBudget` - `google-vertex` → `generationConfig.thinkingConfig.thinkingBudget` The negative e2e in `api-individual.e2e.ts` (gateway returns 400 when `reasoning.max_tokens` is sent to a non-capable model) is kept — it short-circuits at validation, no provider call. ## Test plan - [x] `pnpm vitest run packages/actions/src/prepare-request-body.spec.ts` — 35/35 pass, including 4 new forwarding tests. - [x] `pnpm vitest run -c vitest/vitest.e2e.config.mts apps/gateway/src/api-individual.e2e.ts -t "reasoning.max_tokens error"` — gateway 400 path still verified. - [x] `pnpm format` clean; full build succeeds. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Corrected reasoning.max_tokens support status for gpt-5.5 and gpt-5.5-pro models on OpenAI and Azure. * Enhanced validation to reject reasoning.max_tokens requests on models that don't support this feature with appropriate error messaging. * **Tests** * Added end-to-end tests for reasoning.max_tokens handling and validation across providers. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Summary
This PR adds support for two new OpenAI models: GPT-5.5 and GPT-5.5 Pro, with configurations for both OpenAI and Azure providers.
Key Changes
GPT-5.5: Added base model configuration with 1.05M context size, 128K max output, vision, tools, web search, and reasoning capabilities
GPT-5.5 Pro: Added premium variant with enhanced reasoning using more compute
test: "skip"flagNotable Implementation Details
https://claude.ai/code/session_01XrSSeRjBSUYtNLurCbG9Nm
Summary by CodeRabbit