[GIVE FEEDBACK] Experimental Features being Deprecated - DRAFT LIST

[ryan-crabbe-berri]

Deprecation Notice

We're focusing LiteLLM on being the most reliable LLM gateway in production. By retiring a set of older features and integrations that few teams use and that we can no longer maintain to the standard you expect, we can keep the core of LiteLLM stable and performant.

We are targeting to deprecate these features on our release on September 1st, 2026. You have about 2 months to migrate. If you don't use any of these, nothing changes for you. If you do use some of these and are passionate about it staying reply here with the feature and what your goal is.

This list is NOT final, we want feedback.

Dashboard features going away

Feature	Why it's going	What to use instead
Workflows	Experimental feature, did not get usage	None
Memory	Experimental feature, did not get usage	None
Playground's Agent Builder	Experimental feature, did not get usage	None
Prompt Management	Experimental feature, did not get usage	None
Old Usage page	Replaced by a faster, more accurate Usage dashboard	New Usage dashboard
API Reference tab	Being replaced by a guided getting-started flow	Guided getting-started flow
Learning Resources	Low usage	None
MCP Network Settings + "Internal network only" flag	Experimental feature, added more confusion, solved via permission management	Use a LB to filter, if you need public/private, use teams to gate public/private mcps

Integrations and backends going away

Feature	Why it's going	What to use instead
GreenScale logging	Low usage; can't maintain to the standard you expect	None
DynamoDB as a proxy database	Not something we can maintain to our reliability bar as a proxy database	PostgreSQL
Gradient AI provider	Upstream service was discontinued	None
S3 logging v1	Superseded by S3 logging v2	S3 logging v2
OpenTelemetry v1	Superseded by OTEL v2	OTEL v2
Disk caching	Upstream dependency no longer maintained, old integration	None
CloudZero connector	Replaced by the OTEL v2 connector	OTEL v2 connector
Prisma resolver v1	Superseded by the v2 migration resolver	Prisma resolver v2 (will be default)

Packaging change

We're consolidating our pypi and Docker packages down to a single litellm package. The extra variants (litellm-database, litellm-ee, litellm-dev, litellm-non_root) are going away. The litellm package will be the only suppported package moving forward and consolidate all functionality from litellm-database and litellm-non_root .

For our microservices helm chart, we will be keeping litellm-ui, litellm-gateway, and litellm-backend`.

I want to reiterate again, this is a living document and we are open to feedback. There will be a followup migration guide in the docs as we finalize things.

[jeann2013]

I like the direction of keeping LiteLLM focused on being a production grade gateway. One thought: have you considered moving some of the lower usage integrations and experimental features into community maintained plugins instead of fully removing them? That would keep the core lean while still allowing advanced users to extend the platform without increasing the maintenance burden for the core team. Especially as LiteLLM moves more of its hot path into Rust, having a well-defined extension/plugin API could become a really strong ecosystem story.

[Classic298]

Yeah makes a lot of sense here. Not impacted

[Gaket]

I like the direction of keeping LiteLLM focused on being a production grade gateway. One thought:... [can we have plugins]

I would stop at the first sentence. Plugins are hard, esp if they are across absolutely different parts of the system.

The decision is on the team, of course, but I think that would still add some distraction from the main goal.

[jeann2013]

I’m curious about your perspective on why plugins become particularly difficult in this context.

Many successful ecosystems (IDEs, API gateways, observability platforms) have grown around plugin architectures, so I'm interested in understanding where you see the trade offs for LiteLLM specifically.

Is the concern primarily around maintaining stable extension APIs, performance overhead, security, compatibility across Python/Rust boundaries, or something else? I'd be interested in hearing which engineering challenges you think outweigh the benefits.

[jeann2013]

One idea that might fit this direction is a Plugin/Extension SDK.

Instead of continuing to expand the core, LiteLLM could expose stable extension points for things like providers, routers, auth, billing, observability, guardrails, storage, and MCP. Features with lower adoption or more experimental use cases could live as independently maintained plugins.

This keeps the core smaller and easier to maintain, reduces review and testing overhead, and lets integrations evolve on their own release cycle. It also makes contributing much easier since new functionality doesn't have to be merged into the main repository.

Over time, I think this could help LiteLLM evolve from a gateway into a platform with an ecosystem around it, while allowing the core team to stay focused on performance and reliability.