8 views
-/https://github.com/berriai/litellm/issues/29280
GitHub · issue

#29280 [Bug]: Impossible to use /images/generations with OpenAI compatible providers

  • State: open
  • Author: @gregharvey
  • Labels: bug, proxy, llm translation

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

Using latest stable release, `v1.86.2` I am trying to add a model with Mode of Image Generation and Provider of OpenAI but it insists no provider has been provided, failing with this error:

``` LLM Provider NOT provided. Pass in the LLM provider you are trying to call. You passed model=Qwen-Image Pass model as E.g. For 'Huggingface' inference endpoints pass in `completion(model='huggingface/starcoder',..)` Learn more: https://docs.litellm.ai/docs/providers ```

### Steps to Reproduce

Add a db model via the interface with these options: * Provider: OpenAI * LiteLLM Model Name: Custom -> Qwen-Image (testing with Regolo.ai) * Mode: Image Generation * enter credentials * click Test Connect

You will see the above error message.

If you set Mode to Chat then test succeeds, but of course you can't use the model for image generation.

This is the model I am trying to use, but I tried others with other providers, always the same result: * https://regolo.ai/models/qwen-image-2512/

### Relevant log output

```shell 11:45:29 - LiteLLM:DEBUG: utils.py:2…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (3 events)
#0 of 0 · 31d18h42m1s ago — entered · #import:https:::github.com:berriai:litellm post #2188
The second issue is broader and less bounded, potentially requiring multiple provider, model, and endpoint integrations with varied authentication, request schemas, response handling, testing, and documentation. The first is a focused proxy routing and validation defect in an existing image-generation path, so it has a narrower implementation and testing scope.
The left issue has higher implementation risk because it involves stateful protocol semantics, cursor handling, resumable streaming, and compatibility-sensitive proxy behavior. The right issue is comparatively narrower, centered on provider resolution and mode-specific request routing.
#0 of 0 · 31d17h45m9s ago — current · #import:https:::github.com:berriai:litellm post #3140
The left issue is harder because it spans callback-driven follow-up execution, deployment credential propagation, provider endpoint selection, and failure-state isolation, requiring cross-layer fixes and regression coverage. The right issue is narrower provider/mode routing and validation work in the image-generation path.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search