I tried submitting some PRs, but got a chilly reception. It was taking so long to make any forward progress on the parts I needed that I gave up, and wrote my own layer to do the parts of this that mattered to me. It didn't take long, and ultimately, I've customized it so much over time that I'm glad I didn't make this a dependency.
While the parts of this gem abstracting the various LLMs are nice and well designed, I think this kind of thing is a liability for anything but the most trivial applications. LLMs are moving too quickly to have the core connection infrastructure be gated on the release cycle of a third-party library. You can see this in the various comments down-thread where people are talking about the library lacking the Responses API -- it's great that the library is about to fix that problem, but if you just write your own adapter, you'd have been done months ago.
One of the biggest implications of LLMs in software, in my opinion, is that entire classes of third-party dependencies can be eliminated. It's interesting to look at which ones those are (and which ones continue to get interest) because it tells you a bit about where the post-LLM value of software will reside.
The repeated `chat.to_llm` message bug was reported Apr 30 2025, and fixed May 6, 2025, about 27 minutes after your comment.
It only showed up when reusing the same Rails chat object for multiple turns in the same Ruby object lifetime, e.g. `chat.ask("first"); chat.ask("second")` inside one controller action or one background job.
The usual flow is one turn per request/job, where the record is reloaded each time. Also, it did not overwrite records; it duplicated messages in the in-memory request context.
Gemini tool calling shipped in 1.0, schema support landed in 1.4, and observability landed in 1.16.
As for "the most trivial of applications": check the docs. RubyLLM goes well beyond that, and several multi-million-dollar companies use it in production every day.
> It only showed up when reusing the same Rails chat object for multiple turns in the same Ruby object lifetime, e.g. `chat.ask("first"); chat.ask("second")` inside one controller action or one background job.
That happens all the time. Without it, you can't pass things around to functions that add to the chat, for example.
> The usual flow is one turn per request/job, where the record is reloaded each time.
This may be your usual flow, but it doesn't have to be everybody's usual flow. No offense, but you're currently reminding me of what I interpreted as "chilly reactions" at the time.
> Gemini tool calling shipped in 1.0, schema support landed in 1.4, and observability landed in 1.16.
Great! I did them myself in less time. It's entirely possible that your library, today, is the tool I needed then.
> As for "the most trivial of applications": check the docs. RubyLLM goes well beyond that, and several multi-million-dollar companies use it in production every day.
OK. Cool. If they want to use the software, I'm sure nothing I say will convince them otherwise.
> Also, the same PR was reverted a bit later, IIRC
No. Your #151 was merged. The regressions it introduced were patched the next day in #157/#159.
Cheers!
Erm, OK. I don't think that's even close to what I did, but I guess people can read for themselves.
Again, this was not the only interaction I had with you folks, and even if you accepted my patch instantly and didn't roll it back or anything else at all (Also, once again: completely fine; I understand why you did it and don't fault you for doing it), the fact remains that there were lots of missing features that I needed, and working with you was slower than doing it myself.
Maybe that has changed, but I have to be honest: being defensive and prickly is not making me want to do it. You're actually pretty much illustrating the primary reason why I stopped.
Now you keep saying you had other bad interactions, but you haven't even said what they were. I have a feeling that if you named them, shortly later I'd read a comment about how it wasn't true. Again.
If the library didn't match your needs, that's fine. Who cares? That's happened to all of us many times, right?
I said they were slower than me. I didn't "call anyone out" for un-merging my PR -- I explicitly did the opposite. I could care less.
More than anything, I said I recalled that the reception was chilly. This thread has reminded me of why I had that opinion.
> If the library didn't match your needs, that's fine. Who cares? That's happened to all of us many times, right?
Sure. And we're allowed to talk about it.
2 days is a great turnaround time for PRs isn't it?
It's the wrong question; the first person was sharing their experience, and the reply jumped to collecting evidence that only vindicated the characterisation of a 'chilly response'. It's a human social skills thing. This place is not github issues. People who actually care will see. People who 'clarify' it here were never maintainers
I found one: #813, opened June 16, 2026. Last week.
Well, do real people want to "interact" with bots, including AI? I noticed this problem recently on prawn. Someone wants to merge about 1000 lines of code, 95% of what was auto-written by some AI model. Then he complained that the solo-maintainer does not want to review those ~1000 lines of code. What can I say ... I understand the issues by real humans more than by "vibe" coders here.