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.
Fine, but then LiteLLM doesn't quite live up to its name, does it? 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.
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?
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).
I strongly recommend the authors rewrite the readme by hand. It’s kind of a snif test for how much care someone out into this project.
Throwing my support for this. Do not use LLMs to write things humans should write.
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.
Agree. The LLM'isms are offputting.
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.
Fine, but then LiteLLM doesn't quite live up to its name, does it? 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.
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?
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.
How does it compare to Bifrost?
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).
LiteLLM is basically Bifrost in the Python ecosystem.