[Bug Report] Gemini image resolution control only works on /v1/images/generations — broken on /v1/images/edits and stripped from native GenAI endpoint

[rst-confident]

Description

Bifrost v1.4.16 correctly maps the size parameter to Gemini's imageConfig for /v1/images/generations, producing up to 2K/4K images. However, this mapping is missing from /v1/images/edits, and the Gemini-native generateContent endpoint strips any imageConfig from the request body.

This means there is no endpoint that supports both image editing (input images) AND resolution control for Gemini.

Three related issues

1. /v1/images/edits ignores size parameter for Gemini

Request:

curl -X POST "https://<bifrost>/v1/images/edits" \
  -H "Authorization: Bearer <vk>" \
  -F "model=gemini/gemini-3.1-flash-image-preview" \
  -F "prompt=Place this person on a beach" \
  -F "size=2048x2048" \
  -F "n=1" \
  -F "image=@input.png;type=image/png"

Result: Image IS sent to Gemini (258 image tokens), but output is ~848x1264 instead of 2048x2048.

Expected: Same size → imageConfig mapping as /v1/images/generations (which correctly outputs 2048x2048).

2. /v1/images/generations ignores images[] array

Request:

curl -X POST "https://<bifrost>/v1/images/generations" \
  -H "Authorization: Bearer <vk>" \
  -H "Content-Type: application/json" \
  -d '{"model":"gemini/gemini-3.1-flash-image-preview",
       "prompt":"Edit this image...", "size":"2048x2048", "n":1,
       "images":["data:image/png;base64,..."]}'

Result: input_tokens: 47, text_tokens: 47 — 0 image tokens. The images array is silently discarded. Output is a 2048x2048 text-to-image generation (size works, but input images are ignored).

3. Gemini-native generateContent endpoint strips imageConfig

Request:

curl -X POST "https://<bifrost>/genai/v1beta/models/gemini-3.1-flash-image-preview:generateContent" \
  -H "Authorization: Bearer <vk>" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"role":"user","parts":[{"text":"Generate a 1:1 image"}]}],
       "generationConfig":{"responseModalities":["IMAGE"],
       "imageConfig":{"aspectRatio":"1:1","imageSize":"2K"}}}'

Result: Output is 1408x768 (not 1:1, not 2K). Same dimensions as without any imageConfig — proving Bifrost strips the entire imageConfig from the request body before forwarding to Gemini.

Control test: Removing imageConfig entirely produces identical dimensions (768x1376 for the same prompt), confirming the config is stripped.

Evidence summary

Endpoint | Input images | size/imageConfig respected | Status -- | -- | -- | -- /v1/images/generations (JSON) | images[] IGNORED (0 image tokens) | size → 2K/4K ✅ | Partial /v1/images/edits (multipart) | Image SENT (258 image tokens) ✅ | size IGNORED ❌ | Partial /genai/.../generateContent | inlineData SENT ✅ | imageConfig STRIPPED ❌ | Partial

No endpoint supports both image input AND resolution control.

Expected behavior

1. /v1/images/edits should apply the same size → Gemini imageConfig mapping as /v1/images/generations
2. /v1/images/generations should forward the images[] array as inlineData parts to Gemini
3. The Gemini-native generateContent endpoint should pass through imageConfig as-is (it's the user's explicit Gemini-native request)

Note: Gemini uses imageSize (values: "512", "1K", "2K", "4K") not resolution. Current mapping in /v1/images/generations uses the correct parameter since it produces 2K output.

Environment

• Bifrost: v1.4.16 (latest as of 2026-03-25)
• Provider: Gemini (gemini-3.1-flash-image-preview)
• Deployment: Fly.io, Amsterdam

Impact

This blocks any use case requiring high-resolution image editing through Bifrost. Workaround would be direct Gemini API calls, which bypasses Bifrost's virtual keys, budget enforcement, and observability.

[akshaydeo]

@TejasGhatte we can extend #2266 this PR

[Radheshg04]

hey @rst-confident , this is resolved with #2323 and will be released with v1.5.0

[rst-confident]

Nice. Thanks for quick action.