Hob, an MIT Desktop App From Frigade, Runs Gemma 4 and gpt-oss Locally and Publishes No Hardware Requirements

Frigade released Hob, an MIT-licensed desktop app that runs open-weight models on a user's own machine to work on local files, as version 0.2.1 on October 26. Its Show HN post, titled as an on-device alternative to Claude Cowork and ChatGPT, reached 114 points and 27 comments, and the README lists no hardware requirements.

The Hob repository shows 125 stars, 4 forks and 195 commits. It has two releases, 0.2.0 and 0.2.1, both dated October 26, and the 0.2.1 entry has no release notes beyond a changelog link. The README gives builds for macOS on arm64, Windows x64 and Linux x86_64 as an AppImage.

What Hob says it does

The README calls Hob "An easier way to use AI on your own computer" and says it is "Private, and works offline". It names Gemma and gpt-oss as models, and says "Hob picks the best frontier open-weight model that fits your computer and sets everything up for you." That selection claim is the project's own and is not backed by a published table.

The Show HN post, by a user who introduces themselves as Christian, fills in the design. Chats and files stay on the machine. Only web search, which uses SearXNG and can be turned off, and any MCP connectors the user adds go online.

Part	What the post says it uses
App shell	Electron
Inference	llama.cpp in a separate process
Code tools	Sandboxed Python, with OS-level sandboxing
Images	Qwen3-VL
Dictation	Whisper

The post names Gemma 4 and gpt-oss as the current models. The gpt-oss-20b model card lists Apache 2.0, 21B parameters with 3.6B active, and says the model can "run within 16GB of memory". The author wrote that "systems with 16+ GB of RAM do really well". Nobody in the thread tested that claim, and the README does not repeat it.

The Claude Cowork comparison

The title borrows Claude Cowork's name, but the README never mentions it and sets itself against Claude and ChatGPT only in general terms. The post describes the features users of those desktop apps expect: filesystem reads and writes, document conversion, charts, and PDFs filled in.

The author said the hardest problem was getting small models to call tools reliably, which took guards in code as well as prompt tuning. Neither the post nor the README publishes a tool-call success rate. The README also describes no permission model for the filesystem or for MCP connectors, so a reader cannot tell from the page which folders the app may change.

What the 27 comments raised

User dfltr wrote that "the last mile is so long in this space", citing the difficulty of choosing a model, a runtime and whether an M1 MacBook Pro can run anything useful. User eecks asked for examples of which hardware runs which models. The thread has no answer.

User l3x4ur1n said they use another agent, Hermes, with a cloud DeepSeek flash API as the driver most of the time, which sits oddly beside a fully local pitch. Others recommended koboldcpp, Open WebUI and LM Studio. Another commenter wrote that LM Studio is closed source and "you can't opt out of analytics".

The author said the project was renamed from Garth after a team vote, and that Electron was chosen because it is hard for a solo developer to keep native apps at feature parity. The heavy work, the post says, happens natively in llama.cpp.

Other small local models have been covered here before, including Microsoft's Decision-1, which is hosted-only, and WorldTUI's 360M model. Hob's README has no hardware table yet, and that is the gap the thread's most practical question points at.