Open WebUI + LiteLLM + Azure FLUX.2-pro Image Generation Fix

Date resolved: 2026-08-17
Components: Open WebUI, LiteLLM Proxy, Azure-backed FLUX.2-pro, Docker networking

Summary

Image generation worked from the LiteLLM Playground but failed when invoked through Open WebUI’s built-in generate_image tool. Open WebUI returned only:

400: [ERROR: Bad Request]

The problem turned out not to be the FLUX deployment, prompt, API key, reverse proxy, or basic Docker connectivity. Open WebUI was sending the standard Images API parameter:

"response_format": "b64_json"

The Azure-backed FLUX.2-pro provider did not support that parameter. LiteLLM rejected the entire request with UnsupportedParamsError.

The successful fix was to enable unsupported-parameter dropping in the LiteLLM Proxy configuration:

litellm_settings:
  drop_params: true

After restarting/reloading LiteLLM, image generation through Open WebUI succeeded.

---

Architecture

The relevant request path is:

Open WebUI
    -> LiteLLM Proxy over the shared Docker network
        -> Azure-backed FLUX.2-pro deployment

The working internal LiteLLM base URL configured in Open WebUI is:

http://litellm:4000/v1

This causes Open WebUI to call:

POST http://litellm:4000/v1/images/generations

litellm must be the actual Docker Compose service name or network alias visible from the Open WebUI container. Use the appropriate service name if yours differs.

---

Symptoms

Open WebUI symptom

The built-in image tool failed with a generic error:

generate_image error: 400: [ERROR: Bad Request]

The generic Open WebUI message concealed the useful provider error, so the LiteLLM logs were essential.

Initial incorrect request URL

At first, Open WebUI was configured in a way that produced an Azure-style URL:

https://llm-api.example.org/images/generations?api-version=2024-02-01

Problems with that request included:

1. The expected /v1 path was absent.
2. The api-version query parameter indicated Azure-style image-provider configuration in Open WebUI.
3. It differed from the known working LiteLLM route.

Corrected URL, but request still failed

After changing the Open WebUI image API base URL, the request reached the correct endpoint:

POST /v1/images/generations HTTP/1.1

However, LiteLLM still returned:

400 Bad Request

The decisive LiteLLM error was:

litellm.UnsupportedParamsError: Setting `response_format` is not supported by azure, FLUX.2-pro. To drop it from the call, set `litellm.drop_params = True`.

That message identified the actual root cause.

---

Why the LiteLLM Playground Worked

The LiteLLM Playground successfully generated an image using a Responses API request similar to:

response = client.responses.create(
    model="FLUX.2-pro",
    input="Create an image...",
    tools=[{"type": "image_generation"}],
)

That uses the Responses API image-generation tool flow:

POST /responses

Open WebUI’s built-in generate_image tool uses the traditional OpenAI-compatible Images API instead:

POST /v1/images/generations

These are separate endpoints and LiteLLM code paths. Therefore, success in the Playground proved that the Azure FLUX deployment and credentials worked, but it did not prove that Open WebUI’s Images API payload was fully compatible.

The failing Open WebUI request included response_format; the successful Playground flow did not encounter the same provider-parameter validation issue.

---

Configuration Changes

1. Open WebUI image-generation settings

In Admin Panel -> Settings -> Images, use settings equivalent to:

Setting	Value
Image generation	Enabled
Engine/provider	OpenAI-compatible, not Azure mode
API base URL	http://litellm:4000/v1
Model	FLUX.2-pro
Additional Parameters	Empty unless a tested parameter is required
API key	LiteLLM Proxy key, stored securely

Do not add this parameter for this Azure-backed FLUX deployment:

{
  "response_format": "b64_json"
}

Open WebUI may add response_format internally even if Additional Parameters is empty. That is why the LiteLLM-side change was ultimately required.

2. LiteLLM Proxy configuration

Add the following to the LiteLLM Proxy YAML configuration:

litellm_settings:
  drop_params: true

Illustrative configuration structure:

model_list:
  - model_name: FLUX.2-pro
    litellm_params:
      model: azure/FLUX.2-pro
      api_base: os.environ/AZURE_FLUX_API_BASE
      api_key: os.environ/AZURE_FLUX_API_KEY
      api_version: os.environ/AZURE_FLUX_API_VERSION

litellm_settings:
  drop_params: true

The exact Azure deployment name and environment-variable names depend on the local setup.

What drop_params: true does

LiteLLM checks which parameters the selected provider/model supports. With drop_params enabled, LiteLLM removes unsupported parameters rather than rejecting the complete request.

In this case, LiteLLM discarded response_format and allowed the Azure FLUX image request to proceed.

Scope warning

When configured under litellm_settings, drop_params: true is a global behavior. Unsupported parameters for other models may also be silently removed. This is convenient for compatibility, but it can hide parameter mistakes. Review LiteLLM debug logs when exact parameter behavior matters.

---

Applying the Changes

Restart or reload the LiteLLM Proxy after editing its configuration. Examples:

docker restart litellm-proxy

Or, when managed by Docker Compose:

docker compose restart litellm

If Open WebUI settings were also changed, restart all Open WebUI replicas so they do not retain stale configuration:

docker restart openwebui-3 openwebui-4

Use the actual container or Compose service names in the environment.

---

Verification

1. Verify Docker-network connectivity

From an Open WebUI container:

docker exec openwebui-3 \
  curl -sS -o /dev/null -w '%{http_code}\n' \
  http://litellm:4000/v1/models

Expected results:

• 200: reachable and authorized
• 401: reachable, but the test omitted or used an invalid key
• DNS or connection error: incorrect service name, network alias, port, or Docker network membership

2. Inspect fresh Open WebUI logs

docker logs --since 3m openwebui-3 2>&1 \
  | grep -E -A5 -B2 'generate_image|images/generations|ClientResponseError'

For multiple Open WebUI replicas, inspect each one because a load balancer may route requests to any replica.

The desired URL is:

http://litellm:4000/v1/images/generations

3. Inspect fresh LiteLLM logs

docker logs --since 3m litellm-proxy 2>&1 \
  | grep -E -i -A5 -B2 'images/generations|unsupportedparams|400|error|flux'

Before the fix, the key error was:

Setting `response_format` is not supported by azure, FLUX.2-pro

After the fix, the image request should complete successfully rather than returning HTTP 400.

4. Confirm end-to-end rendering

Generate an image from Open WebUI and verify that:

1. The chat model invokes the built-in generate_image tool.
2. Open WebUI sends POST /v1/images/generations to LiteLLM.
3. LiteLLM strips unsupported parameters.
4. Azure FLUX generates the image.
5. Open WebUI receives, stores, and displays the result in the chat.

---

Troubleshooting Timeline

1. Image generation repeatedly returned HTTP 400.
   The prompt was simplified several times, with no change.
2. LiteLLM Playground was confirmed working with FLUX.2-pro.
   This established that the model deployment and Azure connection were functional.
3. Open WebUI logs revealed a different API path.
   The Playground used the Responses API, while Open WebUI used /images/generations.
4. The Open WebUI URL was corrected.
   The image base URL was changed to the shared Docker-network LiteLLM address with /v1:

   http://litellm:4000/v1

5. The request reached LiteLLM but still returned 400.
   This ruled out the public reverse proxy and basic network routing.
6. LiteLLM logs exposed the unsupported parameter.
   Azure FLUX.2-pro rejected response_format.
7. drop_params: true was enabled in LiteLLM.
   LiteLLM then stripped the unsupported parameter.
8. End-to-end image generation succeeded.

---

Things That Were Not the Root Cause

The following were investigated or suspected but did not cause the final failure:

• The image prompt
• FLUX safety filtering
• The Azure FLUX deployment being unavailable
• The LiteLLM API key itself
• Basic Docker-network connectivity
• The external reverse proxy
• Open WebUI’s ability to invoke a tool
• Open WebUI’s ability to display an image after a successful response

The chat model calls returned 200 OK; the separate image-generation request was the failing operation.

---

Security Notes

• Never place real API keys in troubleshooting documents, chat transcripts, source code, or shell history.
• If a key is exposed, revoke and replace it.
• Prefer Docker secrets, environment variables, or another secrets manager.
• Redact KEY, TOKEN, SECRET, and PASSWORD values before sharing container configuration or logs.

Example environment inspection with basic redaction:

docker inspect openwebui-3 \
  --format '{{range .Config.Env}}{{println .}}{{end}}' \
  | grep -Ei '^(IMAGE|OPENAI|AZURE|ENABLE_IMAGE|DEFAULT_MODELS)' \
  | sed -E 's/(KEY|TOKEN|SECRET|PASSWORD)=.*/\1=[REDACTED]/I'

---

Final Working State

Open WebUI image engine: OpenAI-compatible
Open WebUI image API URL: http://litellm:4000/v1
Open WebUI image model: FLUX.2-pro
Open WebUI additional parameters: empty
LiteLLM setting: drop_params: true
Result: successful image generation and display in Open WebUI