SeekerClaw, where a wallet cap reroutes a trade instead of blocking it

Caps do not block a trade, they change which wallet signs it

Per-transaction and daily caps are set in Settings, denominated in USDC and SOL, and the README is blunt about the ceiling: the agent cannot exceed them.

What happens past that ceiling is the part worth reading twice. A trade inside the cap routes through the burner wallet and is signed silently. A trade over the cap, or any trade made when no burner is configured, routes instead to the main wallet, which raises a wallet popup and waits for you. So a cap does not stop an action. It moves the action from a key the agent holds to a key you hold. The promise is a bound on unattended signing, not a bound on spending.

Five tool names carry that routing decision: solana_swap, solana_send, solana_send_token, jupiter_trigger_create, and jupiter_dca_create. Limit orders and DCA orders are in the list, which means a recurring order can fill unattended inside the cap without asking you at fill time.

A GET payment settles silently and a POST payment always asks

Paid API access runs through x402, and the settlement rule is split by HTTP method in a way that is easy to read past.

A GET settles silently while you are under cap. A POST is always confirmed, no matter where the cap sits. The reasoning is not spelled out, but the verb shapes suggest it: a GET is a lookup, and a lookup that costs money is still a read, while a POST changes something, so the app treats every one of them as something a human should see. Defensible line, and it does mean a paid read can slip through while a paid write never can.

Behind that sit 44 catalogued endpoints across 10 named services: Stablecrypto Market Data, Tripadvisor, Rentcast, Perplexity, WolframAlpha, Reducto, CrushRewards, 2Captcha, Textbelt SMS, and Purch. Both x402 v1 and v2 are handled end to end, including POST settlement. The catalog is opt-in and only activates when you explicitly ask to pay.

The headline still says v2.1 while the newest tag is v2.3.1

The version story in the README lags the release list by two minor versions.

The narrative says v2 introduced the burner wallet and the x402 payment client, and that v2.1 expands it into a full autonomous trading wallet. The recent releases are v2.3.0 on 8 September 2026, then v2.3.1-rc1 and v2.3.1, both on 10 September 2026. The last push to main is 24 September 2026, and the repository is not archived. Nothing in the prose tells a reader what changed between v2.1 and v2.3.1, which means the version number in the README is a history entry rather than a description of the build you are installing. A CHANGELOG.md sits at the repository root and the README never links to it.

The release window is also compressed. The release candidate for v2.3.1 is timestamped 08:51 UTC on the 10th and the final 08:57 UTC the same morning, six minutes apart. That is fine for a small patch and worth a second look for anything larger.

The 26 week heatmap covers half of the 13 months the app keeps

Activity reporting uses two different spans and does not reconcile them.

The System screen draws a 26 week heatmap of API requests, so you can see which days the agent was busy and spot the quiet ones. Behind that, the app persists up to 13 months of daily history on the device. Twenty-six weeks is 182 days, so the stored history is roughly twice what the heatmap draws, and the README does not say whether the older half is reachable through another screen, exportable, or just kept.

The memory feature sits next to it and stores more: a persistent personality, daily notes, ranked keyword search, and session summaries that survive a user-initiated stop. All of that is local, on a phone you carry. Keeping a wallet key and a year of notes in the same sandbox is defensible for an on-device agent, and it makes your own backups load-bearing in a way the README does not discuss.

A clean stop preserves about sixty seconds, and an unclean one nothing

Tapping Stop Agent does not kill the Node.js process on the spot. It starts what the README calls a bounded flush handshake, and pending session summaries plus dirty SQL.js writes are persisted before the process exits.

Bounded is the operative word, and the claim attached to it is that roughly the last 60 seconds of activity survives a clean stop. The contrast with an unclean stop is doing real work here. Android reclaiming memory, a battery event, or an out-of-memory kill give the handshake no chance to run at all, and the README does not describe any recovery pass for the case where it never starts.

SQL.js is the part that explains the design. The agent keeps its memory in a JavaScript database running in process, so state has to be written back to disk before exit. A flush handshake exists precisely because that database is easy to lose. It is a good answer to a real problem, and it is bounded rather than durable by choice.

A JavaScript agent built by Gradle and reached through two links

The repository is listed as JavaScript and the build is Gradle with a Kotlin DSL. At the root sit build.gradle.kts, settings.gradle.kts, gradle.properties, the gradle directory, gradlew, and gradlew.bat. The agent itself is a Node.js process that the README calls the :node service, and the Live Settings entry says configuration changes are written to cross-process JSON stores read by both the UI process and that service. Two runtimes, one app, a file-based seam between them.

Installation is two hyperlinks and no command. One points at a Play Store listing with the package id com.seekerclaw.app, the other at the repository's latest release. There is no adb line, no sideload step, and no install script anywhere in the README, which leaves building from source as the path with zero written instructions.

The root listing does show the project's shape: an app directory, design, docs, scripts, and tests, alongside CLAUDE.md, PROJECT.md, SKILL-FORMAT.md, NOTICES, and a .coderabbit.yaml. The CodeRabbit config matches the badge row in the header.

22 bundled skills and 64 tools, with the tool names missing

The headline counts 22 bundled skills plus 35 or more partner skills. The feature table repeats the same two numbers under Extensible and adds the two other routes in: custom skills and MCP remote tools. Those counts agree with each other.

The tool count gets no such treatment. 64 built-in tools is stated once and never broken down. No table maps a tool name to a purpose anywhere in the README. The only tools a reader can inspect by name are the five Solana ones that carry wallet routing, so the other 59 are a number rather than a surface. SKILL-FORMAT.md at the root implies there is a documented format for authoring a skill, so the enumeration is likely filed somewhere the README does not point to.

The device control row is similarly compressed. Battery, GPS, camera, SMS, calls, clipboard, and TTS is the whole list, with no permissions breakdown and no indication of which of those run silently on a background service.

Editorial conclusion

SeekerClaw suits someone who already runs an Android phone as a personal agent and accepts a wallet key living on that phone, and who wants an assistant that can pay for an API or place a limit order without a confirmation dialog. Check four things before importing a key: whether you can restore the main wallet without the burner, whether the Android version on your phone is 14 or newer, whether the Telegram bot token handling is something you are willing to own, and whether a cap in USDC and SOL is a limit you actually want an agent to spend unattended. Treat the README as a feature list rather than a safety manual; it explains what each control does and leaves the failure modes to you.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sepivip/SeekerClaw on GitHub