SeekerClaw: an on-device AI agent for Android and Solana Seeker
Turn your Solana Seeker (or any Android phone) into a 24/7 personal AI agent
At a glance
- What is it?
- SeekerClaw embeds a Node.js AI agent inside an Android app and exposes it through Telegram or Discord. It ships 64 tools, a burner wallet for capped autonomous trading, and x402 payments, all running locally on Android 14 or later.
- Who is it for?
- Adopt SeekerClaw if you have an Android 14+ phone, you already live in Telegram or Discord, and you want an always-on agent that can also transact on Solana under caps you define. Skip it if you need iOS, if you object to running a Node.js runtime on your phone, or if you are not comfortable importing a Solana key into an app.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What SeekerClaw solves, and who it is actually for
Most personal AI agents live in a terminal on a laptop or in a cloud container. SeekerClaw takes the opposite position: the agent runs on the phone in your pocket, as an Android foreground service, and you talk to it through Telegram or Discord rather than a local UI. The repository describes it as a Node.js AI agent embedded inside an Android app, running 24/7, built for the Solana Seeker but functional on any Android 14+ device.
The audience is narrow and specific. It is for people who already carry an Android phone, want an agent that keeps working when the laptop is closed, and are willing to import a Solana key so the agent can act economically. The v2 line added a burner wallet and an x402 payment client; v2.1 extends that into what the README calls a full autonomous trading wallet. If you only want a chat wrapper around a hosted model API, the wallet machinery is dead weight you will still have to configure or ignore.
Architecture: Kotlin shell, Node.js agent, two wallets
The split is visible from the repository layout and the README. The app/ directory holds a Kotlin and Jetpack Compose Android application. Inside it, a Node.js 18 runtime executes the agent logic. The Android layer supplies the foreground service, the settings UI, and the Keystore-backed encryption; the Node layer supplies the tool loop, the provider clients, and the skill loader.
The tool surface is large: 64 built-in tools plus remote tools over MCP using Streamable HTTP. On top of tools sit 22 bundled skills and 35+ partner skills, with SKILL-FORMAT.md at the repository root documenting the skill format. Model access is multi-provider: Claude, OpenAI (API key or Codex OAuth), OpenRouter, or any OpenAI-compatible gateway under a Custom option. Extended thinking, when the selected model supports it, is preserved across tool calls and across /resume, and the README states this holds on all four provider paths.
The wallet design is the part worth reading twice. There are two wallets. The main wallet goes through Jupiter and MWA, and you sign every action. The burner wallet is a key you import once, stored by the app and encrypted under Android Keystore with AES-256-GCM. The agent signs silently while a transaction stays under your per-transaction and daily caps; above the cap it falls back to a main-wallet popup. Trading covers swaps, converting held balances back to USDC or SOL (including fee-free Token-2022 assets such as PYUSD), SPL transfers, and limit or DCA orders. Payments go through x402 v1 and v2, with GET requests silent under cap and POST settlement always confirmed, across 44 catalogued endpoints in 10 services. The README calls the paid catalog opt-in: it activates only when you explicitly ask to pay.
Installing SeekerClaw and running a first agent turn
The README points at two distribution channels rather than a build-from-source path: Google Play under the package id com.seekerclaw.app, and an APK from the GitHub releases page. The repository also contains a Gradle wrapper (gradlew, settings.gradle.kts, build.gradle.kts), so a source build is possible, but the README does not walk through it.
Once the app is installed and opened, the first real task is connecting a model provider. The README describes provider selection under Settings, with Claude, OpenAI, OpenRouter, and a Custom OpenAI-compatible gateway as the options.
# No shell install is documented. Get the app from Google Play
# (package id com.seekerclaw.app) or the APK on the releases page.After a provider is configured, the agent is driven from chat. The README gives /think as the chat-side toggle for extended thinking, and /resume as the command that continues a session with reasoning preserved.
/think
/resumeThe wallet path is a separate setup step and should be treated as one. You import a Solana key once, then set per-transaction and daily caps in Settings. Until you do that, the agent has no spending authority. The README does not document a rollback procedure for a burner key that has already been imported, so decide what you are willing to fund before you paste anything in.
Where SeekerClaw stops being the right tool
The clearest limitation is stated by the project itself: Android 14 or later. There is no iOS path, and the README does not suggest one is planned. If your phone is older, or you use an iPhone, the project simply does not apply to you.
The second limitation is structural. Running Node.js 18 on a phone inside a foreground service means battery, memory, and thermal behavior are phone-dependent in a way a server deployment is not. The README makes no battery or resource claims, and none should be assumed. A foreground service also produces a persistent notification, which is the price of the always-on design.
The third is the wallet. Autonomy is capped, not eliminated. The README states that transactions above your cap trigger a main-wallet popup, which means the agent stalls until you respond. That is a safety property, but it is also a failure mode for unattended operation: a trade that exceeds the cap at 3 a.m. will not execute. And the x402 catalog, while described as opt-in, is large enough (44 endpoints, 10 services including market data, travel, SMS, and captcha) that the practical question is not whether payments can happen but whether your caps and your intent stay aligned over time.
How SeekerClaw differs from a server-side agent stack
The obvious alternative is a conventional agent deployment: a cloud VM or container running the same kind of Node.js tool loop, reached over SSH or a web UI. Frameworks in that space give you far more compute, no battery ceiling, and a deployment story built on Docker and CI rather than an APK.
The difference in approach is where the keys and the data live. A server-side agent holds your API credentials and, if it trades, your wallet keys on infrastructure you rent. SeekerClaw keeps the agent on hardware you physically control, stores the burner key under Android Keystore, and leaves the main wallet under MWA signing so a human approves each action. That is a meaningfully different trust model, and it is the reason to pick SeekerClaw even though the server route is easier to operate.
The trade is real in both directions. The server stack wins on uptime, debugging, and the ability to run heavier models or longer tool loops. SeekerClaw wins on custody and on the fact that the agent is reachable from Telegram or Discord without exposing an endpoint to the internet. If your threat model does not care about key custody, the on-device design buys you little.
Maintenance, releases, and what the MIT licence covers
The repository is not archived, and the last push was on 2026-09-10. The release cadence is visible in the tags: v2.3.1 on 2026-09-10, a v2.3.1-rc1 candidate the same morning, and v2.3.0 on 2026-09-08. That is a fast, recent cadence, and the presence of release candidates suggests changes are staged rather than pushed straight to stable.
Upgrade cost is mostly on the app side. Because distribution runs through Google Play and the releases page, upgrading means installing a new APK rather than pulling a branch. The README does not describe a migration path for settings or for an imported burner key between versions, so that is something to confirm against CHANGELOG.md before upgrading a device that is actively trading.
The licence is MIT, which permits commercial use, modification, and redistribution with the copyright notice and permission notice retained. The repository also carries a NOTICES file, which typically holds third-party attributions; read it if you plan to redistribute. Nothing here is legal advice, and the bundled skills and partner integrations may carry their own terms that the MIT licence on the main repository does not cover.
What the README leaves undocumented
Several things a cautious adopter would want are absent. There is no documented rollback for an imported burner key. There is no stated resource envelope for the Node.js runtime on-device, so battery and thermal expectations are unknown. The source build path exists in the repository (Gradle wrapper, build.gradle.kts, settings.gradle.kts) but the README does not describe it, which means anyone building from source is working from the files rather than from instructions.
The extended-thinking support list is also worth reading carefully. The README names specific models (Fable 5, Opus 4.8 / 4.7 / 4.6, Sonnet 4.6, GPT-5.6 Sol / Terra / Luna, GPT-5.5 / 5.4 / 5.4 Mini) rather than describing a capability check, so behavior on models outside that list is not specified. If you plan to route through a Custom OpenAI-compatible gateway, assume reasoning preservation is unverified until you test it yourself.
Editorial conclusion
Adopt SeekerClaw if you have an Android 14+ phone, you already live in Telegram or Discord, and you want an always-on agent that can also transact on Solana under caps you define. Skip it if you need iOS, if you object to running a Node.js runtime on your phone, or if you are not comfortable importing a Solana key into an app. Before trusting it with funds, verify three things yourself: that the burner key is actually stored under Android Keystore as the README claims, that the per-transaction and daily caps behave as documented when a trade exceeds them, and that the x402 catalog is opt-in in practice rather than on by default.
Frequently asked questions
Does SeekerClaw require a Solana Seeker phone?
No. The README states it was built for the Solana Seeker but runs on any Android 14+ phone. The Seeker is the target device, not a requirement.
Can SeekerClaw trade Solana tokens without asking me each time?
Yes, within limits you set. The burner wallet signs silently while a transaction stays under your per-transaction and daily caps, and falls back to a main-wallet popup when it does not.
How do I install SeekerClaw?
The README points to Google Play under the package id com.seekerclaw.app, or to an APK on the GitHub releases page. No shell-based install is documented.
Which AI providers does SeekerClaw support?
Claude, OpenAI via API key or Codex OAuth, OpenRouter, and any OpenAI-compatible gateway through the Custom option. Extended thinking is preserved across tool calls on all four paths according to the README.
How does SeekerClaw protect the burner wallet key?
The README states the burner key is encrypted under Android Keystore using AES-256-GCM. The main wallet is separate and stays user-controlled through MWA signing.
Community notes