Live data from Hacker News

RubyLLM: A Ruby framework for all major AI providers

rubyllm.com

51–60 of 91 posts

Re: RubyLLM: A Ruby framework for all major AI providers

#51

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?

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?

Not the commenter, but the reason is the same as the choice to use direct db driver vs ORM - you get to take full advantage of special features and intricacies of one system, rather than trying to maintain a lowest common denominator of functionality between multiple ones.

You can always build multiple clients however. It could be one thorough integration with one API, and a simpler backup via RubyLLM.

Unless of course RubyLLM supports all of the above, but even then, are they going to be able to keep up as much as a native client in the long term?

The answer is almost always that a native client for a more critical integration is the right call. You can always add another if you need it.

Re: RubyLLM: A Ruby framework for all major AI providers

#52

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?

You static typed evangelists have lost your damn minds. You seem to have completely misunderstood what this library even is because you have some primal urge to boast static typing at every chance. You can build high quality software with dynamically typed languages, and Ruby is an absolute dream to read and write.

Static typed languages had been around a long time before Python, JS and Ruby gained popularity. All three of the latter now support some form of type hints.

Why did people switch to these languages in the first place and what's driving the current back-to-typed-languages trend?

Re: RubyLLM: A Ruby framework for all major AI providers

#53
post #4

Earlier quoted context omitted.

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…

Well put!!! You work your arse off for free and the guy who made the disparaging comment didn't even bother to research to see if he had the details right. Hat's off to you Carmine for all your work. Many people really do appreciate it.

FWIW, I don't think the GP post is disparaging (at least as I read it right now.)

I think it is fair to list limitations from using a library that provides an abstraction; it can suggest why a tool isn't right for a person's use cases.

But it also sounds like this API handles those pretty well.

Re: RubyLLM: A Ruby framework for all major AI providers

#54

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?

You static typed evangelists have lost your damn minds. You seem to have completely misunderstood what this library even is because you have some primal urge to boast static typing at every chance. You can build high quality software with dynamically typed languages, and Ruby is an absolute dream to read and write.

I didn't misunderstand what this library is about. I assume the authors are using LLM's to help author their code in general, even meta-frameworks like this.

Re: RubyLLM: A Ruby framework for all major AI providers

#55

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?

This is not a tool for using LLMs to write Ruby code.

No, it's just a tool someone posted that's written in Ruby, with a strong signal that the authors are LLM proponents. It could have been a todo list and I'd still have the same question.

Re: RubyLLM: A Ruby framework for all major AI providers

#56
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.

Re: RubyLLM: A Ruby framework for all major AI providers

#57

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.

Re: RubyLLM: A Ruby framework for all major AI providers

#58
post #16
post #14

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. https://rubyllm.com/instrumentation/

What do you mean by "Rails-style"? It's mentioned a lot in the documentation.

Re: RubyLLM: A Ruby framework for all major AI providers

#59
post #37

Earlier quoted context omitted.

Codebases like Stripe?

they introduced static typing (Sorbet) to avoid problems, it's completely different app and looks nowhere close to what you experience in standard Rails app

AirBnB.

Re: RubyLLM: A Ruby framework for all major AI providers

#60

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 Ru…

Awesome, thank you for the feature run-down
Post reply on HN