litellm - ✅(Solved) Fix [Bug]: Cannot generate 2K images with Gemini 3.1 Flash Image Preview (stuck at 1K) - extra_body is stripped [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#24621Fetched 2026-04-08 01:32:19
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
labeled ×3cross-referenced ×1

PR fix notes

PR #24699: fix(gemini): merge extra_body into generationConfig for image preview

Description (problem / solution / changelog)

Relevant issues

Fixes #24621

Pre-Submission checklist

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

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

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

CI (LiteLLM team)

CI status guideline:

  • 50-55 passing tests: main is stable with minor issues.
  • 45-49 passing tests: acceptable but needs attention
  • <= 40 passing tests: unstable; be careful with your merges and assess the risk.
  • Branch creation CI run
    Link:

  • CI run for the last commit
    Link:

  • Merge / cherry-pick CI run
    Links:

Type

🐛 Bug Fix

Changes

  • Updated GoogleImageGenConfig.transform_image_generation_request() to properly deep-merge the extra_body configuration onto the target generationConfig rather than strictly dropping it.
  • Enabled imageSize: 2K generation parameters for gemini/gemini-3.1-flash-image-preview.
  • Created test_gemini_image_generation.py unit test to explicitly assert deep-merged components map properly alongside the standard response_modalities.

Changed files

  • litellm/llms/gemini/image_generation/transformation.py (modified, +13/-0)
  • tests/test_litellm/llms/gemini/test_gemini_image_generation.py (added, +42/-0)

PR #25333: feat(vertex_ai): support image_size (2K/4K) for Gemini image generation

Description (problem / solution / changelog)

Fixes #24621

The Gemini API supports imageConfig.imageSize to control output resolution (e.g., "2K", "4K"), but LiteLLM had no way to pass this through. The extra_body approach doesn't work because generationConfig is rebuilt from scratch in the transformation layer.

Changes:

  • Vertex AI Gemini image edit: add imageSize to SUPPORTED_PARAMS and include it in generationConfig.image_config.image_size
  • Google AI Studio image gen: same support for Gemini models
  • Both: accept size param as either OpenAI format ("1024x1024" -> aspect_ratio) or Gemini format ("2K" -> image_size)
  • Both: map OpenAI quality="hd" to imageSize="2K" as a convenient alternative
  • Add tests for imageSize, combined aspect_ratio+imageSize, size="2K", and quality="hd" mappings

Relevant issues

<!-- e.g. "Fixes #000" -->

Pre-Submission checklist

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

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

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

CI (LiteLLM team)

CI status guideline:

  • 50-55 passing tests: main is stable with minor issues.
  • 45-49 passing tests: acceptable but needs attention
  • <= 40 passing tests: unstable; be careful with your merges and assess the risk.
  • Branch creation CI run
    Link:

  • CI run for the last commit
    Link:

  • Merge / cherry-pick CI run
    Links:

Type

<!-- Select the type of Pull Request --> <!-- Keep only the necessary ones -->

🆕 New Feature 🐛 Bug Fix 🧹 Refactoring 📖 Documentation 🚄 Infrastructure ✅ Test

Changes

Changed files

  • litellm/llms/gemini/image_generation/transformation.py (modified, +24/-4)
  • litellm/llms/vertex_ai/image_edit/vertex_gemini_transformation.py (modified, +21/-4)
  • tests/test_litellm/llms/vertex_ai/image_edit/test_vertex_ai_image_edit_transformation.py (modified, +67/-0)

Code Example

Internal proxy log showing the extra_body parameter is successfully loaded into memory:
proxy_server.py:9818 - all_models: [{'model_name': 'gemini/gemini-3.1-flash-image-preview', 'litellm_params': {... 'extra_body': {'generationConfig': {'imageConfig': {'imageSize': '2K'}, 'response_modalities': ['IMAGE', 'TEXT']}}, 'drop_params': False} ...}]

Outgoing POST request showing the parameter is completely stripped (overwritten by response_modalities):
POST Request Sent from LiteLLM:
curl -X POST

https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-image-preview:generateContent

-H 'x-goog-REDACTED' -H 'Content-Type: application/json'

-d '{'contents': [{'parts': [{'text': 'A realistic, high-quality close-up...'}]}], 'generationConfig': {'response_modalities': ['IMAGE', 'TEXT']}}'
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

I want to generate 2K images instead of the default 1K images using Google's gemini-3.1-flash-image-preview model via Google AI Studio (gemini/ provider).

To achieve this, the Gemini API requires the parameter "imageConfig": {"imageSize": "2K"} inside the generationConfig block. I injected this via extra_body in the LiteLLM config to bypass standard mappings.

The Issue: While LiteLLM successfully registers this extra_body config internally (as seen in the proxy debug logs), it completely overwrites/strips the extra_body payload when constructing the final outgoing curl request to the Google API. The outgoing payload only retains the hardcoded response_modalities: ['IMAGE', 'TEXT'], forcing all image generations to fall back to the 1K default resolution.

Expected Behavior: LiteLLM should perform a deep merge of the extra_body into the final API request to Google, ensuring that "imageConfig": {"imageSize": "2K"} is included inside the generationConfig block, so the API actually generates a 2K image.

Steps to Reproduce

Add the model gemini/gemini-3.1-flash-image-preview via the LiteLLM Admin UI.

In Advanced Settings -> Additional Litellm Params, add the following JSON to enforce a 2K image: { "drop_params": false, "extra_body": { "generationConfig": { "imageConfig": { "imageSize": "2K" } } } }

Trigger an image generation request via an OpenAI-compatible frontend (e.g., Open WebUI) using the LiteLLM /images/generations endpoint.

Check the LiteLLM console logs: the proxy loads the parameters into memory, but the outgoing request to Google drops them.

Relevant log output

Internal proxy log showing the extra_body parameter is successfully loaded into memory:
proxy_server.py:9818 - all_models: [{'model_name': 'gemini/gemini-3.1-flash-image-preview', 'litellm_params': {... 'extra_body': {'generationConfig': {'imageConfig': {'imageSize': '2K'}, 'response_modalities': ['IMAGE', 'TEXT']}}, 'drop_params': False} ...}]

Outgoing POST request showing the parameter is completely stripped (overwritten by response_modalities):
POST Request Sent from LiteLLM:
curl -X POST

https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-image-preview:generateContent

-H 'x-goog-REDACTED' -H 'Content-Type: application/json'

-d '{'contents': [{'parts': [{'text': 'A realistic, high-quality close-up...'}]}], 'generationConfig': {'response_modalities': ['IMAGE', 'TEXT']}}'

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.82.3

Twitter / LinkedIn details

No response

extent analysis

Fix Plan

To resolve the issue, we need to modify the LiteLLM proxy to perform a deep merge of the extra_body into the final API request.

Here are the steps:

  • Locate the proxy_server.py file and find the function responsible for constructing the outgoing request to the Google API.
  • Modify the function to merge the extra_body into the request payload. This can be achieved using the following code snippet:
import json

# assuming 'payload' is the default request payload and 'extra_body' is the additional configuration
def merge_extra_body(payload, extra_body):
    if 'generationConfig' in extra_body:
        if 'generationConfig' not in payload:
            payload['generationConfig'] = {}
        payload['generationConfig'] = {**payload['generationConfig'], **extra_body['generationConfig']}
    return payload

# example usage:
default_payload = {'generationConfig': {'response_modalities': ['IMAGE', 'TEXT']}}
extra_body = {'generationConfig': {'imageConfig': {'imageSize': '2K'}}}
merged_payload = merge_extra_body(default_payload, extra_body)
print(json.dumps(merged_payload))
  • Update the proxy_server.py to use the merge_extra_body function when constructing the outgoing request.

Verification

To verify that the fix worked, trigger an image generation request via an OpenAI-compatible frontend and check the LiteLLM console logs. The outgoing request to Google should now include the imageConfig with imageSize set to 2K.

Extra Tips

  • Make sure to test the modified proxy_server.py in a non-production environment before deploying it to production.
  • Consider adding additional logging to verify that the extra_body is being merged correctly into the request payload.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING