# MetaClaw: a proxy that turns live agent conversations into skills and LoRA updates > MetaClaw sits between your personal agent and any OpenAI-compatible LLM API, injects learned skills at each turn, and optionally trains LoRA weights on idle windows. Here is what the repository actually documents, and where it stops. **aiming-lab/MetaClaw** — 🦞 Just talk to your agent — it learns and EVOLVES 🧬. - Repository: https://github.com/aiming-lab/MetaClaw - Website: https://arxiv.org/abs/2603.17187 - Stars: 3,492 · Forks: 453 - Language: Python - License: MIT - Published: 2026-09-09 · Updated: 2026-09-09 · Language: en - Canonical page: https://hysenlabs.com/projects/aiming-lab-metaclaw ## The problem MetaClaw targets: an agent that forgets every session A personal agent wired to a hosted LLM starts each session from the same weights and the same empty context. Whatever it got right yesterday is gone today. Prompt-level workarounds exist, but they are manual: you paste preferences into a system prompt, you keep a notes file, you re-explain the project layout. MetaClaw's premise, per the README, is that the conversation itself should be the training signal, and that this should happen while the agent stays usable. The intended user is someone already running a personal agent, specifically one of the claws the README lists: OpenClaw, CoPaw, IronClaw, PicoClaw, ZeroClaw, NanoClaw, NemoClaw. The README also says any OpenAI-compatible client works. That second claim matters more than the first, because it means MetaClaw is not only a plugin for one agent; it is a proxy you can point arbitrary clients at. The pitch of no GPU cluster is the part that separates it from most continual-learning setups: the heavy training is delegated to a cloud backend rather than local hardware. ## How the proxy, skill injection and the meta-learning scheduler fit together The architecture described in the README is a request-path proxy with three decoupled stages. Your agent talks to MetaClaw instead of directly to the LLM API. MetaClaw intercepts each interaction, retrieves relevant skills, and injects them into the prompt before forwarding. Skills are summarized automatically after each session, so the injection set changes over time without you editing anything. Serving, reward modeling and training are described as fully decoupled, which is what lets the agent keep responding while scoring and training proceed. In rl mode the training algorithm is GRPO, and weight updates are LoRA updates run through a Tinker-compatible backend. The README names Tinker as the default reference path and says MinT and Weaver can be enabled through separate compatibility packages; the config key is rl.backend with values auto, tinker or mint. The auto mode adds a scheduler on top. Slow RL updates only run during sleep hours, idle time, or Google Calendar meetings. The release notes for v0.3 also mention support/query set separation, described as a way to prevent stale reward signals from polluting model updates. That detail is the most interesting design choice in the project: it acknowledges that a reward computed from an old interaction may no longer reflect current behavior, and splits the data accordingly. The README does not explain how the split is computed, which is a gap worth noting. Memory is a separate layer. v0.4.0 introduced the Contexture layer, which persists cross-session facts, preferences and project history and injects relevant context at each turn, with adaptive memory policy and background consolidation. v0.4.1 changed ingestion cadence: memory now extracts and persists turns every N turns, default 5, instead of only at session end. The release note frames this as shrinking the mid-session memory blackout window, which is an honest description of the trade-off being made. ## Installing MetaClaw and getting to a first skill-injected session The package is published as aiming-metaclaw and requires Python 3.10 or newer. Core dependencies are click, pyyaml, fastapi, uvicorn, httpx and tiktoken. Install the base package first; the RL, embedding, evolve, wandb and scheduler extras are separate and only needed if you use those paths. ```bash pip install aiming-metaclaw ``` That gives you the metaclaw console script, defined in pyproject.toml as metaclaw.cli:metaclaw. The README describes the flow as two commands. The first is a one-time configuration wizard. ```bash metaclaw setup ``` After the wizard writes your config, the README's default start command brings up the proxy, injects skills, and wires your chosen personal agent automatically. In auto mode this also enables the RL scheduler. ```bash metaclaw start ``` If you want to confirm skill injection works before touching any training backend, the README gives a mode for exactly that. skills_only proxies your LLM API, injects skills and summarizes them after each session, and the README states it requires no GPU and no Tinker. ```bash metaclaw start --mode skills_only ``` A third mode trains immediately when a batch is full rather than waiting for an idle window. ```bash metaclaw start --mode rl ``` The README does not document what the setup wizard asks, what file it writes, or what port the proxy binds. If you need those specifics before running it, read metaclaw/ in the repository rather than the README. The examples directory contains run_conversation_rl.py, run_conversation_opd.py, run_conversation_replay.py and train.jsonl, which are the closest thing to a worked example of the training paths. ## Where MetaClaw stops being the right tool The clearest limitation is the dependency structure. RL mode needs a Tinker-compatible cloud backend for LoRA training. That is the whole reason the project can claim no GPU cluster, and it is also a hard external dependency: if Tinker is unavailable to you, or you cannot send training data to a third party, rl and auto modes are off the table and you are left with skills_only. The README does not document any local training fallback. Second, the proxy is in the request path. Every agent turn goes through MetaClaw. The README does not document what happens when the proxy is down, whether requests fail open to the upstream API, or how to bypass it. For a personal agent that is an annoyance; for anything with an availability expectation it is a design constraint you should resolve before deploying. Third, the memory layer writes to memory_data/ at the repository root, and the README does not describe retention limits, deletion semantics, or what happens when that directory grows. The v0.4.1 change to persist every 5 turns by default means writes happen more often than before, so the growth question is more pressing, not less. Fourth, the scheduler's Google Calendar integration is an optional extra pulling google-api-python-client, google-auth-oauthlib and google-auth-httplib2. If you enable auto mode's calendar-aware scheduling, you are granting an agent-training system access to your calendar. The README does not discuss scoping that access. Finally, rollback. The README does not document how to revert a LoRA update that made the agent worse, nor how to pin to a previous adapter. For a system whose entire purpose is autonomous weight updates, that is a significant omission, and it is the thing I would want answered before enabling auto mode on anything I cared about. ## MetaClaw versus plain OpenClaw: proxy and learned skills against a static agent The natural comparison is OpenClaw itself, since MetaClaw ships as an OpenClaw plugin as of v0.3.3 and the README lists OpenClaw first among supported agents. The difference in approach is straightforward. OpenClaw is the agent; MetaClaw is a layer that intercepts its LLM traffic and changes what the model sees and, optionally, what the model is. Without MetaClaw, improving an OpenClaw agent means editing prompts, tools or configuration by hand, and the improvement is static until you edit again. With MetaClaw in skills_only mode, the injected skills are derived from accumulated sessions and summarized automatically, so the prompt context evolves without manual editing. That is a real behavioral difference and it needs no training infrastructure. The RL modes go further and change the weights, not just the prompt. That is the part with no equivalent in a stock agent, and it is also the part that brings the Tinker dependency, the scheduler, and the rollback question. If you only want the skill-injection behavior, skills_only is the mode that gives you the project's core idea with the smallest dependency surface. A second comparison worth drawing is against offline fine-tuning. The README contrasts MetaClaw with "offline training alone" and positions live deployment as the source of learning signal. That framing is the project's thesis; whether the live signal is cleaner than curated offline data is not something the README argues, and the support/query set separation in v0.3 suggests the maintainers are aware the live signal can be noisy. ## Maintenance cadence, licence and what upgrading costs you The last push to the default branch was on 2026-06-07. The repository is not archived, but the release history shows a burst of activity between March and April 2026: v0.2 on 2026-03-11, v0.3 on 2026-03-13, v0.3.1 the same day, v0.3.2 on 2026-03-16, v0.3.3 on 2026-03-23, v0.4.0 on 2026-03-25, and v0.4.1 on 2026-04-11. Since then the visible changelog is quiet. Treat the project as one that moved fast and then slowed, and check the commit history yourself if cadence matters to you. Upgrade cost is shaped by the extras. The base install is small, but rl pulls torch, transformers>=4.51.1 and tinker; embedding pulls numpy and sentence-transformers; evolve pulls openai; scheduler pulls the Google client libraries. A fresh install of metaclaw[all] is a large dependency tree, and torch in particular tends to pin your Python and CUDA situation. If you only use skills_only, you avoid nearly all of it. The licence is MIT, which is permissive and imposes no copyleft obligation on your own code. Note that MIT covers the MetaClaw code, not the Tinker service you send training data to, and not the LLM API you proxy. Those are separate agreements and the README does not discuss data handling for either. That is not a legal opinion; it is a pointer to the questions your own review should cover. ## Conclusion MetaClaw fits teams already running OpenClaw or another supported claw who want conversation-derived skills without owning GPUs, and who accept that RL mode depends on a Tinker-compatible cloud backend. It is the wrong choice if you need a documented rollback path, offline operation, or a single-process deployment without a proxy in the request path. Before adopting, verify the rl.backend value your config resolves to, run metaclaw start --mode skills_only once to confirm skill injection works without Tinker, and check whether memory_data/ is on a volume you back up. ## FAQ ### What is MetaClaw? MetaClaw is an agent layer that proxies your personal agent's LLM calls, injects learned skills at each turn, and optionally trains LoRA weights from accumulated conversations. It supports OpenClaw, CoPaw, IronClaw, PicoClaw, ZeroClaw, NanoClaw and NemoClaw, plus any OpenAI-compatible client. ### How does MetaClaw's meta-learning work? MetaClaw intercepts interactions through a proxy, injects relevant skills into each prompt, and summarizes skills after each session. With RL enabled, GRPO training produces LoRA updates through a Tinker-compatible backend, and the auto-mode scheduler defers those updates to sleep, idle or meeting windows. ### Does MetaClaw need a GPU? The README states no GPU cluster is required. Training runs through a Tinker-compatible cloud backend, and the skills_only mode requires neither a GPU nor Tinker at all. ## Sources - [aiming-lab/MetaClaw on GitHub](https://github.com/aiming-lab/MetaClaw) - [License: MIT](https://github.com/aiming-lab/MetaClaw/blob/main/LICENSE) - [Project website](https://arxiv.org/abs/2603.17187) - [README](https://github.com/aiming-lab/MetaClaw/blob/main/README.md) - [Releases](https://github.com/aiming-lab/MetaClaw/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aiming-lab-metaclaw