Alpaca's screenshot table names three features its feature list never mentions

The screenshot table names three features the feature list omits

The Screenies section is a five-column table. The header row names Normal conversation, Image recognition, Custom Character, Integrated Script Execution and Web Search Integration. The alignment row underneath is present and correct. The row after it is five empty cells.

So the five screenshots are missing, and the captions are the only description of what is in them. Three of those captions do not correspond to anything in the feature list. Custom Character, Integrated Script Execution and Web Search Integration appear nowhere in the thirteen bullets that follow. Image recognition is the only caption the feature list backs up.

This is not a cosmetic gap, because the two missing captions are the two most consequential features on the page. A character system changes what a conversation is, a web search integration changes where the model's answers come from, and script execution changes what happens on the machine when a response arrives. A reader building a feature checklist from this README would miss all three.

The warning about model-written code describes a capability the list never claims

The first warning block says the author is not responsible for any damages to the device or software caused by running code given by any AI models. That disclaimer only makes sense if the app can run code that a model produced, which is what the screenshot caption Integrated Script Execution describes.

The feature list says nothing about executing anything. What it does list is image recognition, document recognition limited to plain text files, YouTube recognition that answers questions about a video using its transcript, website recognition that works from a pasted URL, chat import and export, editing and deleting messages, regenerating messages, notifications, multiple conversations, talking to several models in one conversation, and pulling or deleting models from the app.

Read together, the two parts of the page tell you something the list does not: there is a code execution path, the author considers it dangerous enough to disclaim liability in the first block of the page, and it is still undocumented on the page. Anyone deciding whether to let Alpaca near a machine with real work on it has to work that out from a caption in an empty table.

There is no install command and the one download link has no text

The README contains no installation section. There is no package command, no build instruction, no dependency list and no platform requirement. The single distribution link is an anchor pointing at a Flathub listing for the identifier com.jeffser.Alpaca, and the anchor has no text inside it, so the page shows a blank space where the download should be.

The repository itself is a normal GNOME application layout: a `meson.build` at the root, `src/` and `data/` directories, a `po/` directory for translations, a `com.jeffser.Alpaca.yml` manifest matching the Flathub identifier, an `Alpaca.doap` file for software catalogues, a `translation_tool.sh` script, and a `SECURITY.md`. Everything needed to build it is present, and the packaging page on the author's site exists for people who want a different packaging method.

None of that is written on the page. A reader who wants the source build has to find the packaging wiki page; a reader who just wants the app has to recognise that the empty link is a Flatpak listing.

Documentation, translations and packaging all live on one personal domain

Three separate things a contributor or a user needs are hosted outside the repository, and all three are on the same personal site. Documentation and tutorials are at jeffser.com, introduced with the words that they are now available there, which implies they used to live somewhere else. The guide for adding a language is a wiki page on that same domain. The guide for packaging Alpaca another way is a third page there.

The repository has no documentation directory at all, so nothing in the tree explains how the app is put together, what the settings do, or what the translation workflow expects from a contributor. What the tree does contain is the translation script itself, which means the tooling is open and the instructions for driving it are not.

The translator table that replaces conventional documentation is extensive: 26 languages, from Russian and Spanish through Bengali, Hindi, Telugu, Kannada, Tamil, Georgian, Hebrew, Arabic, Belarusian and Kabyle, each credited to named individuals. One contributor is listed twice, for Bengali and Hindi. That table is the closest thing the repository has to an architecture document, and it is a list of people.

Three governance blocks sit above the feature list

Before a single feature is described, the page states three rules. The first warning says the project is not affiliated at all with Ollama and that the author is not responsible for damage from running code produced by any model. The second, marked important, says the GNOME Code of Conduct applies to Alpaca before interacting with the repository. The third warning says AI generated issues and pull requests will be denied, with repeated offence resulting in a ban, and adds that the author does not want the project vibe-developed.

That is an unusual set of constraints for a client app, and two of them are worth understanding on their own terms. A project built on someone else's daemon stating non-affiliation plainly is protecting itself from a trademark confusion problem. A maintainer refusing generated contributions is making a maintenance decision: an issue tracker is a place where a human has to read and answer, and a flood of machine-written reports is a cost with no benefit.

The consequence for users is narrow but real. Alpaca is a good candidate for automation tooling, since it is a GTK application with a Flatpak manifest, and it is explicitly not a candidate for automatic issue filing or automated patches.

Release titles say Fixes and Small Update, and one names a GNOME version

The three most recent tags are numbered 9.2.5, 9.2.4 and 9.2.3. Their titles are Fixes, Small Update and Gnome 50 Update respectively. Only the third tells a reader anything about what changed, and what it tells them is that the app moved to a specific GNOME release.

That last one is the informative case, because it shows the coupling between the app and the desktop it runs on. A GNOME client has to track the platform underneath it, and a release named after a GNOME version is a release where something in the toolkit interface changed. It also means the app's own version number, 9.2.x, does not encode the platform it targets, so there is no way to tell from the version alone which GNOME release a given build expects.

The dates are closer together than the titles suggest. 9.2.3 landed on 2026-04-02, 9.2.4 on 2026-06-26, and 9.2.5 on 2026-08-03, the same day as the last push to the default branch. So the newest tag is also the newest commit in the tree, and everything after it is still unreleased.

Model management happens inside the app, and cloud models use your own keys

Two capabilities sit at opposite ends of the trust model and are described in one bullet each. Pulling and deleting models from the app means the client talks to the Ollama daemon to fetch weights and to remove them, which is a different kind of permission than sending a message. Talking to cloud-hosted models through OpenAI-compatible APIs uses your own API keys, so the key material belongs to the account you already have and the app is a client of it rather than a reseller.

The Ollama dependency is stated once, in the first paragraph, and the non-affiliation warning follows from it. The project describes itself as an Ollama client where you can manage and chat with multiple models, and adds that third-party providers such as Gemini and ChatGPT can be used as well. The repository's one-line description calls it a local and online AI hub, which is the same design stated more tersely.

The input features are narrower than their names suggest, which is useful to know before installing. Document recognition is scoped to plain text files. YouTube recognition works from the transcript, not from the video. Website recognition requires pasting a URL. None of the three is a general document or media pipeline, and the README does not state size limits for any of them.

Editorial conclusion

Alpaca is a reasonable desktop front end for someone who already runs Ollama and wants model management, chat history and file input in one window, and its refusal to accept machine-written contributions is a deliberate choice rather than an oversight. Before installing it, look past the feature list: the two capabilities the README is most careful about, script execution and web search, are the ones it names only in a screenshot caption, and the documentation that would explain them lives on the author's own domain rather than in the repository.

Frequently asked questions

Official sources

1. Jeffser/Alpaca on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases