feat(chatgpt): add GPT-5.5 and GPT-5.6 models

[woojung3]

TLDR

Problem this solves:

• ChatGPT subscription routing misses GPT-5.5 and GPT-5.6

How it solves it:

• Registers four models as Responses API deployments
• Tests metadata and Chat Completions bridging

Relevant issues

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review)

Screenshots / Proof of Fix

Validated the four model IDs with a ChatGPT subscription using equivalent explicit mode: responses entries before adding the built-in metadata

Request	Result
Streaming /v1/responses text	HTTP 200 for all four models
Forced function call	Tool call returned for all four models
Streaming /v1/chat/completions	Responses bridge returned HTTP 200 for all four models

Checks run on 2bb7048:

35 passed in 0.56s  tests/test_litellm/llms/chatgpt/responses
3 passed in 0.32s   tests/test_litellm/llms/chatgpt/test_chatgpt_authenticator.py
8 passed in 0.35s   tests/test_litellm/llms/chatgpt/chat/test_streaming_utils.py
model_prices_and_context_window.schema.json validates
make pre-commit passes

Type

New Feature
Test

Changes

Adds chatgpt/ metadata for GPT-5.5, GPT-5.6 Luna, GPT-5.6 Sol, and GPT-5.6 Terra to both model maps. Each entry uses Responses mode and advertises the Responses and Chat Completions endpoints

The existing ChatGPT transformation tests now cover provider registration, bundled metadata, and Chat Completions bridging for each model

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[CLAassistant]

All committers have signed the CLA.

[greptile-apps]

Greptile Summary

Adds built-in ChatGPT subscription routing metadata for GPT-5.5 and three GPT-5.6 variants.

• Registers all four models as Responses API deployments in the primary and bundled backup model maps.
• Advertises Chat Completions bridging, Responses API access, vision, function calling, parallel tools, and response-schema support.
• Extends ChatGPT tests to cover provider registration, bundled metadata parity, and bridge lookup behavior.

Confidence Score: 5/5

The PR appears safe to merge, with the new model registrations consistently represented in both runtime metadata maps and covered by focused tests.

The four records are consistent across the primary and fallback maps, conform to existing ChatGPT Responses routing conventions, and the added tests exercise provider registration and bundled metadata without network access.

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Adds four schema-valid ChatGPT Responses model records with consistent routing and capability metadata.
litellm/model_prices_and_context_window_backup.json	Mirrors the four primary model-map entries so packaged and fallback metadata remain consistent.
tests/test_litellm/llms/chatgpt/responses/test_chatgpt_responses_transformation.py	Adds local, deterministic coverage for model registration, both bundled metadata maps, and Chat Completions bridge lookup behavior.

_{Reviews (1): Last reviewed commit: "feat(chatgpt): add GPT-5.5 and GPT-5.6 m..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing woojung3:feat_chatgpt_5_5_5_6 (2bb7048) with litellm_internal_staging (7dab1ff)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (47d2e22) during the generation of this report, so 7dab1ff was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[willcai1984]

Thanks for adding these entries. I independently validated this against a real Claude Code deployment using LiteLLM v1.94.0.

Before adding explicit deployment metadata, chatgpt/gpt-5.6-sol and chatgpt/gpt-5.6-terra were absent from the ChatGPT provider cost map, so /v1/models exposed max_input_tokens: null and max_output_tokens: null. In a long Claude Code session (~9.5 MiB transcript), the client could not determine the model window early enough to compact reliably; the full request eventually reached the ChatGPT Responses backend and failed with Your input exceeds the context window of this model. Manual /compact then failed for the same oversized request.

As an operational workaround, I set max_input_tokens: 1050000 and max_output_tokens: 128000 on all four sol/terra deployments. After restart:

• /v1/models reported 1050000 / 128000 for both model groups
• LiteLLM live self-test passed 11/11 across Anthropic messages (streaming and non-streaming) and Responses paths
• all existing runtime patch hashes remained unchanged

I also checked this PR locally at 2bb7048:

• 35 passed for tests/test_litellm/llms/chatgpt/responses/test_chatgpt_responses_transformation.py
• both model metadata JSON files validate against the schema
• loading the bundled PR entries into litellm.model_cost makes _get_model_info_helper(model=..., custom_llm_provider="chatgpt") return mode=responses, max_input_tokens=1050000, and max_output_tokens=128000 for both sol and terra

One small regression-test suggestion: add an unmocked lookup assertion for _get_model_info_helper("chatgpt/gpt-5.6-terra", custom_llm_provider="chatgpt") (or the public get_model_info boundary with provider capability lookup isolated). The current bridge test mocks _get_model_info_helper, so the exact lookup path that produced null model metadata is not directly locked down.

The failing OSV check appears unrelated to this PR: it reports pre-existing cryptography==48.0.1 findings from uv.lock; this PR does not modify dependencies or the lockfile.

[woojung3]

Thanks for adding these entries. I independently validated this against a real Claude Code deployment using LiteLLM v1.94.0.

Before adding explicit deployment metadata, chatgpt/gpt-5.6-sol and chatgpt/gpt-5.6-terra were absent from the ChatGPT provider cost map, so /v1/models exposed max_input_tokens: null and max_output_tokens: null. In a long Claude Code session (~9.5 MiB transcript), the client could not determine the model window early enough to compact reliably; the full request eventually reached the ChatGPT Responses backend and failed with Your input exceeds the context window of this model. Manual /compact then failed for the same oversized request.

As an operational workaround, I set max_input_tokens: 1050000 and max_output_tokens: 128000 on all four sol/terra deployments. After restart:

• /v1/models reported 1050000 / 128000 for both model groups
• LiteLLM live self-test passed 11/11 across Anthropic messages (streaming and non-streaming) and Responses paths
• all existing runtime patch hashes remained unchanged

I also checked this PR locally at 2bb7048:

• 35 passed for tests/test_litellm/llms/chatgpt/responses/test_chatgpt_responses_transformation.py
• both model metadata JSON files validate against the schema
• loading the bundled PR entries into litellm.model_cost makes _get_model_info_helper(model=..., custom_llm_provider="chatgpt") return mode=responses, max_input_tokens=1050000, and max_output_tokens=128000 for both sol and terra

One small regression-test suggestion: add an unmocked lookup assertion for _get_model_info_helper("chatgpt/gpt-5.6-terra", custom_llm_provider="chatgpt") (or the public get_model_info boundary with provider capability lookup isolated). The current bridge test mocks _get_model_info_helper, so the exact lookup path that produced null model metadata is not directly locked down.

The failing OSV check appears unrelated to this PR: it reports pre-existing cryptography==48.0.1 findings from uv.lock; this PR does not modify dependencies or the lockfile.

Thanks for taking the time to validate this in a real Claude Code deployment.
The context window and compaction details are very helpful.

Good point about testing the direct lookup path too. That would improve coverage for the original null metadata issue. I’ll keep it in mind while the maintainers review the PR.

Thanks also for checking that the OSV failure is unrelated to these changes.