▲ 447 points
back
82 comments
I found Ruby LLM to be surprisingly good - in terms of usability it's close to Vercel's AI framework.
It tries to strike a balance between working out of the box and being flexible... which has its challenges, still nice overall.
One big real-life pain I experienced is that caches don't always work, e.g. for xAI, since it only supports completions API and thought signatures are returned wrong.
Thank you!
Responses API is now implemented and it's coming in RubyLLM 2.0
https://github.com/crmne/ruby_llm/blob/main/lib/ruby_llm/pro...
Congrats Carmine on being featured!
I am using RubyLLM for quite some time and I am in love with the API design. If someone wants to see how this looks in a real project including custom tools, you can have a look at the SerpTrail project on GitHub.
The Chat model still is just:
class Chat < ApplicationRecord
acts_as_chat model: :llm_model
end
I am quite excited for RubyLLM 2.0 and beyond.
‘acts_as_chat’ feels super cute indeed.
I have an open source gem called Raix that builds on top of RubyLLM's abstractions and is quite popular. https://github.com/OlympiaAI/raix
We use and love RubyLLM! A wonderful and easy to use framework.
Agreed with another commenter on the frustration with the responses API not being naively supported; that seems like a huge miss. There is a connector from another dev, but it's buggy and not as high quality as the main gem.
Really looking forward to future development and especially 2.0!
Edit: Just saw that responses API is now native? I will definitely check that out.
Thank you!
Since a few mentioned Responses API: the reason why it wasn't implemented in 1.x is because RubyLLM 1.x effectively assumes a 1:1 mapping between provider and protocol. That assumption no longer holds since OpenAI has 2 protocols with different capabilities, and to access all VertexAI models we need to support a bunch under that single provider.
Therefore, a major refactoring to split Protocols and from Providers was needed, as well as a way to route different models to different Protocols under the same Provider, transparently.
That's one of the many things that's gonna ship with RubyLLM 2.0.
If you're curious: https://github.com/crmne/ruby_llm/commit/d398354da493570b050... https://github.com/crmne/ruby_llm/commit/0875ce2dfeae9d28a3a...
RubyLLM is very easy to use. Made extensive use of it for a project last year. Drawbacks are it was difficult to instrument for true trace observability and it has a pattern where retries will delete the underlying models so the history you see is clean but not necessarily great for seeing exactly what the sequence of API calls was.
Glad you like it.
Rails-style instrumentation landed in 1.16.0.
We've used RubyLLM for ~6+ months and it's been mostly OK. The API/Dev UX is good but we have seen little success with engaging the maintainer on PRs, and have noticed a lot of vibe coded PRs being merged (including some rewrites of PRs we submitted) - I suspect an minimal API compatible gem with similar heuristics would do well.
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.
I checked whether you or anyone from Wistia, your company, opened PRs.
I found one: #813, opened June 16, 2026. Last week.
> engaging the maintainer on PRs
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.
We use RubyLLM in production too, the most elegant library in this space I've seen so far.
I also liked how they run the issue tracker. If you select "Feature Request", it makes you explain how you explored workarounds, why you believe it belongs in RubyLLM etc to prevent scope creep.
I'm building something that is only pointed at Claude, and I don't anticipate moving away from the Anthropic ecosystem. Does RubyLLM offer me an advantage over directly using Anthropic's Ruby SDK?
To put it differently, is this more like choosing between Fog and aws-sdk-s3, or choosing between Active Storage and aws-sdk-s3?
It analogous to Active Storage and aws-sdk-s3.
Some of the things I like about RubyLLM: 1. the DSL - You can chain methods like ActiveRecord. 2. the Structure - If gives a way to organize agents, tools & prompts 3. the Portability - The costs of AI usage, will one day be an issue for any successful product. Being able to easily test and move from Anthropic to DeepSeek cut my bill down by over 90%. Knowing how easy RubyLLM makes it, ignoring this eventuality feels reckless to me. 4. ActiveRecord Integration - With a simple `bin/rails generate ruby_llm:install `, you can save each chat to your database. 5. Agent Training - This is a side benefit of the above, but has been a huge unlock for me. Since I have all my chats saved, I will regularly pull down that history and give it to claude code to refine my agent instructions.
Why build it in such a way that there you're locked into one provider when you can just use this tool and have the ability to choose any provider in the future? I mean, even for fallbacks, like what if anthropic API is down that particular day when you need the service?
I spent a lot of time with RubyLLM a few months ago. Very nicely designed and implemented. I have my own LLM clients written in various Lisp languages and I thought about appropriating some of the design of RubyLLM. Imitation is flattery.
thank you for bringing ruby into AI community and your open-source work.
Great language must be explored and get more attention :)
Thank you!
I love how MINASWAN Hacker News is when talking about Ruby!
RubyLLM is awesome! I use it on side projects. So interesting how questions and comments from last year SF Ruby conf, https://youtu.be/y535u1EWqAg?si=rbyv52T035apKwQk are already features shipped in the ecosystem.
In case you're using PHP or Node.js, we've made a similar toolkit free and open source on github: https://github.com/Qbix/AI/tree/main/classes/AI
We use this in production for a few apps. Great project.
Meanwhile Ruby is dropping like crazy on TIOBE. TIOBE has tons of issues, I get it, but the underlying message is that Ruby is struggling immensely, for many reasons (and has been for a while). The language is still great as-is, but if there is no solution to lack of new developers, ruby will just follow perl's path to extinction. AI is not going to save ruby here; quite the opposite. More AI will mean less quality overall. The AI generated documentation is useless gibberish. It's not even an improvement over lacking documentation in the first place, which many ruby projects also have as an issue.
I built a similar Ruby based agent development kit that has a different focus and feature set:
As a non-rubyist who nevertheless understands Ruby, and has a keen interest in cross-provider LLM frameworks / abstractions, chat.rb is the most beautiful implementation of the agentic tool-calling loop I've ever seen.
People point at pi-agent (Typescript) as a good one, but I find the Ruby version far more elegant, far more concise, and generally easier to read.
I think it could be simplified further at the cost of making the API a bit uglier — and perhaps an educational fork should be — but it's still really good.
Using RubyLLM in production for https://usetix.io
It drives our event chat agent that is enhanced with toolcalls etc. Super happy with it.
Laravel has a similar library
https://laravel.com/docs/13.x/ai-sdk
It is quite nice, but not as nice as you'd want. You still have to set platform specifics when running completions when you want to tune things like temperature, effort, max tokens, etc.
RubyLLM author here.
I'm not sure where you got that.
`chat.with_temperature(0.2)`
https://rubyllm.com/chat/#controlling-response-behavior
`chat.with_thinking(effort: :high, budget: 8000)`
https://rubyllm.com/thinking/#controlling-extended-thinking
Max tokens is the only one of your list that require provider specific params:
https://rubyllm.com/chat/#provider-specific-parameters
I'm one guy doing it for free. Happy to see your contribution!
RubyLLM is great! Been a very happy user for awhile now :)
Does 2.0 expose explicit capability negotiation, or does it infer capabilities from the selected model?
We have an extensive model registry with cost and capability tracking:
I have created an open source chatgpt clone with rubyllm, check it out here: https://www.railschat.org/
tried it and got this:
> Error: You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. * Quota exceeded for metric: generativelanguage.googleapis.com/generate_content_free_tier_requests, limit: 20, model: gemini-2.5-flash Please retry in 41.543129369s.
Thank you
I haven't tried it but it looks promising.
"What is the best language in the world (say ruby)" ;)
The hard part with these unified wrappers is always the leaky bits: prompt caching, tool-use schemas, structured output, and reasoning tokens differ enough across providers that a common interface tends to quietly drop whatever's provider-specific. How does RubyLLM handle that, escape hatches down to the raw provider, or normalize to a shared subset? Prompt caching is the one I'd care
about most, since it's modeled pretty differently between OpenAI and Anthropic and
it's where most of my cost savings come from.
I have been a fan of Ruby for many years, but in this fast paced era the Ruby ecosystem always struggled with the dependency versioning. Gems I relied on were never available or compatible with the rest of the ecosystem.
Why would anyone still build in dynamically typed languages in 2026? Why relinquish the crystal clear signals that static typing is able to provide to the LLM?