I’m riskpw, a maker rather than a professional software engineer.
My background is in open-source hardware communities. I started RaspberryPi Village in 2013 and helped form the OpenMake community team in 2016. OpenMake Team is not a company. It is a community of people who enjoy open source, open hardware, and running what they build on equipment they own.
On February 3, 2026, I made the first commit to openmake_llm.
The starting point was simple: I wanted an AI workspace that could run on hardware I already owned, where I could decide which models to use and where the application, data, and inference boundaries should live.
I lead the project through AI-assisted, “vibe coding,” with professional developer rocky supporting development and technical review.
That description can sound like AI wrote the code and the product simply appeared. The reality was almost the opposite.
AI helped us produce code quickly. It also helped us accumulate wrong assumptions quickly. The important work was running the system on actual hardware, finding where those assumptions failed, and deleting or rebuilding what did not work.
The current operating topology: OpenMake and LiteLLM on a Mac mini, connected over a private network to vLLM on an NVIDIA DGX Spark.
We removed features we had already finished
Early versions included a marketplace and a canvas. They were implemented, visible, and working.
When we reviewed the product direction, we concluded that they were distracting us from the core workflow. We removed them.
That changed one of the project’s basic questions.
Instead of asking, “Did we already build this?” we started asking, “Does this belong in the workflow people are actually trying to complete?”
The faster AI can produce code, the more important it becomes to delete code that should not exist.
Replacing the inference backend took a day. Paying the migration bill took thirteen.
The project originally grew around Ollama-specific APIs. That was useful at the beginning, but it did not fit the system we were operating across a Mac mini and a DGX Spark.
We moved to an OpenAI-compatible path centered on vLLM and LiteLLM. More than 100 call sites moved, and roughly 4,500 lines of Ollama-specific code were deleted.
The obvious migration finished quickly. The hidden assumptions did not.
Old provider names were still embedded in database constraints, model IDs, environment variables, and UI labels. Replacing an inference client was easier than making the entire system agree that the architecture had changed.
That experience forced us to clarify ownership:
- Where is a model selected?
- Who decides when a fallback is allowed?
- Does the model name shown to the user match the endpoint actually called?
- Which layer owns routing policy, and which layer only executes it?
Those boundaries became more important than adding another feature.
The tests passed. In production, the sandbox did nothing.
We once added bubblewrap isolation for external MCP servers.
The implementation looked correct, and the tests passed. Then we inspected the actual production host: macOS. Bubblewrap is Linux-only. In that environment, the isolation boundary did nothing.
The next day, we removed it and rebuilt the boundary around Docker, using non-root containers, dropped capabilities, memory limits, and network policies.
Passing tests can prove that an implementation exists. They do not prove that it achieves its purpose in the environment where it runs.
That failure changed how we validate OpenMake. Claims are checked on the hardware and deployment path we actually operate. When an assumption is wrong, we document the failure instead of rewriting it as a success story.
What OpenMake looks like now
Today, the Mac mini runs the OpenMake application, orchestration layer, and LiteLLM gateway. A private Tailscale connection reaches vLLM on the DGX Spark. External MCP processes and autonomous agent tasks run in Docker sandboxes.
Normal chat resolves one model and uses the regular chat and tool loop. Discussion mode is optional. When a question genuinely benefits from multiple perspectives, it can run bounded parallel opinions, cross-review, evidence reuse, and synthesis.
The current chat workspace with model selection, tools, and thinking controls.
OpenMake also includes autonomous agent tasks, MCP tools, deep research, artifacts, Discord integration, and NotebookLM grounding.
Agent work is recorded with progress, turns, runtime, token use, and both successful and failed outcomes.
This is not a chatbot for everyone
I do not want to describe OpenMake as a frictionless one-click chatbot.
Self-hosting currently expects Node.js 24, Docker, PostgreSQL, and an OpenAI-compatible model endpoint. It is a better fit for people already experimenting with vLLM, LiteLLM, Ollama, or home-lab AI infrastructure.
There will still be rough edges.
What the project needs now is not manufactured attention. It needs people willing to install it, run one real workflow, and report the first place where the setup or execution becomes unclear.
If you already operate local models, I would value one concrete test:
- Install OpenMake on your own hardware.
- Run one multi-step workflow.
- Tell us where you first lose confidence in what the system is doing.
If the project is worth following, star the repository so you can find it again. An issue describing a real point of friction would be even more valuable.
- GitHub: https://github.com/openmake/openmake_llm
- Project site: https://openmake.cc/en/
- Live demo: https://chat.openmake.cc/
- Self-hosting documentation: https://openmake.cc/en/docs/
Disclosure: I lead the project with AI-assisted development. This article was drafted with AI assistance from the public repository history and operating notes, then reviewed against the source and deployment facts before publication.
Top comments (0)