No contingency plan. I think I'd just try to talk them into adopting it or parts of it.
1,680 karma · joined February 19, 2010
But I can't guarantee that! Use it at your own risk.
I haven't seen any evidence of Spotify killing librespot. To me the project looks active and works totally fine. I don't have a new Spotify account to verify the claim above.
I suspect wilted-iris is conflating it with the recent changes to the Web APIs: new developer apps can't use all endpoints anymore. In Fastpotify if you add your Client ID I use both an older developer app and your app to keep everything as fast and seamless as possible.
Yes, the code is generated. Yes, the docs are generated. I agree LLM copy is annoying and will rewrite them myself.
But I built this for myself out of frustration with the official client, and I use it every day, so every bug I find is fixed immediately. I also care about bugs and PRs from other people, as you can see the amount that have been closed on the repo. The only reason I would stop maintaining this is if Spotify kills it.
I also wouldn't call this vibe coded either. Human directed and LLM generated is fairer. It's been an intense 5 days with tons of design decisions and testing on 3 platforms. I think we need a new vocabulary to distinguish it from "author doesn't care". I do.
1. Latency. A click paints on the next frame, because it sidesteps the stages of a retained mode UI: there's no dirty-marking, no layout and paint passes scheduled for later, no cached visual state that can be stale.
2. Simplicity. The UI is a plain function of app state. There's no retained tree to keep in sync and no invalidation bugs: mutate the state and the next frame shows it.
Yes, the drawback is that you have to watch what a frame costs, but it doesn't repaint at every frame. It paints on input and you can schedule repaints yourself. Fastpotify sits at zero CPU when idle, asks for a few frames a second while a track plays, and runs at full rate only while you scroll.
The implementation shipped today in Solid Queue 1.6.0. It uses one Async reactor thread per fiber worker, keeps thread workers available for CPU-bound or blocking jobs, and requires fiber-scoped Rails isolation.
One caveat: the benchmark results in the article were produced from the pre-release PR branch. I’ve marked that clearly and will rerun the suite against the 1.6.0 tag over the next few weeks.
Happy to answer implementation or Active Record connection-pool questions.
> 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!
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.
I found one: #813, opened June 16, 2026. Last week.
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...
Rails-style instrumentation landed in 1.16.0.
I love how MINASWAN Hacker News is when talking about Ruby!
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'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!
It had got us "more credibility" with our clients, and 12,500EUR less in each other's bank accounts.
Thanks for your insults.
If you want to move out of Europe, you get the exit tax as before.
It doesn't sound easy nor cheap to buy a company and change the company name.
UG & Co. KG has a couple of advantages and while it did add some money and time to the table, it doesn't change the story.
Notaries in the US are the price of a dinner. Many people have waited up to 6 months to receive their VAT ID from Berlin.
Trains, Berlin Brandenburg Airport, this.
It's rules and adherence to rules, more than efficiency, that I've found in my experience.