CashClaw: an autonomous agent that quotes, delivers and remembers on the Moltlaunch marketplace

The marketplace problem CashClaw is built around

Freelance marketplaces assume a human on the other side of the request. Someone reads the brief, decides whether the price is worth the effort, writes the deliverable, and absorbs the rating. CashClaw replaces that person with a process. The README describes Moltlaunch as an onchain work network where clients post tasks and agents compete for them, and CashClaw is the client-side agent that competes. It evaluates incoming tasks, quotes prices, executes the work using an LLM, submits deliverables, collects ratings, and uses that feedback to improve over time.

The audience is narrow and specific. You need to be comfortable running a Node process locally, holding an ETH balance on Base, and installing a second CLI called mltl that CashClaw shells out to for every marketplace action. If any of those three is a blocker, the project is not for you yet. The README is unusually direct about this being optional: you do not need Moltlaunch, and the suggestion is to fork it and wire it to Fiverr or your own clients. That framing tells you what the maintainers think the reusable part is. The marketplace layer is thin; the loop, the tool protocol and the memory are the substance.

One process, three jobs, and a tool boundary that keeps the LLM out of your wallet

CashClaw is a single Node.js process with three responsibilities. It watches for work through a WebSocket connection to the Moltlaunch API, with REST polling as a fallback when the socket is unavailable. It does the work through a multi-turn LLM agent loop with tool use. It gets better through study sessions that produce knowledge entries, which are BM25-searched and injected into future task prompts.

The architectural decision worth pausing on is that the LLM never calls APIs directly. Every side effect flows through a tool that shells out to the mltl CLI or to npx agentcash. That boundary is what makes the agent auditable: the model can decide to quote a task, but the quote is executed by a process you can inspect, and the thirteen tools listed in the README are a closed set. Marketplace tools cover read_task, quote_task, decline_task, submit_work, send_message, list_bounties and claim_bounty. Utility tools cover check_wallet_balance, read_feedback_history, memory_search, log_activity. Two AgentCash tools handle paid API calls and the USDC balance behind them.

The loop itself is conventional and that is a compliment. Build a system prompt from agent identity, pricing rules, personality and learned knowledge. Inject the task as the first user message. Let the model respond with reasoning plus tool calls. Execute the tools, return the results, repeat until the model stops calling tools or hits the max-turns ceiling of 10. The task lifecycle maps onto that loop cleanly: requested leads to quote, decline or message; accepted leads to submit_work; revision leads to reading client feedback and resubmitting; completed leads to storing the rating and updating the knowledge base.

Getting it running without reading the source first

The install path is two global npm packages and one command. Install cashclaw-agent, install moltlaunch because CashClaw requires the mltl CLI, then run cashclaw. The process opens http://localhost:3777 with a setup wizard that walks four steps: wallet detection of your mltl wallet, which is auto-created on first run; onchain agent registration with name, description, skills and price; LLM connection for Anthropic, OpenAI or OpenRouter with a live test call; and configuration of pricing strategy, automation toggles and task limits.

The LLM adapters are worth noting because they avoid SDK dependencies entirely. All three providers go through raw fetch(). Anthropic hits api.anthropic.com/v1/messages with claude-sonnet-4-20250514 as the documented default. OpenAI hits api.openai.com/v1/chat/completions with gpt-4o. OpenRouter hits openrouter.ai/api/v1/chat/completions with openai/gpt-5.4. OpenAI and OpenRouter share an adapter that translates between Anthropic's native tool-use format and OpenAI's tool_calls format, which is the part most likely to break when a provider changes its schema.

Configuration state lives under ~/.cashclaw, with knowledge.json holding the memory entries. The dashboard at port 3777 serves JSON under /api/* and the React frontend as static files everywhere else. There is no separate backend to deploy and no database to provision, which is the main operational advantage of the single-process design.

The memory system is BM25 with a decay curve, not embeddings

Self-learning here means something narrower than the phrase usually implies. When idle, the agent runs study sessions on a default 30 minute interval, rotating through three topics. Feedback analysis looks for patterns in client ratings and runs only when feedback exists. Specialty research deepens expertise in configured specialties and always runs. Task simulation generates a realistic task and outlines an approach, also always. Each session writes a structured knowledge entry into ~/.cashclaw/knowledge.json.

Retrieval is lexical. An incoming task is tokenized, searched against knowledge and feedback entries with BM25+, scored with a temporal decay of score * e^(-lambda * ageDays) and a 30 day half-life, and the top five results are injected into the system prompt under a Relevant Context heading. The model can also call memory_search mid-task for active recall, which is useful when a task drifts away from its opening description.

Choosing BM25 over embeddings is a real trade-off and the README does not argue for it. The upside is that retrieval runs locally with no embedding API cost, no vector store, and no network dependency, and the results are inspectable because the match is on tokens you can read. The downside is vocabulary mismatch: a knowledge entry about React testing patterns will not surface for a task phrased around component verification, because BM25 scores term overlap rather than meaning. The temporal decay also means a genuinely useful insight from four months ago is scored at roughly one sixteenth of its original weight, which may be wrong for stable domain knowledge. The dashboard lets you expand, delete and inspect entries by source and topic tag, so the practical workflow is to prune bad entries rather than tune the ranker.

Where CashClaw is the wrong tool

The dependency on the mltl CLI is the constraint that shapes everything else. CashClaw cannot take work without it, and the README offers no hosted alternative. If mltl is unavailable, rate-limited, or changes its output format, the marketplace tools fail and the agent has nothing to do. Because every side effect shells out to a subprocess, latency per tool call is bounded by process startup, not by the API round trip.

The max-turns default of 10 is a second ceiling. A task that needs more than ten tool-use rounds will stop mid-flight rather than continue, and the README does not describe what happens to the task state when that occurs. Tasks requiring long autonomous chains, such as multi-file code generation with iterative testing, are poor fits at the default setting.

The economics are also unguarded in the documentation. quote_task submits a price in ETH, and the agent decides that price from pricing rules in the system prompt. Nothing in the material describes a floor, a maximum, or a confirmation step before a quote is submitted. An agent that quotes too low on a task it then spends many LLM turns on will lose money, and the loss is denominated in real ETH on Base. Similarly, agentcash_fetch makes paid API calls against a USDC balance, so a loop that repeatedly fetches paid data can drain that balance. The README treats both as configuration concerns rather than safety mechanisms.

Finally, this is an LLM-driven agent with write access to a wallet and a marketplace reputation. The prompt injection surface is the task description and the client messages, both of which flow into the model as untrusted text. The material does not describe any sanitization or allowlist for tool arguments.

What you would use instead, and why the difference matters

The obvious alternative is a general agent framework such as LangChain or the OpenAI Agents SDK, where you build the loop, the tool registry and the memory layer yourself and point them at whatever marketplace you like. The difference in approach is concrete. CashClaw ships the marketplace tool set, the mltl subprocess bridge, the BM25 memory file and the local dashboard as one opinionated package. A framework gives you the loop and nothing else, which means you write the thirteen tools, the persistence format and the retrieval strategy before the agent can earn anything. CashClaw is faster to first task and harder to repoint; a framework is the reverse.

A second comparison is a plain cron job calling an LLM API with a fixed prompt. That approach has no bidding logic, no rating feedback and no memory, but it also has no wallet, no subprocess bridge and no prompt injection surface from third-party task text. For a workflow where you control the inputs, the cron job is the lower-risk choice. CashClaw earns its complexity only when the inputs come from strangers and the price is negotiated per task.

The README's own suggestion, forking and wiring to Fiverr or your own clients, is the third path and probably the most honest one. It acknowledges that the marketplace integration is the replaceable part and the loop plus memory is the product.

Licence, maintenance cost and what to check before funding a wallet

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive enough to fork into a private product. It also means no warranty and no liability from the authors, which matters more than usual here because the process holds a wallet key and spends ETH and USDC. Nothing in the material describes how the key is stored or whether it is encrypted at rest, so treat ~/.cashclaw as a secret-bearing directory and check the file permissions yourself.

Maintenance cost is dominated by three moving surfaces. The mltl CLI is an external dependency you do not control, and any change to its commands or output breaks the marketplace tools. The three LLM providers are accessed through raw fetch() with hand-written adapters, so a provider schema change requires a code change rather than an SDK version bump. The OpenRouter default model is listed as openai/gpt-5.4, which is not a model identifier that matches the naming of the other two defaults; confirm the current identifier against OpenRouter's model list before relying on that row.

There are no retrieved releases, so the project appears to be tracked from the main branch. That means upgrade cost is whatever it costs to rebase your fork on main, and there is no changelog to read for breaking changes. Pin a commit if you deploy this against a funded wallet. The last push recorded is 2026-03-14.

Editorial conclusion

Adopt CashClaw if you already run the mltl CLI and want an agent that bids on Moltlaunch tasks with a visible audit trail on localhost:3777. Do not adopt it if you need offline operation, a hosted service, or a marketplace other than Moltlaunch without forking the tool layer yourself. Before you point it at real money, verify three things in this order: that your mltl wallet is funded on Base, that the LLM provider you chose answers the live test call in the setup wizard, and that the default max-turns value of 10 is enough for the task types you intend to accept.

Official sources

1. Issues
2. License: MIT
3. moltlaunch/cashclaw on GitHub
4. Project website
5. README