GenericAgent: 3,300 Lines of Code Challenging 530,000-Line Agent Frameworks
> "Counterintuitively, lower token consumption often corresponds to better task performance." > — GenericAgent paper
The Provocative Comparison
- OpenClaw: ~530,000 lines of code, hundreds of pre-built modules, multi-service orchestration, plugin ecosystem
- GenericAgent: ~3,300 lines of code, 9 atomic tools, a 100-line agent loop, installable via
pip install - Paper: arXiv:2604.17091 — *GenericAgent: A Token-Efficient Self-Evolving LLM Agent via Contextual Information Density Maximization*
- GitHub: https://github.com/lsdefine/GenericAgent
- BAAI Community coverage: https://hub.baai.ac.cn/view/54333
- 36Kr coverage: https://eu.36kr.com/zh/p/3786342762159107
- Zhihu technical analysis: https://zhuanlan.zhihu.com/p/2030939909826068572
Despite a 160x code gap, benchmarks cited show GenericAgent consuming 1/6 the tokens of OpenClaw on Lifelong AgentBench, and scoring 65% vs 35% accuracy on RealFin.
Core Thesis: Context Isn't Too Short, It's Too Diluted
> "Long-horizon performance is determined not by context length, but by how much decision-relevant information is maintained within a finite context budget."
The team's key observation: models' effective "hallucination-free" context length is roughly an order of magnitude smaller than the nominal window. GenericAgent therefore doesn't expand context — it compresses it, capping the window at 30K tokens while maximizing per-token decision relevance.
Four-Component Architecture
1. Minimal Atomic Toolset (9 tools)
| Tool | Function |
|---|---|
| code_run | Run arbitrary code |
| file_read / file_write / file_patch | File operations |
| web_scan | Perceive web content |
| web_execute_js | Control the browser |
| ask_user | Human confirmation |
| update_working_checkpoint | Update working memory |
| start_long_term_update | Trigger long-term memory updates |
No dedicated upload/download/API tools — anything else is done dynamically via code_run. The toolset is open: basic building blocks, not pre-baked capabilities.
2. Layered On-Demand Memory (L0–L4)
| Layer | Content | Loading | |---|---|---| | L0 — Meta Rules | Core behavior rules | Always present | | L1 — Insight Index | Minimal routing index | High-level overview by default | | L2 — Global Facts | Stable accumulated knowledge | On-demand retrieval | | L3 — Task Skills / SOPs | Reusable workflows | Loaded on task match | | L4 — Session Archive | Archived completed tasks | On long-range recall |
L1 acts as a table of contents, not content. Concrete L2–L4 material enters the context only when explicitly requested, avoiding the noise of stuffing all memory into the prompt. Notably, GenericAgent requires no embedding models or vector databases.
3. Four-Stage Context Compression (near the 30K cap)
1. Tool-output truncation: code_run and web_scan outputs capped at ~10,000 characters (keep first/last halves, ellipsis in between).
2. Tag-level compression (~every 5 turns): repeated working-memory blocks replaced with placeholders; reasoning/tool tags truncated to ~800-character head/tail windows. The last 10 messages are exempt, hitting the prompt cache ~80% of the time.
3. Message eviction: FIFO removal of oldest messages after stricter re-compression, until under 60% of budget.
4. Working-memory anchors: after every tool call, a one-line summary of the last 20 turns, current turn number, and an agent-maintained key_info block are attached — the sole long-term memory source after eviction.
Compression here is refinement, not deletion: raw tool output may be 90% irrelevant (HTML, CSS, duplicate logs).
4. Self-Evolution (Growing a Skill Tree)
New tasks are autonomously explored (install dependencies → write script → debug), then solidified into a reusable Skill. The agent maintains a persistent skill tree scored on breadth, depth, utility, and innovation — and can assign itself tasks, shifting from user-driven to self-driven operation.
Benchmark Data
Lifelong AgentBench
| Agent | Input Tokens | Completion | |---|---|---| | GenericAgent (Sonnet 4.6) | 222K | 100% | | Claude Code | 800K | 100% | | OpenClaw | 1.43M | — |
RealFin Benchmark
GenericAgent 65% > Claude Code (Opus) 60% = Codex 60% > Claude Code (Sonnet) 55% > OpenClaw 35%.
Long-Horizon Tasks (avg of 5)
Both GenericAgent and Claude Code hit 100% success, but GenericAgent used 35.1% of the tokens (2.8x gap), 11.0 vs 32.6 requests (3x), and 12.8 vs 22.6 tool calls (1.8x).
Memory Ablation (SOP-Bench dangerous_goods)
| Memory Mode | Success Rate | Memory Size | |---|---|---| | No-Memory | 13.87% | 0 | | Full-Memory | 52.44% | 575 tokens | | Condensed Memory | 66.48% | 165 tokens | | Redundant-Memory | 66.48% | 288 tokens |
Memory density matters more than quantity.
LoCoMo Long-Term Factual Memory
Multi-hop F1: GenericAgent 43.33 > Mem0 (39.32) > A-MEM (29.03) — without any vector database.
The Striking Number: "Hello" Prompt Size
With the same 20 skills loaded:
| Agent | Prompt Length | |---|---| | GenericAgent | 2,298 tokens | | Claude Code | 22,821 tokens | | Codex | 23,932 tokens | | OpenClaw | 43,321 tokens |
Everyday interaction cost is 1/10 to 1/20 of competitors.
Critical Analysis: Magic or Subtraction?
The 160x gap needs unpacking. OpenClaw's 530K lines cover multi-service orchestration, plugin ecosystem, error handling, multi-agent delegation, web UI, OAuth, payments, and cross-platform apps. GenericAgent omits all of these. OpenClaw is a platform; GenericAgent is a runtime. As the article puts it: comparing them is like comparing a bicycle to a high-speed train — the question is which your scenario needs.
Bootstrapping claims have boundaries. The repo claims every commit was made autonomously by GenericAgent with no human terminal use. True — but for a simple local Python project with no external API integration or multi-service coordination.
Trade-offs of "no preset skills": first-time use of any capability is slow (e.g., first Gmail send requires OAuth setup and scripting), an upfront investment for later compound returns. Skill-tree bloat, deduplication, and conflict resolution are not yet addressed in the paper.
The 30K assumption is empirical and may bottleneck document-heavy tasks; the 100% completion rates come from process-oriented benchmarks, with no data on open-ended creative work.
Design Philosophy
1. Information density > context length: a dense 30K window can beat a diluted 200K one.
2. On-demand loading > full retrieval: L1 routing lets the agent pre-filter what enters context, avoiding RAG noise.
3. Self-evolution > preset ecosystems: slower first use, zero dead weight afterward.
4. CLI as native interface: subagents are os.system() processes, reflection is a cron job — a return to Unix philosophy.
Comparison Table
| Dimension | GenericAgent | OpenClaw | Claude Code | |---|---|---|---| | Code size | ~3,300 lines | ~530,000 lines | Large (undisclosed) | | Architecture | Single-machine CLI | Multi-service distributed | CLI + subscription | | Memory | L0–L4 layered, on-demand | Vector DB + long-term memory | Stateless across sessions | | Self-evolution | Grows its own skill tree | Plugin ecosystem | None | | Token efficiency | 30K window, density-maximized | 200K–1M window | Large window | | Best for | Personal automation, local tasks | Teams, multi-platform | Coding tasks |
Conclusion
GenericAgent did not do everything OpenClaw does — it did a subset, extremely efficiently. Its three core insights:
1. Context length is an illusion; information density is real. 2. Memory should be indexed on demand, not fully loaded. 3. Capabilities should grow, not be pre-installed.
As the article's Feynman-style framing concludes: the real contribution is a redefinition of the problem — from "how do we make the agent remember more" to "how do we make it remember only what matters most." But knowing a tool's boundaries matters as much as knowing its capabilities: this is a bicycle, not a train.