WakeHermesClaw: an Android voice client for OpenClaw and Hermes Agent

The problem WakeHermesClaw solves for self-hosters

A self-hosted assistant usually stops at the chat box. You get a model behind an HTTP endpoint, and everything else (waking the phone, reading a notification, opening an app) stays manual. WakeHermesClaw is the Android half of that setup. It is a native Kotlin client that connects to a server you operate, either an OpenClaw Gateway over WebSocket or an OpenClaw HTTP endpoint that speaks the OpenAI-compatible chat format.

The audience is narrow and specific: people who already run OpenClaw or Hermes Agent on their own machine and want a phone client that behaves like a system assistant. The README frames it as something that should "feel like a real assistant on your phone instead of a thin chat wrapper", and the feature list backs that up: long-press Home activation, a Voice Overlay, continuous conversation, and device actions covering notifications, camera, contacts, calendar, apps, clipboard and WiFi.

The second backend is the reason this repository exists as a separate project. WakeHermesClaw is described as the successor to OpenClaw Assistant, and it adds Hermes Agent as a peer backend that can be configured side by side with OpenClaw. If you only ever ran OpenClaw, the migration path is in place: existing installs upgrade in place because the applicationId is unchanged, and the first launch moves the old Gateway and HTTP settings into a multi-backend repository, marking the existing setup as Primary.

How the backend model and pairing actually work

The architecture is a client with a pluggable backend layer. You configure any combination of three backend types and pick one as Primary: OpenClaw Gateway over WebSocket, OpenClaw HTTP, or a Hermes API Server. Hermes speaks two surfaces, `/v1/chat/completions` for streaming and `/v1/runs` for its Runs API. Authentication is a bearer token, sent as `Authorization: Bearer <key>`.

The app accepts a Hermes URL with or without the version suffix, so both `http://host:8642` and `http://host:8642/v1` are valid. The connection test calls `GET /v1/models` and falls back to `/health` if that fails. The default model name is `hermes-agent`. Those details matter when you are debugging a failed setup, because a server that answers `/health` but not `/v1/models` will still pass the test.

There is a second, optional layer called the Mobile Bridge, off by default. It exposes a bearer-token-protected local HTTP service that lets Hermes reach a curated set of Android capabilities. The shared agent controls listed in the README include 6-character bridge pairing codes, deep-link setup payloads, multi-endpoint candidates raced in parallel on connect, and per-capability TTL grants with three options: 10 minutes, 1 hour, or until revoked. There is a destructive-verb override, plus `/revoke` and `/grants` endpoints. An Accessibility Bridge covers tap, swipe, Home, Back and window describe, and it is sideload-only. Notifications are exposed through `notifications.active.list`, backed by the existing NotificationListenerService. A build flag named `IS_SIDELOAD` gates Accessibility and SMS so a Play-track build can exclude them.

That split is the most interesting design decision in the project. The capabilities that would make an app like this genuinely useful to an agent are also the ones that would complicate a store listing, and the build flag is the seam between the two.

Installing WakeHermesClaw and pairing a first backend

The README points to the Releases page for the latest APK, so the fastest path is downloading it rather than building. If you prefer to build from source, the documented command is a single Gradle invocation that runs unit tests and assembles the debug variant.

./gradlew testDebugUnitTest assembleDebug

You need the server before the app is useful. For a Hermes backend, the README's 30-second setup is to run `hermes gateway` with the API server enabled on its default port, bind it to your LAN or VPN, and generate an API key.

hermes gateway

Then open Settings, go to Backends, and choose Add Hermes API Server. Enter your host and the key. The app will accept either form of the URL.

http://host:8642
http://host:8642/v1

If you are using OpenClaw instead, the legacy quick start is five steps: install the APK, run `openclaw qr` on your server, tap Scan QR Code in the app, approve the device on the server if pairing is requested, then long press Home or say your wake word.

openclaw qr

After either route, the thing to check is the connection test. It hits `GET /v1/models` and falls back to `/health`, so a successful test tells you the endpoint is reachable and the bearer token is accepted, not that streaming works. Send one real message before you trust the setup.

Where WakeHermesClaw falls short

The watch story is incomplete, and the README says so. Wear OS uses its own per-watch backend URL and auth token, and the phone's Primary backend is not automatically synced to the watch yet. You configure the watch separately, pointing it at the same Hermes or OpenClaw endpoint you use on the phone. If you expect a single setup to cover both devices, this is not that.

The Accessibility Bridge is sideload-only, and the `IS_SIDELOAD` build flag gates Accessibility and SMS for a Play-track build. That means the feature set depends on which artifact you install. A user who grabs a Play-track build will not have the same capabilities as one who sideloads, and the README does not spell out how to tell which build you have before you install it.

The server dependency is absolute. There is no hosted fallback and the homepage field is empty, so the README's Releases page is the distribution channel. If you do not want to run OpenClaw or Hermes yourself, this app has nothing to talk to. That is a deliberate choice, not a gap, but it rules out anyone looking for a turnkey assistant.

Finally, the README does not document rollback. It describes the in-place upgrade and the silent migration of Gateway and HTTP settings into the new multi-backend repository, but it does not say what happens if you want to return to the previous OpenClaw Assistant release or how the migrated settings behave if you do.

How this differs from running OpenClaw through a generic chat client

The obvious alternative is pointing any OpenAI-compatible chat app at your OpenClaw HTTP endpoint. That works, and it costs you nothing to try. The difference is everything around the conversation. A generic client has no wake word, no Voice Overlay, no long-press Home activation, and no device actions. It cannot read your notifications or open an app on your behalf.

WakeHermesClaw's offline wake word detection runs locally through Vosk, so always-on listening does not require a network round trip. The README also states that sensitive settings such as server URLs and tokens are stored with AES256-GCM encryption, and that powerful capabilities are opt-in and guarded by Android permissions or explicit user actions. A chat client has no equivalent surface to secure because it has no device capabilities to grant.

The trade-off runs the other way too. A generic client is one install and a URL. WakeHermesClaw is an APK plus a server plus per-capability grants, and the Mobile Bridge adds a local HTTP service that is off by default for a reason. If your use case is text conversations with your own model, the chat client is less machinery for the same result.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-29. The most recent release listed is v2.4.9.1 from 2026-04-28, with v2.4.9 on 2026-04-21 and v2.4.8 on 2026-04-05. The gap between the last release and the last push suggests development activity that has not yet been cut into a tagged release, which is worth knowing if you pin to release artifacts rather than building from main.

The licence is MIT, and the repository carries a LICENSE file plus a THIRD_PARTY_LICENSES.md. MIT is permissive, so the practical implication is that you can build, modify and redistribute the app, but you still need to satisfy the terms of the bundled dependencies. Vosk is named in the README as the wake word engine, and its own licence is separate from this project's. The THIRD_PARTY_LICENSES.md file is the place to check what you are actually shipping if you redistribute a build.

Upgrade cost is mostly handled by the migration described in the README: the applicationId is unchanged, so existing installs upgrade in place and the first launch migrates settings silently. The cost you should budget for is the watch, which is configured separately and is not synced from the phone. Every backend change on the phone is a second configuration step on the watch.

Editorial conclusion

Adopt WakeHermesClaw if you already run an OpenClaw gateway or a Hermes API server on your own hardware and want a phone client with on-device wake word detection and real device actions. Skip it if you want a hosted assistant with no server to operate, or if you need the phone's Primary backend to appear on your watch automatically. Before installing, verify that the release APK's signing key matches your existing OpenClaw Assistant install, confirm whether the build you have is the Play-track or sideload variant, and check that your Hermes server answers GET /v1/models on port 8642.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yuga-hashimoto/openclaw-assistant on GitHub