Open WebUI vs Hermes: Face vs Brain on One Stack
Or: people will tool out the interface. The middleware is the thing that has to stay useful.
Source: ~/Downloads/GoogleSearchAI-So_does_OpenWeb_UI._End_of_day_people_gonna_tool_out_what_they_like_to_use._Obsidian_x_6m_Reply_6_Eh,_OpenWebUi_is_more_of_an_interface,_hermes_is_more_on_the_middleware_side._-_Google_Search.md
Phase: final
Links: Index - OpenWebUI Interface vs Hermes Middleware Stack · Trajectory - Inner Map
Pipeline: CONSTITUTION - Publishable Asset Pipeline · 00 - Master Index
Status: draft
Mode: Experiential
How this one actually started
I did not walk in looking for a brand war between chat apps.
I walked in with a half-finished sentence that already sounded like architecture:
Open WebUI is more of an interface. Hermes is more on the middleware side. End of day, people are going to tool out what they like to use.
That is the whole article if you stop early. Face is swappable. Brain is not.
What I actually needed was placement. Hermes was already on a private VPS next to Nextcloud. Telegram was the face. Telegram is fine for quick pokes. It is a thin window when you want history, files, structured work, and a surface that does not feel like you are yelling into a messenger bot. Primary device is a phone. So the real question was not “which product wins.” It was:
Where does a richer face sit on infrastructure I already own, without ripping Telegram out, and can I drive the same brain from Android?
What follows is the usable stack map from that path: face vs brain, coexistence, mobile path, cost of voice, engines and add-ons, browser leverage, then the part that almost got lost under install chatter - how a systems thinker has to see the agent loop or they underuse the whole machine.
1. Face and brain, not two competing chatbots
The clean split:
| Layer | Job | Examples |
|---|---|---|
| Face | Session UI, history, uploads, visual workspace, mobile chrome | Open WebUI, Telegram, Discord, Conduit as a client |
| Brain / middleware | Agentic loop, memory, tools, terminal, browser, long-running work | Hermes on the VPS |
| File plane | Documents and shared storage | Nextcloud (or similar) on the same machine family |
| Access plane | How a phone or laptop reaches the face securely | HTTPS reverse proxy, Tailscale / WireGuard |
Hermes (the brains): autonomous agentic loop, persistent memory, tool execution. It can expose an OpenAI-compatible API.
Open WebUI (the face): connects to that API the way it would connect to OpenAI or Ollama. Chat surface, file uploads, multi-user polish, visual workspace.
Execution flow
- You type (or speak) in the face.
- The face sends a
POST /v1/chat/completionsstyle request to Hermes. - Hermes decides tools, runs them in the background.
- Progress and final answer stream back into the face.
You keep the extensible agent. You get a UI that is not a messenger box.
Official docs live under Hermes messaging for Open WebUI and Open WebUI’s own “connect an agent” guides. The mental model matters more than the docs link: the face is a client. The agent is the server of work.
2. Where Open WebUI fits when the stack already exists
I had no prior Open WebUI install. I did have domain, VPS, Nextcloud, Hermes, and Telegram. The anxiety was: do I rebuild, or do I add a room.
Answer that held: Open WebUI is another face on the same brain. Telegram does not have to leave.
On the same VPS family:
- Enable Hermes API (community docs often show something like a local API port Hermes already documents).
- Deploy Open WebUI (commonly Docker). Point it at Hermes as a model/provider.
- Reverse proxy a subdomain to Open WebUI’s port.
- Keep Telegram for low-bandwidth, on-the-go pokes. Use Open WebUI for deep sessions, memory-heavy work, files, structured reports.
Nextcloud stays the file plane. Open WebUI stays the AI interaction plane. They can cohabit without one pretending to be the other.
Constraint that is easy to skip: Telegram reaches your bot through Telegram’s cloud. A self-hosted face is a direct phone-to-your-box path. That means HTTPS in front of the UI, or a private mesh (Tailscale / WireGuard) if you refuse public exposure. Raw HTTP over the open internet is not a face. It is a liability.
3. Mobile is not a nice-to-have
If the primary device is a phone, “desktop Open WebUI exists” is incomplete.
Option A: Progressive Web App
Open WebUI behaves as a PWA.
- Open the self-hosted URL in Chrome (Android) or Safari (iOS).
- Add to Home Screen / Install app.
- Launch full-screen without living inside browser chrome all day.
Good enough for many people. Variable on streaming stability and cookie auth depending on browser habits.
Option B: Conduit (native client)
Community-native mobile client aimed at Open WebUI instances. Flutter, WebSocket streaming, file attachments, share-sheet into a prompt, voice call mode. Android distribution is free on Play (open source). iOS has been a small one-time purchase in community reports, mainly to cover store fees. Not an official Open WebUI product: feature lag and occasional VPN / WebSocket edge cases are real trade-offs.
Android verdict from the path
For daily phone use, Conduit often wins on feel: keystore logins, streaming reliability, native voice mode. PWA wins if you want zero third-party client and the newest server features the day they land. Keep PWA as fallback. Treat Conduit as the pocket face if you live on Android.
4. Voice, streaming, and what actually costs money
The fear was simple: does Conduit or “voice call mode” burn extra LLM tokens?
LLM tokens: speech becomes text before the model. Same prompt text costs roughly the same whether you typed it or said it.
Separate bill / load:
| Feature | Extra LLM tokens? | Real cost surface |
|---|---|---|
| Text chat | Base usage | Model price |
| Voice STT / TTS | Not for the LLM itself | Browser-local engines (often free-ish) vs paid STT/TTS APIs |
| WebSocket streaming | No | CPU / network on phone and VPS; batching can smooth load |
| Follow-up suggestion chrome | Can yes | Extra hidden completions some UIs fire for “suggested questions” |
Voice mode exists on Open WebUI itself when TTS is configured, not only inside Conduit. Hands-free loop: talk, hear answer, mic re-arms. Budget the audio pipeline, not a mythical “voice token tax” on the model.
If you care about bills, watch for chat chrome that invents extra prompts in the background. That is a UI habit, not Hermes being greedy.
5. Engines and add-ons around the brain
Once the face is clear, the next blind spot is the engine room. Community patterns around Hermes usually split into:
Model providers
- OpenRouter: one key, many models, low lock-in. Often the power-user default.
- Provider-direct keys: OpenAI / Anthropic / others when you want one vendor and lower hop latency.
- Local via Ollama / similar: when the machine has RAM/VRAM and you want spend control.
- Bundled / subscription access (e.g. OpenCode Go style offerings): sensible if the model mix and price fit your week. Not mandatory. Compare against OpenRouter before marrying one checkout page.
Surfaces and extensions people actually bolt on
- Hermes WebUI (lighter browser face, CLI-adjacent).
- Conduit (mobile client, already covered).
- Obsidian / vault context bridges.
- Firecrawl-style clean scrape backends (less raw HTML tax).
- Skill / plugin packs for recurring jobs.
- Workspace integrations (mail, sheets, chat platforms) depending on what you wire.
The point for this article is not a full app store. It is: you almost missed that faces and engines are separate catalogs. Missing Open WebUI once is a hint to inventory both catalogs before you freeze a setup.
6. Browser work for research, not engineering theater
My use case in the thread was content marketing shaped: visit sites, gather, compare, structure. Not “prove I can reverse shells.”
What the brain can do when browser tools are healthy:
- Multi-step navigation, scroll, extract, summarize.
- Reddit / board style scans (top posts, themes) into structured notes or sheets.
- Authenticated sessions when you deliberately give it cookies / connected browser state (still your risk domain).
- Draft outreach after research, preferably with a human approve step.
What I preferred over “bot applies on job portals for me”:
- Scrape company + role context from public postings.
- Build a clean contact path to people who actually decide (HR / hiring managers), via legitimate enrichment tools you choose.
- Personalized mail instead of joining a pile of portal applicants.
That is not magic. It is a pipeline: observe → extract → verify → draft → human send. Safer operationally than fighting anti-bot on every apply form, and closer to how high-signal outreach works anyway. Use cron-style recurrence if Hermes supports scheduled runs in your install. Keep approval in the loop if reputation matters.
Firecrawl-class backends help when you want clean text for agents instead of HTML sludge. Stealth browser backends exist for hard sites; treat them as power tools with ethics and ToS attached, not default toys.
7. Why linear commands feel like wasting the agent
This is the non-install peak of the thread.
If you are a systems thinker, “find me ten emails” is the wrong shape of ask. It hides the machine. You want a protocol, not a one-liner.
Model A: recursive feedback engine
Hermes on a VPS is closer to a loop than a chatbot:
- Planner breaks a rich objective into subgoals.
- Tools are hands (browser, mail, sheets, shell).
- Memory (
USER.md/MEMORY.mdstyle persistence) is taste over time. - Environment is the live web, not a frozen training blob.
Leverage sits in parallelism, persistence, and synthesis across sources you never listed step by step.
Model B: automated greenhouse (simpler elements)
- Sensors: scan postings, feeds, competitor pages.
- Soil: memory of what you called good or bad.
- Irrigation: tools that fetch, draft, file.
- Feedback: withered leads and your corrections reshape next scouting.
Skills become recipes. Successful multi-step work can be re-triggered instead of re-explained.
Model C: observe → reason → plan → act → refine
Until the objective is done, the agent should not “stop at one reply” the way a pure chat model does. If login fails or the email is a generic inbox, it re-plans. That observe stage is the leverage point people skip when they only send linear scraps.
Protocol shape instead of order shape
Linear user:
Find me 10 marketing jobs and HR emails.
Systems protocol:
Objective: high-conversion direct outreach pipeline.
Scope: roles posted in last 24 hours matching X.
Filter: company size / stage constraints you actually want.
Intelligence: brand voice from About / recent launch.
Action: draft personalized first lines in the face UI.
Feedback: sheet or CRM with status and your corrections back into memory.
Same agent. Different aim. The second one uses the face for review and the brain for the loop.
8. What I locked for myself
- Hermes stays the brain. Memory, tools, long jobs live there.
- Open WebUI is an optional rich face, not a second brain.
- Telegram can stay. Different bandwidth, same agent.
- Mobile path is first-class: HTTPS or mesh, then Conduit and/or PWA.
- Budget audio and UI chrome separately from model tokens.
- Inventory engines and add-ons once, so the next Open-WebUI-sized blind spot is smaller.
- Aim with protocols and diagrams, or a systems brain will use a recursive agent like a slightly smarter search box.
Faces will keep multiplying. People will tool out what they like. That is fine. The middleware has to remain the place where work compounds.
Provenance
- Index: Index - OpenWebUI Interface vs Hermes Middleware Stack
- Trajectory: Trajectory - Inner Map
- Constitution: CONSTITUTION - Publishable Asset Pipeline
- Master: 00 - Master Index
Related cluster (cross-link later, do not triple-cover): Index - WebUI and AI Agents, Index - User Interfaces UI, Index - Excalidraw Self-Host and VPS Open Source Stack.