SeekerClaw

MIT-licensed Android app by sepivip that runs an LLM agent on the phone itself, 24/7, as a foreground service — and lets it spend money. 299 stars, 71 forks, Android 14+, built for the Solana Seeker and running on any recent Android device. You talk to it through Telegram or Discord; there is no app-side chat as the primary surface.

T1 for what it is — architecture, module inventory, tool and skill counts, licence, platform, key handling and the cap policy are all the project's own facts, read from its README and checkable against the repository. Its performance claims are a different grade and are attributed below rather than asserted: "winner of the Solana Mobile Hackathon (April 2026)" and "the first on-device agent that can transact on the open web" are the maker speaking.

The shape, and why it is not the shape this spoke had

mobile-device-agent describes the corner as it stood: a device-side helper exposing control, and an operator-side runtime holding the loop, the model and the tools. SeekerClaw inverts the half that mattered. The loop runs on the phone — a nodejs-mobile runtime (~24k lines of JavaScript, 50+ modules) inside an Android app (~27k lines of Kotlin/Compose, 68 files), as a foreground service with a heartbeat and a cron timer.

What has not changed is the part that made those frameworks model-agnostic: no model runs locally. It calls Claude, OpenAI, OpenRouter or any OpenAI-compatible gateway over the network. So the split this spoke had been drawing between "device" and "brain" was really two splits, and only one of them is load-bearing — the model is remote, the harness need not be. Put the runtime on the device and you get a resident agent instead of a session someone starts from a laptop.

The phone is also not the target here. Device control (battery, GPS, camera, SMS, calls, clipboard, TTS) is one module of thirteen and 64 tools; the rest is an ordinary agent harness — memory with ranked keyword search, skills, MCP, web search and fetch with caching, cron with natural-language parsing, session summaries. mobilerun drives a phone. This one lives on one.

The guardrail is a spend cap, and that is the interesting part

agent-guardrails organizes bounds by reversibility: grant freely where a mistake is cheap to undo, gate where it is not. A Solana swap is the hard case — irreversible by construction, no git diff to review, exactly the gap mobile-device-agent recorded as open. SeekerClaw's answer is not "confirm every time." It is to bound the loss and let the agent act inside the bound:

Two wallets, two policies. A main wallet (Phantom or any MWA) where every action raises a signing popup, and a burner — an Ed25519 key the user imports, never generated by the app — that the agent signs with silently.
Caps in currency, checked before the transaction. Per-transaction and daily limits in USDC and SOL, enforced by a caps/preflight.js check ahead of any send. Under cap, the burner signs and nobody is asked. Over cap, or with no burner configured, it falls back to the main-wallet popup. Swaps, held-token conversions, SPL transfers and Jupiter limit/DCA orders all route through the same dispatch.
An asymmetry by HTTP verb, not by amount. For x402 payments to paid APIs, GET settles silently under cap and POST always asks, regardless of caps — reads are bounded by money, writes are bounded by consent.

This is the corpus's second instance of a budget guardrail after gemini-managed-agents-hooks's max_total_tokens, and the sharper one, because the currency is real and the action cannot be rolled back. It is worth stating what the design concedes: it does not make the action reversible, it makes the maximum loss a number the user chose. The README says so plainly — "only fund the burner with what you'd be okay losing if the agent makes a poor call."

Key handling, stated

The imported seed lives at filesDir/burner_keys/<id> encrypted with a Keystore-derived AES-256-GCM key, and signing happens inside the Kotlin vault: the Node process sends a transaction blob and receives a signature, never the raw key. The loopback bridge between the two processes requires a per-boot auth token, android:allowBackup=false keeps the keys out of cloud backups, and agent_pay resolves DNS before any request and refuses private-range addresses (SSRF and DNS-rebinding defence). Wiping the keys reverts the app to single-wallet mode.

Unaudited here. These are the project's stated measures, and one contributor is credited for a security audit; no external report is linked.

Smaller things this spoke should keep

Skills are Markdown with YAML frontmatter, with a published SKILL-FORMAT.md — another independent implementation of the agent-skills shape, and one that ships 22 bundled plus 35+ partner skills through a marketplace installed by sending the agent a link in chat.
MCP over Streamable HTTP, with what the module list calls rug-pull detection — a client watching for a server that changes its tool definitions after approval. That is the model-context-protocol trust problem named in an implementation.
A loop detector: identical-call detection that warns at 3 and breaks at 5. Cheap, and the kind of thing agent-evals never measures because it is a failure mode rather than a score.
Reasoning handling as its own subsystem — per-provider echo policy, an adaptive three-step quarantine on 400 reasoning_content errors, and sha256 fingerprint-only logging of reasoning content. Keeping extended thinking alive across tool calls on four providers is evidently not a flag you set.
Graceful Stop: a bounded flush handshake so pending session summaries and dirty writes persist before the Node process exits, preserving roughly the last minute of activity — a durability concern surfacing in a phone app.

Reflexive note

This hub runs an LLM agent on an Android device, curated over Telegram. SeekerClaw is the same deployment shape built as a product, with a wallet attached, which makes it the closest thing in this corpus to a mirror of the thing reading it.

mobile-device-agent · mobilerun · agent-guardrails · agent-skills · model-context-protocol · gemini-managed-agents-hooks · durable-agents · agent-evals · agentic-tooling · sepivip · x402 · synthesis