earcar

Source?

I prioritized shipping over carefully crafting docs. I thought nobody would read them and they'd rather enjoy the software. I was wrong. I'll rewrite them.

Author here.

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.

Author here.

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.

Author here. Two reasons I chose an immediate mode UI framework:

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.

Thanks for the link, I responded there: https://news.ycombinator.com/item?id=49519723

No. The "Star" button is a simple link to the repo.

No. The "Star" button on the website is a simple link to the repo.

Author here. Happy to answer any questions!

Author here. I opened the Solid Queue fiber-worker PR because I needed Rails background jobs to handle long-running LLM streams without allocating a worker thread per conversation.

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.

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!

We have an extensive model registry with cost and capability tracking:

https://rubyllm.com/available-models/

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.

I checked whether you or anyone from Wistia, your company, opened PRs.

I found one: #813, opened June 16, 2026. Last week.

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

Interesting! What were you guys trying to achieve by running them in your own tool harness?

Glad you like it.

Rails-style instrumentation landed in 1.16.0.

https://rubyllm.com/instrumentation/

Not yet. I'll do a series of blog posts and tweets in the next weeks.

Thank you!

I love how MINASWAN Hacker News is when talking about Ruby!

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