Focus: Stabilize core features and fix accumulated bugs/UX issues

[babanetworx]

The Ask

Take a step back from new features and focus on making everything already documented work correctly.

The proxy and UI have accumulated numerous bugs and broken/incomplete features over successive releases. Rather than continuing to add new functionality, we should prioritize shipping a solid, reliable baseline where every documented feature actually works as expected.

---

Why This Matters

• Erodes trust: Users encounter broken features that are documented, making the project feel incomplete
• Regression burden: Each new feature adds potential for breaking existing functionality
• UX friction: Non-working features frustrate users and create support overhead
• Maintenance debt: The longer bugs sit, the harder they are to fix (context is lost, root causes become unclear)

---

Suggested Focus Areas

Proxy

• Request routing reliability
• Error handling consistency
• Health checks and status endpoints
• Authentication/authorization edge cases
• Timeouts, retries, and fallback behavior

UI / Dashboard

• Working log viewing and filtering
• Accurate usage metrics and reporting
• Navigation and settings that actually persist
• Responsive behavior across viewports
• Real-time updates (if applicable)

General

• All documented API endpoints behaving as specified
• Configuration options that actually do what they claim
• Error messages that are clear and actionable
• Feature flags that correspond to actual behavior

---

What We're Not Asking For

This is NOT a call to stop development or remove features. It's a request to:

1. Audit the existing feature set against actual behavior
2. Fix or document broken/unreliable features
3. Establish stronger regression testing before releases
4. Slow down new feature additions until the foundation is solid

---

How to Help

• Confirm which issues you're aware of in the proxy/UI that match this pattern
• Link related issues that should be addressed as part of this stabilization effort
• Consider pinning this issue while the work is done

---

We want to love litellm — right now the bones are great but the finish work is needed.

[ishaan-berri]

@babanetworx this is great feedback

• What are the areas you'd like us to focus on ?
• Can you give me some core flows that you're trying to do ?
• Can you point me to recent bugs that you saw ?

[krrish-berri-2]

We want to love litellm — right now the bones are great but the finish work is needed.

Appreciate this. This aligns with our thinking of using April in a stability sprint.

Echo'ing ishaan's point, how would you recommend we approach this?

[krrish-berri-2]

Pinning this ticket, in case others want to add in their thoughts

[mubashir1osmani]

There are multiple "failing" lints that are impacting basically every PR. As an example, "Run MyPy type checking" causes failures on PRs even to new branches from main. This makes knowing if contributions are negatively impacting code quality. Is there appetite/desire for these to be fixed and turned into requirements for code to be merged?

it'd be great if we can make contributing easier. current documentation shows use of make lint which runs on every unchanged file. we also need to find a way to better address the failing tests on every PR, users do not know if their changes are making our codebase better / worse.

keep our PR checklist strict, manual testing should be a MUST. users should feel confident that their contributions will be accepted within litellm. if not make sure they're recieving feedback on what changes could be better

[mubashir1osmani]

might be stating the obvious but: follow a strict release pattern, lower the number of releases, a second user should be responsible for QA'ing changes for each customer before its sent out to them

[pyguy]

It's a great idea to focus on fixing accumulated bugs, I personally would like to promote fixing team member budget issues, like the following:

#21109

Thanks.

[kolchinae]

#24437
#21102

[Classic298]

As we reported through other channels

• many requests always or almost always go through passthrough endpoint and support has no idea why, which causes difficulty in logging
• Redis has to be configured TWICE in two areas in the config.yaml otherwise spend logs dont work CC @Sameerlite
• web search in UI is still not on the same level as is with config - on config.yaml you can configure all providers properly. On UI, you can't because the UI is missing some fields for some providers for example Google PSE requires the Key AND the search engine ID and you cant configure them in the UI
• Certain response types (SearchResponse, possibly others) don't have a model attribute. When LiteLLM tries to extract model/endpoint info from these responses, it fails and defaults to empty values.
  • Affected Endpoints
    • /search
    • /ocr
    • Possibly others
• ValueError: Unknown partner model: zai-org/glm-4.7-maas: Vertex AI partner models (GLM-4.7, Moonshot Kimi, etc.) are not recognized by LiteLLM's model registry. When unrecognized, requests are incorrectly treated as pass-through
• Post Call Failure Hook does not always invoke, which causes user frustration
• Gemini Deep Research on Vertex AI doesnt work
• Web Search interception missing from UI even though available on config.yaml
• Gemini 3.1 flash image preview doesnt work when called via normal endpoint of Open WebUI CC @yuneng-berri @Sameerlite
• Cached tokens for most providers are not shown in the UI because the wrong fields are being requested from the database CC @yuneng-berri

[bn-msethuraman]

Most of these were reported through Slack or other channels and apply to v1.82.3:

• Cost pane in LiteLLM UI shows duplicate date bars (e.g., Feb 12, 13, 17 appearing twice).
• Broken invite links: When an admin create a new user using 'Invite User', the invite link generated is just https://base-url/ui with no invitation ID — making it non-functional. Admin has to then choose to reset password and use that as a work-around.
• Observability > Usage doesn't retain chosen filters, date ranges etc when hitting refresh.
• Deployments where admin and inference nodes are separate are seemingly not treated with importance. We run into the use of the incorrect URL in several places (documentation and UI tooling) or see regressions over time. As an example - Admin UI "Create Agent" fails due to Admin/Inference node URL mixing.
• database_connection_pool_limit: 50 is not honored - 7 pods × 2 workers × 50 connections should cap at 700, but connections exceeded 1000, crashing clients. LiteLLM's performance engineer reproduced the bug and noted other customers reported the same, but no fix or update has been shared since early Feb. We are currently working around this by using pgbouncer between LiteLLM and Postgres
• UI could enforce input validations in LOTS of places. Key management is an area with a lot of quirks (values that should be invalid are accepted and defaults silently applied, team limits on key duration not enforced on regenerate)
• Costs shown by Usage don't match independent measures. We've shared an example where token counts match but dollar amount shown by LiteLLM doesn't match tokens * price per token
• Prisma migrations missing things leading to broken functionality with configurations that previously worked. Example - MCP servers
• Long term viability of Prisma migrations are a concern. Notice: Deprecation of the Prisma Python client #9753

[metalshanked]

A recent regression from 1.82.6 to 1.83.x --> #25143

[yuquan2088]

Strong +1 on the stability sprint — especially the cost tracking and logging reliability items. These are foundational.

One angle worth adding to the roadmap: as teams move from single LLM calls to multi-agent pipelines, the observability problem shifts from "which model was called" to "which agent did what, on whose behalf". Cost/token attribution at the agent level becomes murky fast.

I've been building around this problem — an open-source layer called ClawSocial that gives agents a persistent identity (agent card) and behavioral reputation signal. The idea is that litellm handles the LLM call observability, while a layer above tracks who (which agent identity) made the call and whether its behavior is consistent with its declared purpose.

Not suggesting adding this to litellm itself — just flagging it as a natural extension point once the core logging is solid. Would be happy to explore a callback/hook integration once the stability work lands.

The bones really are great here. Good luck with April.

[yongzhang]

I feel the releases are kind of a bit messive and not consistent with the docs. Maybe they can just follow basic Semantic Versioning, for example, for 1.82.3-stable, maybe it can just be 1.82.3, then 1.82.3-stable-patch1 seems weird and maybe it can be 1.82.4 (minor version to 1.82)? And there're are lots of -dev, -dev.xxx etc ... I don't know if these are valuable to end users.

[f403]

Joining the comment from @yongzhang.

1. This blog post appeals to update to v1.83.0, but main-stable (on ghcr.io as of today) is pointing to v1.82.3-stable.patch.2
2. Which repo is used for distribution? It used to be ghcr.io/berriai/litellm, but now the documentation contains two servers: docker.litellm.ai (which is hosted by scarf.sh) and ghcr.io - GitHub