Funny, everything you pruned away is the reason I’m deploying LiteLLM in our platform. Having a reliable way to track token spend per customer across different services is important to us, and LiteLLM handles this well
Really? I mean, yeah, it's probably written by an LLM, but it's hardly the worst that I've seen. Looks way more straight forward than the modern README featuring a ton of badges, emojis, confusing out-of-context screenshots, "trust me bro" installation instructions, vague elevator pitches, "used by netflix, nasa, disney, good morning america, alex jones, the church of scientology", and other verbiage to create the illusion that the author won't immediately get bored and abandon their glorified dissertation piece. They all scream "give me your github stars" whereas this one doesn't. But I still get what you mean when it comes to the particular 'isms.
This is a cool project, and the idea of using LLMs to selectively extract features from open source projects is an interesting concept.
The only thing I take issue with is the phrase "LiteLLM Without the Bloat." A lot of the features that have been removed (like cost tracking, streaming, caching) are... kind of the core value proposition of LiteLLM for many of their users.
LiteLLM doesn't quite live up to its name. With all those features, there is nothing "lite" about it. It is essential for a project to live up to its name.
Imagine Sqlite adding heavy features from Postgresql, e.g. row-level security.
But imagine Sqlite not supporting joins or window functions... sure they are useful but look how many LOC it adds! Who is the arbiter of what Lite actually means?
This is a 30 minute project with a frontier LLM. I don’t see why anyone would use anyone else’s router. Techniques are valuable today. Libraries are not.
First off, cool project! It's always great to see derivatives that question the efficiency of the established product.
I think the main thing the readme is missing is the core benefits. Reducing LOC and dependencies is cool, but it would be great to understand if this provides some additional benefits like lower latency or memory requirements.
I'm always confused by LLM proxies that claim to support tool calling. Even for Bifrost that claims to be doing it, at least when I was checking it out, I found out that while it injects the list of MCP tools that's available on the proxy-side, it doesn't actually make the call on client's behalf, and clients get confused by it (response returns MCP call request whose tool doesn't exist on the client-side).
> Please don't post shallow dismissals
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage.
See: Hacker News Guidelines
I’m biased but I think mine is coded to a higher standard than litelm. https://github.com/s-banach/langchaint
The only thing I take issue with is the phrase "LiteLLM Without the Bloat." A lot of the features that have been removed (like cost tracking, streaming, caching) are... kind of the core value proposition of LiteLLM for many of their users.
Imagine Sqlite adding heavy features from Postgresql, e.g. row-level security.
Yes, LLMs can do a great job at writing semi-working MVP. Turning it into a usable project still requires a team.
Yeah, maybe for your toy project you can use a LLM written tool.
Also, I am not saying LiteLLM is good either.
I think the main thing the readme is missing is the core benefits. Reducing LOC and dependencies is cool, but it would be great to understand if this provides some additional benefits like lower latency or memory requirements.