Which Buzz versions have functioning CUDA acceleration support?

[Gitoffthelawn]

The Buzz readme currently states:

If you are on Buzz version 1.4.6 or later and have a Nvidia GPU, go to Help -> About Buzz and install CUDA Acceleration.

Is that version number correct? I ask because, as of this post, the latest Buzz version on SourceForge and GitHub is 1.4.5.

There are post-1.4.5 dev releases (e.g. https://github.com/chidiwilliams/buzz/actions/runs/35691640768#artifacts), although it's unclear if those are the versions that the readme is addressing.

[yudin-s]

Your reading looks right: the docs currently point at a version that has not been published as a stable release yet.

The current release list shows v1.4.5 as the latest stable release, and the README/FAQ both say the Help -> About Buzz -> install CUDA Acceleration path applies to Buzz 1.4.6 or later. The FAQ also says the latest development builds can be downloaded from the GitHub Actions artifacts, which matches the dev-build link you found.

So I would interpret the state as:

• Stable packaged release: 1.4.5
• CUDA installer UI mentioned in docs: intended for 1.4.6+
• If you want to test that feature now: use a successful development build artifact from the main CI workflow, understanding it is pre-release/dev-build territory

For 1.4.5, the documented GPU path is still platform-specific rather than that 1.4.6+ in-app installer path: Linux mentions Nvidia GPU support out of the box with CUDA/cuBLAS/cuDNN caveats, Windows packaging mentions bundled GPU support plus CUDA 12 requirements, and PyPI installs need CUDA-enabled torch / torchaudio packages.

So yes, I think the README should probably be clarified to say that the in-app CUDA installer is for unreleased/dev 1.4.6+ builds until 1.4.6 is actually published.

If that clears up the version boundary, please mark this as answered so others do not go looking for a missing stable 1.4.6 download.

[Gitoffthelawn]

Thanks Serge. I appreciate your response. I'm just curious (no judgement, I promise), did you write all that by hand (if so, your writing skills are excellent!), or did AI lend a hand? If the latter, what was your process to generate the response?

I submitted PR #1634 to reflect our matching interpretation of the current situation.

[Bruce-Yii]

Good catch — the README is ahead of the releases. I verified just now: the newest published release is v1.4.5 (2026-08-23), while the README already documents the 1.4.6+ flow (Help -> About Buzz -> install CUDA Acceleration). So the version number is correct but forward-looking: the in-app CUDA installer exists on main / dev builds, not in any stable 1.4.x you can download from SourceForge/GitHub releases yet.

Practical options right now:

1. Wait for the 1.4.6 stable cut, then use Help -> About Buzz as documented.
2. If you need CUDA today, use the latest development build (see the FAQ entry "Where can I get latest development version", e.g. CI artifacts from a recent main run such as the one you linked) rather than 1.4.5 stable.
3. Alternative on any version: PyPI install (pip install buzz-captions, Python 3.12) plus the CUDA-enabled torch stack from the README GPU section.

Also note the README now says Intel Macs top out at 1.4.5, which is consistent with 1.4.6 being the next (unreleased) line. Worth filing a tiny docs PR/issue suggesting the CUDA paragraph say "upcoming 1.4.6 (currently dev builds only)" to avoid exactly this confusion.

[yudin-s]

Thanks, and nice move opening the docs PR.

Yes, AI helped with the first draft, but I do not use it as a substitute for checking the claim. My process here was roughly:

1. Check the published releases/tags to confirm the newest stable version.
2. Compare that with the README/FAQ wording about the 1.4.6+ CUDA installer path and dev build artifacts.
3. Draft the answer with AI assistance, then trim it back to only the claims I could tie to the release/docs state.

For these GitHub Discussions replies I try to keep the useful part source-backed: if I cannot verify the version boundary or code path quickly enough, I usually skip the thread rather than post a confident-sounding guess.

[Gitoffthelawn]

You're welcome. Thank you for the details. It's very interesting to learn how others are using LLMs. Are you largely using the LLM in a chat interface, with some back and forth between you and it? Or do you have it more automated than that?

I'm seeing an increase in AI/LLM content on GitHub these days, and I've noticed the quality of it is rapidly improving. In many cases, I'm noticing that it is making conversations easier to understand, as many developers and users are not fluent in English. Even for those that are fluent in English, often mathematics or science is their forté, and not writing. Consequently, AI/LLM output often improves the readability of what they are trying to convey to others.

[yudin-s]

Mostly the first one: a chat interface with a fair bit of back and forth, plus direct source checking alongside it.

For a GitHub Discussion reply like this, the loop is usually:

1. Read the thread and decide whether I can actually verify the useful claim.
2. Check the relevant release notes, docs, code, issues, or API output myself.
3. Ask the LLM to help turn those notes into a concise answer.
4. Remove anything that is too broad, too speculative, or not backed by what I just checked.

So it is not a fully automated posting pipeline, and I try not to let the model invent the confidence. The automation is more in the “find candidates, fetch context, keep an audit log” part. The actual value still comes from deciding whether the answer is grounded enough to post, and from skipping threads where it would only add noise.

I agree with your observation too. The best use I see is not making people sound artificially polished, but helping a technically correct answer become easier to read across language and writing-style differences.

[Gitoffthelawn]

Thanks for your detailed responses. I sincerely appreciate them, and learned from them as well. Thank you for taking the time to create them.