16 views
-/https://github.com/berriai/litellm/issues/18686
GitHub · issue

#18686 I WISH LITELLM HAD - Models, Providers, Endpoints requests

  • State: open
  • Author: @ishaan-jaff
  • Labels: llm translation, docs

# I WISH LITELLM HAD - Models, Providers, Endpoints requests

This is the central place for the LiteLLM community to request and vote on new models, providers,endpoints.

👉 See supported models/providers/endpoints here: https://models.litellm.ai/

## How to Request

To request a new integration:

1. **Comment below** with: - Provider/Model name - Documentation link (if available) - Your use case

2. **Upvote** existing requests you want to see added

## Prioritization

Requests are prioritized based on: - Community upvotes

## Already Supported

Check our [providers documentation](https://docs.litellm.ai/docs/providers) - we currently support 100+ models across OpenAI, Anthropic, Azure, AWS Bedrock, Vertex AI, and more.

---

For urgent production needs, contact us directly at support@berri.ai

GitHub resolver

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

Refresh page
vote history (6 events)
#0 of 0 · 31d19h2m33s ago — entered · #import:https:::github.com:berriai:litellm post #1825
The right issue requires debugging and correcting provider-specific request translation across Responses and Bedrock Converse, while preserving behavior for multiple model/API paths and adding regression coverage. The left issue is primarily an intake and prioritization mechanism with no defined implementation scope.
The right issue has open-ended integration scope and potentially touches multiple provider, endpoint, documentation, and compatibility areas. The left issue is a bounded metadata change across two known files with relatively low implementation risk.
The left issue requires tracing and correcting header propagation across OpenAPI-to-MCP conversion, request filtering, and upstream dispatch, with regression coverage across authentication and tenant-context scenarios. The right issue is primarily an intake and prioritization tracker rather than a defined engineering change.
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 right issue is harder because it represents an open-ended integration effort with provider-specific implementation, API compatibility, authentication, configuration, documentation, and testing requirements. The left issue is a localized request-routing regression with a comparatively contained fix and targeted sync/async regression tests.
#0 of 0 · 31d18h27m26s ago — current · #import:https:::github.com:berriai:litellm post #2416
The left issue requires diagnosing and correcting streaming translation logic across protocol formats, preserving chunk semantics, and adding regression coverage for backend-specific edge cases. The right issue is primarily a coordination and prioritization request without a defined implementation scope.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search