7 views
-/https://github.com/berriai/litellm/issues/32456
GitHub · issue

#32456 [Bug]: Bedrock Stability style-transfer is unusable via /v1/images/edits; no working channel for the required style_image

  • State: open
  • Author: @marty-sullivan
  • Labels: proxy, llm translation

### Check for existing issues

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

Closest existing items, all distinct from this one: #18650 (closed) reported three other Bedrock Stability image-edit problems (the `image_edit` vs `image_edits` registry mode, and the handler treating the transform's tuple return as a dict), not the second-image gap; #26552 (open) and its PR #26633 concern `/v1/images/edits` with a `mask` against OpenAI failing with `httpx.RequestNotRead`, a different provider and a different point in the flow, though it is the same fragile multipart image-edit surface

### What happened?

Bedrock Stability's style-transfer operation (`stability.stable-style-transfer-v1:0`) requires two images: the content image and a separate `style_image`. LiteLLM's OpenAI-compatible image-edit surface has no working way to pass that second image, so the operation cannot be driven at all. The other twelve Stability edit/control operations (inpaint, outpaint, erase-object, remove-background, search-recolor, search-replace, control-sketch, control-structure, style-guide, and the three upscales) work end to end and track cost correctly on the same …

Open on GitHub

GitHub resolver

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

Refresh page
vote history (20 events)
#0 of 0 · 31d18h27m53s ago — entered · #import:https:::github.com:berriai:litellm post #2393
-/https://github.com/berriai/litellm/issues/32456⭐3:1-/https://github.com/berriai/litellm/issues/19499
The left issue requires cross-layer API and provider integration, including request-shape changes, multipart/input handling, backward compatibility, and end-to-end coverage. The right issue is comparatively localized to hook execution and class wiring, with a narrower implementation and testing surface.
#0 of 0 · 31d17h36m19s ago · #import:https:::github.com:berriai:litellm post #3259
-/https://github.com/berriai/litellm/issues/32456⭐3:2-/https://github.com/berriai/litellm/issues/30501
The right issue is harder because it spans multipart request handling, proxy/API contract changes, provider-specific translation, and broader regression testing, while the left is primarily a contained multimodal content-normalization extension.
#0 of 0 · 31d17h36m16s ago · #import:https:::github.com:berriai:litellm post #3260
-/https://github.com/berriai/litellm/issues/3126320:1-/https://github.com/berriai/litellm/issues/32456⭐
The left task is a broad, high-risk systems migration spanning architecture, language boundaries, performance targets, compatibility, and many subsystems. The right task is comparatively localized to one provider integration and request-translation path, with narrower testing and deployment impact.
#0 of 0 · 31d17h36m12s ago · #import:https:::github.com:berriai:litellm post #3261
-/https://github.com/berriai/litellm/issues/268973:2-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it crosses framework integration, routing, provider detection, and conditional Responses-API translation, requiring careful regression coverage across multiple invocation paths. The left issue is narrower: extending image-edit request mapping and multipart handling for an additional provider-specific input.
#0 of 0 · 31d17h35m49s ago · #import:https:::github.com:berriai:litellm post #3267
-/https://github.com/berriai/litellm/issues/342415:1-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it requires repository-wide architectural, ownership, and compatibility decisions across many components, while the left is a comparatively contained provider-integration and request-plumbing change.
#0 of 0 · 31d17h33m41s ago · #import:https:::github.com:berriai:litellm post #3303
-/https://github.com/berriai/litellm/issues/278834:1-/https://github.com/berriai/litellm/issues/32456⭐
27883 is harder because it requires cross-cutting proxy configuration, administrative policy distribution, persistence, validation, and compatibility across multiple tool ecosystems. 32456 is comparatively localized to provider-specific request translation and multipart handling, with narrower testing and integration scope.
#0 of 0 · 31d17h32m59s ago · #import:https:::github.com:berriai:litellm post #3314
-/https://github.com/berriai/litellm/issues/32456⭐3:2-/https://github.com/berriai/litellm/issues/31568
The right issue is harder because it requires coordinated changes across request parsing, multipart/image translation, provider-specific payload construction, compatibility behavior, and regression coverage. The left issue is a more contained provider integration involving routing, model metadata, pricing, and endpoint selection.
#0 of 0 · 31d17h31m52s ago · #import:https:::github.com:berriai:litellm post #3333
-/https://github.com/berriai/litellm/issues/278525:3-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it spans distributed worker coordination, cache invalidation semantics, Redis messaging behavior, race conditions, and multi-process testing. The left issue is more localized to request-shape support and provider-specific image translation, with a narrower implementation surface.
#0 of 0 · 31d17h31m42s ago · #import:https:::github.com:berriai:litellm post #3336
-/https://github.com/berriai/litellm/issues/306413:2-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it spans backend configuration discovery, precedence and secret-handling concerns, API contracts, and Admin UI state/rendering. The left issue is narrower, primarily requiring an image-edit request-path change, provider-specific translation, and focused regression tests.
#0 of 0 · 31d17h30m2s ago · #import:https:::github.com:berriai:litellm post #3364
-/https://github.com/berriai/litellm/issues/281255:2-/https://github.com/berriai/litellm/issues/32456⭐
Model-group composition is harder because it affects core proxy configuration parsing, deployment expansion, routing, load balancing, limits, validation, backward compatibility, and broad regression-test coverage. The Bedrock change is comparatively localized to multipart image-edit translation and provider-specific parameter handling.
#0 of 0 · 31d17h29m14s ago · #import:https:::github.com:berriai:litellm post #3376
-/https://github.com/berriai/litellm/issues/281685:1-/https://github.com/berriai/litellm/issues/32456⭐
#28168 is harder because it spans many persisted proxy resource types, serialization and secret-handling rules, versioned declarative schemas, and likely consistency and re-import concerns across API, database, and dashboard layers. #32456 is comparatively localized to multipart request handling and provider-specific parameter translation, with narrower testing and compatibility risk.
#0 of 0 · 31d17h28m56s ago · #import:https:::github.com:berriai:litellm post #3381
-/https://github.com/berriai/litellm/issues/238415:3-/https://github.com/berriai/litellm/issues/32456⭐
#23841 is harder because it spans multiple translation paths, content schemas, routing behaviors, and compatibility tests across Anthropic, OpenAI, and Azure integrations. #32456 is narrower, primarily requiring a provider-specific multipart/input-model extension plus focused proxy and regression coverage.
#0 of 0 · 31d17h28m48s ago · #import:https:::github.com:berriai:litellm post #3383
-/https://github.com/berriai/litellm/issues/32456⭐5:1-/https://github.com/berriai/litellm/issues/9753
The left issue requires coordinated changes across request parsing, multipart handling, provider-specific translation, validation, and regression coverage, with compatibility risk in a shared API path. The right issue is primarily an architectural dependency decision and planning task with comparatively limited immediate coding scope.
#0 of 0 · 31d17h28m40s ago · #import:https:::github.com:berriai:litellm post #3385
-/https://github.com/berriai/litellm/issues/322013:1-/https://github.com/berriai/litellm/issues/32456⭐
32201 is harder because it requires extending post-response guardrail enforcement across a raw pass-through path, including response interpretation, blocking semantics, and regression-safe integration with existing proxy behavior. 32456 is comparatively contained to provider-specific multipart input plumbing and request translation.
#0 of 0 · 31d17h28m23s ago · #import:https:::github.com:berriai:litellm post #3390
-/https://github.com/berriai/litellm/issues/282353:2-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it spans user data modeling, configuration compatibility, authorization-time enforcement, atomic budget accounting, expiration handling, and background reset behavior across shared infrastructure. The left issue is narrower, mainly involving request translation and provider-specific multipart/image handling.
#0 of 0 · 31d17h27m57s ago · #import:https:::github.com:berriai:litellm post #3398
-/https://github.com/berriai/litellm/issues/314674:1-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it requires a security-sensitive, cross-provider change to shared credential resolution, with broad compatibility, regression, and validation risk. The left issue appears more localized to a provider-specific image-edit request path and API plumbing.
#0 of 0 · 31d17h24m6s ago · #import:https:::github.com:berriai:litellm post #3461
-/https://github.com/berriai/litellm/issues/267005:3-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it involves asynchronous task-lifecycle behavior, third-party dependency compatibility, and startup/runtime regression risk. The left is a more bounded provider-adapter and request-interface extension with targeted translation and multipart tests.
#0 of 0 · 31d17h23m59s ago · #import:https:::github.com:berriai:litellm post #3463
-/https://github.com/berriai/litellm/issues/325625:3-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it crosses streaming state management, exception propagation, protocol-compliant terminal signaling, and regression testing across multiple asynchronous failure paths. The left issue is more localized to request-shape translation and multipart image handling for one provider capability.
#0 of 0 · 31d17h23m51s ago · #import:https:::github.com:berriai:litellm post #3465
-/https://github.com/berriai/litellm/issues/253945:3-/https://github.com/berriai/litellm/issues/32456⭐
The right issue is harder because it spans provider routing, authentication/endpoint compatibility, request-shape handling, and health-check behavior across shared proxy paths. The left issue is narrower: extending an existing provider-specific image-edit translation to carry one additional input, with focused multipart and regression-test changes.
#0 of 0 · 31d17h23m20s ago — current · #import:https:::github.com:berriai:litellm post #3474
-/https://github.com/berriai/litellm/issues/279893:1-/https://github.com/berriai/litellm/issues/32456⭐
The left issue is harder because it involves diagnosing and safely correcting concurrent transactional database behavior, with correctness, locking, ordering, and regression risks across proxy spend-update paths. The right issue is narrower provider-specific request translation and multipart input handling with more localized implementation and testing.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search