Rendered at 14:12:56 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
swe_dima 23 hours ago [-]
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.
earcar 23 hours ago [-]
Thank you!
Responses API is now implemented and it's coming in RubyLLM 2.0
Do you have any details published around 2.0? Would love to learn more.
earcar 23 hours ago [-]
Not yet. I'll do a series of blog posts and tweets in the next weeks.
curtisboortz 20 hours ago [-]
[flagged]
strzibny 7 hours ago [-]
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
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.
earcar 20 hours ago [-]
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.
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
qrush 13 hours ago [-]
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.
timr 10 hours ago [-]
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.
earcar 6 hours ago [-]
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.
nougati 2 hours ago [-]
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.
timr 6 hours ago [-]
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.
earcar 6 hours ago [-]
Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago.
> 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!
timr 5 hours ago [-]
> 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.
earcar 6 hours ago [-]
I checked whether you or anyone from Wistia, your company, opened PRs.
I found one: #813, opened June 16, 2026. Last week.
shevy-java 11 hours ago [-]
> 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.
Finbarr 22 hours ago [-]
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.
What do you mean by "Rails-style"? It's mentioned a lot in the documentation.
aaronbrethorst 19 hours ago [-]
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?
techscruggs 15 hours ago [-]
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.
aaronbrethorst 13 hours ago [-]
Awesome, thank you for the feature run-down
piratebroadcast 18 hours ago [-]
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?
hakunin 17 hours ago [-]
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.
rohitpaulk 21 hours ago [-]
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.
mark_l_watson 19 hours ago [-]
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.
zhisme 23 hours ago [-]
thank you for bringing ruby into AI community and your open-source work.
Great language must be explored and get more attention :)
earcar 23 hours ago [-]
Thank you!
I love how MINASWAN Hacker News is when talking about Ruby!
mogox 19 hours ago [-]
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.
digitaltrees 21 hours ago [-]
We use this in production for a few apps. Great project.
RubyLLM is great! Been a very happy user for awhile now :)
mosselman 23 hours ago [-]
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.
I'm one guy doing it for free. Happy to see your contribution!
mosselman 22 hours ago [-]
Hi! Valid challenge, I am probably misremembering. We were playing with various 'one-interface to all providers' solutions and I might have mixed up RubyLLM there. Sorry for that.
I will have a deep dive into which things I felt we needed to adapt per provider.
I didn't mean to imply that you have to solve all of our wants of course.
One thing we did do was monkey-patch the spot where tool_calls are performed by RubyLLM. We had our own mechanism for that and were able to skip RubyLLM's and still extract the tool calls and run them through our own tool harness. That all worked beautifully. I don't know if that type of stuff is something you want PRs on or that you want to keep steering towards the route that does everything within RubyLLM classes. Happy to contribute some of that.
earcar 22 hours ago [-]
Interesting! What were you guys trying to achieve by running them in your own tool harness?
mosselman 20 hours ago [-]
We had already implemented tool_calls in our own database and have a system that executes them and creates our conversation array, etc. So we wanted to leverage the providers that RubyLLM supports without having to change the tool execution in our platform.
realty_geek 19 hours ago [-]
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.
jaredsohn 17 hours ago [-]
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.
katzgrau 12 hours ago [-]
The issue is that it’s relatively low effort to make false and unverified claims. Defending and refuting it is a much higher effort task for the person doing the work to everyone else’s benefit.
RubyLLM dev literally had to take time to provide code samples and doc links.
No issue with listing legit limitations, but be a bro and fact check claims before wasting a volunteer’s time - and potentially leading other developers on a public board astray.
jaredsohn 11 hours ago [-]
I completely agree that unverified claims create a heavy burden for maintainers. My only point was about the language used: 'disparaging' to me implies a bad-faith attack or a dismissive attitude, whereas this was just an honest technical mix-up that the poster immediately corrected.
I think part of the confusion with that word comes from things like corporate non-disparagement clauses. In those contracts, lawyers write the terms so broad that "disparagement" means saying anything negative, regardless of malice or intent.
techscruggs 23 hours ago [-]
And thank you! It is absolutely awesome and a true joy to work with.
> 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.
fragkakis 17 hours ago [-]
I have used a personal Gemini token for all users, which often exceeds quota. You can:
1. Check out the repo and use your own tokens
2. Use your own tokens in the browser, they are only held in the browser and are not being persisted or logged in the backend
hit8run 20 hours ago [-]
Using RubyLLM in production for https://usetix.io
It drives our event chat agent that is enhanced with toolcalls etc. Super happy with it.
shevy-java 11 hours ago [-]
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.
"What is the best language in the world (say ruby)" ;)
bitedeck 22 hours ago [-]
Thank you
grepzero 16 hours ago [-]
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.
maxothex 22 hours ago [-]
[flagged]
modgate 12 hours ago [-]
[dead]
randomuser558 20 hours ago [-]
[flagged]
balicien 23 hours ago [-]
[dead]
mv_d5339e31 13 hours ago [-]
[dead]
guesswho_ 21 hours ago [-]
[dead]
Mr_Xpes 13 hours ago [-]
[flagged]
arbirk 20 hours ago [-]
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.
notpachet 22 hours ago [-]
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?
MitziMoto 20 hours ago [-]
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.
lackoftactics 19 hours ago [-]
Why do you think that follows?
I was on team dynamic typing for about 12 years, and Ruby was a big part of that. I still think dynamic languages can be wonderful to read and write.
But after using modern statically typed languages with good inference, I changed my mind. Many of my old objections were really objections to verbose type systems, not static typing itself. With inference, you can keep a lot of the readability while gaining safer refactoring, better tooling, and earlier feedback.
That doesn’t mean dynamic languages can’t produce high-quality software. They obviously can. But I don’t think appreciating modern static typing is just evangelism.
And yes, I understand what this library is about, it's for "beautiful" easy to use interface to AI providers for Ruby apps. It's the popular play nowadays with litellm, bifrost, gomodel and vercel gateway. We have at least couple AI gateways, libraries like that every week on HN.
pmdr 17 hours ago [-]
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?
notpachet 16 hours ago [-]
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.
lackoftactics 20 hours ago [-]
Even as rails dev, I am seeing that you might be right. It’s really hard to find specific pros nowadays that Ruby brings to the table. All that talk about conventions over configurations and vast presence of Rails in weights is fun, but if writing speed isn’t an issue anymore, then Ruby on Rails has serious problems with larger codebases
cutler 20 hours ago [-]
Codebases like Stripe?
lackoftactics 19 hours ago [-]
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
cutler 14 hours ago [-]
AirBnB.
taylorlapeyre 22 hours ago [-]
Well, LLMs have an obscene amount of context built into their weights about Ruby on Rails, and can work within it extremely quickly.
jimbokun 22 hours ago [-]
This is not a tool for using LLMs to write Ruby code.
notpachet 16 hours ago [-]
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.
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.
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...
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:
More: https://github.com/serpapi/serptrailI am quite excited for RubyLLM 2.0 and beyond.
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.
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...
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.
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.
Rails-style instrumentation landed in 1.16.0.
https://rubyllm.com/instrumentation/
To put it differently, is this more like choosing between Fog and aws-sdk-s3, or choosing between 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.
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.
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 love how MINASWAN Hacker News is when talking about Ruby!
https://rubyllm.com/available-models/
https://github.com/tweibley/legate
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!
I will have a deep dive into which things I felt we needed to adapt per provider.
I didn't mean to imply that you have to solve all of our wants of course.
One thing we did do was monkey-patch the spot where tool_calls are performed by RubyLLM. We had our own mechanism for that and were able to skip RubyLLM's and still extract the tool calls and run them through our own tool harness. That all worked beautifully. I don't know if that type of stuff is something you want PRs on or that you want to keep steering towards the route that does everything within RubyLLM classes. Happy to contribute some of that.
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.
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.
RubyLLM dev literally had to take time to provide code samples and doc links.
No issue with listing legit limitations, but be a bro and fact check claims before wasting a volunteer’s time - and potentially leading other developers on a public board astray.
I think part of the confusion with that word comes from things like corporate non-disparagement clauses. In those contracts, lawyers write the terms so broad that "disparagement" means saying anything negative, regardless of malice or intent.
> 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.
You can build high quality software with dynamically typed languages, and Ruby is an absolute dream to read and write.
I was on team dynamic typing for about 12 years, and Ruby was a big part of that. I still think dynamic languages can be wonderful to read and write.
But after using modern statically typed languages with good inference, I changed my mind. Many of my old objections were really objections to verbose type systems, not static typing itself. With inference, you can keep a lot of the readability while gaining safer refactoring, better tooling, and earlier feedback.
That doesn’t mean dynamic languages can’t produce high-quality software. They obviously can. But I don’t think appreciating modern static typing is just evangelism.
And yes, I understand what this library is about, it's for "beautiful" easy to use interface to AI providers for Ruby apps. It's the popular play nowadays with litellm, bifrost, gomodel and vercel gateway. We have at least couple AI gateways, libraries like that every week on HN.
Why did people switch to these languages in the first place and what's driving the current back-to-typed-languages trend?