Similar experience. I tried using this library about a year ago, but the Rails integration was really rough at the time, and things like persisting the conversation to the database required essentially bespoke code. Also, tool use, schemas, etc. for Gemini required a lot of work, observability was limited, and IIRC, it did stuff like overwriting records in specific situations. I don't know if that is improved, but it was essentially a no-go for me at the time.
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.
Your PR #151 was opened May 4, 2025 and merged 2 days later.
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.
The decision to audit (frankly, aggressively) this guy out the gate with this comment on a discussion thread is not a good look. It's a very unnecessary way to tarnish the reputation of the devs by picking fights with someone sharing their experience. If you can't see how you did that, perhaps you should ask an LLM to help.
I don't remember every interaction I had with you folks, but that wasn't the only one. Also, the same PR was reverted a bit later, IIRC -- I think I made a mistake in my PR or it wasn't compatible with some other use case, so that's fine, but the overall theme of the interactions (again, in my recollection) was that I was personally moving much faster than you, and using your library was hurting more than helping. So I stopped.
> 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.
> Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago.
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.
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.