Why open-source AI gateways belong in your stack – and why the enforcement layer still needs a vendor on the hook.
Open-source LLM gateways are how most platform teams start. They should. LiteLLM in particular is a good piece of software with an active community, a fast release cadence, and a tracker that gets real bug reports from real production deployments. Nothing below argues against using it.
It argues a narrower question than security – the case for who patches a CVE at 2 a.m. is a separate piece. This one is quieter: not whether the gateway is breached, but whether the gate held on a day when nothing went wrong. When the gateway is what stops an agent from spending money it shouldn't or reaching a tool it shouldn't, who is accountable when it doesn't?
Over the past two weeks, LiteLLM's own issue tracker has answered that question more clearly than any vendor pitch could. Here is what it shows, and what it means for anyone running an open-source control plane in production.
What the tracker shows
The reporter reproduced every item below against a published release, with config and output attached. None of them are theoretical.
1. A $0.02 budget admitted $0.225 of spend - and reported it correctly afterward.
#40741 – A ModelInfo validator writes None into its own cost fields, and the cost-map merge only fills absent keys – so a priced model reads back as unpriced, the pre-call estimate returns zero, and the budget reservation reserves nothing. On v1.97.0, a twenty-wide concurrent burst against a key with two cents of budget admitted all twenty requests and spent eleven times the cap. Post-call tracking resolves pricing separately, so the spend dashboard stayed accurate. The number on the screen was right. The enforcement behind it was off.
2. The team budget you updated governs nobody.
#40783 (opened 11 Sep 2026) – Updating a team's team_member_budget returns 200 and shows the new value. But existing members were cloned from the old default when added, and enforcement reads the clone - the update reaches no one already on the team. Nothing records which budgets were inherited, so no fix can safely propagate it. A budget page that looks configured while every member is enforced at a different number is an audit problem, not a cost problem.
3. The MCP deny rule that showed "Passed".
#40583 – Any pre_call guardrail – the built-in tool_permission and custom_code alike - cannot see tools in the Anthropic /v1/messages format. An admin adds a ^mcp__.*$ Deny rule; the UI confirms it is active, the guardrail fires, finds no tools, and passes the request through. The tool runs. The log shows Passed. The triggering client is Claude Code. Unfixed from 1.95.1 through 1.100.1 – every published version. An org-wide MCP ban enforced nothing for anyone on Anthropic's wire format.
4. The budget resets in the database and not in the cache.
#39726 – The scheduled end-user budget reset zeroes spend in Postgres but never invalidates the Redis counter enforcement actually reads. Worse, every rejected retry refreshes the Redis TTL, so a retrying client keeps its own block alive. One customer was locked out for 70+ seconds after their budget reset, released only when traffic stopped. Reproduced on 1.95.0; still present in 1.101.0.
5. The reset that can never complete.
#40564 – When more than ~32,700 end users share one budget, the reset cascade packs every ID into one prepared statement, PostgreSQL rejects it (bind-variable limit), the transaction rolls back, and the job retries every tick, forever. Capped customers stay rejected indefinitely; the only signal is a log line. A regression from 1.95.0. For a consumer product on a shared default budget, this is where enforcement silently stops resetting. For a consumer product on a shared default budget, this is where enforcement silently stops resetting.
6. The blocked call that left no trace.
#40555 – A pre_mcp_call guardrail block on the REST path was turned into an HTTP response, bypassing the failure handlers – so no spend-log row was written. A denied action missing from the audit trail is, to an auditor, an action that never happened.
And the longer tail, still open or only recently closed: budget enforcement bypassed outright in v1.82.3 (#26672); tag budgets skipped when the tag arrives on a header instead of in the body (#27480); exhausted budgets returning 429 on /v1/models and breaking every OpenAI-compatible client (#27923).
This is not a LiteLLM problem
It would be easy - and wrong - to read the list above as an indictment of one project. Look at what actually happened on the tracker: within days of each report, a contributor volunteered to fix it. #39729 is open against the cache bug. #40587 chunks the reset. A first-time contributor asked to take the MCP guardrail issue. That is open source working exactly as designed.
The problem is what happens between the report and the fix, and who carries it.
A monitoring bug costs you a data point. An enforcement bug costs you money, or control, or an audit finding - and, as every case above demonstrates, it does so silently. The budget bug reported correct spend. The team bug returned 200. The guardrail bug logged Passed. The reset bug logged a line nobody was watching. Enforcement failures do not announce themselves, because the whole point of enforcement is that nobody is supposed to be watching.
When that happens on open-source software, the answer to "who owns this?" is: you do. The maintainers owe you nothing - not a response time, not a fix window, not a backport, not a regression test on the request path your client uses. The license says so, in capital letters. That is the correct deal for a library. It is a strange deal for the component whose only job is to say no.
